Creating a guided visit that removes uncertainty for Experts
Guided Visits reshaped the visit workflow, giving Enjoy Experts the confidence to help customers in every situation.
Drove collaboration with Partner, Field, and Support teams to ensure our redesign was carefully considered
Managed 1 product designer to help extend the Guided Visit framework
Presented the vision of Guided Visits to our Operations and Product teams to get alignment
Distilled complex Partner system flows and contextually integrated them into the Expert App
Designed a set of reusable task views that were interchangeable between Partners (AT&T, Apple, BT/EE, and Rogers) for efficient engineering implementationContext
When I originally designed the Expert App, an Expert’s role was fairly straightforward. They would deliver a purchased product at the customer’s requested place and time, then help unbox and set it up.
Over time, Enjoy’s service offering expanded to reflect our Telco Partners’ (AT&T, Apple, BT/EE, and Rogers). This meant that the role of an Expert required deep knowledge of each Partner’s POS system to be successful. Experts needed to process orders, add lines, upgrade devices, and sell additional services and products.
Most Experts felt unprepared and overwhelmed with the shear volume of workflows they needed to memorize. Along with negatively impacting our Experts, the lack of knowledge eroded trust with our customers, reducing our revenue, and impacting the number of visits we could complete.
A Guided Visit Experience
Since the Expert App lacked guidance for Partner workflows, many Experts wouldn’t even attempt to offer certain solutions, given their complexity.
How can we remove ambiguity from Partner workflows so an Expert feels comfortable positioning and adding solutions?
To alleviate this uncertainty, the redesigned visit flow in the Expert App functioned as a companion to our Partner systems.
An Expert initiated a task through the Expert App, then received contextual help with the Parter system to complete the workflow. The App provided the information an Expert needed to input, straightforward steps to navigate the system, and moments to capture serial and transaction numbers for reporting. These carefully considered task flows perfectly mapped to what an Expert was seeing in the Partner system, removing any ambiguity they once had.
Before arriving at this design, we had to better understand the existing flow’s limitations. Below I’ve documented the process I went through to break down our existing problem, and how we arrived at our Guided solution.
Issues with the Existing Experience
The existing visit flow in the Expert App was modeled on an early version of Enjoy. It was light on touch-points, only requiring Experts to capture a few inputs, and lacked any guidance when Experts were interacting with our Partner systems, which consumed much of a 30 minute visit.
Existing visit flow starts and ends in the Expert App, but the majority of time is spent in a closed Partner system.An Expert needed deep knowledge of each system to be successful and was often left on their own to figure it out. When an Expert got stuck, their only help was to call their market leader (not scalable) or connect with our support team through chat.
“On average, I spend 5 hours a day on the phone with Experts helping them with [Partner System].” - San Jose Market Leader
The lack of support was most acutely felt when adding solutions (new lines, upgrading devices, and Fiber). Our business relied on incremental revenue from visits, so an Expert had to be comfortable positioning solutions as well as adding them in the Partner system. Unfortunately, many Experts wouldn’t even attempt to offer certain solutions, given their complexity (some requiring over 60 steps to complete). Here’s an overview of some of the issues Enjoy was experiencing with the existing model.
-
![]()
Partner systems take a long time to learn
Experts were required to know the ins-and-outs of countless workflows, some requiring more than 60 steps to successfully complete.
-
![]()
Expert's rely on support to be successful
Because of these complex workflows, Experts continually reach out to Support or call their market leader when they need help in visit.
-
![]()
What happens in visits is opaque to everyone
We don’t know if a long visit is due to issues with a partner system, an Expert adding multiple solutions, or general lack of knowledge.
-
![]()
Hard to guarantee best practices are followed
New partner initiatives were not built into Expert workflows, so we relied on other ways to communicate best practices, like Slack.
Designing a Scalable Interaction Model
The existing interaction model had just two states in visit, a details view which housed the task list an Expert was required to complete, and a focused task view.
The task views were simple, just a screen or two to complete. If we were going to help Experts navigate the complexities of our Partner systems, we would need to include more involved tasks, some with sub tasks and branching, nothing that our existing model could support.
To accurately reflect our Partner systems in the Expert App, we needed to understand the nuances between each Partner and align on a set of shared, reusable task views. I created high-level workflow diagrams of each Partner system flow. From processing orders, adding solutions, exchanging devices, these diagrams allowed us to see common interactions and task types between Partners. They also helped me to begin to define a system that would scale to each Partner.
Mapping our partner system workflows helped to define a consistent framework that would scale to every Partner.Keeping Tabs and a Persistent Action Bar
After understanding where partner flows aligned and diverged from these diagrams, I set out to design an interaction model that would support more involved tasks, but contain them in a way that wouldn’t interfere with other parts of the App.
Adding segmented controls gave Experts a dedicated and focused space for their current task. If an Expert navigated away to reference or interact with another part of the App, their state was saved, so when they returned to their task they could continue where they left off.
Because our partner workflows could be so complex, I designed a persistent action bar that notified Experts what was next in their workflow and acted as the main call-to-action, moving Experts through a task.
Variations to the action bar gave Experts a clear understanding of the operation they needed to perform. State change action bars switched an Expert from one state of the visit to the next (Pre-Visit, In Visit, Post Visit). Progressive action bars moved an Expert through states of a task. Save state and destructive action bars complete parts of a flow, and skip state action bars allow Experts to bypass optional subtasks.
The combination of a focused view for each task and a persistent action bar throughout the visit, helped break down complex partner workflows and removed ambiguity for Experts. The next challenge required designing reusable tasks to make interactions obvious to Experts and implementation efficient for engineers.
The new Guided interaction model housed all tasks in a new task tab and also introduced a persistent actionbar that ensured Experts knew where they were, what to do, and what was next.Designing a Flexible System
From our high-level diagrams of each Partner’s workflow, I recognized similar tasks within and across partners. With some tweaks, we could build one task, derived from our design system components, and reuse it many times. This helped an Expert have a consistent understanding of how to perform each task, reducing cognitive load. It also allowed our engineering team to quickly implement workflows across partners.
AT&T and Rogers’ process order task provides a good example in how we could reuse task views across partners, with minimal changes. For AT&T, an Expert was required to process the customer’s order before adding any solutions. For Rogers, an Expert was able to add device protection and accessories onto the original order, including them in a single transaction. We were able to use content views to give an Expert instruction in processing the order for both Partners, use our add items subtask to capture the receipt ID for both, and simply add an additional add items subtask for Rogers to capture accessories and device protection add ons.
Using reusable views from our design system allowed us to flex based on nuances in partner flows. Here, AT&T and Rogers both had a Process Order task, but Rogers allowed Experts to add items onto the original order during the task, where AT&T did not.Outcomes
We recognized the sizable impact for Experts by changing their workflow - easier ramp for new Experts, removing ambiguity from Partner systems, reducing burden on market leaders and Support; but we were also focused on driving impact for our business.
By giving Experts guidance at the right times, we could ensure they felt comfortable positioning our partners’ complete service offerings, opening up additional revenue opportunities.
By providing help upfront, we could tamp down the reactive need to contact Support when an issue arose, effectively decreasing visit duration and ensuring Experts would complete their next visit.
Evolving business initiatives and being intricately linked to our Telco Partners meant continual changes to the visit experience. We were able to reduce the time and effort of changes by creating a scalable system for engineering.
Outcomes over 6 months7 minute decrease in visit duration
14% drop in Support outreach in visit
~20% drop in implementation effort for engineering
Postscript
Guided Visits was successful in what it set out to achieve - providing Experts with the contextual help they needed in visit, but we were also conscious of its potential risks.
Change management was a big risk with Guided Visit’s new interaction model. This required a cross-discipline partnership with Field Leadership, our Comms and Learning and Development teams to ensure Experts were onboarded to Guided Visits in the right way. We also partnered closely with Experts and Product Support throughout the design of Guided Visits to make sure we correctly translated their visit experience across Partner systems to the Expert App.
Another risk we identified was the burden we’d put on engineering with future changes to workflows. Even though Guided Visits made it significantly easier to modify the visit flow, we didn’t want routine, Partner-driven changes to fall on engineering to make. I started designing a wysiwyg that a non-engineer could access to see any Partner workflow and add or modify tasks as needed.
