– Leveraging zero party data allowed for the automation of customer support, resulting in 80% self-solve rate and a decrease in response time.
– The process involved categorizing tickets and standardizing responses, leading to increased efficiency and cost savings.
– The system was successful in improving ticket handling and categorization, leading to ongoing use and replication by others.Implement a system to automate customer support using zero party data to categorize and organize tickets, standardize responses, and prioritize changes with the product team.The first time I leveraged zero-party data, I built a system to automate customer support. We received 1,200 in-depth technical tickets per week. Through automation, we achieved an 80% self-solve rate and a response time of less than 10 minutes during working hours, all with just 4 representatives. We had achieved the efficiency of a team four times our size, saving $240k in salaries. These were not just “where’s my order” tickets. They involved complex issues with networks, devices, firmware, houses, routers, internet, and other devices. It took at least 4+ interactions to gather information and provide the best advice. So, what happened? Why did I do it? How did I do it? I hate doing the same task multiple times. In fact, I absolutely refuse to do it more than twice. If it can be automated, it will be automated. For one week, I handled support tickets and learned the intricacies of dealing with our products. It was a terrible experience. The subject lines of the tickets were often “Your product sucks” or “My product doesn’t work,” with little explanation. I had to hover over the tickets in the queue just to see if I could answer them. There was no organization or way to filter them, and it was miserable. I vowed never to do this again. As a process-oriented person, my starting point was simple. If I could categorize the tickets better and obtain the necessary information in a more organized manner, I wouldn’t have to hover over them and cherry-pick. Instead, I would know the type of ticket and provide standardized responses. It’s easier to handle 10 identical tickets than to jump back and forth. It took a full week to build the first form. The original form had 120 logical steps mapped out. It was a complex process involving Typeform, Zapier, and Zendesk. However, through iteration and breaking down smaller, more common issues (eventually 5), and improving classification, the system started working. It wasn’t the most visually appealing, but it was effective. Over three iterations, we achieved an 80% self-solve rate, reduced the number of interactions with tickets by at least 25%, and categorized data for nearly every ticket. Instead of subject lines like “My product doesn’t work,” they looked like this: “device – product – issue – sub-issue – quantity owned – quantity impacted.” Most would have stopped there, “not my problem” is what typically is said. But I wanted to get to the root cause of the problem. We then broke up tickets by type, categorized via reports and worked directly with the product team to prioritize changes.Those forms are still used today, 6 years since I made them and nearly 3 years after I left.Since then a lot of people have tried to copy the model we used. At the time however, most people in the company didn’t understand what I was doing and I got a lot of pushback. This is why we aren’t just software but a consultancy. The lesson here, you don’t have to understand what we’re working towards at Formtoro, only that we have a track record of outsized results and processes.#business #strategy #automationhttps://www.linkedin.com/in/jivanco