Re-Usable Designs

Re-usable design components are, what can be called, encapsulating blocks for a conversational skill. These are scenarios in day-to-day conversations, which can be used with little or no modifications. Re-usable design components help scale the design by breaking the overall design into a set of conversational blocks, which can then be individually worked on. They can also be leveraged in a “copy-paste” fashion, where it is possible to “copy” a conversational block and “paste” it into a different design to use it.

Level 1 Authentication

Authentication scenario for one question authentication. This is a scenario where the bot tries to verify the user’s identity by asking a security question.

Below is the high-level design for building a micro-conversation for capturing authentication information from the user.

High-level design

Example implementation - Birthplace capture

Example scenario - Asking the users their birthplace to confirm their identity.

Key highlights

• Consensual authentication - Users shouldn’t feel as if authentication is being imposed upon them. Even in scenarios where authentication is mandatory, the bot must ask for consent before proceeding.

• A gentle nudge on denial - If the users don’t consent to authentication, then the bot should give a gentle nudge to try and get them to authenticate if it’s mandatory. If it’s not, then it should simply tell them that the functionality would be available, albeit in a limited capacity.

• The not-so-happy paths - The not-so-happy paths must be covered. Some of them are mentioned below. More could be added on a need basis
  • What is needed - What’s needed before proceeding to authenticate.
  • Where to find - Where to locate this particular bit of information.
  • Hold - Hold for the users to fetch this information.
  • Doesn’t remember - Users may or may not remember the piece of information that the bot is asking. It’s important to not only handle this but also assure users that forgetting something is not a big deal.

• Persona maintenance - The bot in this example implementation personifies a service desk agent and throughout the conversation, it carries this persona. It goes to an extent where it calls the service desk agent its “human colleague”.

• Exit point mapping - Users may exit from any point in the conversation, and it becomes super imperative to capture as many exit scenarios as possible. The exit point mappings are values assigned to the ‘exit status’ variable which is then logged in the database. This helps identify the outcome of a conversation quickly without doing a detailed data analysis.

Level 2 Authentication - non OTP/Passcode based

Authentication scenario for 2-question authentication. This is where the bot determines the identity of the user based on two questions. This, however, does not apply to an OTP/Passcode type scenario.

Below is the high-level design for building a micro-conversation for capturing two bits of authentication information from the user.

High-level design

Example implementation - Capturing employee ID and birth date

Example scenario - Asking employees their employee ID and birth date. This is similar to the above scenario except for one more bit of information being collected from users.

Key highlights

• Consensual authentication - Users shouldn’t feel as if authentication is being imposed upon them. Even in scenarios where authentication is mandatory, the bot must ask for consent before proceeding.

• A gentle nudge on denial - If the users don’t consent to authentication, then the bot should give a gentle nudge to try and get them to authenticate if it’s mandatory. If it’s not, then it should simply tell them that the functionality would be available, albeit in a limited capacity.

• The not-so-happy paths - The not-so-happy paths must be covered. Some of them are mentioned below. More could be added on a need basis
  • What is needed - What’s needed before proceeding to authenticate.
  • Where to find - Where to locate this particular bit of information.
  • Hold - Hold for the users to fetch this information.
  • Doesn’t remember - Users may or may not remember the piece of information that the bot is asking. It’s important to not only handle this but also assure users that forgetting something is not a big deal.

• Persona maintenance - The bot in this example implementation personifies a service desk agent and throughout the conversation, it carries this persona. It goes to an extent where it calls the service desk agent its “human colleague”.

• Exit point mapping - Users may exit from any point in the conversation, and it becomes super imperative to capture as many exit scenarios as possible. The exit point mappings are values assigned to the ‘exit status’ variable which is then logged in the database. This helps identify the outcome of a conversation quickly without doing a detailed data analysis.

Level 2 authentication - OTP based

Authentication scenario for an MFA (Multi-factor authentication) based scenario. Here the second bit of information is dynamic, and can’t be “forgotten”.

The high-level design for this scenario is depicted below

High-level design

Example implementation - Capturing employee ID and OTP

Example scenario - Asking users for their employee ID and OTP which is sent to their registered mobile number after they have successfully provided the first bit of information.

Key highlights

• Consensual authentication - Users shouldn’t feel as if authentication is being imposed upon them. Even in scenarios where authentication is mandatory, the bot must ask for consent before proceeding.

• A gentle nudge on denial - If the users don’t consent to authentication, then the bot should give a gentle nudge to try and get them to authenticate if it’s mandatory. If it’s not, then it should simply tell them that the functionality would be available, albeit in a limited capacity.

• The not-so-happy paths - The not-so-happy paths must be covered. Some of them are mentioned below. More could be added on a need basis
  • What is needed - What’s needed before proceeding to authenticate.
  • Where to find - Where to locate this particular bit of information.
  • Hold - Hold for the users to fetch this information.
  • Doesn’t remember - Users may or may not remember the piece of information that the bot is asking. It’s important to not only handle this but also assure users that forgetting something is not a big deal.
  • Didn’t receive OTP - Users may complain that they haven’t received the OTP, and the bot should do below two tasks
    • Assure users that it does take some time to receive. This is to prevent users from repeatedly asking for sending the OTP again. Each transaction has a cost.
    • Give them the option to request a new OTP.
  • Resend OTP - Allow users to request a new OTP.

• Persona maintenance - The bot in this example implementation personifies a service desk agent and throughout the conversation, it carries this persona. It goes to an extent where it calls the service desk agent its “human colleague”.

• Exit point mapping - Users may exit from any point in the conversation, and it becomes super imperative to capture as many exit scenarios as possible. The exit point mappings are values assigned to the ‘exit status’ variable which is then logged in the database. This helps identify the outcome of a conversation quickly without doing a detailed data analysis.