Beyond Debugging

Product problems usually arrive dressed as feature requests. Customers ask for more logs. Support asks for more visibility. Implementation consultants ask for better documentation. Product asks for stronger diagnostics. Four different groups, four different asks, and the instinct is to solve each one where it landed. The risk in doing that is you optimize four corners while the system underneath stays exactly as it was.

I went into research on unified routing and IVR debugging with what felt like a narrow question: how do we help people understand why a routing decision happened the way it did? What came back was bigger than the question. Information was not scarce. The problem was that every stakeholder was being made to reconstruct the same story, separately, in their own way, from scratch.

Data was never the shortage

Across customer admins, operations leads, implementation consultants, and internal support engineers, the pattern held. When something went wrong, people were not short on data. They were short on a coherent explanation. Working out a routing issue meant manually correlating configuration screens, timelines, capacity models, activity logs, queues, and whatever institutional knowledge happened to be available that day. The work was less about finding information and more about assembling meaning out of it, which is a different kind of labor and a much more expensive one.

Framed that way it stopped being a diagnostics problem. We had built systems that could generate answers and had not built anything that generated understanding.

Studying the system, not the persona

The easiest mistake in enterprise research is stopping at the first stakeholder. A support engineer can describe support pain. An admin can describe admin pain. Each of those is real and none of them is the system. To understand why debugging was hard I had to follow how information moved between people rather than how any one person completed a task, which meant the questions changed. Not what information does this user need or what screen should we improve, but where does knowledge originate, how does it travel, where does context fall out, which groups keep rebuilding the same understanding, and whose expertise are we quietly depending on.

That reframing produced a completely different opportunity set. Stakeholders had asked for better search, more filters, expanded reporting, all valid and all symptomatic. What the research pointed at was reducing the effort required to reconstruct what happened, which is where ideas like routing replay, evidence-backed explanations, historical state reconstruction, and structured exports came from. What those had in common was not technology. It was cognitive efficiency, each one shaving down how much interpretation a human had to do before they could act.

Trust before reasoning

This project shaped how I think about AI in operational tools. Participants genuinely wanted AI assistance and were also very clear about the conditions under which they would refuse it. If an explanation could not be verified, it was not useful. If the evidence behind it was missing, confidence collapsed. If the reasoning could not be traced, the recommendation was hard to act on. Which gave us a principle worth keeping: AI explanations need an evidence architecture underneath them, not just a language one. A fluent answer is only as good as the evidence model supporting it.

The path to trustworthy AI was not better AI. It was better systems design.

One last thing I did not expect. Customer enablement and support reduction, which every org I have worked in treats as separate domains, turned out to be the same problem. Support engineers held knowledge customers did not have, so customers escalated, and every escalation was really a knowledge transfer happening one ticket at a time. Make that knowledge reusable inside the product and diagnostics becomes an enablement strategy, self-service becomes knowledge distribution, and lower support volume becomes a side effect rather than the goal.