A sales manager sits in a meeting, phone in hand, Telegram open. The client asks: “which regulation does our product get certified under?” The idea was simple. Let a bot answer inside that same Telegram, right away, while the manager is still talking to the client. We wrote a spec with two quote options, sign-off stalled, and the bot never reached production. Here is why it played out that way, and what the spec left behind.
Snapshot
| Industry | product certification, B2B market analytics |
| End client | Certificate Analytics |
| Engagement | ongoing retainer — a standalone spec with two quote options |
| Project type | prototype Telegram bot as a channel between a manager, the platform’s database, and the technical team |
| Work done | a spec with two quotes: full version (stepwise dialog, morphological parsing, identification with clarifications, link to the technical team) and demo (simplified dialog) |
| Project date | July–September 2022 — spec and pricing prepared; sign-off stalled |
| Effort | not invoiced. The estimate fixed two quotes (full and demo), but no sign-off and no build followed |
| Team | Anton Hersun (project manager; wrote the spec and the quotes). No developer assigned. |
| Tech stack (planned) | Telegram Bot API · Laravel server · linguistic and morphological parsing · integration with the analytics database |
| Status | prototype. Spec prepared, never reached production. |
The problem
A manager in a meeting room needs a fast answer: is there a certificate for this product, which technical regulation applies, what object type it is (serial, batch, single item). The platform holds that answer, but climbing into the admin interface mid-conversation is awkward. Telegram is already open. The manager is talking to the client in it.
We discussed the idea with the client’s side, then wrote the spec and the pricing. The chat records it in one line: “spec and pricing for the chatbot are ready” (2022-07-04). The spec laid out 5 properties of the bot:
- Stepwise queries. The bot gathers data over steps, not in one message. First a fork: start from the product name or from the regulation. Then it narrows the name, the field of use, and the type.
- Linguistic normalization. If a user types “metalic” but the database holds “Metallic”, the system matches them and returns the right value. In the spec this is a separate stage: “for the query ‘reibar’ the system corrects the error and finds everything under ‘rebar’.”
- Identification with clarifications. If “Packaging food container” overlaps several records, the bot shows a selection menu (“Food product packaging”, “Perfume product packaging”, “Children’s toy packaging”, “Home storage of food products”, “Other product packaging”) and asks rather than guesses.
- Several regulations per product. A product can be certified under several regulations at once: a household refrigerator needs certificates under TR CU 004 and 020 plus a declaration under TR CU 037. The bot returns the full set with schemes, not a single document.
- Link to the technical team. If the manager does not know the name, the query goes to a technical-team specialist’s private chat. The answer comes back into the bot and is written to the database. So the bot reads the name directory and fills it from the technical team’s hands at the same time.
Why this is hard. The main risk of a B2B chatbot is trust in the answers. Let the bot return an answer from a different product category once, because the name “looks similar”, and the manager stops believing it and goes back to the familiar admin interface. So the base principle written into the spec: the bot does not guess, it asks. Slower, but right. A bot that returned the wrong regulation once is scarier than a bot that asks one extra question.
What we fixed in the spec
1. A stepwise dialog instead of one long query.
The manager writes to the bot, the bot leads through steps and checks the input at each one. The spec lays out both flows in full: from the name (“specify the product name” → “specify the field of use” → a finished answer with the document and scheme) and from the regulation. The user does not need to pack the whole query into one phrase. The bot walks it to the answer.
2. Normalization: “metalic” equals “Metallic”.
We planned a linguistic and morphological parsing library: it brings typo’d and morphologically varied inputs to the canonical form from the database. Without it the user types with errors and gets “not found”, the classic failure of directory search. In the quote this is a separate 20-hour stage. Morphological parsing costs more than the rest of the dialog, and in the full version it sits as its own block.
3. Narrowing the field of use through a list.
When a name matches several records, the bot hands back a menu of buttons and the user picks the right one. The narrowing goes step by step, with no guessing. The same trick applies to object type: household or industrial use changes the certification scheme.
4. A growing name database through the technical team.
The “manager does not know the name” flow does not hit a dead end. The query goes to a specialist, the answer is written back to the database, and next time the bot answers on its own. A static directory turns over time into a knowledge base the technical team fills during ordinary work.
5. The demo as a separate scope.
The spec carries two quote options. The demo comes down to a trimmed dialog: one manager account, no link to the technical team, and no linguistic parsing at all. The whole morphology stage is removed from the quote, and hours are cut from the core and the flows. The logic is plain. The client first checks the bot’s mechanics on a limited flow, then decides about the full version. The “full or demo” fork is a third option between everything and nothing.
6. One account on each side in the first iteration.
The spec says so directly: in the first iteration, one Telegram account for the manager and one for the technical-team specialist. That strips a whole layer of permissions and session work off the prototype. The multi-user model moves to the next iteration.
Two quotes in the estimate
The estimate breaks the spec into stages, and that breakdown shows how the demo differs from the full version.
| Stage | Full version | Demo |
|---|---|---|
| Chatbot core | yes | yes, trimmed |
| Integration with the platform database | yes | yes |
| Linguistic and morphological parsing | yes | removed entirely |
| Flow development | full set | reduced |
| Estimate | full (~3 weeks) | demo (~1.5 weeks) |
The hour figures stayed inside the estimate files, but this was a quote for sign-off. No invoice and no acceptance act were issued for the spec, so the case carries the logic rather than the effort: where the line runs between “try it” and “build it right”.
Why it never reached production
The spec and pricing were ready on 4 July 2022. After that everything jammed on the client’s sign-off. In September the client said it plainly: “sign-off on the chatbot is slow for now. But I think we’ll get to building it in the end” (2022-09-02). They did not.
Tasks that signed off faster ran in parallel: an amoCRM widget with documents by tax ID, fixes to the general report, then the accredited-bodies table and the parsing farm. Budget and attention went there. The Telegram bot kept coming up in conversation, but never made it into the active scope.
The topic surfaced twice more. In 2024 we built an AI-analyst prototype: natural-language queries to the database closed the same pain from another angle (a separate case). And in August 2025, 3 years after the spec, the bot idea came back again: “I looked for off-the-shelf chatbot solutions, found nothing decent yet.” The idea lives on, and the worked-out spec still sits there.
Results (as of today)
| Metric | Value |
|---|---|
| Status | prototype. Never reached production. |
| Artifacts | a spec with two quotes (full and demo), dialog flows, stage-by-stage pricing |
| Orders | 1 standalone spec |
| What was fixed | dialog architecture, property list, demo/full boundary, stage breakdown |
| What was not done | development. Sign-off stalled, the order was never opened. |
Team
- Anton Hersun, Xaver Pro: project manager, wrote the spec and the two-option pricing
- No developer assigned. The spec stayed at the estimate stage: the client’s sign-off never closed, and the order was never opened for work.
Screenshots and materials
Not applicable: prototype, no production interface.
If you have a spec that has sat untouched for half a year but still looks useful, show it to us. We’ll tell you what in it is stale, what could come up as a minimal prototype, and whether it’s worth thawing at all. The first review is free.