Alfonso Catrón

WordPress Engineer, Support & Tooling

Test-Driven Support: an approach for scalable Support Operations

Some support tasks can be hard, some processes are complex to follow, with many steps, and require lots of training and seniority.

Identifying complex processes, and converting them in repeatable “tests” is like finding the holy grial in support operations. This improves the experience for everyone, reduces friction, complexity, democratizes knowledge, makes such tests desirable and easy to do, as a result customers and support teams are happier!

Let’s talk about Test-Driven Support

Support keeps gaining complexity: More features, integrations, edge cases. And behind every ticket, there’s a real person expecting us to solve something quickly, clearly, and confidently.

When facing cases, it might happen that we are relying too much on memory, on digging up old tickets, or asking teammates, “Hey, didn’t you solve something like this before?”

That kind of freestyle support might work. But it doesn’t scale because it’s fragile, inconsistent, and exhausting. It also has a tendency to produce KB silos: team members with superpowers that become too important in the support flow to even take a decent holiday, and are in risk of burnout.

We need a better way to work

When we talk about Support Operations, we’re really talking about making support sustainable. Repeatable. Less dependent on who picks up the ticket. Less chaotic. Proctecting people from burnout, breaking silos, improving the overal customer experience.

That’s where Test-Driven Support comes in.

What do we mean by “Test-Driven”?

The idea is simple: if we treat Support like a multidisciplinary group of processes, we can pay attention to patterns.

We look at the things we check again and again, those quick verifications, or those highly technical tests we will repeat across hundreds of tickets, those processes or techniques that live only in the minds of a few, or hidden in the 14th paragraph of an internal doc. These are our seeds, these are the things we will hack. So we isolate them and think: How can we turn this into a test?

Sometimes creating tests comes easily, other times tests are hard to build, it’s a puzzle, we have to be creative and find ways, investigate, ask developers for help. Some tests are just not possible yet, so we keep them in our backlog: Someday, someone will be able to find a way.

During our investigation, we push the limits of what’s possible, of what we can do. We improve, interact, learn… The output is variable: it can be something automated like finding specific tags in the HTML and display a list with reds and greens to quickly identify enabled features, maybe a checkbox in a plugin that writes a complex log, a predefined list of files we will have to check, or why not a button that performs a complex database query we have to run 7 times per week.

The key: tests are now repeatable and accessible to everyone, not just the most senior teammates.

The impact is big. Here’s what that gives us:

  • A shared language for troubleshooting
  • Fewer things falling through the cracks
  • Better feedback to other departments, such as Engineering or Product
  • Empowered teams, better prepared to handle the increasing complexity
  • Tasks that used to take 15 minutes now take 2
  • Less stress, reduced risks of burnout
  • New teammates onboard faster, because a part of the knowledge is embedded in the workflow
  • We stop reinventing the wheel on every ticket
  • The result: a better experience for customers, faster, actionable, accurate support interaction that consistently provides solutions.

This is not just about saving time or removing the human side of support. It’s about removing the busywork, the repetitive, mind-demolishing tasks, so we can focus more of our energy where it actually matters, be happier, and more sustainable.

The Mindset of Test-Driven Support

If something is done more than three times a week and can be standardized and automated, you do it. You create a Tool: it can be an extension, a plugin, or an app. You create a Tool that contains a Test, and you explain how to use it. The team will know if it is good and makes sense. You can’t impose these new workflows on senior teammates; they know better than you, and each of them has a special and unique way of doing things. But if they discover this tool makes their lives easier, gives them autonomy in solving more complex problems, they will adopt it. After adoption, the team can iterate, over and over, creating a virtuous circle, optimizing one process at a time.

That’s Support Ops done right.

That’s how we scale Support without sacrificing quality.

That’s how we make Support a Human place to work.

That’s how you improve the Customer experience.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *