Customer Support Callback

We mapped three scenarios as they were: scheduling a follow-up, letting the member know, and making the call. Each one’s problems fed the next. MSRs couldn’t capture the notes the next MSR needed; between calls, members got voicemails; and the MSR who called back had to ask members to repeat themselves. That MSR was rarely the one who had booked the call: “9/10 of the call backs are not us,” one MSR said.

With those insights and further research, we mapped how callbacks were scheduled. Each kind of call had its own method, only the third-party route carried notes on why the call was placed, and the process as a whole was complex for MSRs and not compliant with federal regulations.

With a roadmap agreed, the first designs went into InVision Freehand. They explored putting everything a follow-up needs on one page; further exploration settled on three steps: the call’s details, a date and time, and a review before submitting.

We tested in one-on-one sessions with outbound P&C MSRs: wireframes in December 2019, comps in January, revised comps with error states in early February, and the notes field on its own later that month. I wrote the research plans and moderated the February sessions, with a design teammate taking notes. In the role-played calls of early February, each MSR scheduled a follow-up, canceled an upcoming one and worked through error messages, then walked back through every screen to say what worked and what didn’t.

The wireframe round already pointed at the notes. MSRs understood what the section was for but wanted the most common reasons for a callback ready to pick; the recommendation was a set of options, with a smaller free-text box for anything else.

Throughout, we worked with Product and Development to understand the business requirements and the technical limits. One of those limits shaped the notes: the dialer that places the callback shows only 100 characters of them, so we tested whether that was enough for the next MSR to pick up the conversation.

Round after round, each set of wireframes gave way to the next.

A user flow helped business partners follow the solution: one window, opened from the MSR’s portal, that schedules a new appointment in three steps, or shows and cancels the member’s upcoming ones.

The high-fidelity comps went to development as design specs.

V2 added two things identified early in the project and sharpened by what MSRs told us: changing an existing appointment, and notes MSRs could click instead of type.

February’s comp testing had said as much about the notes. MSRs welcomed them and asked again for options they could select; the recommendation was to keep clickable reasons in mind for the next iteration past the MVP.

Scheduling a new appointment kept the MVP’s three steps, and scheduling and current appointments moved to tabs of their own.

The notes became reasons to tick, such as a time constraint, a payment constraint or a need to consult a spouse, with an optional line of free text. A second list records the documents the member still needs to complete their business.

Editing follows the same steps as scheduling: change the details if the member needs to, then the date and time, review, and save.

Five MSRs tested the V2 wireframes. They understood the new tab, and knew what to do when editing because it mirrors scheduling. The order of the Next, Previous and Close buttons confused at least two of the five, and three asked to choose how the member is told about the appointment.

After rounds of design and content reviews, feedback sessions and work with Product and Development, we delivered V2’s high-fidelity comps and prototype for production.