British gas Centrica
British gas agent tool
As part of a 12 week engagement with Centrica, we were tasked with improving the overall usability of their internal (Salesforce) tool used by service agents, with the aim of reducing average call times and repeat calls, while simultaneously increasing the first-call solution rate. As UX lead on this project, my role was to assist in the research process, derive key insights and then drive the high level design of a better tool, to then be handed over to Centrica’s SF consultants to be produced and shipped.
User research
UX design
Taxonomy
Object oriented design
The key bits
Engagement period
10 months
Point 1
Point 2
Point 3
Point 4
Point 5
Point 6
Point 7
Point 8
Location
London & remote
Point 1
Point 2
Point 3
Point 4
Point 5
Point 6
Point 7
Point 8
Aims
Paragraph text
Migrate online services from newly acquired satellite business into one place.
Decrease drop-off between landing and contacting sales team.
Increase recognition of new Planet brand with coherent and cohesive design.
Pains
Paragraph text
Planet Payment has acquired a huge number of services that may be difficult to reconcile in the mind of potential customers.
Until now, website has received very few visits, and even fewer completions.
Limiting factors
Paragraph text
Must be CMS-able within Drupal for reusability and scalable use.
Only a short engagement for the amount of functionality required.
Deliverables
Paragraph text
A full set of designs for the pages that would comprise the core website.
CMS-friendly components in Drupal with which the client can expand their offering.
Documentation for new pages and components to support proper use.
Big
Outcomes
Universal adoption
Our research-backed simpler workflow and revamped object hierarchy went on to be integrated into both Saleforce best practice methods AND BG’s other digital partner, ENSEK.
Global app improvements
Though our original scope focussed on a limited number of journeys, our research showed room for more holistic improvement, leading to far greater value delivered with the same time and resources.
Reduced task times using AI
Among the many untapped functionalities of Salesforce included the leveraging of their assistant technology, Einstein. Leveraging this in accordance with out research made way for huge gains.
The goal
British Gas, as part of a wider engagement with us, and a shift towards a new CRM infrastructure, was looking to overhaul the way its service agents interacted with end customers. The motivation? An internal analysis showed that the current state of customer service calls were a huge dampener to the goals of both customers and the business.
For customers: It reduced overall customer satisfaction rates for customers who were making multiple repeat calls to BG and waiting weeks for their problems to be solved.
For agents: It impacted professional targets and created huge inertia due to poor usability and lack of cohesion on a single platform.
For British Gas: It was a source of huge inefficiency, with over 40% of customer-agent interactions being repeat case calls, and directly conflicting with their wider aims of moving to a self service-driven model by 2024.
"
Our goal is to drastically simplify the customer support journey for Centrica agents. By identifying the best tool for the job at every step of the way and focusing intensely on how to make that tool work for the agent, we can free the agents to focus on what matters most – the customer.
When agents have a toolset that provides consistency, ease of use, and surfaces relevant information at the right time, they can serve the customer with empathy, ensuring Centrica customers are delivered the level of support they deserve.
When agents have a toolset that provides consistency, ease of use, and surfaces relevant information at the right time, they can serve the customer with empathy, ensuring Centrica customers are delivered the level of support they deserve.
"
Initial scope
As part of this wider aim, our workstream was set up to specifically target the portion of the wider customer experience that did involve direct engagement with a service agent, by targeting the agent-side tool as a necessary component driving this experience. We scoped the following 3 agent journeys to focus on:
01
Identification & verification (IDV)
Streamline and sequence repetitive tasks that help an agent identify the customer account and surface potential reasons for the contact, prior to actually engaging the customer.
02
Billing issues
Design the optimal approach to handling billing issues in Salesforce, centred around the journey of a customer contacting about a bill increase.
03
Metering issues
Design the optimal approach to diagnosing and handling metering issues in Salesforce, centred around an agent diagnosing an issue with a customer’s meter and requesting the customer submit a meter reading.
The timeline
Week 1
Learn and empathise
Paragraph text
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
Week 3
Learn and empathise
Paragraph text
Identify pain points to target on each journey.
Detail the current breakdown of tasks between ENSEK & SF, including overlap.
Identify the to-be breakdown of tasks.
Identify what information needs to be surfaced, when and in the best way.
Define success for each journey.
Week 10
Create prototypes
Paragraph text
Work with SF to create detailed wireframes that are testable and feasible within the SF construct.
Document the best way to implement in a manner that allows for component extensibility across SF for a consistent experience.
Week 10
Test and iterate
Paragraph text
Validate the to-be behaviour with real agents.
Identify further improvements, iterate, and re-test.
Week 12
Deliver designs and playbook
Paragraph text
Furnish a playbook to the business detailing how best to proceed should they decide to do so.
Foster a shared understanding of the benefits to be gained, considerations to keep in mind for implementation, and risks or challenges to be mitigated.
4
Hours of silent observations
12
Moderated interviews
3
As-is journey maps created
Pain point
Findings
There were multiple aspects of the current agent tool that created inertia and overcomplicated the process for agents, that extended beyond simply the journeys of billing or metering issues.
Unnecessary task switching
Agents have to switch back and forth between Salesforce and their billing & metering tool, Ignition, which carries all energy meter information about a customer.
Case inefficiencies
There are too many empty cases open and this leads to confusion and huge duplications of work.
Case notes are a pain
Creating notes added huge overheads to each case, and so either added to the effort or were ignored, leading to complications down the line.
Poor supporting literature
Knowledge hub (SF’s supporting articles) did not surface the information needed at the right time.
Guided journeys not optimised
Guided journeys are useful pieces of functionality but it is not clear when they should be used.
Poor workflow & task notifications
Notifications are inconsistent and do not provide useful next actions when surfaced.
Design
Outcomes
Our researched surfaced several key insights, but most significantly: wrapped up in the improvement of our 3 key journeys were crucial improvements that would span a far wider spread of the agents’ experience.
We approached the client with this conundrum. Ultimately, it wasn’t about simply finding clicks to reduce. The problems (and the solutions) were far more deeply entrenched. The findings of our researched were presented and they were received enthusiastically, along with the feature recommendations derived from our discovery phase:
We approached the client with this conundrum. Ultimately, it wasn’t about simply finding clicks to reduce. The problems (and the solutions) were far more deeply entrenched. The findings of our researched were presented and they were received enthusiastically, along with the feature recommendations derived from our discovery phase:
01
IDV
A simplified IDV process that allows agents to instantly look up a customer in SF and choose the best following action.
02
Cases
A refined case structure and object hierarchy that provides a more coherent approach to opening and solving cases.
03
Bills & metering integration
Surface customer billing & meter data from Ignition at the best time, in a way that is beautifully visualised and editable.
04
Smart next actions
Bring in ‘next best actions’ (NBAs) as a cognitively driven, ever present option for agents to streamline their workflow,
05
Guided journeys
Surface guided journeys for all suitable tasks, so that agents can follow a simple step-by-step process in most cases.
06
Case closure notes
Automatically generate case notes on close for all cases and use smart templates to cut down the workload.
69%
Decrease in time to completion
100%
Of agents preferred the new method
83%
Fewer clicks
IDV
Before
- Case opens in Salesforce.
- Switch to Ignition.
- Ask for customer details (either email address, postal address or account number).
- Enter details in Ignition and search.
- Locate consumer account number.
- Switch back to SF and enter account number.
- Assign customer to case.
- Add case details and continue.
IDV
After
- Case opens in Salesforce.
- Switch to Ignition.
- Ask for customer details (either email address, postal address or account number).
- Enter details in Ignition and search.
- Locate consumer account number.
Key
Benefits
Task & app switching
Agents have to switch back and forth between Salesforce and their billing & metering tool, Ignition, which carries all energy meter information about a customer.
Case inefficiencies
There are too many empty cases open and this leads to confusion and huge duplications of work.
Case notes are a pain
Creating notes added huge overheads to each case, and so either added to the effort or were ignored, leading to complications down the line.
01
Simplified case structure
Over a period of 6 weeks (alongside designing other features) we formulated a brand new case and object structure. This feature formed potentially the largest overall revision to the tool.
Case structure
Before
Paragraph text
New cases would be opened automatically with every inbound customer contact.
Agents had to search for a customer in a separate platform (ENSEK Ignition), copy their details back into SF and assign the customer to the new case.
Cases sat at the upper tab level of a 2-tier tab system, with customer details (or sometimes even other cases) sitting below them on the lower level.
Non case-related customer information is found primarily under the case itself, duplicating information on customer details pages.
Tab structure
Tabs in the tool sat across two levels high a high amount of repetition. Cases for example could exist as a top level tab with several other objects below it, or beneath other cases in a strange sort of infinite loop. This often led to confusing and highly inconsistent tab structures with no clear object hierarchy.
New cases would be opened automatically with every inbound customer contact.
Agents had to search for a customer in a separate platform (ENSEK Ignition), copy their details back into SF and assign the customer to the new case.
Cases sat at the upper tab level of a 2-tier tab system, with customer details (or sometimes even other cases) sitting below them on the lower level.
Non case-related customer information is found primarily under the case itself, duplicating information on customer details pages.
Case structure
After
Paragraph text
Inbound customer contacts first require the customer ID&V, after which the agent has the option to open a new case OR a recommended existing case.
Cases always sit in the lower level of the 2-tier tab system, under either a customer account or contact at the upper level.
Exiting a case tab or closing a case automatically prompts the agent to complete notes.
Cases are always opened against an action that would require one (even if it just taking a note), otherwise no case is created.
Tab restructure
We updated cases to follow a new tab model. Cases were no longer allowed to exist on the top level, having to exist both structurally and conceptually within a specific consumer account. The new top level was reimagined as the Incoming contact/Consumer account tabs (the former for during a contact and the latter for outside of a call or message). Beneath this tab, there could only exist 3 possible objects: A consumer/customer, a service address (billing account) or a case.
New cases would be opened automatically with every inbound customer contact.
Agents had to search for a customer in a separate platform (ENSEK Ignition), copy their details back into SF and assign the customer to the new case.
Cases sat at the upper tab level of a 2-tier tab system, with customer details (or sometimes even other cases) sitting below them on the lower level.
Non case-related customer information is found primarily under the case itself, duplicating information on customer details pages.
02
New case creation
The creation of new cases was a huge overhead for agents, who had to complete 30+ fields in a single page form when opening any new case. This was problematic for a number of reasons:
Paragraph text
Numerous duplicated and redundant fields.
Large number of mandatory fields front-loaded in journey.
No logical chunking of form completion.
No smart pre-population.
Redesign v.1
So we redesigned the case creation journey to better guide agents through the process, removing duplicated fields and better grouping them into multiple pages after an in-depth, SME-driven analysis of the existing form.
The result was a much more manageable process that brought in existing information, either from the ID&V process or customer utterances, to pre-populate as many fields as possible.
The result was a much more manageable process that brought in existing information, either from the ID&V process or customer utterances, to pre-populate as many fields as possible.
Redesign v.2
On testing our new case creation journey gained some significant accolades. However, it became evident that it did not go far enough to cut down the overheads required of the agent at the most customer-centric part of the interaction.
We decided to make a huge pivot; to a barebones journey that would only require the agent to enter the bare minimum details to move forward, and allow them to complete the remaining fields later on, potentially once contact with the customer had ended.
We decided to make a huge pivot; to a barebones journey that would only require the agent to enter the bare minimum details to move forward, and allow them to complete the remaining fields later on, potentially once contact with the customer had ended.
The
Result
Faster case creation
Agents were able to create richly populated cases with necessary details (i.e. not an empty shell) much faster.
Better communication
Redistribution of bureaucratic overheads away from communication-heavy part of the customer interaction.
Simpler process
More easily manageable completion of crucial case fields due to simplification and de-duplication.
03
Consolidated data hierarchy
In the old world, customer information sat across 2 systems, with all billing and meter information in Ignition, and CRM data and case information in Salesforce. This created unnecessary complexity for the following reasons:
Paragraph text
Switching back and forth was necessary in almost every single case.
Everything done in Salesforce had to be handled within the context of a specific case.
Information was duplicated across multiple parts of Salesforce.
Ignition understood customers via their billing account, while SF worked with consumer accounts (we will later get onto why this was an issue).
So we took an in-depth approach to reinventing this. With our new structure where consumer account details, billing accounts, and cases sat as 3 separate objects within SF, we were able to map each piece of information to one of these 3 objects, then designing each object as its own tab/page or card containing this information.
Consumer account
Data points
Account details & status
Customer contacts
Customer address(es)
Latest cases
PSR status
Billing account
Details
Transactions & billing
Readings
Data points
Account details & status
Customer contacts
Customer address(es)
Latest cases
PSR status
Cases
Overview
Notes
Guided journey
Files
Related
Workflow & handoff
Data points
Account details & status
Customer contacts
Customer address(es)
Latest cases
PSR status
Leveraging
Quick cards
The solution we decided on to best facilitate this was the use of a SF lighting design system component known as “quick cards.” These were highly flexible card-type components that enabled us to elegantly reorganise, categorise and display key data for agents.
Balance
A simplified IDV process that allows agents to instantly look up a customer in SF and choose the best following action.
Cases
A refined case structure and object hierarchy that provides a more coherent approach to opening and solving cases.
Leveraging quick cards
The solution we decided on to best facilitate this was the use of a SF lighting design system component known as “quick cards.” These were highly flexible card-type components that enabled us to elegantly reorganise, categorise and display key data for agents.
Balance
Paragraph text
Show me:
Help me:
Leveraging
Smart actions
Surfacing actionable tasks when they were needed formed a crucial part of the billing and metering journeys. We wanted an effective way to distill all available situational data into an associated recommended follow on, surfaced on two consistent reference points they could look to to streamline their next action.
On quick cards
The first of these reference points, more specific to these billing and metering journeys, was on the quick cards themselves, as static actions that would always be associated with a specific card.
On the magical toolbar
The second, was as a more dynamic and journey-agnostic ‘next best action’ (NBA) on the Einstein-powered actions and tasks toolbar.
Unpacking
The flow
We used the following three forms of research as sources of knowledge to create a ‘Next Best Actions map’ for the billing issues and meter readings journeys:
User (agent) interviews
What do agents do currently to reach each solution for customers? How do they decide the best course of action?
Exploration of the current taxonomy
What information exists currently in the system? How are tasks, case types and solutions mapped?
Interviews with industry SMEs
What is the optimal path to solving each customer’s problem? How should agents optimise their decisions?
User driven
Data input - Utterance
What is the user saying coming into the call that we can use for early or even pre-call triage?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
System driven
Data input - Agent
What is the user saying coming into the call that we can use for early triage?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
Paragraph text
Customer details
Previous/recent cases
Latest bill reading
Current balance
Agent driven
Triage
What gaps does the agent have to close to refine the potential solution?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
System driven
Identify problem
What problem can we then ascertain from the combination of?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
System driven
Propose
What is the solution directly derived (usually 1:1) from the problem?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
Agent driven
Solve
What now needs to be done to action this on the agent’s side?
Gain deep understanding of the users and the challenges they face.
Identify specific journeys to focus on.
Create a shared understanding of success.
Map end-to-end process.
Identify enablers of and blockers to accelerate from here.
Magic
Moment
To better understand the Triage step of this [map], we mapped out a full decision diagram to represent the manual ways agents would reach a solution to a customer’s problem, based on every input they might receive. This exercise had never been done in British Gas before and took over 20 hours of interviews with agents and SMEs, but proved invaluable.
A Next Best Action for
Everything
The result of all this was the blueprint for a much improved NBA sidebar that would go on to enrich the overall agent experience, not only for the billing and metering journeys, but throughout all tasks.Other examples of NBAs we introduced included:
Adjusting vulnerability status
Triggers:
Paragraph text
The customer was new to British Gas (agents were already encouraged to ask all new customers)
Certain parameters including passing a certain age threshold
Adding a new customer to the system
Triggers:
Paragraph text
Always suggested pre-ID&V completion in case of a call from a new customer
Opening an existing case
Triggers:
Paragraph text
Agent has ID&V’d a customer and an open case matches the customer’s utterance
Customer has called in to British Gas within the past ‘x’ days and case is not closed
Upload a file
Triggers:
Paragraph text
Agent has opened a metering case under specific sub-categories that require attachments such as photos but has not yet uploaded any
Agent has received communications from customer with files attached
Workflow
Pains
A major pain point we encountered in our research that was not foreseen in our brief surrounded the case workflow. Cases would occasionally be opened by one agent but picked up by another, who would have little context besides the notes they were given.
Minimal incentive
Ultimately there was no real reason for agents to want to take notes. The process was usually enforced by management where possible.
Arduous overheads
Taking notes was a long and arduous process, requiring agents to perform significant overheads at the end of every customer engagement.
Room for variance
Notes are not snowflakes. They do not thrive and blossom in their uniqueness. Even so, there was a lot of room for differentiation in quality and structure.
Design
Changes
Based on this we updated the design of the opening and closing case journey to work in the following ways:
01
Autopopulate case details
New cases, when opened, would auto-populate as many case detail fields as possible based on incoming data, and prompt the agent to manually fill in any remaining fields.
02
Easy complete
The case close button was moved to the toolbar of any case tab, so that the agent could close it easily.
03
Quick closure notes
On closing a case OR exiting a case tab, Salesforce would trigger a smart modal to prompt the agent to create at least basic notes. This would be pre-populated if possible.
SME reviews
We embarked on a series of review sessions with the aim of finessing the information structure of our key components, cards and pages to ensure we were displaying the correct data points where agents needed them most. This involved over 30 hours of review sessions, presenting visual reference points either in a 1-on-1 or focus group settings.
4 object cards
3 toolbars
8 billing & metering cards
5 insight cards
7 action modals
Moderated testing
We also conducted 6 x 40 min testing sessions, each asking agents to complete 1-2 tasks in a mid-fidelity prototype. The aim was to test the true impact of our design on those who will be using them, agents, with the aim of getting accurate and actionable feedback and thus make improvements.
The result was a refinement of:
Paragraph text
A new case creation journey
Core information architecture
69%
Decrease in time to completion
100%
Of agents preferred the new method
83%
Fewer clicks
"
Andrew’s contributions were critical to the success of an important initiative with Centrica. His expertise in UX and User Research ensured our designs met the needs of the end user and client goals. The project had significant challenges as we had to balance the constraints of Salesforce, with reported desires of call centre staff, needs of the end customer and the business goals of our key stakeholders.
Andrew demonstrated strong leadership skills, leading client presentations and building their trust in our ability to provide impactful solutions. He also provided mentorship and guidance to more junior designers, creating a supportive team environment.
His proficiency in wireframing and prototyping enhanced our project deliverables, ensuring they were both feasible and functional. Andrew will approach any project at CI&T with positivity and a solution led attitude.
Andrew's collaborative nature and commitment to delivering great work make him a valuable team member. I look forward to working with him again the future.
Andrew demonstrated strong leadership skills, leading client presentations and building their trust in our ability to provide impactful solutions. He also provided mentorship and guidance to more junior designers, creating a supportive team environment.
His proficiency in wireframing and prototyping enhanced our project deliverables, ensuring they were both feasible and functional. Andrew will approach any project at CI&T with positivity and a solution led attitude.
Andrew's collaborative nature and commitment to delivering great work make him a valuable team member. I look forward to working with him again the future.
"