Migrating a network of 1.3K+ remote repair technicians and adding 800K+ annual jobs to the Asurion Field App

Migrating a network of 1.3K+ remote repair technicians and adding 800K+ annual jobs to the Asurion Field app

Repair Job Detail

Repair Job Map

Repair Queue

Overview

Overview

My Role

Impact

Impact

Impact

uBreakiFix has been a strategic partner of Asurion since the launch of their same unit repair (SUR) service. Historically, the majority of uBreakiFix jobs took place in store. In 2020, Asurion acquired uBreakiFix and wanted to increase the volume of national SUR jobs while streamlining the operational side of the business which included the app that technicians use.

Before this project uBreakiFix remote repair technicians were using Bringg, a primitive platform that's main functionality was to assign and route repair jobs. It was not designed to manage the complex daily tasks of technicians. My job was to redesign the repair technician experience while integrating it in our existing Asurion Field app that we built for employees delivering and setting up insurance replacement devices.

I partnered with one of my favorite designers and pal, Alex Fortney, throughout the process. We shared all responsibilities for research, ideation, iteration, and testing.

I partnered with one of my favorite designers and pal, Alex Fortney, throughout the process. We shared all responsibilities for research, ideation, iteration, and testing.

Migrating same unit repair (SUR) jobs meant doubling the number of jobs we were running on our app which translates roughy to 1 million jobs a year.

Migrating same unit repair (SUR) jobs meant doubling the number of jobs we were running on our app which translates roughy to 1 million jobs a year.

What's going on?

In order to understand what needed to be done I needed to understand the systems that were being used, what repair tech workflows looked like, what information was being passed through from which platform, and basic things like how techs were even checking out repair parts from the warehouse.

To make things even more interesting this project kicked off right as COVID shutdowns started which meant we couldn't do what I'd normally do— hop in a repair van for a few days. Instead, I pulled from existing research and UBIF documentation and bought a technician a GoPro so I could see what the job was like in the van.

What does a typical day look like?

What does a typical day look like?

Before this work, nobody in the product org understood a repair techs day looked like so I began collecting questions from stakeholders in Notion and created a “source of truth” for all the details.

Before this work, nobody in the product org understood a repair techs day looked like so I began collecting questions from stakeholders in Notion and created a “source of truth” for all the details.

Before this work, nobody in the product org understood a repair techs day looked like so I began collecting questions from stakeholders in Notion and created a “source of truth” for all the details.

Collecting existing documentation from uBreakiFix…

Collecting existing documentation from uBreakiFix…

This flow chart was the only asset my team got during the transition. Confusing, but workable.

Research

Research

Since the main objective of this project was to migrate all SUR jobs into the Field app the most important task was to create a flow that was as similar to what we currently had in production but accounted for the repair use case in an intuitive way.

It all started very messily. I laid out a simplified flow for same day delivery and a rough sketch of a flow for SUR. From that I made a pass at a V1 flow that raised a ton of questions. Namely, a lot of questions about what happens when a job doesn’t go as planned. This led to a lot of digging into the wonderful world of resolution codes and other edge cases.

Flows

Since the main objective of this project was to migrate all SUR jobs into the Field app the most important task was to create a flow that was as similar to what we currently had in production but accounted for the repair use case in an intuitive way.

It all started very messily. I laid out a simplified flow for same day delivery and a rough sketch of a flow for SUR. From that I made a pass at a V1 flow that raised a ton of questions. Namely, a lot of questions about what happens when a job doesn’t go as planned. This led to a lot of digging into the wonderful world of resolution codes and other edge cases.

Flows

Job Outcomes

Job Outcomes

More interviews

Additional interviews were critical to understanding resolution codes. We learned how much money could be lost if techs were putting in the incorrect resolution codes and how vitally important it was to get this part of the job flow right.

Additional interviews were critical to understanding resolution codes. We learned how much money could be lost if techs were putting in the incorrect resolution codes and how vitally important it was to get this part of the job flow right.

Additional interviews were critical to understanding resolution codes. We learned how much money could be lost if techs were putting in the incorrect resolution codes and how vitally important it was to get this part of the job flow right.

I know, it’s not the most exciting topic but this was the main thing that needed to be addressed in the next iteration. The first task was to identify all the possible outcomes and what that meant for the customer and the repair tech.

This meant a lot of talking to uBreakiFix stakeholders and documenting this well so we could communicate with our product and engineering partners.

(This photo was taken by a tech when we gave him a GoPro and had him record his day because we couldn’t do in-person research during COVID)

(This photo was taken by a tech when we gave him a GoPro and had him record his day because we couldn’t do in-person research during COVID)

One screen to rule them all…

If anything went wrong on the job the tech was given this screen and asked to select the correct resolution code. Obviously, there were a lot of incorrect resolution codes selected which was a huge problem.

If anything went wrong on the job the tech was given this screen and asked to select the correct resolution code. Obviously, there were a lot of incorrect resolution codes selected which was a huge problem.

Key takeaways

Although there were a of takeaways the most important were:

Although there were a of takeaways the most important were:

Although there were a of takeaways the most important were:

uBreakiFix techs have a lot more trust and autonomy than our Experts have. They need flexibility in the way they run jobs and they need to be put in the drivers seat.

At the same time, techs entering incorrect resolution codes is a real problem that costs the company a lot of money and causes huge headaches for customers.

Flow revisions

Flow revisions

In the next flow we got much closer to MVP, accounting for paths that would trigger a specific resolution code to reduce cognitive load on techs and reduce input errors. We also began exploring the idea of having a “hub” that gave techs more autonomy and flexibility than the more linear flows we gave Asurion Experts.

The circles you see are end points where we trigger resolution codes.

Screens

Screens

Taking the flows into screens was probably one of the easier parts because I just needed to reuse existing UI. There were a few exceptions and new screen created for MVP, the most complex being the tool belt/hub concept.

Since it would take a very long time to explain a lot of MVP I will just drop some in here to give you a taste of the kind of work that happened to arrive at MVP. Feel free to reach out if you’re interested in talking more about this project, it was a big one.

Repair Hub

By creating a central hub for each individual job we gave techs increased flexibility and a way to visually see where they were in the repair process. We also gave them easy access to all the tools they need like notes, ability to add photos, and important contact information.

Simplifying job outcomes

Simplifying job outcomes

Before, techs were given a huge list of resolution codes every time a job needed to be rescheduled or canceled (see photo in “job outcomes” section). This lead to a lot of human error, headaches for customers, and lost money for the business. By logically placing job outcomes where they belonged we solved this problem in a simple, intuitive way that didn’t limit the techs autonomy.

Below are examples of situations where a job is canceled because of an IMEI number that doesn’t match (yes, we have to list the whole number) and if a customer doesn’t want to disable Find my iPhone.

What happened next?

What happened next?

After we ran alpha testing with 5 uBreakiFix techs, I handed off the app to Alex for revisions and beta testing when I was moved to Asurion Photos to lead the Activation team. Luckily the app was in great hands and it was very successfully iterated on and ramped to all uBreakiFix stores in September 2020. We now have 1.3K+ techs running over one million jobs a year on the Asurion Field app.