Support Is a System

In most companies, support is two unrelated functions that happen to share a word. There's the IT help desk that unsticks employees, laptops, access, the printer nobody owns. And there's customer support, which absorbs the friction your product generates. Different teams, different tools, different bosses, different metrics. Nobody owns the through-line. I've come to think that's the mistake. Support isn't two help desks bolted to the side of the org. It's one system, and it should be run like one.

I've run technology for 30-plus companies as a fractional and interim CTO, and before that I was a CTO in healthcare EMR and a CPTO in online learning. In every one of them, the support functions were treated as overhead to be minimized. The good ones treated support as a sensing system, the part of the org that finds out, before anyone else, exactly where reality and design have diverged.

One loop, two surfaces

Employee IT support and customer support look different, but structurally they're the same machine: someone hits friction, asks for help, and a ticket records where the friction was. Internal tickets tell you where your own tooling, access model, and ops are broken. External tickets tell you where your product is broken. Treat them as one system and you get a single, honest map of where the organization is leaking time and trust.

The failure modes rhyme. An onboarding flow that confuses customers is usually built by a team whose own access provisioning takes three days and four tickets. Internal and external friction come from the same culture of shipping the happy path and leaving the edges for support to mop up. When one leader sees both queues, the pattern is obvious. Split across IT and CS, nobody connects the dots.

The KPIs that actually matter

Most support dashboards measure the wrong things confidently. Volume, average handle time, first-response time, tickets closed per agent. Those are speed metrics, how fast you process the symptom. They say nothing about whether the disease is spreading. A team can post beautiful handle-time numbers while the same ten root causes generate the same tickets every week. The metrics I care about answer a different question: is the system getting healthier?

• Repeat-cause rate. What fraction of this period's tickets trace to a root cause we already saw last period? Flat or rising means the loop is broken.
• Ticket-to-fix conversion. Of the top recurring causes, how many became a shipped product or ops change this quarter? This is the number that separates a help desk from a system.
• Time-to-root-cause, not time-to-close. Closing a ticket ends a conversation. Identifying the cause starts a fix.
• Escalation accuracy. Of issues escalated, how many genuinely needed the next tier? Too low means you're flooding seniors; too high means front-line is under-equipped.
• Deflection by root-cause elimination, volume that dropped because you fixed something, tracked separately from volume a bot absorbed. Only the first kind compounds.

Escalation is the nervous system

Escalation paths are where most support systems quietly fail. The common pattern is a tier ladder defined by seniority, Tier 1 tries, gives up, kicks it to Tier 2, who eventually loops in an engineer through a Slack channel and a prayer. The handoffs are lossy, context evaporates at each step, and the customer or employee re-explains the problem three times.

A system has escalation paths defined by where the fix lives, not by who's senior enough to take the heat. A billing edge case routes to the team that owns billing logic, with the ticket evidence attached, not to a generalist who'll improvise a workaround. The path is named, the owner is named, and the clock on time-to-root-cause keeps running until that owner closes the loop, not until the front line makes the customer go away. Escalation should move a ticket toward the people who can make it never happen again.

Closing the loop is the whole point

Here's the part almost everyone skips. Support generates the richest stream of operational truth in the company, and in most orgs it dead-ends. Tickets get categorized, closed, and aggregated into a chart nobody acts on. The loop from support to product and ops, the loop that would turn that truth into permanent fixes, was historically too expensive to keep open. You needed support to surface trends, product and IT to listen, and everyone to agree on priority. The activation energy was too high, so it never happened.

That cost has collapsed. You can now read every ticket from both queues, cluster them by root cause, weight them by volume and business impact, and hand the owning team a ranked list with the evidence attached. This is the operational core of an AI-native transformation: not a chatbot that closes tickets faster, but a feedback loop that's finally cheap enough to run continuously. The support system stops being a place where problems get absorbed and becomes the mechanism by which the organization learns.

When that loop is live, the numbers move in the direction that matters. Volume drops because causes get eliminated. The remaining support people get more senior and more influential, because their job shifts from closing tickets to interpreting them. And the same discipline applied to the internal IT queue quietly fixes the developer-experience drag that was slowing every team down.

Where to start

Pick one root cause that shows up in both queues and follow it all the way to a shipped fix. Instrument repeat-cause rate and ticket-to-fix conversion before you touch handle time. Put one person in charge of both surfaces and give them a standing seat where product and ops priorities get set. Support stops being the place your problems go to be closed, and becomes the place your organization goes to find out what's actually true.