For years, the RIFT contact centre agents had been using limited, generalist software to input the claim information provided by their customers.

Despite each agent making up to 100 customer calls every day, there was no dedicated system to help them with such a specific task. Instead, information was entered in a generic account area, resulting in inconsistencies in the data captured.

RIFT asked me to help them create a more intentional and tailored application for their staff, providing a tool that actively aided their task, rather than simply facilitating it.

Content writing

Form design

Interface design

Journey mapping

Pattern library

Prototypes

Stakeholder interviews

Wireframes

Before I could offer solutions with any confidence, I first needed to understand how claims worked, what the data capture process looked like, and where people were being slowed down or tripped up.

I met with a number of stakeholders, working at various levels of the claim process, to discuss both the existing claim process, and their vision of what a new world may look like.

As well as asking people for their opinions, I wanted to witness the capturing of information for myself. I spent hours listening to RIFT agents speak to customers, and in doing so uncovered a number of opportunities for software to improve the process.

The process of capturing claim information by phone is mimicked almost entirely by RIFT's online customer-facing tool, MyRIFT.

Where possible, we borrowed the order of question, their wording, and any additional explanatory content from MyRIFT. Reusing these decisions helped us avoid duplicate work, and reduced the amount of maintainable content.

Presenting questions in such a way that they could be read out verbatim to customers meant that less confident or experienced agents would be be afforded additional guidance in how to ask for customer information.

The application the RIFT contact centre agents were using to capture customer details was clearly functional, but it offered little help in structuring how claim information should be gathered.

The system was designed to give complete flexibility to the agent, allowing them to capture and enter customer details in any order they chose to. However, it was apparent that different parts of the claim process were closely related, and the ideal path through the various steps was very much linear.

It was evident that certain answers from the customer had a direct impact in narrowing the scope of subsequent questions, so by solidifying the order of tasks, we were able to create a shorter, more focused path through the steps.

With the web forms the RIFT agents used being multipurpose, there was very little to help the agent navigate a customer call.

By acknowledging the sequential steps of the process, it became possible to introduce a loose call script. With the increased structure and rigidity of the call, we could now be confident in the direction of conversation, allowing the system to present hints, suggestions, and even shortcuts to functionality at the very moment the agent needed them.

Due to the nature of tax claims, RIFT often need to gather complete timelines of what their customers were doing across four year periods.

The previous system had no concept of how complete (or incomplete) a set of date-based information was. For example, a gap of four months between two employments would have been left unexplained, when in reality it could be a third unidentified employment, or simply a period out of work.

While listening to customer calls, agents would routinely use the last answer given to drive the next question. For example, after establishing that somebody was employed by the MOD, the next question might be, "where did you work before the MOD?". A truly powerful tool should do the same thing.

I proposed the idea of a 'timeline', where we'd start with a single question, and with each new answer, we'd generate a new question, relative to the last response, until there were no gaps remaining for the period. This approach would give agents more confidence in the information captured, and ensure that any refund covered the entire claim period.

Claims are usually made annually, so quite a bit of time will usually pass between a customer making their first and their second claims.

When they return, there will be some expenses which were true the last time they had contact with RIFT, but may or may not be correct now.

The Conversion Wizard includes a step for returning customers, allowing the agent to ask which of their previous expenses they're still incurring now. The agent can then discard any expenses which are no longer applicable, and automatically export everything else through to the new claim.

JO STREETER, RIFT — IT PROGRAMME MANAGER

An 'expense' is effectively any taxable cost incurred by a customer in their line of work. Previously, all expenses were captured equally.

From reviewing the different types of legitimate expense types, it became clear that all expenses fell into two categories: those that happened on site, and those that didn't.

If a customer spent £8 every day on lunch while they worked in London, but only £4 a day while in Leeds, these costs would otherwise require follow-up questions to establish the dates of each expense. However, by recognising the relationship between the expense and where they were when they incurred it, we can use the information we already have about the workplace to infer the dates, reducing the number of questions, and simplifying the process for all parties.

Capturing dates is a huge part of information gathering process, and it was a priority to allow agents to enter them in the most efficient way.

In the Conversion Wizard, some dates need to be exact, while month/year is acceptable for others. Often, if a date is prior to April 2017 (four tax years ago), we simply need confirmation that it fell outside of our period of interest.

Many things can be simplified, but even in their simplest form, some things are inherently complex.

Each expense has a type (e.g. a meal), a cost (e.g. £4.50), and a frequency with which it was incurred (e.g. per day). The expense may be true between a given date period, or simply reoccur throughout the claim. There can also be more than one of the same type (e.g. breakfast and lunch), and different sectors can claim different expenses.

I designed a two-step expense process, first capturing any expenses specific to a physical location, and secondly the general costs of doing business. In the first phase, a single value is asked for each expense that the customer incurred. By default, it is assumed that each expense applies to all of their work on site (i.e. £3 per day for meals, no matter where they worked), although a location-by-location breakdown can be used where a more granular level of detail is required.

Each expense uses a sensible default for its frequency (e.g. the daily cost of meals, or the monthly cost of their mobile phone), and each type has a pre-defined set of alternative options too (e.g staff wages are monthly by default, but could also be weekly, yearly, or one-off payments).

There are certain answers a customer can give that end the opportunity of a claim.

Previously, it fell on the agents themselves to determine when the possibility of making a claim had ended. The risk of leaving this to chance is that, when missed, there's a considerable time cost to both the agent and the customer.

In the Conversion Wizard, issues are highlighted immediately, making the agent aware that the claim is no longer valid. This helps the agent and the customer to avoid spending any longer than they need to on the process, and allows RIFT to communicate the bad news in a timely and consistent manor.

Read original case study: https://chrisannetts.com/conversion-wizard