Before I automated anything, I ran support teams. Ten years of it, across customer service operations and experience roles, ending up managing frontline teams and later being recognised with a Rising Star of the Year award at the CX Leaders Awards. I mention that not for the trophy but because it is the reason my automation work looks the way it does. I did not come at this from the software side first. I came at it from having been the person accountable for a team’s experience, and later from watching that team try to deliver good service with tools that fought them at every step.
The lesson that shaped everything I build now is a simple one, and it took me longer to properly believe than I would like to admit: great customer experience starts with agent experience, not the other way round.
The switching problem nobody puts a number on
Picture an agent handling a fairly ordinary interaction. They need information that lives in one piece of software, they need to log what happened in another, and once the call or chat ends they are pasting notes into a CRM, or updating a spreadsheet, or both. None of those steps are hard. Individually, each one takes seconds. But strung together, dozens of times a day, they add up to something worse than lost time. They add up to a mindset.
When switching between systems is just how the job works, agents stop noticing it as a problem worth raising. It becomes “this is just how it is.” And once a team settles into that mindset, something else goes quiet along with it: the ideas, the suggestions, the “have you thought about changing this” conversations that are exactly the input a support operation needs to actually improve. Growth stalls, not because anyone stopped caring, but because the daily friction trained people to stop flagging it.
Where it actually costs you money
Here is the part that gets missed in most conversations about support automation, because it usually gets framed purely as efficiency or cost saving. There is a genuine revenue cost too.
A good agent, given the headspace, will spot the moment to mention an extra product or a relevant service. “Have you thought about this as well” is a completely natural thing to say when someone is actually present in the conversation. But if that same agent is mentally three steps ahead, already rehearsing which tab they need to open next and what they will need to copy across, that moment does not happen. The barrier is not a lack of sales training. It is that the tooling is occupying the part of their attention that a good customer moment actually needs.
What “automation people trust” actually means
This is where the phrase in the title of this post comes from. Automation that agents trust is not automation that is clever. It is automation that removes a step they had to think about, and does it reliably enough that they stop thinking about it at all.
The standard I hold any build to is this: if an agent has to do one thing, once, and everything mundane that follows happens in the background without them touching it, that is the best possible experience for that agent, full stop. Not “pretty good.” Not “better than before.” The best possible version, because it gets the tooling out of the way of the actual human interaction the agent is there to have.
That single design principle is doing more work than any dashboard or reporting feature I could add on top. It is why, when I sit down with a support team now, I am not asking what they want automated. I am watching what they touch twice, and asking why they still have to.
If your team is living with exactly this kind of friction and you are not sure where to start unpicking it, that is precisely what an Automation Audit is for. I also walk through how to turn what you find into an actual sequenced plan in The Automation Roadmap, my Maven workshop. Details and dates are here.