Awesome Agent Experience — Payments
This summer I joined Intuit as an Interaction Design Intern. During my 10 week internship I worked closely with the Enterprise Business Solutions XD team on an internal tool that allows sales agents to sell products such as Quickbooks Online (QBO) and Payments to our customers. This required me to also talk to the sales team to understand their needs, understand care agents, and take marketing into consideration. There are hundreds of sales agents across the 11 Intuit campuses around the world.
Background + Research
To give some context, the EBS team works on tools to help the company be the most efficient it could possibly be. Recently a two year effort called the Awesome Agent Experience (AAE) has been spearheaded to rethink and redesign the sales agent’s experience since currently, sales agents are using really outdated software…
One project out of AAE had already been completed, a 3 step process of sales agents selling only QBO. My specific project was to think about how to sell Payments in the same way that we sell QBO. Below is the newly redesigned flow of sales agents selling only QBO…
To understand the current process of selling Payments more clearly, I watched a few research videos already recorded about how sales agents will apply for payments for the customer.
- Sales agents are spending a lot more time than needed if a customer wants to buy both QBO and Payments as they would have to visit a separate process for both QBO and Payments, both with multiple applications. Additionally, if they want an additional product like Revel, that makes three separate flows, all with multiple applications.
- There is a lot of manual labor being done such as copying the Application ID generated from the Payments application into the opportunity — this is causing the sales agent the pain and extra steps/time of having to go back and forth different screens.
- In the Sales Assisted Application (SAA) today, the payments offerings include marketing and channel attributes resulting in multiple filters and an unwieldy offerings list.
In the ideal world, the sales agent should quickly be able to 1. identify what the customer wants, 2. prepare items for payment, 3. checkout and apply for approval.
The experience should be painless, just like purchasing and checking out an item online. The less time it takes to check out an item through a sales agent perspective, the more customers that can be reached, which drives more conversions. That being said, our high-level goals for a new flow:
- Streamline checkout process for sales agents who are selling QBO and payments services. With a faster and more efficient selling process, the less confusion there is, increasing the number of customers reached, and increasing conversions. (early thoughts for potential solutions: parallel flow, less steps, simplify catalog)
- Automate processes on the back-end whenever possible.
- Provide a solution that scales to services and products beyond Payments (Revel, Payroll, etc…)
After sitting in an all-day design jam with designers from other teams, we visited various ideas and jotted down notes on post-its. Below are several ideas that a few designers, PMs, and people familiar with the sales agent tool came up with.
Review findings from Design Jam
After reviewing these notes, I grouped these post-its in an affinity diagram to see patterns and connections more clearly.
I transformed these into a document listing all the experience requirements and use cases. Both the experience requirements as well as the use cases would be revisited as the project progresses.
I started out reviewing the experience requirements, use cases, and ideas that other Intuit designers came up with at the design jam. It took around a month for me to understand the flow and the constraints (especially technical), and iterate. This required me to dive deep into understanding what the products conceptually are— Payments is a service, not a product, so technically, sales agents are not “selling payments” — they’re just applying to enable the ability to process credit cards. This also required me to understand the IA, especially within the product catalog.
With every iteration I would learn something new. Throughout these few weeks I talked with various people such as Samaj, the PM I was working with, Stephanie, the ex-sales-agent-now-business analyst who knows everything about the offers catalog list, Leslie, my design mentor, as well as Amanda, the researcher, and the rest of the EBSXD team.
On the first iteration, I sketched up three main design concepts, some inspired by ideas coming from the design jam, some more similar to others. At the same time I looked at IA of the product catalog.
Concept A — Parallel flow with Payments being shown in the same catalog as QBO. I first experimented with a parallel flow as it made the most sense that harmonizing payments and QBO would minimize the amount of steps a sales agent would take and the screens that a sales agent would see, getting the sales agent in and out as quickly as possible. The four variations were originally individual concepts but I realized how similar they all were, just nuanced in the information shown in the product catalog.
Concept B — Pre-flow hub for managing products. Concept A4, the product pre-selection, inspired what was to become an out of scope idea. The sales agents would see an additional step where he would be able to select products up front, and remove products if needed. However I later found this idea to be way out of scope and unnecessarily complex. It would also break when customers change their minds about what products to buy. This line of thought rules this concept out, as well as A4 (Product pre-selection).
Concept C — Inserting Payments as an extra step after the QBO catalog. From a business standpoint, this concept is beneficial as it prompts the sales agent to ask the customer if they want payments with every QBO order. Such cannot be done in concept A. On the flip side, this prompts the question of how much of a priority it is to be efficient.
Product Catalog IA
This was a challenge as currently, there are more than a hundred offers listed but in reality there are only four or five unique offers. The reason why there are hundreds of offers listed is that the duplicates are only present for the sole purpose of tracking which team is selling the products and services so those teams can get credit. In an ideal world, we would only display those four/five unique offers and track the sales channel on the back-end. However I believe that a huge part of design is not only empathizing with the user but also the PM and engineers. Because of time constraints, we will design and implement a solution that is not the ideal user experience for Version 1, but in the future I would continuously bring back the ideal design and continue to advocate and push for it. Through actively communicating with the PM and business analysts, Version 1 would extract information from the title of the offer and divide it into table columns that would allow the sales agents to easily sort through the offers.
(show offer list here)
I eventually narrowed the three concepts down to two concepts and then one, as some accounted different parts of the flow and were combined, some were very similar and were combined, and some were ruled out.
Research — Feedback Session and User Testing
This was a key moment in my design process because through research I realized my concepts did not follow very closely with the sales agent’s journey. A lot of concerns were realized:
- A2— what happens if the payments application doesn’t get approved?
- Since QBO Company and Payments Application are shown as tabs, doesn’t that imply that Payments is an optional tab/form to fill out? What if a sales agent misses the second tab? It seems unnecessary that a sales agent would have to click on the second tab every single time. How do we emphasize that Payments is a required application?
- C1 — If QBO Company and Payments Application are shown side by side on the same page, what would happen if a customer only wanted Payments and not QBO? And this is not very scalable either. When we introduce Revel or other add-on products, we wouldn’t be able to fit all those separate applications onto one page.
- It just doesn’t make much sense to have QBO and Payments process at the same time. What if we find that the customer doesn’t even qualify for QBO? It would be wasted time to visit Payments and then find that out.
I concluded that a parallel flow would not work well as there are many problems around a declined QBO. These concepts also do not closely follow the journey of the sales agent.
It seems that a sales agent will ask the customer whether they want QBO, and once that’s done, then bring up Payments. Once Payments is asked about, then Revel, etc. I came up with two concepts based on the user feedback sessions. Instead of QBO and Payments being processed in parallel, what if we allowed QBO to finish processing, then visit Payments? This not only solves for the declined QBO problem, but it also follows the sales agent’s journey more closely.
Additional Products Page
Master Products Page
(design ideal flow)
(refine visual design)
Challenges Faced and Takeaways
- Find balance of business goals, technical constraints, and user delightfulness.
- Really study and understand the user again and again.
- Time constraints — first design for version 1, but always keep in mind the ideal, long term solution. If I had more time I would constantly be revisiting the product and pushing for the ideal version.
- Bigger companies operate a lot slower. Pros and cons.