HR Service Line
An NDA-friendly recreation of one of my original designs. This simple routing app is for internal use by the HR department at a large technology and communications company. It identifies a caller's needs and sends him or her to the right agent or voicemail box.
Tab 1: Main Menu
This tab begins the conversation, and also serves as a base for when users want to start the conversation over. Note that the options for Leave of Absence (LOA) and Employee Relations do not have separate handling, and so they will not have their own tabs.
First, the user hears a greeting. Remember, this is a live app, but the company name has been redacted in honor of non-disclosure agreements that protect my clients.
After the greeting, there is a decision diamond. Handling for when the office is open and agents are available to help the caller is different from when the office is closed.
When designing VUIs, many of my colleagues would write "Yes" and "No" instead of "TRUE" or "FALSE." I would use TRUE and FALSE because many prompts (in this case, the blue rectangles) asked the user yes/no questions. We would map out a path for Yes, and another for No, and pretty soon there were a lot of Yeses and Nos all over the design. I switched to capital TRUE and FALSE to visually differentiate these paths from those for prompts, and make them stand out more. This particular VUI did not ask the caller yes/no questions, but it was still a standard that I kept. If your eye happened to catch TRUE or FALSE on the page, you knew it was related to a decision, no matter what.
If the office was open, the user would be given his or her first choice: Benefits, Leave of Absence, Employment, Employee Relations, or Anything Else. There were a number of deliberate choices in this prompt.
One was the persona. Every interaction in the world comes with a persona, whether or not one was deliberately chosen. In this case, I selected a more human, yet professional approach. Conversational approaches like this tend to make the IVR more approachable and easier to deal with, and make users more likely to forgive mistakes. They also improve brand image. No one wants to feel like they're talking to a robot that doesn't understand what they want or know how to help.
Another was the verbiage. Many IVRs are very explicit in stating "for blank, press blank" at each option. However, that most users don't need such thorough hand-holding. Once the stage is set by explaining what to do in detail once, the rest can be inferred. I did that here by explaining, "If you need help with payroll, please press 1," reducing it to "Benefits, press 2" after that, and removing the verb for all options after that, until the last one. Not only does this honor persona by speaking conversationally to the user, using human speech techniques they already use daily in the world, but it also shortens the prompt by cutting out unnecessary words.
There's an incoming link labeled "Start Over" that leads into the Main Menu prompt. Later, the user is offered the chance to "Start Over" if he or she does not hear the right option. Instead of coming back to the beginning of the IVR and going through the greeting and hours check again, the IVR starts the call right at the main menu to get things going again as quickly as possible.
You'll also notice the beginning of the tag system used in this design, represented by the green rectangle labeled "Set Tag." This is a routing app; its purpose is to identify the user's need and transfer him or her to an agent. Once the need is identified, the tag lets the system know what to do with the user once he or she reaches the Transfer tab.
Every prompt that expects a response from the user comes with error handling. This is an example of how that error handling works.
This particular design was for a Dual-Tone Multi Frequency (DTMF) IVR system--that is, an IVR that uses button presses as input. It will give the user options that he or she selects by pressing one of the numeric buttons on a phone's keypad. If the user presses a button we don't expect (for example, pressing 9 when the IVR has asked them to select between 1 and 6), or if the user does not respond at all, the IVR needs to remind him or her of the available options.
Here, we let the user know that something's wrong by starting the sentence with "Again" if we didn't get a response, or "I didn't quite get that" if we got an incorrect response. Then, we restate the available options as concisely as possible.
Automatic Speech Recognition (ASR) IVRs (the ones that you talk to instead of pressing a button) handle things differently. If the user "fails" the prompt, they'll restate the options, but then if there is a second failure, they will restate the options once more, but using DTMF instead.
Finally, if there is a Max Fail--that is, if the user fails the prompt more times than the IVR is designed for--the call will be transferred to an agent with the tag FINALFAIL.
Tab 2: Payroll
Every prompt that expects a response from the user comes with error handling. This is an example of how that error handling works.
This particular design was for a Dual-Tone Multi Frequency (DTMF) IVR system--that is, an IVR that uses button presses as input. It will give the user options that he or she selects by pressing one of the numeric buttons on a phone's keypad. If the user presses a button we don't expect (for example, pressing 9 when the IVR has asked them to select between 1 and 6), or if the user does not respond at all, the IVR needs to remind him or her of the available options.
Here, we let the user know that something's wrong by starting the sentence with "Again" if we didn't get a response, or "I didn't quite get that" if we got an incorrect response. Then, we restate the available options as concisely as possible.
Automatic Speech Recognition (ASR) IVRs (the ones that you talk to instead of pressing a button) handle things differently. If the user "fails" the prompt, they'll restate the options, but then if there is a second failure, they will restate the options once more, but using DTMF instead.
Finally, if there is a Max Fail--that is, if the user fails the prompt more times than the IVR is designed for--the call will be transferred to an agent with the tag FINALFAIL.
Tab 3: Benefits
The Benefits prompt became tricky. On the Payroll tab, I highlighted how stacking options together can harm cognitive load. However, here I deliberately did exactly that. Let me explain.
When I first designed the prompt, it was very simple:
"Alright, benefits. If it's about your health-related benefits, press 1. Elective benefits, 2. Retirement benefits, 3. Advocacy services and EAP, 4. Anything else, 5. (pause) To start over, press pound."
Afterward, the client got back to me saying that some users were getting confused because they did not know what "health-related" benefits or "elective benefits" entailed. As a result, they were selecting 5 for "Anything Else" and the client's call center was fielding calls they weren't equipped to handle. Notice the "Ext_" in some of the tags. That means that when the IVR transfers this call, it will be to a third party, meaning that particularly for elective benefits, there is nothing that one of the client's agents can do to help the user.
There wasn't really a better way to word these options, so to solve this problem, I needed to describe the options as concisely as possible. For the health-related one, I used examples, preceded deliberately by the term "such as" to help make clear that examples were following, and not options. Health insurance can cover a number of things: medical, dental, vision, life, disability, hospital indemnity, and much more. I chose medical, because it would be the most obvious clue to what "health-related" could mean; dental, to show the user that less prominent options like dental and vision and mental health insurance are included; and life, to show that less immediate health-related insurances are also included. For the elective insurance, I explicitly listed the options because there were only a few, and they were very specific and unrelated.
What about cognitive load? Using "such as" at the health option helps. So does grouping together "home, auto, or pet insurance." However, one more thing can help when you have no choice but to increase cognitive load, and that's the talent--the person whose voice is speaking to the caller through the IVR. I left coaching notes in the prompt that asked the talent not to read quickly, and highlighting places to pause, and to read without pausing. Structuring the delivery of the line can improve understanding and aid customer success when design itself cannot.
Tab 4: Employment
For this particular client, job listings are only available online, but job seekers would still call to ask about listings. Path 1 out of this prompt clearly lets the user know where to find job listings, which both guides the user and frees up resources at the client's call center. Afterward, it gives the user options to continue using the system or disconnect, and if the user does not respond, it disconnects the call itself.
​
Disconnecting the call might feel a little cold, especially considering that many people who call seeking a job hope to speak to a human. However, jobs with this client follow a process starting with an online application, which means the humans at this line can do nothing to help a job seeker. Not being to help a user requires a strategy, and in this case, that strategy is to let the user know, show appreciation by thanking the user for his or her time, and disconnect the call.
​
This tab also illustrates handling for users who need employment verification. For example, a user who comes here could work for a company that may want to employ someone who previously worked for my client. In this situation, the client only handles employment verification in-house if the employee left the client more than three years ago. If the employee left any sooner than that, verification is handled by a third party. Since this involved specific times, I need to be more clear to avoid confusing the user. I start with human language to preserve persona and engage the user, letting him or her know that something important is coming ("No problem. Now..."). After that, I clearly state the options, and include notes that coach the talent to deliver the line slowly and clearly.
Tab 5: Transfer
The transfer module is where the transfer to an agent actually occurs once the user's need is identified. The tags set throughout the VUI state where the user needs to be transferred, and also determine what the user will hear before being transferred.
​
Once the user has heard the appropriate verbiage, the IVR first determines whether the user will be transferred externally (to a third party) or internally. If it's an external transfer, I send the user off, and the IVR's work is done. If it's internal, we initiate the transfer, and begin a hold process until one of two things happens: either the call is answered by the intended agent, or the user decided to leave a voicemail.
​
The IVR checks on the user every two minutes once the hold begins, and when it does, it offers him or her the option to leave a voicemail instead of waiting on hold. Pressing 1 will end the hold, set a new kind of tag called a VM tag to "ELSE," and move to the Voicemail module.
Tab 6: Voicemail
Users come to the Voicemail module automatically if the office is closed, or if they press 1 while on hold. If a user gets here automatically, it's the first thing he or she will hear after the initial greeting on the Main Menu tab. I start by explaining to the user that the office is closed, letting him or her know when it will be open, and offering voicemail an option to begin helping solve the problem. If the user chooses to leave a voicemail, the IVR determines which voicemail box to record to, and sets that location in a new VM tag. Then, the user is sent to the Record function.
​
The Record function is also where users go when they press 1 while on hold to leave a voicemail. I give the caller instructions and play a tone called an earcon, and then the IVR begins recording. After 2 minutes or a maximum amount of silence, I play another earcon, let the caller know that the voicemail was successfully record it, save it to the appropriate voicemail box using the VM tags, and disconnect the call.