Most people booking an Automation Audit expect a form. Fill in what tools you use, get a report back a week later with a few bullet points and a quote attached. That is not what actually happens, and it would not be much use if it did. A support stack looks completely different on paper to how it behaves when you actually watch it running, so the audit starts by looking, not asking.
Here is the process, in order, exactly as I run it.
Step one: map what you have actually got, not what is on the pricing page
The first conversation is always about the tools: are you on Zendesk, Intercom, HubSpot, something else. But the tool name only tells me the shell. The real question is what is built inside it that nobody talks about anymore because it has become just “how things work”, things like automatic tagging rules, triage logic, and routing that got switched on eighteen months ago and hasn’t been looked at since.
Increasingly that also means a native AI chatbot bolted onto the help desk, and this is where an audit gets genuinely interesting, because almost nobody can tell me with confidence what theirs actually does.
Interrogating the chatbot: frontline questions, or the complicated stuff
Every help desk platform is shipping some flavour of AI chatbot now, and the pitch is always the same: it handles customer queries so your team does not have to. What that means in practice varies enormously, and finding out where the line actually sits is one of the first things I do.
There is a real difference between a bot that answers “how do I reset my password” and one that can handle “I ordered a product, it has not arrived, and I want a refund.” The first is a lookup against a help centre article. The second means the bot has to establish what was ordered, check where it actually is, apply whatever refund policy applies to that product and that delay, and then either action it or hand off with the right context attached. Most bots I see are doing the first and quietly failing at the second, usually by looping the customer back to “would you like to speak to an agent” three messages too late.
So I trace it properly. What does the bot actually call out to when it is trying to answer something more complex than a lookup? Is it pulling from help centre articles only, or does it also reach into somewhere like Notion for internal guidance the team relies on. Does it call a webhook that pulls live order information from an ecommerce platform such as Shopify or WooCommerce, or is it working from stale or partial data because that connection was never built. That distinction, between a bot that can actually see the order and one that is guessing from a script, is usually the single biggest gap between what a business thinks its AI is doing and what it is actually doing.
Step two: talk to the people doing the job
Once I have a layer of understanding of what is actually built, the audit moves off the software entirely and onto the people. I sit down with frontline agents and with support team leaders separately, and I ask a version of the same question both times: what is the most frustrating part of your day right now.
This step matters more than the tooling review, not less. Software tells you what is technically possible. People tell you what is actually costing them time, every single day, in ways that never make it into a ticket count or a dashboard. I am listening for two things specifically: the quick wins, small friction that is cheap to fix and immediately noticeable, and the bigger frustrations that point at something structurally broken in how information moves through the team.
I sort what comes out of those conversations against effort versus impact, roughly a quick-win-versus-heavy-lift framework, so the list that comes out the other end is not just “everything that’s annoying” but something properly prioritised.
Why the quick wins matter more than they look like they should
Here is the part that is easy to underrate if you have not run one of these before. The point of tackling the quick wins first is not really about the time they save, though that matters too. It is about trust.
The first time an agent’s actual, named frustration gets fixed within a couple of weeks rather than filed away and forgotten, something shifts. People stop assuming automation projects are something that happens to them and start treating it as something they can shape. That is when the second and third rounds of ideas start showing up unprompted, because the team has learned that raising a frustration leads somewhere rather than nowhere. An audit that only produces a list of automations misses this. The list is the output. The trust is what makes the next six months of work possible.
What you actually get at the end
By the end of an audit you have three things: a clear map of what your stack is actually doing, including the AI parts most businesses have never properly interrogated, a prioritised list of automation opportunities weighted by effort and impact, and a team that has already been asked what is wrong rather than told what is about to change. That last part is the one that determines whether the automation work that follows actually sticks.
If you want to see how an audit like this feeds into an actual build, I walk through the sequencing, what gets checked first, what can wait, and how the quick wins turn into a proper 90-day plan, in The Automation Roadmap, my Maven workshop on building your team’s first 90-day automation plan. Details and dates are here.