Customer: "Hoi ik heb een vraag, ik ben niet zo blij met het volgende: ik heb dinsdag *product* gekocht voor 64 euro en op de website is exact de zelfde set 50 euro."
Employee: "Goedemiddag! Bedankt voor je bericht. Ik kan me voorstellen dat dat erg vervelend is, ik wil er dan ook graag naar kijken. Kun je mij vertellen om welk specifieke *product* het gaat? Alvast bedankt!"
Customer: "Ik kan u even een foto van de bon sturen." Employee: "Ja graag, dan ga ik naar kijken."
Customer: *sends picture*
Employee: "Hartstikke bedankt voor het toesturen van de gegevens! Ik zie inderdaad dat de prijs van deze *product* op *date* verlaagd is. Wij hanteren geen vaste prijzen voor onze artikelen, deze kunnen dus op ieder moment omhoog of juist omlaag gaan. Omdat ik helemaal begrijp dat je van dit prijsverschil niet zo blij werd, wil ik je graag een cadeaukaart sturen van euro. Zou je mij je adresgegevens + je e-mailadres willen sturen?"
Customer: "Okay op die manier. Dan is wel mijn vraag, kan het verschil ook teruggestort worden?. Fijn dat jullie iig oplossingsgericht denken! Complimenten."
Employee: "Fijn dat je dit op prijs stelt! Dat horen wij graag. Het verschil kan niet worden teruggestort, dit omdat zoals mijn collega al heeft aangegeven wij geen vaste prijzen hanteren en deze kunnen op ieder moment omhoog of omlaag gaan."
Customer: "Dan heb ik nog een andere vraag kunt u anders nagaan of deze *product* nog ergens is?"
Employee: "Ik kan je adviseren om op internet nog eens te zoeken ik zie namelijk wel dat de *product* tevoorschijn komt."
Customer: "Oke dat is goed dan ontvang ik graag de cadeaubon van 15 euro."
Employee: "Ik wil dit graag voor je regelen, mag ik nog je adresgegevens en je e-mailadres plus je achternaam ontvangen?"
Customer: "Ja mijn adres is *address* en mijn e-mail is *e-mail*."
Employee: "Bedankt voor je gegevens! Je zal halverwege volgende week de cadeaukaart in je brievenbus gaan vinden. Ik wens je er alvast veel plezier van!"
Appendix F
DS developer use cases
Build RuDS
Context of use
The DS developer has collected conversational data, analysed the data, designed the behaviour for a RuDS based on the analysis, and has built rules, expressions, actions and examples based on the DS designs. Now, the DS developer wants to use OBI4wan’s RuDSDev to input the data and start training and deploying the RuDS. Scope System (DS development, training, and deployment)
preconditions Rules and expressions have been written, data has been collected, access to the system has been granted, the DS developer has the right privileges to build RuDSs.
Success
postcondition A RuDS has been developed, trained, and deployed. Failed
postcondition
The DS developer is unable to build a RuDS on the platform or unable to deploy it after it was created.
Primary Actor DS developer
Trigger The DS developer wants to build and deploy a RuDS he / she has designed.
Main success scenario
The DS developer logs in to the RuDSDev using his / her user-name and password. (2) The DS developer creates an untrained RuDS and the system stores it on the system database. (3) The DS developer adds examples, expressions, and rules to the untrained RuDS, which are stored in the database by the system. (4) The DS developer trains the RuDS and the system uses all the information (e.g. rules and expressions) provided by the developer to train the RuDS. (5) The DS developer clicks the deploy button and the system re-trains the RuDS again and adds it as deployed to the database. RuDSs need to be trained before employment to ensure the NLU model is updated.
Exceptions / Alternatives
The DS developer can not log-in or use other services of the RuDSDev because the service has down-time.
Normally the DS developer has to build every aspect of a RuDS from scratch, but there is also an option to import an existing RuDS and edit the imported version instead. Before deploying a RuDS it has to be trained, so deployment will fail if this condition is not met beforehand.
Edit RuDS
Context of use
DS developers can edit, add, and remove content (e.g. rules, expressions and examples) of RuDSs via the OBI4wan’s platform. Rules, expressions, example data etc. of any RuDS can be edited if a user has permission to access or select the RuDS. Editing of RuDSs generally takes place when a DS developer wants to remove data that has become irrelevant or wants to add new rules.
Scope System (DS development and editing)
preconditions The DS developer has access to a previously developed RuDS, the DS developer has the right privileges to edit RuDSs.
Success
postcondition Some aspects of a selected RuDS has been changed / edited. Failed
postcondition The intended edits / changes were not applied. Primary Actor DS developer
Trigger Some aspect of a RuDS needs to be changed.
Main success scenario
(1) The DS developer logs in to the RuDSDev using his / her user-name and password. (2) The DS developer selects the RuDS which needs to be edited / changed. (3) The DS developer selects which aspect of the RuDS should be edited (e.g. rules or example data). (4) The DS developer performs a change to the selected content by performing an add, remove or edit action. (5) The DS developer saves / applies the new changes and the system confirms if the changes were saved in the database.
Exceptions / Alternatives
After applying an edit, the DS developer has to train the edited RuDS before it can be deployed. Multiple aspects of a RuDS can be changed before performing a training operation.
When no RuDSs are available the DS developer can not perform any editing actions and thus has to build or import a RuDS before they can start editing.
The DS developer needs to input RuDS content in the right format, otherwise the edit will be rejected.
Monitor RuDS
Context of use
The DS developer has build and possibly deployed a RuDS on a certain platform. The developer now wants to monitor how the RuDS has been performing and what kind conversations the RuDS has been a part of by using OBI4wan’s system. They can navigate the UI to find a dashboard that contains visualisations of conversation session information for a particular DS
Scope System (DS monitoring)
preconditions The DS developer has access to a previously developed RuDS, the DS developer has the right privileges to monitor RuDSs.
Success postcondition
The DS developer has successfully navigated to a particular RuDS and can successfully access all information and visualisations regarding the selected RuDS. Failed
postcondition The DS developer is unable to access the RuDS or its information. Primary Actor DS developer
Trigger The DS developer wants to gain information about RuDS session history, performance, rule-base, or other RuDS related information available via the system.
Main success scenario
(1) The DS developer logs in to the RuDSDev using his / her user-name and password. (2) The DS developer selects the RuDS that he / she wants information from or wants to monitor. (3) The DS developer selects the right topic (e.g. rules or session
visualisation) that he / she wants to access. (4) The DS developer views the information or visualisations that they just navigated to.
Exceptions / Alternatives
The DS developer can not log in or use other services of the RuDSDev because the service has down-time.
When no RuDSs are available the DS developer can develop a RuDS and then access the information regarding the developed RuDS.
If the RuDS has no session data, rules or other input, there will be nothing to monitor. The DS developer can export a RuDS’s JSON to view rules, expressions and examples outside of OBI4wan’s RuDSDev.