Support dashboard and the knowledge base it produced

The leak

The digital support team handled requests from across the business about the lending platforms, and nobody could say how long a request really took. There was a time from open to close, but inside it were stretches when the technical team was working, stretches when the request was waiting on the requester for a clarification that never came, and stretches when it was waiting on nothing in particular. Without that split, every conversation about support speed was an argument.

A second leak was less visible. The platforms had no proper documentation. Every answer the support team gave lived in a closed conversation, so the same question was answered again the following month, and an assistant that could answer platform questions was impossible to build because there was nothing for it to read.

The constraint

The data lived in support conversations, not in structured fields, so the measurement had to come from reading the threads: who spoke, when, and what they were waiting for. The team was small and busy, so the dashboard had to need no maintenance. And the knowledge base had to be built from what was already there, not from asking engineers to write documentation they had not written in years.

The system

A dashboard that reads every support request end to end. It records where requests come from, by team and by platform, and categorises what they are about. For each request it reconstructs the timeline: time the technical team spent, time waiting on the requester for information, time spent on a technical change if one was needed, and the gaps in between. Resolution time stops being one number and becomes a breakdown that points at a cause.

Each conversation is also summarised: the question, the answer, the fix if there was one. Those summaries accumulated into something the company had never had: a knowledge base of how the platforms actually behave and how their problems are actually solved, written from six months of real resolutions rather than from a documentation project.

That knowledge base now feeds the policy assistant, which routes platform questions to it and answers them in place, so the technical questions that used to become tickets increasingly do not.

The number

Every request's resolution time split into technical work, waiting on the requester and waiting on nothing, visible by team and by category. Six months of resolutions turned into the first documentation the platforms ever had, now answering questions through the assistant.

What I would do differently

Treat the knowledge base as the product from the first week and the dashboard as the way to build it. The dashboard was the brief and the knowledge base was the by-product, but the by-product is what removed tickets. Starting with that intent would have shaped the summaries for retrieval sooner.