Загрузка…
The system gathers requests from three channels, answers them on its own using the client's own materials, and hands off to a human what a human should decide
3 channels to 1 stream
Telegram, email, and the website form are handled the same way
How we measured: before the system, each channel was checked separately in its own interface; afterward, requests are normalized to one format and go through the same processing path
Requests came in through three channels: Telegram, email, and the website form. Three different places to check, and three different formats of the same thing: a person describes their task and waits for a reply.
Most of these requests were routine. What's included in the work, how much it costs, what the timeline is, how to get started, whether you take on tasks like this. Answers to these existed and barely changed, but they were rewritten from scratch every time, by hand, in different words, because copying from a template turned out to be no faster.
A client who wrote in the evening got a reply in the morning. During that time, some people went to whoever answered faster.
The main loss was reply time. Requests arrive around the clock, and one person, who also has a full-time job, answers them. A client who wrote in the evening got a reply in the morning; a client who wrote on a busy day got a reply in the evening. During that time, some people went to whoever answered faster.
And attention got scattered. Checking three channels throughout the day means constantly switching from the main job to sorting the inbox, without knowing in advance whether the next message will be an important conversation or a question already answered a hundred times.
A system that stands in front of the person, not in their place. Requests from all three channels land in one shared stream and get normalized to the same shape: where it came from, who sent it, what they're asking. From there, the same logic handles it, whether the message arrived by messenger or email.
The reply is built from the client's own materials. We collected what the client was already telling clients anyway: terms of work, service scope, timelines, answers to common questions. That became the base the model relies on. This is the key difference from "we hooked up a neural network to the chat": the system answers with what the client actually tells clients, not with what the model finds plausible.
The system answers with what the client actually tells clients, not with what the model finds plausible.
The client gets a reply in the channel they wrote from, phrased conversationally, not as a template pulled from a handbook but as an answer to their question. If the core of the request is unclear, the system asks a clarifying question: for what task, on what timeline, what scope.
And the boundary: a question with no answer in the materials is not guessed at. A request like that gets flagged and goes to a person along with the conversation history, so the client steps into a conversation that already has context.
A stream of requests flows through the system, and each one is a call to the model, sometimes more than one. In a task like this, the price per request stops being trivial: it multiplies by volume and turns into a fixed cost that grows with the flow of clients.
That's why DeepSeek was chosen, a model with a low per-request cost that's enough for the task. The task here isn't to "reason," it's to understand a request and draft a reply from ready-made materials; that doesn't call for the most expensive model on the market, and paying for one would have made every message more expensive with no benefit to the client.
The price per request multiplies by the flow of requests and becomes a fixed cost. The most expensive model here wouldn't have given the client any benefit, only a bigger bill.
This is the kind of choice worth explaining out loud. Picking the best-known model means making a decision that doesn't need defending, but the client pays for it, every month. We work from the premise that a decision fit to the task is cheaper and more honest than a decision fit to expectations.
An AI solution is easy to sell as fully autonomous, and that's almost always an overstatement. We drew the boundary explicitly, and it became part of the design, not a disclaimer.
The system answers where the answer is known: it's in the client's materials and fits the question. Everything else goes to a person: nonstandard terms, disputed situations, requests where the client is unhappy, and anything resembling a decision that costs money or reputation.
A model answering beyond what it knows starts making things up, and does it more convincingly the less it actually knows.
This boundary exists for two reasons. Technical: a model answering beyond what it knows starts making things up, and does it more convincingly the less it actually knows. Business: a client can be mistakenly promised terms that then have to be either honored or walked back. An automatic reply is cheap right up until the moment it's wrong.
So a person stayed in the loop, but now handles only the requests where a person is actually needed.
The client gets a reply right away, in the channel they wrote from, regardless of time of day or how busy the client is. For an incoming stream, this is what matters most: interest doesn't last long, and reply speed competes directly with whoever answers faster.
Routine questions stopped taking up time. The volume of correspondence made up of repeated answers is now closed by the system on its own, and the person steps in for conversations where there's something to decide.
Three channels stopped being three separate duties. Checking the messenger, email, and the form was replaced by one stream, and there's no more switching between them throughout the day.
And requests stopped getting lost. Every one is logged and handled, regardless of when it arrived or how busy the client was that day.
The first conversation commits you to nothing: we will look at your situation and tell you whether you need a project like this at all.