Support is expected to be fast, consistent, and smooth for both customers and the team. Sometimes things don’t flow, processes are time-consuming, and the product or the market evolves faster than our knowledge. We rarely stop to think: what’s slowing us down? What are our pain points?
That’s where Tooling comes in. Not as a fancy side project, but as a way to scale good support, standardize knowledge and techniques, reduce burnout, and make the complex processes more accessible.
If you are curious about tooling in general, or if you are thinking about building internal tools and want to optimize processes, this article might be useful.
So, where to start?
First, you should start small.
Over the past few years, I’ve built some tools, and none of them started big. None of them started as “let’s build a tool.” They all started from the same place: a way to avoid repeated pain.
If you want to kickstart a tooling initiative in your support team, here’s how I’d approach it:
1. Find friction, think with laziness
Don’t start with what’s shiny and cool. Start with what’s annoying: What’s the thing your team does repeatedly, manually, with way too many steps? What’s the test that only a couple of teammates know how to do? What’s the Slack question that keeps getting asked every week?
Some of the best tooling ideas come from pure laziness: I don’t want to repeat this step 20 times!!
Tooling is best when it solves a problem people already feel. For example, when some teammates suffer in silence when someone suggests in Slack, “you should log the value of the $urls array in line 609 of the router.php file.” and this happens twice a week, there you have a good starting point.
Why?
Simply because doing that will require a LOT of work, you will need to:
- Get FTP and WP Admin access,
- Log in and navigate to the right location,
- Add the
error_log, check that nothing got broken - Wait for the function to trigger
- Navigate again to discover where the log file was written… this can be a confusing point: if the log is not there, is it because the path is wrong? Because the
error_logwas added in the wrong place? Because the function hasn’t triggered at all? - Once you get the log, you have to undo the edit and check that nothing got broken.
- Clean the log files
This might be for advanced teammates, time-consuming, prone to error, and increase stress.
2. Feel the pain! Learn how to do it manually first
Before anything else, you have to understand the process you are trying to optimize, feel the pain, and write the steps. You should document the test. Learn the thinking process… this is important because the Test that will end up embedded in a Tool has to reflect how Support actually works, and Support has its own logic. It is not just about what you think or expect, it is more about empathy and “pain relief”.
Bonus: You might end up with a documented procedure even before the tool is built. That’s already a win!
3. Build small, build ugly
Your first version can be ugly and quick. That’s fine. Just build something that works, something that saves 2 minutes, answers 1 question, cuts 3 steps, or prevents 1 mistake. Maybe it’s a snippet, a PHP script, a full plugin.
Remember: You are optimizing a process
Internal tooling doesn’t need polish. It needs adoption.
4. Share it
Scary moment! Yes, now you have to share your work. This can be super embarrassing; your teammates are very smart, and you will feel exposed.
But this is also where things might start to shift. After you share with the team how to use it, if the tool provides real value and makes tasks easier, some people will start adopting it. They will provide feedback. You will be able to iterate, improve the tool. Once people use it, you’ll see what’s missing, what’s confusing, and what’s worth automating next.
This also invites contributions. This is key: tooling as a team task is super fun and exciting, you will have “tooling buddies”. Slowly, this won’t be your tool anymore. It will become part of the team’s workflow.
Slowly, the adoption will make the tool an addition to onboarding, linked in internal docs, and referenced in Slack threads, just because it is the simplest way to do a good portion of the now-common tasks.
5 Expand it
Soon, you will find more processes to optimize. Things can get messy, so try to be systematic and use the tool UI to classify the processes you are optimizing, for example:
- Standardized Checks: configuration files, parameters, etc, actions, a database view, a check with a notification, a search function, a known conflicts detection API, anything that saves time through common predefined tests that, otherwise, you have to do manually.
- Logs: complex error_logging processes
- Advanced Aids: complex or risky procedures that are streamlined with a button, a link. This reduces the load of the higher Tiers while elevating juniors.
Of course, this structure will change depending on the product, but it is important to plan this because the structure will standardize how the team approaches cases with repeatable steps and a common language. If you reach this spot, the impact is noticeable, and things are on the right path. Tooling without adoption is just code. But tooling with adoption becomes infrastructure.
Keep building: over time, that initial simple test will become 10, 20, 30 optimized processes, and the added impact will be huge!
Final thoughts
If you are working in a Support team and have an interest in improving processes, you don’t need permission to start building a tool. You need a mix of curiosity, frustration, laziness, and the willingness to improve something you touch every day.
Start small. Keep it real. Build the thing you wish you had when that tough ticket landed in your queue. And then, share it.
Leave a Reply