2.4 - 2-factor user authentication with Zendesk (basic scenario)

Most contact centers are requested to authenticate the person who is calling their service. This often takes time and is quite repetitive for agents. One major benefit of using smart phone systems are the possibilities to automate user authentication, therefore saving relevant agent time.

Authentication can become as complex as it get, however, today, we will focus on one of the  most simple case. Again, we will make use of Zendesk to authenticate the user.

The use case

• A caller reaches your hotline
• In the background, the caller is looked up in Zendesk, using the phone number
  • The phone number therefore is the first verification factor
• In the next step, we check whether a user was identified based on the phone number
  • If no user exists under the calling number, the caller is forwarded to a standard flow
  • If the user is identified, we ask for the customer id
    • the input is read back to the customer and confirmed
    • then the input is compared to the information in Zendesk
  • If the id matches the information in Zendesk, the user can skip a long waiting time and directly jump to the queue of identified users
  • If the id does not match, the user is placed into the standard wait queue

The high level use case in babelforce

This is a use case that requires knowledge from previous chapters. We will not repeat some basics. You should be familiar with the article about looking up end users in Zendesk as well as the confirmation option in Speech to Text (STT) call modules. You should also be familiar with custom fields in Zendesk.

• For every incoming call, a lookup end user action based on caller id is running
• On a Switch node, we check whether the custom field "customer_id" contains data
  • If this is not the case, the customer enters a general ACD to be authenticated manually
  • If it does, the customer is asked to enter the customer id
• The customer who entered the customer id hears the input and is asked to confirm whether the input is correct
  • If it is not, the customer enters the general wait queue
  • If it is, the entered id is compared with the value from the Zendesk field
• If the input of the customer and the data in the Zendesk field match, the customer is authenticated and enters a fast track queue
• One important setup we will be looking at in this chapter is the fallback in case the customer did not provide any input in combination with a confirmation template

Implementing the use case

• First, you will need a customer field in Zendesk which stores the customer id. In our example we named it customer_id, but feel free to use any field name of your liking
• Start your flow with some Welcome Audio (TTS or Audio Player)
  • Add a Local Automation (Pre) to lookup the end user
• Following the Welcome Audio should be a Switch node. In this switch, we will be testing whether the variable integration.zendesk_v2.enduser.user_fields.customer_id is given. In your case, the variable depends on your field name, as you remember from the previous chapters.
• This is how the Switch node could be set up:
  • The single route checks in a trigger whether integration.zendesk_v2.enduser.user_fields.customer_idis given - if this is true, the call is forwarded to a Speech to Text module
  • If the route conditions are not true, the call goes to the After flow, the general question ACD - this is the end of this part of the call flow
• Let's continue with the path asking the customer to enter the customer id - in this case, a STT module could be used
  • You will get the best results if you enable numeric = true and define the minimum and maximum of expected characters
    • e.g., if your customer ids are always 8 characters long, min and max should both be 8
    • don't ignore "no inputs" - ensure to add "no input" but also "no match" audio or TTS to ensure that the customer has the chance to repeat the input if it isn't matching the expected value or if no input is provided
    • Call the variable customerId
  • We are adding a fallback mechanism for the scenario that a customer did not provide any input. This is very important! Always check whether you received any input before you read out the input to get it confirmed!
    • Create a switch node that checks that the variable customerId is given
    • If the variable is empty, the customer is led to the general ACD
    • If a variable is given, the flow continues to the the STT module, our confirmation module
  • The confirmation STT module is set up like this:
    • Remember to select the right template in the setting
    • As TTS, play back the customer's input, asking for instance:
      • Is your customer id {app.speechToText.customerId} correct?
      • The placeholder should be replaced by the customer's input
      • This is also the reason why you cannot let an empty input go to this confirmation, as the TTS would otherwise read the placeholder
      • You could name the variable customerIdConfirmation
  • Checking the customer's response in a Switch node and comparing the result with the variable from the Zendesk ticket field 
    • The STT leads right into another Switch node with a single route:
      • The trigger checks two conditions
        • customerIdConfirmation = true
        • customerId = integration.zendesk_v2.enduser.user_fields.customer_id
      • If this is true, the caller is forwarded to the ACD for already authenticated user
      • If false, the customer goes to  the general ACD
    • In either case, the call flow has reached its end

Of course, there are options to loop the customer back to the customerId input, however, this would extend this already complex flow even further.