# A Pattern Library for Conversation by Joseph Tyler, Maaike Coppens and Ronald Ashri ![](/files/LB1jeznrJlhCpkusZs2W) Patterns help us make sense of the world. They identify and describe where there is regularity in a design. They make the design process and the outcomes more predictable. Patterns help us scale our thinking about a complex system through categorisation and encapsulation of complex behaviour under a simplified label. Patterns provide shared understanding between a team from design to development and deployment. This library was created to make your life, as a conversation designer, easier and your conversational applications better. It collects insights about the nature of conversation, distills them into their most useful essence, and describes them through conversational patterns to make conversation design simpler and more robust. ## Why a Pattern Library for Conversation Design? ### Conversation is systematic Conversations between humans show immense variation, but within all that variation there are consistent patterns. People have studied these patterns: scholars of sociology, linguistics, anthropology and many other disciplines have studied the patterns of everyday talk under the banner of conversation analysis, discourse analysis, interactional sociolinguistics, and other terms. These patterns have been recorded, analysed and documented, showing the systematicity of everyday conversational interaction. Being able to carry on a conversation involves the competent use of these conversational patterns. > **The process of building a conversational application to carry on a conversation can be facilitated by understanding and using those patterns.** Most people don’t think about the details of everyday conversation while talking. We don’t deliberate on every word choice, the details of timing, how to transition between topics, or how to wrap up a conversation. We communicate everyday and generally the mechanics of conversation feel second-nature. But bots don’t know any of these things without being explicitly trained, and conversation designers need to know what to tell the bot to do. We can make the conversation design process easier AND more robust by collecting the many conversational patterns in everyday talk into a library. ### Patterns capture conversation’s systematicity For our purposes, a conversational pattern is a sequence of conversational actions that can generalise beyond a single instance. As an example, a single conversation may start with each person saying “Hello”. That is, one conversational pattern is the conversation opening, which features each participant giving a greeting. Using the label “greeting” is a way of abstracting away from specific word choice to the social action (a greeting). Having a greeting-greeting conversation opening pattern means that a single pattern can be realised in thousands of ways, for example: `A: Hello` `B: Hello` Less formally: `A: Howdy` `B: Yo` More formally: `A: Greetings` `B: Good day` In other languages: `A: Bonjour` `B: Bonjour` The pattern exists independent of specific words. For conversation design, this means you can build a conversation structure one time but realise that structure in infinitely different ways. Patterns offer the structural strength for generalisability. ### Patterns can help conversation designers Now that we have established the patterned nature of human conversation, we can leverage this knowledge to make it easier to do conversation design. You are not starting from scratch! With a library of standard patterns, pre-built components, fleshed out to meet the common ways those patterns are used in everyday conversation, your design process can be more efficient, since you do not have to rebuild these patterns each time. Your designs also end up more robust, since you are less likely to leave out key components. The library of patterns is here to make it fast and easy to include a breadth of conversational competence. You’re not starting from zero. You’re starting with the basics already there. ## OpenDialog wins with patterns This library is useful for any conversation design working on any platform. It is especially useful if you are on the [OpenDialog](https://opendialog.ai) platform! OpenDialog is a pattern-centric framework, able to leverage patterns for robust conversation design. With its context-forward design philosophy, the patterns can be leveraged smoothly for nearly any design. ## Resources and Links * Christopher Alexander * [A Pattern Language](https://www.amazon.com/Pattern-Language-Buildings-Construction-Environmental/dp/0195019199) * [The Timeless Way of Building](https://www.amazon.com/gp/product/0195024028/ref=dbs_a_def_rwt_bibl_vppi_i2) * [A City is Not a Tree](https://www.amazon.com/City-Not-Tree-50th-Anniversary/dp/0989346978) * Software Engineering * [Design Patterns: Elements of Reusable Object-Oriented Software](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612) * Conversation Design * [Conversational UX Design: A Practitioner's Guide to the Natural Conversation Framework](http://www.morganclaypoolpublishers.com/catalog_Orig/product_info.php?products_id=1414) # A "Read Me" for this Library ### Who It Is For This library is for anyone working to make automated conversations, whether they call themselves a “conversation designer” or something else. In addition, anyone in the halo of the conversation design process (product managers, marketers, engineers) can benefit from understanding the patterning described below. ### How It Is Structured This library contains a set of conversational patterns to help you when building a conversational experience. Some of these are standard across all types of conversational interactions, e.g. openings, closings, and repair. Others are more useful in certain use cases or domains, e.g. information collection, providing recommendations, handling transfers, and user authentication. The goal of this document is to provide an overview of these common patterns, some examples, and templates that you can use yourself. Before listing patterns, it is useful to describe a taxonomy of pattern types. These types will help you know what patterns you are dealing with, and how they relate to each other. Drawing inspiration from [Moore and Arar](https://www.morganclaypoolpublishers.com/catalog_Orig/product_info.php?products_id=1414) (2018, p77), some conversational patterns are about saying things and others are about managing the interaction. Each of these patterns can then have their own subtypes. This library is not an exhaustive list of all patterns. #### ***Saying things*** *Conversational activities*, i.e. saying things, are about what can get done in a conversation. A simple example is a question-answer sequence, where either the bot or the user asks a question, and the other answers. These question-answer pairs can be in long sequences as well, which in aggregate become larger genres like quizzes or user information collection. If thought about more generally, the question-answer pair involves an initiation (question) and a response (answer). There are other ways of initiating than with a question, e.g. with a request, a suggestion, an instruction, among others. Each initiation can then be followed by the other’s response, e.g. a granting of a request: A: Please turn off the lights. B: Sure thing <\> While initiation-response pairs involve a lot of back and forth, another common conversational activity involves one participant speaking for an extended period, e.g. storytelling. In storytelling, the patterns change, such that the speaker holds the floor for a while. The listener gives backchannels to encourage continuing (or doesn’t and interrupts the story). At some point, the story ends and the conversation moves on to the next thing. This extended telling could be useful not just for storytelling but for any extended turn, e.g. giving an educational training talk, doing a how-to explanation, or leading a guided meditation. #### ***Managing the interaction*** In everyday talk between humans, much of the time spent conversing is spent managing the interaction itself, either the immediate sequence or the conversation as a whole. A common sequence management pattern is repair, where the participants work to resolve some misunderstanding or misstep. Repair itself can be managed in many ways, but the overarching purpose is to fix some bump in the road. A simple example is when the user doesn’t hear what the bot said and asks it to repeat. Another is when the user doesn’t know what a word or acronym means and asks the bot to explain. In addition to managing or negotiating sequences within the conversation, the participants also need to manage the conversation as a whole. This includes how the conversation starts (the opening), how it ends (the closing), and meta-discussion about what the bot can do (capabilities). While the conversation’s openings and closings can be more involved, sections of the conversation also have openings and closings. Of particular interest is sequence closing moves that indicate a particular section of the conversation is complete. #### ***Compositionality: combining patterns*** Building conversations from patterns instead of from atomic units can help facilitate and motivate more complex designs. The patterns of conversation are powerful also for how they work together to compose larger structures of talk. In fact, conversation design itself is a compositional process. The concept of *compositionality* is central to much of linguistics, where one challenge is to explain how a finite number of words can generate an infinite number of sentences. The magic to that generative power is in compositionality, i.e. how the units of language can be combined and recombined in ever-expanding and recursive ways to support limitless possibilities. The subfield of *compositional semantics*, for example, explores how the semantic meaning of a sentence is determined by the parts of the sentence and how they combine together. “The principle of compositionality is the principle that the meaning of a complex expression is determined by the meanings of its constituent expressions and the rules used to combine them.” (Wikipedia) The goal of the library is to facilitate the composition process. In addition, composed patterns could themselves be reused, taking the reusability even further. For example, a post-purchase retail module could include patterns like asking for contact info, upselling, and closing. A new conversation design could adopt the whole module, not just the patterns themselves. ### How to Use It Current state: a conversation designer writes sample dialogues, looks at project requirements, sketches out an initial build. In the process, they are likely to confront some of the same challenges that others have. They may crib portions from previous work they have done, but often the entire experience needs to be built from scratch. With this pattern library, you can “stand on the shoulders of giants,” taking advantage of the patterns that others have analysed and documented, and quickly incorporate them into your designs. You may design the overall component structure of the interaction, but can then leverage the patterns to flesh them out. The library is here to help you put meat on those bones. One way to use this library is for ideas. You can read through the different types of patterns and common subtypes, and then use that in your brainstorming. In this sense, it can operate as an educational resource, and it may be useful to read through all the patterns. Another way to use it is to go straight to a pattern that is important for you at a particular moment. Perhaps you are designing a welcome sequence and want to know what commonly occurs during a conversation opening. In this case, you could jump straight to the Opening pattern, get ideas for what commonly occurs there, and move forward on that part of your design. A third way to use this library is as a source of pre-built templates within the OpenDialog ecosystem. As part of explaining the patterns, we show how they could be implemented with OpenDialog. This helps see a demo of that pattern in action. It also means the building process is already complete. Simply clone the template to use it, or dig inside to see how it was done. # About this Library The information contained here comes from academic research, books, blog posts and other web information, product documentation, live products, and personal experience. You are getting a distillation of this diversity of sources into meaningful pieces. The goal is to create a pattern language for conversational AI, one that captures central features of conversation, organises it into easy to digest pieces, and facilitates leveraging the patterns for quality conversation design. What was it like making this document? Much of the academic literature is relevant, but tangentially. The public documentation and blog posts come with insight into the interface, but also motivated by the author’s and company’s needs. This is not an easy project. It’s also not a project that is ever really done in the same way that language and conversation never really stops changing. But within that forest of variability, we hope to have captured the pieces that can guide us. The idea of a pattern language can be traced back to the architect, design-theorist, and professor at UC Berkeley, Christopher Alexander. In multiple books and essays, Alexander laid out his vision for what ails modern urban design, and how a pattern language could address some of those concerns. Simply, many designed spaces have a top-down sterility to them, because they impose a structure that does not reflect the vitality and energy of lived-in spaces. To capture that realness, Alexander wanted to observer how spaces evolve in living human ecosystems and what systematicity is inherent there. He captured this systematicity in a book named A Pattern Language. This pattern language approach was later extended to software engineering and object-oriented programming in the book Design Patterns by Gamma et al. The book described common ways that software engineering gets done, collects those into a library of types, and presents them for others’ benefit. More recently, Moore and Arar, in the book Conversational UX Design, move towards doing this within the space of designing conversations with bots. Their proposed framework is inspired largely by the academic literature of the field of Conversation Analysis, and implemented within IBM. This document elaborates on the mission of these prior efforts, focused on conversational AI, drawn from many sources, and focused on important patterns for the design of conversational experiences. It can help you see more, and achieve more more easily. # Openings (Inge updated this) Conversation openings are a standard way of starting a conversation. This section and the next pages describe the parts of an opening and examples of openings. In the OpenDialog platform, the opening is implemented in the Welcome conversation. ## Openings are important Every aspect of conversation design is important and the overall goal is to provide an engaging and intuitive user experience. The opening however, is particularly important for a number of reasons: * User's familiarity with the virtual assistant as a channel to communicate with a brand. Many users have used chatbots in the past; according to one source () 88% of respondents had at least one conversation with a chatbot in 2022. While that is encouraging, it doesn't mean that all users are familiar enough with assistants to feel entirely comfortable with them. Think about how comfortable many users now are with websites and mobile apps. That wasn't always the case however. Most users are only just starting to become comfortable with virtual assistants * User's perception of virtual assistants and willingness to use them has been improving. (need reference). However, many users have had poor experiences with conversational assistants and may be hesitant to use them, instead favoring other channels * The opening is the start of the conversation, and sets the tone for the interaction. As such, there is a lot of focus on getting this part right. There is a visual aspect to text-based interactions that matters, but the language and dialogue itself are critical, along with the personality and tone The first impression a user has goes a long way towards their acceptance and continued use, throughout the single session and influencing their willingness for future interactions. ## Transactional versus relational mode When someone is in a **transactional mode**, they are motivated to get to the actual transactional need quickly. As a result, they may skip parts of a common opening sequence to jump right into the first topic. Here is an example of a bot in transactional mode: `< user launches bot on a retail website >` `Bot`*`: Welcome! Here's what I can help you with: order status, store hours, and a shopping assistant.`* In this example, the conversation opens with a short greeting, and the assistant then jumps straight to offering help, i.e. the transactional need. For contrast, some bots (and people in general) prioritize relational work in openings, operating in a **relational mode**. Here is an example of a bot in relational mode, taken from the mental health app Woebot: `< user launches bot in the mental health app Woebot >` *`Bot: Hi, I’m Woebot`* [*`👋`*](https://emojipedia.org/emoji/%F0%9F%91%8B/) `What should I call you?` `User: Joseph` *`Bot: I’m excited to get to know you, Joseph!`* *`Bot: While you might not be feeling your best lately…`* *`Bot: I wanted you to know I have the tools to help you feel better. We can work on this together.`* Here, the conversation opens with a greeting (“Hi”), a self-identification (“I’m Woebot”), a wave (“[👋](https://emojipedia.org/emoji/%F0%9F%91%8B/) “), and a name request (“What should I call you?”). After giving a name (“Joseph”), the bot expresses enthusiasm for building the relationship, empathy for the user’s emotional state, background on the bot’s abilities (“tools to help you feel better”), and an emphasis on the collaborative nature of the work (“We can work on this together”). Woebot is doing conversational work to establish a relationship between the user and the character. This relationship is central to the mission of Woebot, using mental health tools in the context of a therapeutic relationship to improve the user’s well-being. This conversation opening in relational mode reflects much of what happens in human-human conversation openings. Identification of the participants in the conversation is common in openings, saying who each person is, including their name, role, affiliation or more. In short, relational mode is the full conversational experience; transactional mode is an expedited form that skips some of the relational work to jump straight to the task. ## Considerations for openings To understand conversation openings then, it’s key to determine to what extent they need to be included, if at all. If the context suggests a transactional mode, the opening can be greatly reduced, or (perhaps) skipped. Skipping the opening is a way of establishing transactional mode (p457, [Dempsey](https://crl.acrl.org/index.php/crl/article/view/16525) “Are You a Computer?”). Behaving this way could be seen as rude or as efficient, depending on circumstances. It generally suggests that you don’t expect to see each other again. Such a transactional interaction is a way of avoiding a full conversation. A conversation partner may respond to a transaction bid by accepting the transactional mode and simply answering the transaction request. On the other hand, you may want to shift the mode to a relational one, redefining the relationship. This can be done by adding in more opening items, or by being more verbose in the opening items. A transactional bot may choose to add more relational components. However, one must consider the audience and their appetite for a possible switch; as much as a purely transactional approach may seem rude, a switch to a relational approach may seem cumbersome and as getting in the way of completing the task. It is important to get user feedback on the opening prompt to maintain the balance between a transitional versus a relational approach. This will be different for each assistant, task, and brand. Transactional versus relational mode sounds like a binary, but it’s actually more of a continuum. The more relational work you do in an opening, the more you are in relational mode. Do you have greetings, identifications, background and footing, and how-are-you’s? More relational. Do you have a greeting only? Less relational. Do you start with the first topic, the reason-for-the-call? Least relational, i.e. transactional. ## User-initiated versus assistant-initiated Conversations could be triggered by either a user action or by the bot itself. If a user launches a web page, they may not be aware there is a bot waiting for them. In this case, the bot may initiate the conversation by launching a chat window. Bot-initiated conversations could also come from notifications or contextual triggers (e.g. “it’s time to do your daily check-in”). In many cases, however, the user will be the one initiating the conversation. In this case, the user could start with relational moves like greetings (“Hi!”), well-wishing, and so on. The user may also jump straight to the transactional need, much like talking to Alexa or Google Assistant to e.g. set an alarm. No need to say hello, just say “Alexa, set an alarm for 6pm”. If the user starts in relational mode, using greetings and identifications, the bot can match that. If the user starts in transactional mode, e.g. asking “what’s my account number”, the bot can simply complete the transaction, e.g. answering the questions. ### User info: new versus returning versus frequent (and beyond) Conversation openings also vary depending on the history between the user and the bot. A conversation is likely to open differently if it is the first time the user has ever talked to the bot (a new user) versus if the user has talked to the bot before (a returning user). At a simple level, the conversation opening can make reference to the shared context, e.g. the user’s name, previous activities, user preferences, and more. For example, it can be useful to follow up with the user about a previous interaction, or welcome them back. The contextual intelligence (how long it’s been since they last talked) can help build the relationship and establish the bot’s credibility. A simple contrast between new and returning users still glosses over a huge amount of variation in how the conversation might open (cf. Maaike Coppens). A returning user that talked to the bot once before has different conversational expectations than a returning user who has been talking to the bot daily for months. The depth of context between bot and user affects the opening, and that depth can grow along a continuum of complexity. There may be a lot of variation in how much you know about individual users. Some users may be pretty unknown, while you may have a lot of information about others. This user information could come from a long user history (i.e. a returning user), but it also could be supplied via an API, from a separate registration process, from contextual information like geolocation, and more. You may know a lot about a new user because the info is passed along, and you may know little about a returning user because the data isn’t saved! That said, having a user’s name, their preferences, their purchase history, their conversational style, and more can all affect how to open a conversation. ### The End of the Opening The end of the opening occurs when the conversation moves on to the first topic. In telephone conversations, this is called the reason-for-the-call, the time when the participants get down to business. Shifting from preliminaries to the first topic is the marker that the conversation has moved from the opening to the body of the conversation. # Anatomy of an opening The specifics of what is included in an opening depends on the context, the mode, the users, the channel and other factors. Much of the academic research on conversational openings comes from telephone conversations, which may or may not fit your use case well. What are the common patterns we see in openings? ### Summons/answer Summons (aka trigger)/answer (ring → hello?; knock knock → come in) This establishes the availability of both parties for a conversation. Completion of SA creates non-terminality, i.e. the interaction is expected to continue. This seems to be what popup chatbots often leverage to create/coerce engagement, i.e. it feels awkward to leave a popup bot hanging so people may be more likely to engage with it (either responding or closing). ### Greetings `A: Hello`\ `B: Hello` ### Identification/recognition Caller ID or other ways of already knowing who’s there can modify this. * Name sharing, name request, name giving, name correction * Establish footing, roles for each participant * Organizational affiliation (“I’m Tom, your Lowe’s bot”) ### Welfare check How-are-you sequences. These can vary substantially across cultures. ### News check What’s new? ### Authentication * (“What is your account number?”); many designs include this as a required part of an opening sequence, but it is a worse experience to require a user to authenticate when their reason for being there doesn’t actually need authentication. As a result, the authentication process will be treated as its own pattern (see below). – separated into a distinct OpenDialog pattern These patterns are informed by human-human conversational patterns, however some might not be directly transferable to bot-human conversations. It therefore makes sense to take a user-centred approach and handle these patterns should a user invoke them. The app, however, likely should not invoke them on its own (unless contextually relevant). # Examples of transactional openings for text-based assistants (Inge added this WIP) The linguistic analysis in the previous pages suggests a number of aspects for an opening. On this page, we will take that information as input, craft a list specific to virtual assistants, and more specifically focus on transactional openings. Typical items in an opening are: 1. **Greeting,** e.g. "Hello", "Welcome" 2. **Self-identification,** the assistant introduces themselves, e.g. "I am Leo, your Lowe's automated assistant." 3. **What the assistant can do** for the user, e.g. "Here's what I can help you with". The options appear as buttons. In general, it is advisable to provide a list of items the assistant can help with rather than providing an open-ended "How may I help you" which may lead to user responses that the assistant is not equipped to handle 4. **Instructions on how to interact** with the assistant, e.g. "Type "menu" if you need to start over." 5. **Consent**, if applicable, such as consent to a Privacy Statement, Terms of Use or consent to use personal information, e.g. in health care 6. **Authentication**, if applicable, to determine whether a user is a returning or new user. This can be used early in the greeting to determine which options to display. If the options remain the same, it is recommended to authenticate only when needed in order to reduce the barrier of entry 7. **Personalization**, if access to this information is available, use of the user's first name in the greeting, e.g. "Hello, Avery" 8. **Relevant prior information** for known or returning/authenticated users. E.g. an appointment confirmation assistant informs the user of the appointment in question as part of justifying why the assistant is contacting the user (e.g. through SMS). E.g. when a returning user engages with an assistant, the assistant may take the opportunity to suggest relevant information (example Bank of America's Erica below) This list above is a great starting point. Items 5 through 8 come with certain conditions and the exact items to include in the greeting will depend on the specific context in which the assistant is used. Consider an assistant on a website support page. That assistant may have been introduced elsewhere on the page, something like "Use the virtual assistant to get quick answers to your questions". The context is the support page, so the topics the assistant handles are support type topics. The "quick answers to your questions" bit may even imply that this is an alternative to searching the support knowledge base. Given this context, the opening in the assistant itself can be reduced quite a bit. At a minimum, the opening explains what the assistant can do. Even though the context on what the assistant can help with has been set, it is always a good practice to list the most common types of requests as options. The greeting will likely be added as well; it's a short item and it's quite natural to greet a user, especially since the assistant is another channel the user is switching to. A greeting helps with that transition. In situations where authentication is possible, consider creating a more elaborate opening for new users, and a most concise one for returning users, assuming that returning users access the assistant on a regular basis, and have built up familiarity with the assistant and options. On this page we focus on the types of items in an opening. We are not focusing on the wording of the items, but the personality and tone (described in the Best Practices section) influence what words are used, and influence the verbosity or brevity of the actual prompts. **Examples** Lowe's is a home improvement store. The automated assistant opening contains the majority of items in the list. Authentication is not necessary yet; the assistant can help with a number of actions that don't need customer authentication. Once a customer is authenticated, presumably after selecting "My Orders", personalization can be applied as well. Numbers refer to the numbered list above.

