A ticket booking can be completed if and only if:
The user has expressed the intention of booking a train ticket that will be covered by the
The user has provided the following attributes:
origin: the train station the user is travelling from
destination: the train station the user is travelling to
departure_datetime: the datetime at which the user wants to leave
Now let's get started and create this Train booking application that contains a
BookTrainTicket intent. You can refer this article if you want to learn more about intent creation in the console.
In dialogue management, filling such a contract is called frame-based dialog management - the dialogue is successful when the contract is fulfilled, in the same way a web form can be validate once all required fields are specified. Despite the simplicity of the contract in our case, covering all interaction scenarios is actually trickier that it seems in the context of voice interfaces.
In most cases, only a subset of the required attributes will be provided with the initial user intention. In certain cases such as "Book me a train ticket", none of the required attributes is actually specified. You'll therefore have to support multi-turn conversations to elicit the missing slots.
The user can be collaborative (or not) and the interaction flow should account for such cases. Slot-by-slot elicitation is often not satisfactory from a user experience standpoint. Let's consider the following interaction flow:
- User: Book me a train ticket- Assistant: Sure, where will you be leaving from ?- User: Going from San Diego to L.A- Assitant: Leaving San Diego, got it. Where are you heading ?- User: Already told you, I'm going to L.A- Assistant: When will you be leaving ?- User: Tomorrow at 5
Despite the fact that the contract is fulfilled, the user would have expected the assistant to be more collaborative in the sense that it could have detected both the
origin and the
destination slots from the user second turn.
For an action involving payment such as ticket booking, the user also expects to be asked for confirmation before the payment is made, hence the need for more interaction turns between the assistant and the user.
At any time, the user should be able to leave the conversation, either by not answering a specific question or by simply mentioning that the current interaction should stop.
Enabled by default
Intent and Slots
In order to cover for elicitation in a collaborative way, confirmation and early termination, we're creating dedicated intents. It is important to note that none of these intents should be enabled by default.
The interaction flow chart is provided below and showcases how intents are used depending on the state of the dialogue.
Sounds fairly complicated no ? The good news is that the Dialogue API allows us to implement such a flow using the
hermes/dialogueManager/continueSession message (see the reference here and related tutorial), and the