Can Engineering principles solve sales problems?
Written by , September 17, 2019 5-7 minute read
“Onboarding customers is taking too long!”
“Our customers are feeling frustrated!”
“Our sellers are missing their quotas!”
“Q4, our busiest season of the year, is right around the corner, and we need a solution ASAP!”
All of the above complaints were funneled into the Solutions Engineering team at NextRoll. We were not providing support that met the standards expected from our team. In turn, our sales teams and our customers were suffering. If we did not solve some of these challenges quickly, we could’ve missed out on substantial revenue for Q4.
The Solutions Engineering (SE) team at NextRoll is responsible for the technical aspects of onboarding clients, debugging post launch platform issues, and building tools to automate manual tasks. At our core, we sit at the junction between sales and engineering, communicating problems bi-directionally. We represent the voice of the client within engineering teams, but we also provide engineering expertise for sales teams. When a bug impacting clients is discovered, the SE team conveys the impact and priority to the engineering team. When an SE is onboarding a client and is being pressured to rush, it is imperative that the SE advocates for what is best for the client, technically.
When we first started learning about the problems our stakeholders –the sales teams– were experiencing with using our services, my response was, “Oh! Of course the end-user doesn’t understand how to use our system!”. Patrick Mee, our EVP of Engineering, patiently waded through this initial defensiveness I felt about our team. He scheduled meetings with our stakeholders and continuously displayed real empathy to their concerns. Through these meetings, I was able to remove myself from the SE team and instead place myself in the end user’s perspective.
After accepting that our end users had concerns, I could actually begin to listen to their complaints. Even though the heart of these issues were people and processes, the solution naturally came to me from thinking through this from an engineering lens. My background is in systems engineering, and the first step in building any system is to write down the use cases. How would an end user use our services as a system?
The previous user story flowed like this:
- Customer has a question
- Customer reaches out to their account manager/self service chat support representative (Tier 1)
- Account manager/chat rep reaches out to Support Engineers (Tier 2)
- Support Engineer escalates to Solutions Engineer (Tier 3) where needed
- Solutions engineer contacts engineering if bug is found
- Engineering provides resolution - bug fixed/won’t fix, potential workarounds, and any associated timelines
- Solutions Engineer provide this feedback back to customers via account managers
The interfaces are the weaknesses
The above user story shows a minimum of seven handoffs between teams to solve one issue. If you’ve ever played telephone, then you know information is lost as it transfers between parties. That’s because in any system, the interfaces are the weaknesses. The less handoffs there are between systems, the less information is lost between components. Here we had both component and interface issues. We started thinking about which handoffs to eliminate to reduce information transfers. We thought, “let’s reduce turnaround times for customers, making our sellers and customers happy at the same time”. Win-win, right?
We first removed the barrier for support engineers to reach out to solutions engineers prior to reaching out to engineering teams. Due to some legacy baggage around not properly reaching out to the right channels, support engineers had been restricted from creating bug tickets for engineering as well as reaching out to those engineering teams in slack channels.
Now, the user story flows like this:
- Customer has a question
- Customer reaches out to their account manager/self service chat support representative
- Account manager/chat rep reaches out to Support Engineers
- Support engineer contacts engineering if bug is found
- Engineering provides resolution - bug fixed/won’t fix, potential workarounds, and any associated timelines
- Support Engineer provides this feedback back to customers via account managers
Perform QA on individual components prior to integrating components
Another bit of feedback we received was that Support Engineers were occasionally failing to provide sufficient information to the teams they were working with to onboarding clients. This led to multiple back and forths between SEs, Account Managers, and customers, introducing potential churn risks at a critical phase in the client relationship. We needed to ensure that communications from our team were thorough, accurate, and identified any needed data immediately. To ensure every onboarding started on the right path, we needed to improve the quality of written information provided on the initial response in the ticket.
We introduced code reviews. Code reviews, in engineering, are meant to provide a systematic way to improve code. In slack, we created peer review channels, pairing a support engineer with a solutions engineer. Solutions Engineers reviewed the onboarding instructions written by support engineers to ensure quality before they were sent to new clients. We noticed that the overall time to resolution was reduced significantly. By approaching our service as a system and performing Quality Assurance on the individual components prior to integration, we were able to have a smoother deploy to production.
Focus on the right metrics
The support engineers were being held accountable to a 24 hour SLA(service level agreement). The support engineer needed to respond within 24 hours to a ticket, regardless of the quality of responses within the ticket. Unfortunately, time to response as an SLA was emphasized over other metrics, leading to lack of concern for other metrics such as number of iterations per ticket.
Frankly, our end users were not concerned about receiving an incomplete response back within 24 hours. We shifted the focus from “time to response” to reducing the number of iterations between the requester and the SE on the ticket. We found that the higher the number of iterations on a ticket, the more likely end users were frustrated by customer service.
Gathering Feedback Post Changes
The feedback we received from the sales teams after we implemented the changes truly honored the amazing work our Solutions Engineering teams do. The Support Engineering and Solutions Engineering teams at AdRoll work incredibly hard to improve the quality of service we provide to our customers. Hearing positive feedback from the same teams we provide service to makes us want to celebrate a great release, just like the engineers.