Lowes.com

Okta's OktaBot uses a more transactional style. The bot greets the user. The self-identification is more implicit in the header and above the prompt. The bot goes straight into authentication to then show the relevant options. ![](/files/6rwlGUdFbg7rbZzdcjlR) ![](/files/QjTOX19aEtO9X5lOmbZz) Erica is the assistant for Bank of America. Erica is integrated in the mobile app, and has been featured for a number of years, so the need for self-identification is less of a priority. Erica greats the user, and since the assistant is integrated in the app, access to the first name is available for personalization. Next Erica actually shows "new insights": a list of things that may interest me as a user, before showing the options ![](/files/ERETXY9ZQS6lqXcTyLAe)
## More examples Variants of a generic example with a greeting and options: `A: Hello! How may I help you? [show 2 - 5 buttons with most commonly requested topics]` `A: Welcome! Here’s what I can do for you. [show 2 - 5 buttons with most commonly requested topics]` A generic example that explicitly suggests the option to type in other requests: `A: Welcome! What can we help you with today? For something else, please type in the space below. [show 2 - 5 buttons with most commonly requested topics]` Examples with user authentication that allows a level of personalization: `A: Welcome back, {user.first_name}! How can I help you today? [Order Status], … other options Because the user is authenticated we provide options specific to authenticated users first.` One step further: `A: Welcome back, {user.first_name}! Are you contacting us about your open order or something else? [My open order] [common option 1] [common option 2], …` Example with reason for contacting the user embedded in opening: `A: Good afternoon, {user.first_name}. I am Avery, the Car Service shop assistant. You have an appointment for an oil change scheduled for the day of tomorrow, Friday 14 May at 8 AM. [Confirm] [I need to change this]` # Additional Information ## Resources and Links * Academic literature * [Sequencing in Conversational Openings](https://www.google.com/url?q=https://www.degruyter.com/document/doi/10.1515/9783110880434-006/html\&sa=D\&source=editors\&ust=1644928111681709\&usg=AOvVaw1zrPgtEoqgtjfYnnMPLbBT) * [Constructing reason-for-the-call turns in everyday telephone conversation](https://www.google.com/url?q=https://kops.uni-konstanz.de/handle/123456789/3808\&sa=D\&source=editors\&ust=1644928111682574\&usg=AOvVaw1HxoYMlkGgAlsAMFkoIHNw) * [Interactional prosody: High onsets in reason-for-the-call turns](https://www.google.com/url?q=https://www.cambridge.org/core/journals/language-in-society/article/abs/interactional-prosody-high-onsets-in-reasonforthecall-turns/7CBF5D8BFB85586FDFF1F42A1CBA7A82\&sa=D\&source=editors\&ust=1644928111683225\&usg=AOvVaw1vpnbrIjvXSqMHSEMukm-w) * [Librarian chat openings](https://www.google.com/url?q=https://crl.acrl.org/index.php/crl/article/view/16525\&sa=D\&source=editors\&ust=1644928111683897\&usg=AOvVaw2N8NyMzXFT3n3iwksBTKge) * [Telephone Calls: Unity and Diversity in Conversational Structure Across Languages and Cultures](https://www.google.com/url?q=https://www.google.com/books/edition/Telephone_Calls/QVo9AAAAQBAJ?hl%3Den%26gbpv%3D0\&sa=D\&source=editors\&ust=1644928111684543\&usg=AOvVaw1iIZPSFpLy94SzOIwX2tpI) * ## Research Highlights Openings are likely to vary by culture, with participants in different countries having different norms. For example, in one country it may be common to skip greetings and in another callers may ask for the identity of the answerer. This could be a result of things as simple as the reliability of the phone system or whether or not people have caller-ID. The familiarity of the participants may also affect the length of the opening sequence. [One study](https://www.google.com/url?q=https://www.google.com/books/edition/Telephone_Calls/QVo9AAAAQBAJ?hl%3Den%26gbpv%3D0\&sa=D\&source=editors\&ust=1644928111693263\&usg=AOvVaw00obBmlXRinF0At7Ku-lUy) found that relative strangers had longer openings, while close connections used greetings and how-are-you sequences but skipped other parts. The conversation channel can also affect openings. If the channel makes clear who the participants are (with perhaps a linked profile), then the identification/recognition portion may be skipped. The opening pattern above has been described for “normal” conversation. Institutional forms of talk can look different, where interviews, for example, tend to start with extended preliminary talk (Heritage 2002). This extended monologue may be more for third parties than the interactants themselves. Interviews often open with the host stating the state of affairs, sharing a headline, which sets the context for the following discussion. Interviews tend to skip greetings or how-are-you’s, though they do include identifications. Interviews are structured ahead of time for the benefit of a media audience, while conversation is dynamically created in the moment. Like interviews, sometimes bots start with an extended monologue, sharing legal disclaimers, disclosing capabilities, or other context-setting. If this context is for the user’s benefit, i.e. it provides relevant background info, it makes sense to include it. But be careful, since these preliminaries can add friction to actually starting the interaction. # Authentication User authentication may be needed when protected information is transmitted. Some example use cases requiring authentication include initiating a transaction, checking balances, looking at information about employees, or reviewing company analytics. When looking at public information, users may not need to authenticate. Whether or not a user needs to go through the authentication process themselves depends on whether the system can do it for them or not. If the system already knows who the user is, the bot could authenticate behind the scenes for a frictionless interaction. If, for example, the bot is integrated into a mobile app that already knows the user’s info, then that info could be used to authenticate, and the user would never need to know. The user then gets an authenticated experience without having to re-authenticate. {% hint style="info" %} If user authentication is needed, it is good to do it “just in time”. A user may start by asking general questions (FAQs), in which case there is no need to hassle them with authentication. But at the moment they try to do something requiring authentication (e.g. check their account balance), then the authentication pattern should be triggered. Basically, don’t waste a user’s time authenticating unless or until it’s necessary. {% endhint %}
# Components ### User authentication status * User is authenticated, accomplished behind the scenes via an integration (an action, not an intent) * User is authenticated, just tried to authenticate conversationally and succeeded * User is not authenticated and confronts an authentication trigger * User is not authenticated, just tried to authenticate conversationally and failed ### Triggers for authentication * Whole experience requires authentication, so this is triggered at the start of the interaction. * Just-in-time authentication trigger examples * Entering secure chat * Asking for protected info * Initiating a transaction * Checking balances/due dates/credits ### Authentication conversation * Explanation to user for why they need to authenticate * Options if the user doesn’t want to authenticate. * Exit * Subset: only offer an experience not requiring authentication * Repair * Persuade: try to convince them it is worth authenticating * Authentication procedure * Collect user info conversationally (e.g. username and password) * ​​If no account, then register * Link to external authentication page * Secret questions * Voice biometrics * Optional: Explanation of authentication success or failure ### Embedded authentications (aka double authentication) * You might authenticate at multiple levels. For example, a user could authenticate with the Alexa service, and then also authenticate with a skill within the Alexa service. A CapitalOne banking skill within Alexa might need to do this. # Example Dialog User is in the hotel lobby, not their hotel room, and wants to order room service. User talks to a kiosk voice bot. User not authenticated. `[User launches the bot]` *`Bot: Welcome to Hotel OpenDialog. How can I help you today?`* `User: I’d like to have a bottle of Dom Perignon brought to our room at around 10pm this evening. Is that possible?` *`Bot: I can have room service bring you a bottle of Dom Perignon at 10pm this evening. Is that what you’d like?`* `User: Yes.` *`Bot: Before completing this change, I’ll need to verify your information. What room are you in?`* `User: Room 406.` *`Bot: Room 406. And to confirm who you are, what is your credit card number?`* `User: 1234 1234 1234 1234` *`Bot: Thank you, Jason. You will receive your room service at 10pm tonight.`* `User: Thank you.` In the above interaction, the user is making a request for room service from a location where they are not authenticated. Purchasing room service is an authentication trigger. Once the user intent is confirmed, the bot collects user information conversationally. In this case, instead of a username and password, the bot asks for the user’s room number and credit card number. The bot can compare the credit card number on file for room 406 and confirm that they match, thus accomplishing the authentication. Once authenticated, the transaction (a room service request) can be completed. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} In OpenDialog, there are two primary places you are likely to put a supporting pattern like authentication. If the entire scenario requires authentication, then it belongs in the welcome conversation. In this case, the scope of authentication is the entire experience. The figure below provides an example of how such a scenario-wide authentication could be handled. Within the Welcome Conversation we have two scenes - one which welcomes the user if they are already authenticated and one which leads them to an Accounting Linking conversation (or an Info conversation for help) if they need to authenticate. ![](/files/IJH59KD7H4x6I1QW5MN3) If, however, authentication is required only for a specific conversation within the overall scenario, then the authentication could live as a scene within that conversation. This approach is the just-in-time approach to authentication. If some subset of conversations require authentication, but not the entire scenario, then a more complicated solution is required. The design decision for where to put the authentication pattern depends on what parts of the scenario require authentication. # Information Collection Information is always being collected during a conversation, with every question, story, or any other exchange. But sometimes specific information is needed to accomplish the goal of the interaction. The information collection process could be system-driven, where the bot leads the user through specific areas of interest. It could also be user-driven, where the user provides an extended account. With user-driven information collection, the system must be capable of processing and handling the diversity of incoming information appropriately. In addition to conversationally collected information, it is also possible to use external sources like a user profile or an API pass-through to collect information. In the components below, we discuss some common approaches to information collection with conversational bots. # Components ### Question The simplest way to collect a piece of information is to just ask: `Bot: Are you ready?` `User: Yes/No` In this case, a single question/answer pair collects a single piece of information. But sometimes you need more than that. ### Slot-filling With slot-filling, a single turn collects (potentially) many pieces of information. You might ask a question that has a lot of possible answers, and a lot of detail is needed to fully answer: `Bot: What kind of pizza would you like?` In this case, there are a number of relevant pieces of information you need to be able to fully define (and deliver) the desired pizza, including pizza size (S, M, L), type (thin, deep dish), toppings (olives, mushrooms), and more. You may know all of these categories ahead of time and simply need to make sure they are all answered. This calls for a slot-filling solution. The user can give an open-ended answer that can be analyzed to extract answers to each of the slots, and if a required slot is unfilled, then follow-up questions can directly query the relevant slots. For example: `Bot: What kind of pizza would you like?` \ `User: A large pepperoni pizza. [slots: size, topping]` \ `Bot: Round or deep dish?` \ `User: Round [slots: type]` An alternate approach to slot-filling would be directed dialogue, navigating the user through each slot one at a time without any open-ended inputs. For example: `Bot: What size pizza would you like?` \ `User: Large` \ `Bot: What toppings?` \ `User: Pepperoni` \ `Bot: And round or deep dish?` \ `User: Round` Both sample dialogues above collect the same information, but the first supports an open-ended input and requires an intelligent NLU to map the input to fill the slots. It then follows up with targeted questions to fill any remaining required slots. By contrast, the second dialogue forgoes any open-ended inputs and railroads the user into a step-through process to answer the questions the system knows are required. This approach is more controlled, easier to implement, but can feel unnatural or controlling to a user. It’s not how you would usually talk to a human. Slot filling approaches to information collection depend on a user’s ability to accurately fill slots. That is, the conversation could prompt a user for the relevant pieces of information at the right time, but if the user is unable or unwilling to provide the right information, then the conversational goal won’t be met. For example, asking someone what kind of food they want may receive a reply like “not sure” or “something healthy”, which may not line up to existing categories. There are conversational cues however to the valence a user brings to their responses. In a study of dietary reporting, cues to problematic reporting include “it depends” (denoting variability), “probably” (suggesting guesswork), and elaborated talk. The conversation can be structured to elicit more accurate reporting. Slot filling is also restricted to cases where users are unlikely to need to go outside of a predefined set of values. “Traditional slot filling methods with classification models in the task-oriented dialogue system cannot predict unseen slot values in a pre-defined value list” (ref). In slot-filling use cases, it is often good practice to present the full set of slot values back to the user for confirmation. ### Complex logic In some cases, the conversational need is more complex than a set of slots that need to be filled. For example, symptom checkers have become a popular way of automating the triage process for health symptoms. These automated triage services first map a user’s symptom statement to an algorithm, which then elicits information about the user’s state of health, and gradually navigates to outcomes (e.g. whether to see a doctor, if so how urgent it is, what specialty that doctor should have, connecting to follow-up services, etc…). The questions to be asked, and the information to be collected, are guided by a clinical logic behind the scenes, much like how a doctor would assess a patient's symptoms. In a use case like this, the information cannot all be collected in one turn, nor can it be neatly summarized as a set of slots. Instead, many turns are working together to fulfill an external logic. The symptom checker is a piece of technology that converts the logic of clinical triage into a conversational information collection service. Other clinical logics can similarly be conversationalized, including chronic condition monitoring programs for conditions like diabetes or congestive heart failure (CHF). In these cases, the logic is more complex than simply filling a list of pre-existing slots. Instead, the “slots” that need filling depend on prior answers, according to the relevant features of the health situation. You don’t just fill slots like blood pressure and weight, since what values are important depend on other factors. ### Slot-filling + complex logic You can also combine slot-filling approaches with these broader logics. Perhaps you have narrowed a patient to a heart failure program and know that you need blood pressure and weight information. At that point, there are two slots that need filling, the user’s blood pressure and weight, and a slot-filling structure could support the elicitation. On the other hand, a more directed dialogue could collect this information, asking for each piece one at a time. # Example Dialog In this Hospitality use case, the user wants to make a restaurant reservation. The bot helps them do this by collecting the relevant information. `Bot: I can help you make a reservation. Okay, so you’re looking for a reservation at Bella Italia, at 7pm tonight, is that right?` `User: Yes.` `Bot: Great. How many people will there be?` `User: Four people`. `Bot: Okay, a reservation for four at 7pm tonight at Bella Italia. Let me check with them.` `[Bot checks availability]` `Bot: It looks like there is nothing available then, but there is an opening at 7:30pm. How does that sound?` `User: That works.` `Bot: I can book it for you, using the same name as your hotel reservation, Jason Bourne. Shall I book it for you?` `User: Yes.` `[Bot books the reservation]` `Bot: Done! You’re booked for a table for four at 7:30pm tonight at Bella Italia.` `User: Oh, one question. Does Bella Italia have gluten free options?` `Bot: Unfortunately, I don’t know the details of their menu, but I can call them for you if you’d like to ask directly. Shall I do that?` `User: Yes please.` `Bot: Sure thing, one second.` This sample interaction includes direct information collection (How many people?), as well as repair (nothing available at requested time), and a transfer when the user asks a question the bot cannot answer. The information collection process is central to booking the reservation, but the associated patterns of repair and transfer are key to successfully managing the interaction. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} The information collection challenge has been met by many technology companies with slot-filling approaches, but it is not the only way. Google’s Dialogflow, for example, has implemented slot-filling as a dedicated component where one must fill the slots before continuing, an experience separate from the rest of the conversation. By contrast, OpenDialog treats slot-filling as just another contextualized variation on conversation, where each slot is a (required) exchange within a conversation or scene. A benefit of the OpenDialog approach to information collection is that the conversation can support user questions outside of the slot-filling paradigm while information is being collected, and maintain the context. For example, say the user has said they want a large pepperoni pizza but hasn’t yet said what type of crust. While the system may be expecting the next slot to be filled, the user may have a seemingly unrelated question about the restaurant’s hours or delivery time or something else. To be able to handle such unexpected questions, the technology needs to be able to change context to answer the question and then pick up the information collection sequence where they left off. OpenDialog handles this gracefully with the contextual structure inherent to its architecture and the use of “virtual intents”. Within OpenDialog you have a design choice to implement this collection pattern in a single scene or as a collection of scenes (with each piece of info as a separate scene). “Would you like a sweet or dry wine” – could be a single turn or a scene, depending on how much you need to do to “fill that slot”. A doc may need to explain this design choice in OpenDialog. # Additional Information ## Resources and Links * Academic literature * [Conversation modelling for chatbots: current approaches and future directions](http://www.essv.de/paper.php?id=405) * [Talking with Alexa](https://nottingham-repository.worktribe.com/index.php/output/1451674/talking-with-alexa) * [IIAS: An Intelligent Insurance Assessment System through Online Real-time Conversation Analysis](https://www.ijcai.org/proceedings/2021/0721.pdf) # Providing Recommendations The providing recommendation pattern often involves features of the [collecting information pattern](/the-pattern-library/information-collection). This is because providing recommendations is broken into two parts, which can loop on each other: collecting user preferences (input) and providing a recommendation (output). Recommendation systems are built to narrow a set of possible alternatives down to something the user is likely to like. Doing this can start with a recommendation that the user responds to (e.g. like or dislike), or it can start with collecting user preferences and then offering a recommendation. The collection of user preferences tends to be either system driven or user driven. In a system driven approach, a bot would guide the interaction, asking a user for things like their shoe size, color, running style and more. In a user driven approach, a bot may ask the user to state their own preferences. In response, a user may say something like “I’d like some size 10 running shoes for women,” which the system then needs to process appropriately (which can be a challenge). Mixed-initiative approaches are a mix of bot-asked questions and user questions of the bot. Done well, this is probably the best. Many recommendation systems are one-shot, but multi-turn approaches where users can ask questions and give feedback can be more robust. A good recommendation system requires not just dialog management, but also user modeling and knowledge elements. That is, the system needs a way to keep track of the user’s preferences, and to organize the set of recommendable items with their attributes. This discussion of the providing recommendations pattern will focus on the dialog side of things, but for it to work well it needs all three parts. The channel can also affect how to implement a recommendation pattern. If you’re voice-only or text-only, then you have to work within those constraints. But situations of disambiguation work best with a mix of interfaces (e.g. NLP with buttons) (Narducci et al.). It is not always clear how much guidance a user wants, so offering flexibility and adaptability can help. # Components This conversational input/output process can be repeated such that the input becomes richer and the output recommendations change (hopefully getting better). In general, if you are presenting recommendations conversationally (in voice or text), you will want to either choose one to present or somehow summarise a set of options. You could show one at a time and if the user says no you move on to the next. But, if you have the option of presenting multiple options in a carousel or in a linked page, more options can be presented at once. If your bot is able to get subtle user sentiment in response to recommendations, that sentiment could also be fed into the recommender system to guide future recommendations. ### Output: Present a recommendation (or multiple) * Optional: explain why that recommendation was presented, e.g. “a bestseller”, a “new release”. Explaining “can increase the system’s perceived transparency, user trust and satisfaction, and they can help users make faster and better decisions” ([Gedikli](https://www.sciencedirect.com/science/article/abs/pii/S1071581913002024)). * Ask if the user likes it * if yes, ask if they’d like to buy or see more like it * if no, propose different options or ask for preferences * assess user sentiment of the response, then go down yes or no path (or something else) * Show possible critiques (too colorful, too small, reject, “on track”) that a user can use to respond that refine future recommendations. ### Input: Preference collection (see Collecting Information pattern) * System driven: ask user preference questions (shoe size, gender, running style) → when complete, **present recommendations** * User (then system) driven: Ask user to state their own preferences or ask their own question (“I’d like some size 10 running shoes for women”, “do you have size 10 running shoes for women?”) → use system-driven slot filling to complete required categories → when complete, **present recommendations** * Optional: external knowledge of items. You can filter with preferences from user profile or other sources, though you’ll want to be careful with how this is used since users may buy for someone other than themselves.
# Example Dialog In a Hospitality use case, a hotel guest may want a restaurant recommendation. `Bot: I can recommend local restaurants for you. What kind of restaurant are you looking for?` `User: Maybe an Italian restaurant nearby, not too expensive.` `Bot: It sounds like you’re looking for an Italian restaurant, within 5 miles, that is inexpensive. Is that right?` `User: Yes.` `Bot: Great. One option is Bella Italia at 520 Main St., about a 5 minute walk from here. It gets good ratings and isn’t too expensive. How does that sound?` `User: Seems good.` `Bot: If interested, I can book a reservation for you, or call them for you.` `User: Let’s make a reservation for tonight at 7pm.` In this example, the system recommends the restaurant Bella Italia to the user. Before doing so, however, the system collected the relevant user preferences to be able to make such a recommendation. This process is documented in more detail in the Collecting Information pattern section, filling slots for things like type of food, location and cost. Once those slots are filled, the system has enough information to recommend a restaurant. In this sample, the user accepts the system’s recommendation, and the conversation moves on to making a reservation. If the user had declined the reservation, the system could make another recommendation or ask for more user preferences. This could include asking for why that recommendation wasn’t a fit, e.g. it was too expensive. With this extra information, the system can refine its recommendations. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} In progress # Additional Information ## Resources and Links * Academic literature * [A Survey on Conversational Recommender Systems](https://scholarphi.semanticscholar.org/?file=https://arxiv.org/pdf/2004.00646v2.pdf) * [IAI MovieBot: A Conversational Movie Recommender System](https://imsure318.github.io/assets/pdf/2020_cikm_demo.pdf) * [Tutorial on Conversational Recommendation Systems](https://conversational-recsys.github.io/) ([slides](https://drive.google.com/file/d/14Fvxi--sX-52ZOZLySityXnTdsfWHWRe/view)) * [An investigation on the user interaction modes of conversational recommender systems for the music domain](https://www.semanticscholar.org/paper/An-investigation-on-the-user-interaction-modes-of-Narducci-Basile/146bd856a83c71714e19c655e077e82085f2ac7e) * [How should I explain? A comparison of different explanation types for recommender systems](https://www.sciencedirect.com/science/article/abs/pii/S1071581913002024) ## Research Highlights There is research within computer science focused on Conversational Recommendation Systems (CRSs). # Extended Telling Extended tellings are for contexts where you need to communicate a lot of content and the bot holds the floor for an extended period of time. Common types of extended tellings include trainings, education modules, stories and quotations, all times where a bot may need to hold the floor for longer than a single turn. Structurally, extended tellings are conversational sequences with an opening (e.g. “tell me about Paris”), a body, and a closing. A training pattern’s body involves the teller 1) giving the first part of the telling and 2) waiting for a listener cue to continue. These continuation cues may be simple tokens like “uh-huh”, “okay”, “yeah” or gestures like a head nod. The pause for a continuation cue allows the listener to initiate repair if needed, or interrupt or redirect the conversation if desired (taking the floor). The training can be sped up if the bot doesn’t wait for continuation cues, though the user should still be afforded a way to initiate repair (e.g. a UI element to exit the telling). Doing an extended telling without any listener option to provide continuation cues or initiate repair can feel like railroading to a user, being forced to cede the floor unwillingly. This can show up when a chatbot presents many text bubbles all at once, flooding the chat UI. To be clear that you intend to hold the floor, reduce cues to turn transition at utterance end (but you can add those cues inside utterances when it’s unambiguously not a turn transition). In addition, at utterance end make sure not to pause too long, to start again quickly, speak louder, don’t use falling intonation, use high onset pitch. # Components ### Triggers for an extended telling * User questions * How does one meditate? * How do I do that? * User requests * Tell me a story * Tell me all the things you can do * Tell me about your vacation * Bot proposals * Would you like to hear some healthy sleep tips? ### Extended telling sequence * Bot gives the first part of the telling * Good message design here will reduce cues to turn transition at utterance end (lots of intonational cues, avoid sequence-ending moves e.g. gratitude, summation, etc…), making it clear bot plans to continue.
* User provides cues to the next step (skipping the option for these user cues can speed things up but also feel like railroading to the user; it can also overwhelm e.g with a ton of chat bubbles from the bot all at once). * Cued to continue (“hm mm”, “yeah”, “go on”, “continue”) → loop with more tellings. Note: if the user does nothing during bot pausing for cue, normally this is taken as cue to continue. * Cued to stop the telling (“I’m bored”, “can we do something else?”) → exit * Cued for repair → trigger repair (see example below) * Aborting the story `A: Tell me a story` `B: Once upon a time, there was…` `A: {{pause}}` `B: And then the hero…` `A: This is boring` `B: Shall I stop?` `A: Yes` `B: Okay` ### Closing cues for an extended telling * Ask for questions: “Do you have any questions about what I just shared?” * Summation: “And that’s a short introduction to how square-breathing works.” * Gratitude: “Thank you for your attention.” * Well-wishing: “I hope things improve for you soon.” * Offer to repeat: “Would you like to hear this again?” * Restatement of the reason for the extended telling (“And that’s a practice that you can use anytime you’re feeling stressed.”). ## Examples * Training: a walkthrough or how-to, e.g. for how to meditate * Education: deeper content sharing, e.g. guidance for how to get healthy sleep * Story, e.g. giving the origin story of the bot * Quotation, e.g. reciting a lengthy poem or quotation
# Example Dialog During a conversation, there may be an opportunity for the bot to talk for an extended period. In this example for a hospitality use case, the bot offers to give background on the hotel. `Bot: Hotel OpenDialog was first opened in 1908. Would you like to hear more about its history?` `User: Yeah!` **`Extended Telling`** `Bot: Hotel OpenDialog was first established by the Smith family in 1908 as a comfortable space for travelers to rest and relax while they explored the downtown area. Since the construction of the ballroom in 1965, we’ve been hosting weddings as well.` `[pause]` `Bot: Hotel OpenDialog has three locations, one downtown, one near the airport, and one at Pier 37 on the waterfront. The hotels at all three locations were sold to the Marriott company in 2002, and have been operated by Marriot since then.` `User: Cool, that’s enough.` First, the bot shares a piece of information, and then asks if the user would like more. When the user says yes, this launches an extended telling sequence wherein the bot educates the user about the history of the hotel. After two long sentences of the content, the bot pauses briefly for the user to give a cue to continue or steer in a different direction. The user not saying anything is taken interpreted by the bot as a cue to continue, which the bot does by talking about different locations and the acquisition of the company by Marriott. When the bot pauses again, the user indicates that the bot can stop. This closes the extended telling sequence, moving on to the next part of the conversation. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog, please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} In progress # Additional Information ## Resources and Links * Industry resources * [Conversational UX Design](https://www.google.com/books/edition/Conversational_UX_Design/sxidDwAAQBAJ) * Academic literature * [Narrative analysis: Oral versions of personal experience](https://psycnet.apa.org/record/1997-39195-001) ## Research Highlights Work in "narrative analysis" that focuses on storytelling sequences within conversation could help inform designs for extended tellings. # Repair (Inge WIP) At any point in a conversation, any party can run into difficulties. Perhaps what was said was not understood, or one party isn't sure what to say or do next. Maybe you don’t know what a word means. In voice assistants, maybe the utterance wasn't heard or understood. In such cases, there needs to be a process by which the conversation can get back on track. That process is repair. We use the word “repair” here to describe "the means of overcoming an obstacle blocking the smooth progression of a conversation". There are more everyday meanings for “repair”, e.g. “repairing a relationship” being about getting back on good terms with someone, or “repairing a car” being about fixing a car. In this document and context, repair is narrowly referring to the process of fixing an issue (“trouble source”) blocking the conversation’s progress. Being prepared to repair an issue is critically important, because of the ramifications: without it, the conversation may break down to the point where the conversation can not be completed successfully. Think back to a time where you were not able to complete your task because the conversation irreparably halted. This represents a blocker, and leaves you with a negative feeling, as you need to find other ways to complete your task. The repair strategy depends on the nature of the issue, and may involve asking the speaker to repeat themselves, to clarify, to correct, to define, to paraphrase or something else. If a “trouble source” occurs, a user could choose to initiate repair or use a “let-it-pass” strategy. The initiation of repair is often accomplished by asking a question. The interactional force of questioning may be achieved with interrogative syntax, but also could be indicated with question marks, dashes, explicit statements of non-understanding and presenting candidate understandings. Secondary strategies include declarations of non-understanding (“I don’t get it”, “unclear”) and dictionary look-ups. The taxonomy of repair is sometimes divided between who initiates the repair (self or other) and who completes the repair (self or other). A simple type of repair is speaker self-correction, often accomplished within a single turn. Other-repair takes more work, comes at least a turn later, is less common and can be more elaborate. # Types of repair There are many ways in which a conversation can break down, and as a result there are many types of repair. From a linguistic point of view, here are some of the most common triggers of a repair pattern. The response to each type will depend on content and use case. ### General * What? * I don’t get it * That’s not what I asked ### Definition request * What is pronation? * What is a cross-trainer? ### Repeat request * What did you say? * Can you repeat that? ### Partial repeat request * Size 10 what? ### Paraphrase request * What do you mean? * Can you say that another way? ### Example request * What are my options? * What shoe brands do you carry other than Nike? ### Understanding check * Delectable means delicious? * Flan is a dessert? ### Confirmation check * A pizza with pineapple and papaya? ### Correction * Self-correction: “What sizes are the boots- *er- shoes* available in?” * Other-correction: `A: They’re gonna drive back Wednesday.` `B:`` `*`Tomorrow.`* `A: Right, tomorrow.` `A: How much do the Nikes in size 7 cost?` `B: The Nike Air Max in size 7 costs $100.` `A:`` `*`Oh I thought those were $80.`* `B: The Nike Air in size 7 costs $80.` `A: Oh okay.` ### Hearing check \[voice only] * I didn’t hear that ## Dimensions of repair * User-initiated vs. agent-initiated repair (who triggers repair?) * User-repair vs. agent-repair (who fixes the problem?) * Repair sequencing: What if an initial repair doesn’t work? How can you combine them? Looping through different repair strategies, fallback options, scaling up to agent-transfer. * There could be different fallback strategies. Perhaps, a definition request could be answered, but if that doesn’t work, then use the general repair strategy, and if that doesn’t work, offer to transfer. Alternatively, a user could say a general “I don’t get it”, to which you could respond with a paraphrase. # User request not understood One common reason for communication breakdown between humans and digital assistants is when the assistant does not understand the user's request. In this section we focus specifically on text-based assistants. The lack of understanding means that the meaning of the user's input could not be resolved by the assistant. In the case of voice assistants, there is an additional layer of possible misunderstanding where the speech recognition fails. The latter is out of scope for this page in particular and we focus on those situations where the assistant does not understand the meaning of the user's input. Let's talk about how it can happen that a user is not understood. The system takes an input from the user and maps that to an intent. That user input can be a button, in which case a proper conversation structure would have an intent that the button label is mapped to. This mapping is mandatory in OpenDialog. It is possible that the button label is mapped to the wrong intent. This is a bug that should be discovered in functional testing. In conclusion, it is not common to run into issues with buttons. A higher chance for failure is possible when the user inputs natural language, in other words, they type a message, either a request or answer to a question. If the system can't map the user input to an intent, we have a breakdown that needs to be repaired. There are a number of user actions that can result in this breakdown. One set of actions are done by the user in good faith, meaning they are cooperating in the conversation and hence also expect to be understood, but they are not: * The user input is not covered in the system; the utterance is not added to any intent, so it can't be mapped. This is a very common reason for this issue (add longer term solution, e.g. analyze logs and improve) * The user uses another language or their written language has severe grammatical and spelling mistakes. The system understands what it was told to understand, so if the system was built for English, it will not automatically understand another language. If the system was not trained on sentences with severe grammar and spelling issues, it may not understand the user. * # Example Dialog In a Hospitality use case, a hotel guest may want a restaurant recommendation. This is the example dialog from the Providing Recommendations pattern, but with a repair sequence inserted. **`Providing Recommendations`** `Bot: I can recommend local restaurants for you. What kind of restaurant are you looking for?` `User: Maybe an I#&*$&#n restaurant nearby, not too expensive.` `Bot: It sounds like you’re looking for an Indian restaurant, within 5 miles, that is inexpensive. Is that right?` **`Repair`** `User: Mostly, but I asked for an Italian restaurant.` `Bot: Got it. So, an Italian restaurant, within 5 miles, that is inexpensive. Is that it?` `User: Yes.` **`Providing Recommendations`**` ``(cont.)` `Bot: Great. One option is Bella Italia at 520 Main St., about a 5 minute walk from here. It gets good ratings and isn’t too expensive. How does that sound?` `User: Seems good.` `Bot: If interested, I can book a reservation for you, or call them for you.` `User: Let’s make a reservation for tonight at 7pm.` In this sample, the user provided three pieces of information for use in providing a restaurant recommendation: cuisine, distance and cost. The bot heard the request for an “Indian” restaurant. When the bot seeks confirmation, the user corrects the error by indicating a desire for an Italian restaurant, not an Indian restaurant. The bot is able to accommodate the change and seek confirmation with the update. When the user confirms, the conversation continues. The repair is a brief side-sequence to correct an error in understanding. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} In progress # Additional Information ## Resources and Links * Academic literature * [Resilient Chatbots: Repair Strategy Preferences for Conversational Breakdowns](https://dl.acm.org/doi/10.1145/3290605.3300484) * [Say it Like You Mean it: Priming for Structure in Caller Responses to a Spoken Dialog System](https://link.springer.com/article/10.1023/A:1022326328600) * [An Introduction to Conversation Analysis](https://www.google.com/books/edition/An_Introduction_to_Conversation_Analysis/kpI6EAAAQBAJ?hl=en\&gbpv=0) * [A data-driven model of explanations for a chatbot that helps to practice conversation in a foreign language](https://aclanthology.org/W17-5547.pdf) * [The Preference for Self-Correction in the Organization of Repair in Conversation](https://www.researchgate.net/publication/230876456_The_Preference_for_Self-Correction_in_the_Organization_of_Repair_in_Conversation) * [​​Conversational Repair in Chatbots for Customer Service: The Effect of Expressing Uncertainty and Suggesting Alternatives](https://link.springer.com/chapter/10.1007/978-3-030-39540-7_14) * Web resources, blogs * [Repair in Conversation Analysis](https://www.thoughtco.com/repair-speech-1692044) ## Research Highlights Users prefer repair with options listed ([Ashktorab et al. 2019](https://dl.acm.org/doi/10.1145/3290605.3300484)), and options should probably be listed before the question ([Sheeder & Balogh 2003](https://link.springer.com/article/10.1023/A:1022326328600)). # Transfer Transfers are when a user is handed over to someone or something, most commonly a transfer from a bot to a human. A transfer could also include a hand off to a different channel (bot to website, bot to email, bot to a different bot). Other considerations beyond transfer destination include if the user can come back and continue the original conversation, if the transfer is optional, if the user is told that they will be transferred, and if data are transferred too. When is a transfer needed and what are good ways to accomplish it? Let's dive in. # Components ### **Transfer triggers** These are some of the events that commonly trigger a transfer. * **User preference**. This could be the user indicating a desire to talk to a human, either by tapping a button or speaking/writing that intention. * **User sentiment**. If the user is perceived to be unhappy/frustrated/angry/annoyed, you may want to offer the option of transferring to talk to a human. * **Criticality of the conversation**. The conversation is critical for some reason, you may want to transfer to a human or other more sensitive interface option. Examples of critical could be a sensitive topic, a high-value interaction, a risk of churn, the interaction dragging on for a long time, or the user being in a special category. * **Complex issue, fallback option**. If the bot can’t handle something, there is the option to escalate to a human. * **Admin/agent oversight**. If the bot interactions are being monitored, a moderator may recognize a need for human intervention and take over. ### **Transfer** procedure When initiating a transfer pattern, there are some common steps. * Tell the user that a handoff is coming * Collect any remaining information so bot knows who to hand off to * Some choices for the transfer destination * A human OR a bot * Synchronous OR asynchronous. Usually synchronous is preferred. * Common synchronous channels: chat, WhatsApp, FB messenger, phone * Common asynchronous channels: email * The bot OR the user chooses * [Routing conditions](https://www.affinsys.com/Seamless-Bot-to-agent-hand-off): * Round-robin: assign user to the first available agent * Language-based: assign user to an agent with matching language preference * Skills-based: assign user to an agent with the skills matching the user's need ### **Wait phase (if needed)** When a transfer is initiated, there may not be any agents available immediately. In this case, the user is put in a queue, and would benefit from clear communication on how long they are likely to have to wait and their position in the queue. This can help manage expectations. Transparency is key to user satisfaction, and “time-fillers” might help too. The Liz bot shows one example of how to handle waiting: ![](/files/nBnGL02eeUulRu15vGyv) This example shows estimated waiting time, position in the queue, and even offers the user the option of filing a ticket as an alternative to continuing to wait. ### **The actual handoff** In a bot-to-human handoff, the human takes over. In such a case, the human needs to be trained to handle the transfer smoothly as well. While the human agent may be new to the conversation, the user has been there for a while. The user's experience can be improved if the human agent is given contextual information like the dialog history, the handoff trigger, user info (what product they use, demographics, geolocation), tips for how to help the user, and sample statements. ## **Examples** Below are some screenshots of transfer experiences. To start, this LiveChat bot uses failure to understand user intent as a trigger for a transfer. After two fails, the transfer to a LiveChat agent is initiated. ![](https://lh4.googleusercontent.com/-fephlS1GFh1wzSgufd-uu4ThG6VQpDWYhaH5GwXdwROsVevRRHhzDL6r9zM62ZioggzAR6D9nvrPSkRviHi3TX2WWFAmQBucfE78lM1IpCPD_Wx8WgfNZqFlF6BfjONyAKTFhrI) The Lowe’s bot responds to a different trigger to initiate a handoff, namely when the user expresses an interest in a specific product. It doesn’t ask if the user wants to transfer to a human agent. Generally, we recommend giving users the option to transfer or not. The health tech company Sensely has a symptom checker that offers transfer options after completing triage. Once the symptom has been assessed, the user is offered a list of options for next steps, including a nurse line, a callback service, and appointment booking for either a video or in-person visit. ![](https://lh4.googleusercontent.com/81FVqdrfg4PWunqvKsJWPi6nTzFvkJHYnYhZJhF4bCQrrqBGqXhQVbknaXXUBn23SSJNRpszgxoPYUX_0D9NA3w6yyFLGNozhBrDPGggNoNl7UCzjjxhGlH8XoUxSY_7Kh9lR5LG) It may not always be clear to the user whether or not they are talking to a bot or a human. As an example, Liveperson’s home page normally triages with a bot, but one day the system was down and so a human was covering it. ![](https://lh3.googleusercontent.com/7i5kHbb6tuzuMotTBTN0ZSVd-N4kKyvkumfZJaLlS-tCxtwK65fq5kIAh7AoHd14JGIIjy8eRQSfAUqBsvdtp7PFwNHt6IbXjIoraG12XPv2V8gSOf_63pUzz-t7EpNgzP6V_7cO)![](https://lh6.googleusercontent.com/PQw7t1nDhx5ulOhyk65r4fsHid7PhW2XCeMH8lNtWoWHlY2q8EDeB0TMEKM6dvdldxzHpGbxbFxAY6ktQ_Mxnb-tP_bfMG4fypE9x2oAiS195CEFj2c-GLZh1hFF3XDBo6OdXPmm) At the end, the human initiates a transfer to another human. # Example Dialog Transfers commonly happen when a bot is unable to complete a required task, or when a user asks to talk to a human. `Bot: Unfortunately, I don’t know the details of their menu, but I can call them for you if you’d like to ask directly. Shall I do that?` `User: Yes please.` `Bot: Sure thing, one second.` **`Transfer`** `[Phone rings at Bella Italia, human-human conversation clarifying the user’s question, then the call ends, bot picks up]` `Bot: Were they able to help you?` `User: Yes, thank you.` **`Closing (Pre-Closing)`** `Bot: Is there anything else I can help you with?` In this sequence, the user asks the bot a question the bot recognizes well enough to know it doesn’t know the answer and that a transfer to the restaurant may be the appropriate next step. The handoff trigger is a question the bot cannot handle on its own. The bot offers to call the restaurant for the user, which the user accepts. In this sequence, the bot is put on hold while the user has a traditional phone conversation with the restaurant. When the call is complete, the bot takes over again and asks if the user’s need was met. After the user says it was, the bot moves on to the next step of the conversation, in this case a last topic check as part of a pre-closing. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog, please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} In progress # Additional Information ## Resources and Links * Academic literature * [Hybrid Service Recovery: Design for Seamless Inquiry Handovers between Conversational Agents and Human Service Agents](https://scholarspace.manoa.hawaii.edu/bitstream/10125/70756/0117.pdf) * [A Role-Selected Sharing Network for Joint Machine-Human Chatting Handoff and Service Satisfaction Analysis](https://arxiv.org/pdf/2109.08412.pdf) * Web resources, blogs * [Why ‘containment rate’ is NOT the best way to measure your chatbot or voicebot](https://vux.world/why-containment-rate-is-not-the-best-way-to-measure-your-chatbot-or-voicebot/) # Closing Conversations don’t usually stop all of a sudden (it would feel weird if they did!). Instead, a closing pattern facilitates clarity to all parties that the conversation is on its way to ending, offers an opportunity to address any remaining issues, does some relationship work (gratitude, future contact), and creates an opportunity for upsells, feedback requests or other added value moves. Structurally, the heart of a conversation tends to be a series of topics, followed by a pre-closing, and a final closing. ![](https://lh4.googleusercontent.com/qkarKeapL3wP7uhv8Y-O0Z0H4KekozMdwZ5NmgdQlx0fQWamDxtmK4d4XHga1QLldBkFEt83yXVtxbZ4Z7QhAG-dY6uU18Df9MUqnFkO_ePjV_KVgnLmumq7j5d_djiCKW0GUcLz) Pre-closings can either lead to opening a new topic or continue on to a final closing. Within the pre-closing period, there are common social functions like well-wishing or a discussion of future contact. The very end (the “closing”) is a final adjacency pair of farewells like goodbye and bye. Here is an example closing from Moore and Arar (2018, p167): `A: ok SEQUENCE CLOSING` `B: Anything else? LAST TOPIC CHECK` `A: no DECLINING A NEW TOPIC` `B: Have a good day! WELL-WISHING` `A: You too WELL-WISHING` `B: Goodbye FAREWELL` `A: Bye FAREWELL` There is a sequence closer (“ok”), which shuts down the last topic of conversation. Then the pre-closing begins with a last topic check (“Anything else?”). At this point, the user could open a new topic and re-enter the body of the conversation (leaving the pre-closing), or they could decline to open a new topic and continue the pre-closing (disaffirmation). The pre-closing often continues with optional social graces like well-wishing (“Have a good day!”), acknowledgments about the relationship or activity (“It’s been a pleasure chatting with you”), mentions of future activities together (“I’ll see you tomorrow!”), or more. Once the optional pre-closing steps are complete, the participants do the final closing (“bye/bye”, “cheers/see ya”, etc…), at which point the conversation is over. Most conversations benefit from a closing pattern. Exceptions include transfers to an agent, intolerable input (e.g. offensive language), or aborting (instant conclusion). # Components Closings are composed of pre-closing material and a final closing pair. ### Common pre-closings Pre-closings are social actions that commonly bridge between the body of a conversation and the final closing pair. These often include: * Last topic check * Well-wishing (“Have a good day!”, “Enjoy your vacation!”) * Acknowledgments about the relationship or activity (“It’s been a pleasure chatting with you”) * Mentions of future activities together (“I’ll see you tomorrow!”) * Restatement of the reason for the conversation (“Yeah I just called to make sure you’re doing well.”) * A common saying, proverb, or aphorism (“Yeah well, things always work out for the best.”) ### Closing pair * Bye - Bye * synonyms for “bye” can be swapped, e.g. goodbye, see ya, later, ciao, cheers, or whatever works in your context. The last topic check can be used for a single part of the conversation, or for the conversation as a whole. This is an approach taken by one of DialogflowCX’s templates, a Financial Services bot. Within a discussion of card features, the section closes by asking “Would you like to compare any more card features?” This is a last topic check on the card features portion of the interaction. Once this is closed, the bot moves up to the level of the whole conversation, asking “Is there anything else I can help you with?” If declined, this last topic check then moves on to the pre-closing part of the conversation. Alexa’s version of templates are called skill blueprints. The format for the “Business Q\&A” skill is a series of questions, a last question check, and then a goodbye. This template includes none of the pre-closing social actions listed above. Interestingly, the Amazon doc doesn’t transcribe the closing even though it is part of the audio recording, suggesting it is an afterthought. # Example Dialog `Bot: Is there anything else I can help you with?` `User: No, that’s all.` `Bot: It’s been a pleasure chatting with you today.` `User: Likewise, this was strangely fun.` `Bot: Feel free to come back any time.` `User: Sure thing.` `Bot: Goodbye` `User: Goodbye` This sample starts with a last topic check, an opportunity to open up a new topic. After the user declines, the bot moves on to other pre-closing moves, including gratitude and a future contact offer. This proceeds smoothly. The bot says Goodbye, the first half of the final closing pair. When the user completes this pair with a Goodbye, the conversation has ended. # Using in OpenDialog {% hint style="info" %} As you learn about how to implement different patterns in OpenDialog, please keep in mind that OpenDialog is a flexible model that can support a variety of different implementations. We urge conversation designers to use the indications below as a means to learn, be inspired or be unblocked but not as the canon of how things should be done in OpenDialog! {% endhint %} The topic closing check and last topic check are a good fit for OpenDialog, closing different levels of the interaction hierarchy. This can be realized in OpenDialog as a closing of the scene and then a closing of the conversation. Other times, there may only be a last topic check (there is no scene-level topic closing check). Once the closing is complete, the user may be offered the opportunity to restart. # Additional Information ## Resources and Links * Academic literature * [Opening up Closings](https://www.degruyter.com/document/doi/10.1515/semi.1973.8.4.289/html) * [An Introduction to Conversation Analysis](https://www.google.com/books/edition/An_Introduction_to_Conversation_Analysis/kpI6EAAAQBAJ?hl=en\&gbpv=0) * Web resources, blogs * [Every Chatbot Needs an Exit](https://medium.com/the-chatbot-guru/chatbotexitsequence-7c45219e77a7) * [9 Tips to Design Conversational Style for Your Bot](https://medium.com/salesforce-ux/chatbot-conversational-style-f7b1d584fb1d) ## Research Highlights Mostly, guidelines talk about Grice’s maxims, or speak in generalities. [Greg Bennett](https://medium.com/salesforce-ux/chatbot-conversational-style-f7b1d584fb1d) says to fit the closing to the context, fitting the style of your bot. [Google](https://developers.google.com/assistant/conversation-design/learn-about-conversation) doesn’t address closings specifically. A [contact center blog](https://www.providesupport.com/blog/customer-service-tips-how-to-close-conversation/) says not to leave the conversation before the user; 1) if wrapping up, say thank you and goodbye; 2) if transferring, notify the user; 3) if chat is left open (or a long delay?), ask if the user needs more assistance. Another [live chat blog](https://www.comm100.com/blog/ending-a-chat.html) emphasizes the importance of the pre-closing (without using that term), including a last topic check, gratitude, and future contact orientation. One [blog post](https://medium.com/the-chatbot-guru/chatbotexitsequence-7c45219e77a7) encourages including an exit button, recognizing a user’s “exit” intent, and a task completion closing flow.