Dental Provider IVR Sample

This dental insurance customer had some specific requirements around the playbacks at this point in their provider IVR. They asked for particular fields to be played back, and wanted it as quick and painless as possible.

The dynamic playback was heavily dependent on the nature of the API returns and the table values.

This simple solution was exactly what the customer expected, a no-frills playback of dental history.

Large Project Case Study

The project

A large power utility with 80% market share in its state has an extensive automated phone system. The documentation of this system is just over 2000 pages long, including design, development, and grammar requirements.

I was the lead designer for this project for more than 2 years. My charter was to unify the tone and persona across this immense project, all while building usable and elegant conversational functionality.

The team

The size of my team varied between 1 and 6 designers. The modular nature of the project provided an ideal environment for new designers and interns to learn the processes involved, with the opportunity to build functionality from start to finish.

Additionally, the customer wanted to use their own internal designers, so I supervised their training and design work as well.

The result

In addition to completing a best-in-class automated system, the customer was thrilled with the quality of work and organization of our team. The designers under me went on to lead successful projects of their own. They brought innovative ideas to the design practice, and their techniques were integrated into the process.

Usability Case Study

The product

The product is a proprietary metrics analysis tool, specially designed to analyze logs from inbound phone systems. It’s a GUI over a database.

Defining and recruiting the user archetypes

We determined a range of users, from the non-technical director who only wants the bottom line, to the experienced Speech Scientist who is trying to solve a deep data problem. Then, we found each of these users incarnate.

Designing the test

It was important to us to test a range of skill sets, so we designed a range of problems with varying difficulty. Some of the tests were just to evaluate discoverability, while others were to complete specific filtering tasks. The last scenario was incredibly generic, but typical of real life: People are having problems. There's no specific complaint. What can you find that might be making people complain?

Moderating the test

I worked with the participants over a 2-day period, monitoring their behavior from the adjacent viewing room and taking detailed notes on their behavior. When they got stuck, or otherwise reached an unrecoverable point, I would regroup with them to get feedback. We found everything from major bugs to an unfortunate kerning problem.

Writing up the recommendations

It became immediately clear what needed to be fixed, and in what priority. I categorized my notes into a deliverable that made it easy to track the progress and disposition of each item.

Fraud Case Study

The problem

My large utilities customer had an issue with callers attempting to make check payments using fraudulent routing numbers. This needed to be fixed immediately. The customer provided a list of the routing numbers that needed to be blocked. They also needed a sternly worded message played when the fraud attempt was detected.

The team

We scrambled all the needed skill sets: a UI designer, a Spanish localization specialist, a developer, a QA lead, a speech scientist, and the recording studio. Very quickly, we identified all the details of the solution, laid out a plan for rapid design, implementation, testing, and deployment.

The solution

We added logic to the existing routing number collection to check the given routing number against the list of fraudulent numbers. We worked with the customer’s legal department to finalize the stern warning. We added logic to allow the caller another try to provide a valid routing number. We had all the prompts localized into Spanish, and had all the new prompts professionally recorded.

The outcome

The turnaround time from reporting the problem to our team to the deployment of the solution, was 36 hours including all the change control restrictions on the customer side. The customer reports that there are no longer any instances of this type of fraud occurring on their automated system.

Life Insurance Case Study

The Problem

The customer, a large, well-known life insurance company, needed a complete overhaul of their antique automated phone system. They didn’t know where to begin.

Where to begin

I met with the stakeholders and we made a list of all the functionality they wanted, all their business rules around those functions, as well as details of the back-end values that were available for use. The customer had already a persona defined, as well as user archetypes. They also had a voice talent already contracted.

Whiteboard the design structure

Using the inherent structure of their business, we worked out a plan for the high level flow that would fit with the persona. Authentication determines the policy type, and each policy type has a unique subset of functionality. The idea was to build reusable functions that would be called when chosen from a given menu. After discussion and refinement, the business agreed on the approach.

high level flow chart of IVR functionality

Sample conversations

I put together sample conversations so the customer could get a feel for the overall experience. This allows the customer to see how their business rules would be implemented. This also gave us a chance to verify that the back-end variables were mapping to the right fields.

Complete the specification

Now that the customer liked the samples, the detailed specification could be written. While writing, I worked closely with the development team to ensure back-end accuracy, and with the QA team to ensure that all the use cases would be covered. The resulting documentation, including all the error handling and global behavior, was handed off to the development team.

Deployment

Because of the close communication between design and development, the project deployed without any major defects. The SIT and UAT passed without any problems. The first round of metrics showed that the containment rate doubled, reducing their call center expenses by several million dollars in the first year alone.

GoTo Chatbot

We lovingly refer to this bot as the MegaBot. It allows the same bot to be used across several domains.

It has been designed to handle requests for any of the 12 products in the portfolio, and retain the product context while it navigates the flows.

This bot also has answers for >80% of the support questions.

One innovative feature is the automated help for joining a GoToMeeting or GoToWebinar. The flow successfully talks the user through the steps to join a meeting or webinar, saving countless helpdesk tickets.

Another innovative feature is the 'help me decide’ flow for prospects. GoTo has several products that have similar functionality, and users don’t always know what they want or need. The user can select ‘help me decide’ from the product selection menu, and an alternate flow will ask more detailed questions to help narrow the product choice.

Grasshopper Chatbot

The Grasshopper chatbot was an interesting project. The marketing shifted from a slightly goofy interface to a theme of putting a professional face on your micro-business. The recent rewrite reflects this shift in persona. Also, no live chat agents are available, so the design had to be carefully constructed around that business rule.

LastPass Chatbot

I designed the LastPass chatbot for 2 distinct audiences: prospects and existing customers. Prospects receive a light touch TOF flow, with larger businesses escalated to live chat sooner rather than later. Existing customers get the support experience, covering >80% of support topics.

This bot has several successful innovative features:

1) By far, ‘forgot master password’ is the most frequent request. The bot talks the user through 5 different methods of password recovery, leading to a 4-5% decrease in associated helpdesk tickets.

2) Data showed that users often asked to cancel their account, but only because of a forgotten master password. The cancellation flow asks first if the reason for canceling is password related. If so, it runs the password recovery flow. Implementing this flow resulted in 8-9% decrease in cancellations.

3) Usability testing showed that new users frequently stopped using the product soon after installation because of a lack of instructions. The bot now has an on-boarding flow that talks users through several important features.