Mar 1
Case Study: Empowering 600,000 Pest Control Customers
Note: In deference to the company and its SEO efforts, I have changed the company name to Acme.
Summary
- Problem: Acme’s 600,000 customers didn’t have a good self-service option.
- Solution: Create a customer dashboard for things like account information, payments, and service scheduling.
- Business constraints: The portal had to sync with multiple data sources and the login had to use a third-party authenticator.
- Timeline: 9 months from concept to MVP release.
- Outcome: The beta release of the customer portal successfully achieved its KPIs and is projected to save the company $1.5M to $2M in 2024.
- Tools used: Figma, Lucid, FullStory, and other data analytics tools
Project Takeaways
- Thorough research and data analysis was critical to the project’s success. Empathetic research, such as listening to customer calls, helped us prioritize features based on most-common user needs.
- Strategic design choices, such as intentional friction, can help direct user behavior in a way that increases ROI.
- Agile Development is not always the enemy of good design.
Introduction
In this case study I’ll show you how I worked with my product team to design and release a customer portal for 600,000 customers, and how we did it in only 9 months. I’ll show how this product, including some strategic design decisions, will save Acme around $2 million per year, while also significantly improving the customer experience.
Background
Imagine you’re a new Acme customer. You did your research before signing the service contract and found they’re one of the largest pest control companies in the U.S., just behind Orkin and Terminix. They’ve got over 600,000 customers and their reviews are generally better than the local competition, so here we are.
A month goes by and being the savvy consumer you are, you want to have a look at that service contract. Now where did you put that? It was electronic so you should be able to see it online, right? And when is that service tech supposed to spray again? And what email address did you give them? And what if you want to change which credit card is being billed?
The answer to all these quandaries seems to be, “call the 800 number.” Ugh. Surely a company with upwards of $1 billion in revenue would have a nice customer dashboard where you can take care of all these things yourself, right? Well, not exactly.
The Problem
The customers didn’t have a good self-service option.
Like most pest control companies, Acme has relied on third-party software to manage its customer data. We were in the process of building a custom CRM application as part of a future SaaS offering, but for the time being the customer dashboard provided by our CRM vendor wasn’t going to cut it. The feature set was so limited that it was better to just have the customers call the toll-free number for just about everything.
Research
The company was spending millions of dollars on call center staff, VoIP systems, IVR software, additional CRM tools, and much more. Our data showed that over half of the inbound calls were for issues that a customer could take care of themselves if they had a customer portal. The annual savings was estimated at around $2 million.
Our research showed that there were ancillary expenses that a customer portal could also help mitigate. For example, We were spending nearly $10 million per year on credit card processing fees. Most of the customers are on auto-pay, so the call volume for payments was relatively low. But even with auto-pay, we were still being hammered with processing fees. We needed to get more customers on ACH payments. Of the 600,000 customers, less than half of one percent were on ACH.
Planning and Strategy
Throughout the customer portal project, I worked closely with the project manager to ensure that the design and development efforts were aligned with the overall product strategy. Early on in the project, we had a series of meetings to define the product vision, goals, and objectives.
We used this information to develop a set of key results (OKRs) that would guide our efforts throughout the project. These OKRs were used to prioritize features and ensure that our work was aligned with the overall business goals of the company.
Empathy
One of the most glaring issues for the customers was one that I could personally empathize with: I hate making phone calls. For introverts like me, the thought of waiting on hold and then talking to a bubbly customer service agent triggers an irrational dread.
We wanted to see what the experience was actually like for the customers, so we listened in on some of the recorded calls from the call center. We were pleased to find that call center agents were professional and friendly and were able to resolve the customer's issues quickly and professionally. But, our observations confirmed our quantitative research. More than half of the calls wouldn’t have been necessary if the customers had a good self-service dashboard.
Ideation and Feature Mapping
Once we had identified the problems that needed to be solved, the next step was to begin ideating and designing a customer portal that would meet our customers’ needs and reduce call center costs.
On most projects, I would have conducted user interviews at this point, but in this case, we were able to validate our hypotheses through the extensive call center data and recordings. This gave us the necessary information to know what feature categories needed to be prioritized:
- Account Overview
- Payments and Invoice History
- Appointment Scheduling
From there we could organize the features into these main categories and start getting an idea of what the user flow would be. At this point in the project, I was working closely with the project manager to ensure all the business requirements were documented in Confluence.
User Flows and Wireframes
The first touchpoint for any app is the login screen. You never have a second chance to make a first impression, so it’s critical to get the login experience right. That sounds simple enough, but because I work closely with the dev team throughout the design process, I knew that there were constraints on their end that had to be considered.
One of the business requirements was that we use a third-party authentication platform, and unfortunately no one on the team had used it before. At first, it looked as though the user would have to create an Acme account, and then create a separate account for the authentication platform. This concerned me, not only because it was a lot of extra work for the user, but because it had the potential for serious confusion. First of all, from the user’s point of view, they already have an Acme account. They made one when they signed the contract, so why are they being asked to make another one? Second, they were on the Acme website, and now they’re being sent to an unfamiliar site with a different URL. A savvy user would recognize this as a potential phishing scam and opt to keep calling the toll-free number rather than put their personal data at risk. If we wanted this app to have wide customer adoption, we had to get this part right.
By working with the dev team and understanding the data architecture and the engineering constraints of the platform, I was able to work with them to create a user flow that would work.
It took a lot of testing and several design iterations, but the result was a login process that was as simple and seamless as the user would expect. We fulfilled the business requirement of using the third-party authenticator, but essentially mask it from the user thereby eliminating the confusion and phishing concerns.
Prototyping and User Testing
Once we had the initial design concepts and user flows mapped out, we began the prototyping and user testing phase of the project. We used Figma to create low-fidelity wireframes and high-fidelity prototypes of the customer portal.
Our first step was to conduct internal testing with team members to identify any potential design flaws, usability issues, or technical challenges. This allowed us to catch any potential issues early on and make changes to the design as needed. We then moved on to conducting user testing with real customers to validate our design assumptions and make sure that the portal was intuitive and easy to use.
Using Friction in Product Strategy
An easy approach to UX Design is to empathetically do whatever is easiest for the user. And to that end, as UX designers it’s normally our goal to reduce friction wherever possible. But there are realities in business that have to be considered, and these might not always align with what’s easiest for the user.
Acme was spending upwards of $16M per year on credit card processing fees. One of the easiest ways to reduce this expense was to get more customers using ACH payments. This requires the user to enter their bank account and routing number, and allow us to directly debit their account each month. ACH costs the company nothing, whereas our merchant services were hitting us with fees of up to 3% on every credit card transaction. Less than 1% of the 600,000 customers were on ACH, so you can see how the fees add up fast.
I felt like the new customer portal could be a golden opportunity to dramatically increase the number of customers using ACH, but it would require asking the users to do something they might not be used to. It’s easier for most customers to pull a card out of their wallet and enter the numbers that are right there in front of them. It’s what they’re used to doing and it feels more secure than disclosing your bank details. But I designed the “add payment method” screen in a way that encouraged the user to use ACH. Rather than giving the user an option to choose ACH or credit card, by default the new payment screen asks the user to enter their bank account and routing number. However, we still accommodated credit card payments by including a secondary button at the bottom of the page labeled, “Use Credit Card Instead.”
We found this design friction to be effective, but for those that chose to go to the credit card screen, we included text at the top of the screen that simply and politely suggested that we would prefer that they use ACH.
When we tested this user flow the results were promising. In the original design, nearly all users selected credit cards as their payment method. But with this design, we could expect 10–25% of the users to opt for ACH. When that percentage is applied to the projected customer acquisition numbers for the coming year, this design would save the company around $1.5M.
Another area where we were able to use a friction strategy to reduce company costs was with excessive re-treatments. Acme guarantees their work and will re-treat a property at any time. The normal treatment schedule was every 90 days, but it wasn’t unusual to have a customer request a return visit after 30 days, especially as the seasons change and different pests begin hatching. But less than 30 days was unusual. It’s not that the company was unwilling to come back in under 30 days, but some customers did tend to abuse the service.
I designed the app so that if the user requested a re-service, they would be required to provide some information about the treatment they needed.
The hope was that this little amount of friction would prevent users from scheduling unnecessary treatments. We further addressed this by having the developers build an endpoint that would look at how many treatments the customer had had in the last 90 days. If it was more than 3, the customer would not see the option to self-schedule, but rather be directed to call the customer service number.
Unlike the ACH issue, the data in this case wasn’t sufficient to predict how much money this design strategy would save the company, but the executive stakeholders agreed it would be significant. In both cases, user tests showed that the friction was acceptable because users were not abandoning the tasks or voicing frustration. We were able to provide the customer the service options they need, but used friction to direct them in a way that could increase ROI on the product.
MVP Development
One thing I’ve learned after many years as a designer is that no matter how well-defined your UX process is, we rarely get to follow the ideal process. In a perfect world, not a single line of code would ever be written until the prototype is pixel-perfect and fully tested. But when you have developers sitting on their hands, sometimes you have to adapt your process.
In this case, we had to work with the development team to create an MVP (minimum viable product) that could be built quickly and iterated on as needed. We focused on creating the most essential features of the portal and getting it up and running as soon as possible.
To do this, we prioritized the features that would have the greatest impact on the customer experience and that would be the most technically feasible to build. This included features like viewing and downloading service contracts, scheduling and rescheduling spray dates, and updating payment information.
We worked closely with the development team throughout the process to ensure that the MVP met both the design and technical requirements. We used an agile development process, which allowed us to iterate on the design and functionality of the MVP as we received feedback from users and stakeholders.
While agile development often conflicts with the waterfall design process that design teams tend to be more comfortable with, I was able to use this to my advantage. The testing that I would normally have been doing in a pixel-perfect Figma prototype could instead be done using the early versions of the actual product. We arranged for a limited alpha release, where a select group of internal users were given access to the application. They became our feedback group, and we arranged for user interviews, a focus group, and were even able to conduct unmoderated user tests using FullStory.
Outcomes and Key Takeaways
At the time of writing, the customer portal is in a wide beta release and will be made available to all Acme customers soon. During the crucial beta phase, data is being gathered through analytics tools such as FullStory so that we can identify any pain points and make improvements on future releases. The beta product has successfully achieved its KPIs and is on track to save the company $1.5 to $2 million in 2024. But most importantly, Acme’s 600,000 customers will now be empowered by greater visibility of their customer data, and have the ability to self-manage key aspects of their accounts.
Some of the challenges in this project were:
- Timeline: We were only given about 9 months from kickoff to release. We overcame this by adapting the design process and working in a phased rollout. The beta release was delayed by a month, but for the most part, we were able to deliver the MVP on schedule.
- Limited resources: As the sole designer on this project I had to balance my time between research, testing, and design. The project manager was a tremendous asset in the research and data-gathering process. The QA team also helped uncover design flaws.
- Limited context: As a relatively new employee at Acme, it took some time for me to understand the business constraints and customer needs.
- A global product team: While the PM and I were at the corporate office, the rest of the team was spread all over the world. We had developers and QA personnel in Poland, Belarus, Vietnam, Hungary, and other parts of the globe. While the schedules were sometimes a challenge, we had an impressive level of collaboration through daily standups and Slack messages.
Some of the key takeaways from this project are:
- Conducting thorough research and data analysis can uncover opportunities for cost savings and process improvements.
- Using empathy in design can help create user experiences that meet both business goals and user needs.
- Friction can be a valuable tool in design strategy to encourage users to take desired actions and reduce costs.
- Adapting the design process to work with developers and create an MVP can be necessary for timely product delivery, but can also create new testing opportunities.
- Continuous testing and iteration can help identify issues and improve the product over time.
