Asurion

Making sense of a massive operational challenge

To complement Asurion’s new service line, our teams moved fast to learn, test, and iterate on a streamlined solution for end-to-end appliance repairs.

The challenge

When Asurion set out to add major appliance repair as a new service line to its catalog, teams started moving fast—too fast. We had a myriad of aging tools, all completely disconnected from one another, and disparate teams that all needed access to similar information. This was leading to confused customers who missed critical communications, and experts that couldn’t answer basic questions about the repair process.

In the beginning, we only had loose metrics as our target, given the speed at which this new service line was evolving. We knew we needed to get call resolution time down and the number of jobs booked up, so we set that as our guiding light.

Approach

For this work to be successful, we needed to deeply understand the problem space. We started with a huge number of interviews, ranging from stakeholders across the company to the user’s calling customers to collect triage and parts information. We used Notion to keep track of progress and synthesize notes.

I kept track of the discovery process in Notion, my favorite tool for collecting notes.

One trend became clear: no one fully understood the capabilities of our current systems and what pain points existed for our users. So, after getting to know them through interviews, we hung out with them for a week to watch them answer calls and to pick their brain about the entire process. Along the way, we documented everything, including screenshots of each step.

The workshop

With a week’s worth of “chair-sharing” and gathering documentation and screenshots of the current system, I worked with the product domain leads to organize and facilitate a large virtual workshop across product, operations, and supply chain. Our goal was shared understanding of the current platform’s shortcomings, and action items for teams to move forward and make it better.

I took a simplified service blueprint model and broke the flow down into five discreet buckets for us to go deep on. Each bucket had detailed steps tied to system events and customer/expert interactions. To build empathy with our cross-functional team, I also used video clips to showcase real customer interactions and how our current software was being utilized.

It looks like a mess, but led to a very structured session

MVP iterations

After a few weeks of discovery and a productive (and fun!) workshop, the teams were ready to build something to start getting feedback. However, while we had been going deep into the problem space, our Operations team had continued to move forward, booking new jobs with customers and creating downstream effects that were showing up on our NPS scores. We had to move fast.

We started at the beginning: when customers call us to schedule. Leveraging a Salesforce interface layer called Skuid, we created a custom scheduling interface that followed patterns we had created for customer-initiated scheduling.

Our original version was optimized based on our customer-facing web scheduler.

Our first version forced our experts into a very linear flow, where we segmented scheduling, problem diagnosis, and customer information in disparate steps. While this worked for a customer-facing flow, it didn’t match the natural ebb and flow of voice calls with customers. We quickly pivoted and tested prototypes of a “sticky sidebar” that allowed experts to capture customer and triage information while choosing appointment dates at the same time.

Our fast-follow made the flow less linear, to allow experts to converse with customers more naturally.

Slow it down

After a series of quick releases that were largely driven by requirements from our Operations department, and weeks of working with new team members and contractors who weren't as familiar with our product team process, it became evident that the team was struggling. Through 1 on 1s, deep interviews across the entire team, and unfortunately an exit interview with one of our designers, I synthesized all the feedback and came up with a proposed action plan to discuss with senior product leadership.

We agreed that these problems needed to be addressed immediately and that my action plan was a good approach, but wanted to give the teams a chance to brainstorm about what kind of change they wanted to see.

I organized and led a “reframe workshop” that started with a retro, a review and shaping of the vision and mission statements for the domain, and ideation on jobs to be done, all of which helped us reorganize and re-focus the teams.

I like to run sailboat retros because it’s fun and is a format that everyone can understand

Affinity grouping of output from Jobs to be Done exercise

Outcome

After one month of norming and storming with new teams, and a fresh take on our ceremonies and touchpoints, the feedback from the team was overwhelmingly positive. The team felt largely unencumbered to focus on the most impactful work ahead.

To help set the tone for where we wanted this app to go, I worked with the Senior Manager in this team to create a One App vision to share with stakeholders. This included a synthesis of research and insights and a renewed focus on the visual execution within the Salesforce platform.

Really taxing the limits of Salesforce