Simplifying A tracker to increase customer trust AND SATISFACTION

The existing system had a few issues. For starters, customers were calling into our customer care to complain about the tracking. The statuses weren't clear, and no notifications were being sent. 

The current tracker also did not align with Verizon's new branding and updated design system. Verizon's new voice was conversational and human with a touch of playfulness.  

Understanding the technician tracker

Data showed that customers were left confused about the statuses. Based on some preliminary research, it was evident that customers were getting frustrated by a barrage of statuses that they couldn't necessarily act on. 

Initial statuses and descriptions from the product brief. There were too many statuses that were not very clear.

These original statuses involved updates even before the technician was dispatched. There wasn't really much movement between Assigned and At dispatch.

The proposal to update this tracker with a map was also rejected by the technicians union. It also wasn't ideal to track the technician to such an extent, and this might also mean a breach of privacy of the previous customer whose equipment the technician worked on.

Working alongside three product designers, product owners and multiple teams of engineers, I set out to find some answers. Some of the questions I had included:

• What are some data points and user quotes we could use to decide the trajectory of this project?

• What strict constraints on location tracking did the technicians union have?

• What does our new brand voice look like when implemented? We were still cementing our new content guidelines, and it helped to iterate often to show the team when we hit the right note.

• What are some legacy systems and engineering limitations we're working with? 

• What did this feature need to do differently from the technology already in use today? Since we were overhauling the product design and copy for this feature, this was a good opportunity to revisit the whole flow.

• What's leadership's vision for this feature? We'd already had plenty of leadership changes and feedback that needed the team to pivot frequently.

Updated statuses

Based on feedback I received, I proposed some updated statuses. These were meant to be clear and concise, reassuring the customer without overwhelming them with updates.

These statuses were much clearer and reassured the users without bringing additional complications. Once we plugged these statuses into iOS dynamic islands, it was easier to present them to the stakeholder and get their approval.

I also proposed not bringing any backend statuses into this until we absolutely had to. Situations where we needed to apprise the user might include some backend delays or system errors that we're unable to explain in detail.

I used the iOS dynamic islands as a way to explore clear and succinct status updates. What did the user need to know? What are some backend statuses that don't need to be conveyed?

First drafts

When the users unlocked their phone, these statuses would expand to give them additional information. 

Initially, due to some triaging limitations, I considered not revealing the technician's name to the customer. 

First drafts that I created. These drafts helped me test my own understanding of the overall process and also align the team on our priorities.

The primary goal for the first drafts was to have some copy down so I could present this voice to the team and align with them. Was I on the right track? Having a starting point helped me bring something to the team to discuss and refine.

Up close and personal

I wrote many iterations where the status clearly explained what was happening with the technician appointment, but many of these iterations felt too cold and impersonal. This approach didn't align with Verizon's new brand, which advocated for a more human, conversational tone that left the customer feeling like they were being cared for. The ultimate goal was to give the customer the same personal attention that they'd receive if they walked into a Verizon store. The initial drafts of this experience weren't delivering that.

I spoke to the technical teams to get a deeper understanding into how the backend system worked. 

• At what point did they assign the technician? How soon in the process would they know the technician's name? 

• How did the technicians' union feel about having their identity revealed before they reached the customer's home?

Based on the input I got from multiple teams, I was able to create new copy that felt a touch more personal without getting into the creepy territory. 

Since the Verizon Design System's content guidelines were still getting solidified based on ideas from leadership, we didn't yet have concrete directions on the voice and language. So these iterations were crucial in helping the team visualize what the look and feel of the new Verizon brand voice was. How did the broader vision the leadership had for the brand voice translate in the nitty-gritty of the design?

I iterated on the copy, keeping in mind a few considerations: How can we make this a personal but safe experience for the customer? When is it a good time to call the technician by name? What are some ways to inject Verizon's new brand voice into these status updates?

Zoom in or out?

Just because we have access to more information, do we present it to the user? This was a key question that we didn't have the answer to. 

How much is too much or too little detail? 

• • Are we able to tell the customer how close the technician in minutes? And if we're able to, do we have to?

  • If there's a delay, do we tell the customer why? Do we tell the customer that a previous engagement ran later than expected, or some unexpected pre-dispatch delay occurred?

I also got in touch with customer care to understand their perspective. What complaints were they hearing from customers? What were the most common scenarios they dealt with? How can I accommodate them in the design and copy?

These were only some scenarios I hashed out with them. It was important to consider all these different situations and align the whole team on what we were letting the customer know.

Exploring more statuses. What level of information was TMI? 

As a next step, I proposed performing A/B tests with different levels of information. What did customers prefer? Any patterns we obtained from the initial testing could then be applied to refine this copy further.

Outcomes

A noticeable decrease in customer service calls and cancellations. The customer service team was no longer getting inundated with anxious customers trying to understand convoluted statuses. 

Reusable framework of statuses, alerts and notifications for repair, equipment exchange and technician visits. This new experience was not only consistent with the new Verizon Design System, but also formed the foundation for the new content guidelines we were developing.

This project involved so many moving parts, and several teams came together with granular pieces of knowledge to make this happen. This meant a lot of friction and data lost in translation, but it also meant the opportunity and critical need to get everyone on the same page. I realized quickly that one of the best ways to work in this kind of scenario is to gather all the key decision makers into one meeting and write copy on the fly. This truly tested — and improved — my ability to write copy on the spot without much preparation while also taking real-time feedback and polishing everything with everyone present in the room.