From opening a ticket for everything to solving it in the conversation
An assistant over their own documentation that removed 75% of the ticket volume and turned the ones that were real incidents into complete tickets.
Financial services startup
BEFORE
Every question became a ticket
AFTER
75% fewer tickets
The problem: hardly any ticket was an incident
The platform worked. What did not work was finding things inside it: where this feature lives, who to talk to about this case, how to pull this report. Every one of those questions ended up as a ticket, because that was the only route the user had.
Support spent its days answering things that were already documented, and that volume buried the cases that genuinely needed a person.
The second problem was the opposite one, and more expensive. When a ticket really was an incident, it arrived with almost nothing in it. The engineer had to write to the customer, wait, ask again for the missing detail, wait again. A bug that takes ten minutes to fix took days to close, and none of those days were engineering time — they were round trips.
What we built
An assistant grounded in the client's own documentation, doing three different things depending on what the user needs.
Answering. It resolves the question in the conversation, grounded in the product's real documentation rather than in whatever the model thinks it remembers. When the full answer lives on a specific page, it takes the user there instead of half-summarising it.
Routing. Some cases cannot be settled with documentation and need a specific person, not a shared inbox. The assistant recognises those and points the user at whoever handles them.
Filing the ticket, already complete. When what it is looking at is an incident, the assistant collects the information the engineering team will need and creates the ticket automatically with all of it inside.
The client owns the documentation base. Updating an answer means updating their documentation, not asking us for a deployment.
The decision: do not block the ticket, complete it
Support chatbots are usually sold on a single metric: how many tickets they deflect. Measured that way, success means the user gives up before writing.
The thinking here was different. The surplus tickets were the ones the documentation already answered, and those disappear on their own once the answer arrives sooner. But the ones that really were incidents had to keep existing — the problem was never that they got opened, it was that they arrived empty.
So half the work ran the other way from the usual approach: when the assistant spots a real incident, it does not try to talk anyone out of it. It gathers what is needed and files the ticket itself.
The effect is that both paths improve at once, rather than one at the other's expense.
What it takes to put a model in front of a fintech's customers
In financial services, a conversational assistant is not just a model with a good prompt. Three things were decided before the first line was written.
Personal data does not leave unfiltered. Messages pass through a personal-information detection and anonymisation layer before they reach the model. Using Presidio, as a mandatory step rather than a configuration option.
Every answer is traceable. Langfuse records what was asked, which documentation was retrieved and what was answered. Without that, an assistant in production is a black box nobody can audit when something goes wrong.
Changes are evaluated before they ship. DeepEval runs a battery of cases against the system, so updating the documentation or adjusting behaviour does not quietly degrade answers that used to be correct.
The rest is Python with FastAPI, Pydantic AI for orchestration and pgvector for the knowledge base. That last one was a decision too: the embeddings live in the Postgres the client already runs, rather than in a separate vector database to administer, secure and pay for. The model is Qwen.
The result
Ticket volume fell by 75%. Not because anyone is discouraged from opening one, but because the vast majority were questions about how something works or where it is documented, and those now get settled in the conversation.
The quarter that remains is the quarter that should always have existed: real incidents, which now arrive carrying what the engineer needs from the first message instead of after three emails. And the queries that need a person reach the right person.
V1 was an assistant on the web. There is now also a WhatsApp agent with the same capabilities, so the client's customers come in where they already are rather than where we decided they should be.
It is in production and in use.
SCOPE
What v1 covered
V1 shipped on the web only, deliberately: first confirm the answers were good against the real documentation, and only then open a second channel. WhatsApp came in a later phase, once that groundwork held.
Services involved
Shall we build something that scales, together?
Tell us about your project. We'll get back to you with a concrete plan and a senior team — not a generic quote.