Build people,
not simply teams

Proactive by default

We started with one thought of being the most proactive. Reactive support is a treadmill — the queue sets the agenda and the team never gets ahead of it. Proactive means finding the pattern before the customer has to report it for the fortieth time, and being willing to spend this quarter’s capacity on next quarter’s volume.

Change the model, not the tool

Transformation isn’t about implementing another platform. Most struggling support organisations do not have a tooling problem; they have an ownership problem. Who owns the customer’s outcome? Where does expertise actually live? What happens the moment a case exceeds one person’s knowledge?

Answer those and the tooling decision becomes obvious. Skip them and the new platform inherits every old dysfunction.

Swarm instead of escalate

Tiered escalation optimises for protecting senior engineers’ time. Swarming optimises for resolving the customer’s problem. POD-based ownership — a small, durable group that holds a segment of customers or product surface end to end — gets expertise to the case on the first attempt rather than the third, and it builds depth in people instead of routing around them.

Measure outcomes, not motion

Touch counts, first-response timers and queue volume are easy to move and easy to game. Resolution, repeat contact, escalation rate and whether the underlying defect actually got fixed — those are harder to move and worth far more. Focus on outcomes that create value for customers and business.

Let automation take the work nobody should be doing

AI and automation free people for the work that truly matters. Triage, summarisation, similarity matching across historical cases, drafting the first version of an article — hand all of it over. Keep the judgement calls, the difficult customer conversation and the design of the system itself with the humans. Used this way, automation raises the ceiling on what a support engineer’s career can be rather than lowering the floor.

Technology only counts when the experience improves

Technology is only successful when it creates a better experience. That is the test I apply to every migration, integration and dashboard: did a customer’s day get better, or did we simply move the work somewhere less visible?

Cover for your people

Teams take real risks only when they trust that a good-faith failure will not be used against them. That trust is built in the unglamorous moments — the post-incident review that looks for the systemic cause instead of a name, the escalation you take personally rather than passing down, the promotion you argue for in a room the person isn’t in.

Building with AI

Building it, not just directing it

I don’t only set direction on AI in service operations — I build. I design and ship internal tooling that applies retrieval and agentic techniques to the unglamorous parts of running a service desk: triaging what arrives, surfacing the right prior case, drafting the first version of an answer, and keeping the knowledge base honest.

Three things that only become obvious once you have actually shipped one of these rather than specified it:

Retrieval quality beats model choice

Most disappointing internal AI is a search problem wearing a model’s clothes. If the system cannot find the right three documents, no amount of model capability rescues the answer. The work that pays off is almost always upstream — in how knowledge is structured, chunked and kept current.

The human stays where the accountability is

Automation drafts; a person owns what reaches the customer. That line is not a limitation to be engineered away. It is the thing that makes the tool adoptable by the people who would otherwise quietly refuse to use it — and it is where the liability actually sits.

Adoption is a change problem, not a technical one

The build is the easy half. Getting an experienced team to trust a tool that will occasionally be wrong needs the same things any other operational change needs: honesty about failure modes, an obvious escape hatch, and visible wins early enough that people stop bracing for it.

I don’t name internal systems or employers here. The methods travel; the specifics belong to whoever paid for them. Happy to go deeper on approach in a conversation.