The company's support team was drowning in the usual way: ticket volume growing faster than headcount, the same questions arriving every week, and the answers living in three places — the docs, the ticket archive, and the heads of two senior support engineers. New hires took months to ramp because the real knowledge wasn't written anywhere. It was in years of resolved tickets nobody could search.
They'd already tried an off-the-shelf AI support bot. It answered from the public docs in a generic voice, was wrong just often enough that customers stopped trusting it, and knew nothing about the product's actual failure modes — the stuff that only lives in resolved tickets. The team turned it off after a quarter. The lesson wasn't 'AI doesn't work.' It was that the bot didn't know what the team knows.
We built the copilot over the company's real knowledge: the docs, years of resolved tickets, and the release notes. A support engineer gets a draft reply for every incoming ticket — grounded in how this exact issue was solved before, written in the company's voice, with the source tickets linked. The engineer reviews, edits, sends. The AI drafts; the human owns the answer.
The detail that made it work: we built the curation in, not on. When an engineer corrects a draft, the correction feeds the system. When a release changes behavior, the release notes update what the copilot believes. The senior engineers marked which historical resolutions were canonical and which were workarounds that should die. The system got sharper every week because the team's judgment kept flowing into it.
First responses now go out in a fraction of the time they used to take. Escalations fell, because the drafts carry the senior engineers' judgment to the whole team. Volume keeps growing; headcount hasn't had to. The two senior engineers spend their time on the hard tickets now — the work they were hired for. Next lane: the same knowledge, surfaced to customers as self-serve.