Менеджер сидит на встрече, в руке телефон, в телефоне открыт Telegram. Клиент спрашивает: «По какому регламенту наш продукт сертифицируется?» Идея была проста: пусть в этом же Telegram отвечает бот — сразу, пока менеджер ещё разговаривает с клиентом. Мы написали ТЗ с двумя вариантами оценки, согласование застряло, и в продакшен бот не вышел. Ниже — почему так получилось и что от этого ТЗ осталось.
Сводка
| Отрасль | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» |
| Формат сотрудничества | Регулярное сопровождение — отдельный ТЗ с двумя вариантами оценки |
| Тип проекта | Прототип Telegram-бота как канала связи менеджера с базой данных платформы и техническим отделом |
| Объём работ | ТЗ с двумя вариантами оценки: полная версия (поэтапный диалог, морфологический разбор, идентификация с уточнениями, связь с техотделом) и демо (упрощённый диалог) |
| Дата проекта | Июль–сентябрь 2022 — ТЗ и обсчёт подготовлены; согласование застряло |
| Трудозатраты | Не выставлялись. В смете план-цены зафиксированы две оценки (полная и демо), но согласования и сборки не было |
| Команда | Антон Херсун (руководитель проекта; написал ТЗ и обсчёт). Разработчик не назначался. |
| Технологический стек (планировался) | Telegram Bot API · сервер на Laravel · лингвистический и морфологический разбор · интеграция с аналитической базой |
| Статус | Прототип. ТЗ подготовлено, в продакшен не вышло. |
Постановка задачи
Менеджеру в переговорке или на встрече нужен быстрый ответ: есть ли сертификат на такой-то продукт, какой технический регламент, какой тип объекта (серийный, партия, единичное изделие). В платформе этот ответ есть, но залезать в админ-интерфейс посреди разговора неудобно. А Telegram уже открыт: в нём менеджер и общается с клиентом.
Идею обсудили со стороной заказчика, после чего мы написали ТЗ и обсчёт. В чате это зафиксировано коротко: «Готово ТЗ и обсчёт по чатботу» (2022-07-04). В спецификацию заложили 5 свойств бота:
- Пошаговые запросы. Бот собирает данные не одним сообщением, а по шагам. Сначала развилка: идти от наименования товара или от регламента. Дальше уточнения наименования, области применения и типа.
- Лингвистическая нормализация. Если пользователь ввёл «металическая», а в базе лежит «Металлическая», система должна сопоставить и вернуть нужное значение. В ТЗ это отдельный этап: «по запросу „Армотура“ система скорректирует ошибку и найдёт всё по „Арматура“».
- Идентификация с уточнениями. Если наименование «Упаковка пищевой контейнер» пересекается с несколькими записями, бот выдаёт меню выбора («Упаковка пищевой продукции», «Упаковка парфюмерной продукции», «Упаковка игрушек для детей», «Хранение пищевой продукции в домашних условиях», «Упаковка прочей продукции») и спрашивает, а не угадывает.
- Несколько регламентов на один продукт. Продукция может сертифицироваться сразу по нескольким регламентам: бытовой холодильник требует сертификата по ТР ТС 004 и 020 плюс декларации ТР ТС 037. Бот должен вернуть полный набор со схемами, а не один документ.
- Связь с техническим отделом. Если менеджер не знает наименования, запрос уходит в личный чат специалиста техотдела. Ответ возвращается в бота и записывается в базу. То есть бот читает справочник наименований и заодно пополняет его руками техотдела.
Что в этом сложного. Главный риск B2B-чат-бота — доверие к ответам. Стоит боту хотя бы раз вернуть ответ из другой категории продукции, потому что наименование «похоже», и менеджер перестанет ему верить, вернётся в привычный админ-интерфейс. Поэтому базовый принцип, заложенный в ТЗ: бот не угадывает, а уточняет. Медленнее, зато правильно. Бот, который один раз выдал не тот регламент, страшнее бота, который переспросил лишний раз.
Что мы зафиксировали в ТЗ
1. Пошаговый диалог вместо одного длинного запроса.
Менеджер пишет боту, бот ведёт по шагам и на каждом проверяет ввод. В ТЗ прописаны оба сценария целиком: от наименования («Уточните наименование продукта» → «Уточните область применения» → готовый ответ с документом и схемой) и от регламента. Пользователю не нужно собирать весь запрос в одну фразу — бот сам доведёт его до ответа.
2. Нормализация: «металическая» = «Металлическая».
Планировали библиотеку лингвистического и морфологического разбора: она приводит варианты с опечатками и разной морфологией к канонической форме из базы. Без неё пользователь набирал бы с ошибками и получал «не найдено» — классическая беда поиска по справочнику. В смете это отдельный этап на 20 часов: морфологический разбор стоит дороже остального диалога и в полной версии вынесен в самостоятельный блок.
3. Уточнение области применения через выбор из списка.
Когда наименование совпадает с несколькими записями, бот отдаёт меню кнопок, и пользователь выбирает нужное. Уточнение идёт шаг за шагом, без угадывания. Тот же приём для типа объекта: бытовое или промышленное назначение влияет на схему сертификации.
4. Растущая база наименований через техотдел.
Сценарий «менеджер не знает наименование» не упирается в тупик: запрос уходит специалисту, ответ пишется обратно в базу — и в следующий раз бот ответит сам. Статичный справочник так со временем превращается в базу знаний, которую техотдел пополняет по ходу обычной работы.
5. Демо как отдельный объём.
В ТЗ заложены два варианта оценки. Демо сводится к урезанному диалогу: одна учётная запись менеджера, без связи с техотделом и без лингвистического разбора вообще. Из сметы убран весь этап морфологии, срезаны часы на ядро и сценарии. Расчёт простой: заказчик сначала проверяет саму механику бота на ограниченном сценарии, а уже потом решает про полную версию. Развилка «полная или демо» — третий вариант между «всё» и «ничего».
6. Одна учётная запись на каждой стороне в первой итерации.
В ТЗ так и написано: в первой итерации — одна учётная запись Telegram у менеджера и одна у специалиста техотдела. Это снимает с прототипа целый пласт сложности с правами и сессиями. Многопользовательская модель уходит в следующую итерацию.
Две оценки в смете
В смете план-цены ТЗ разложено на этапы, и по этой раскладке видно, чем демо отличается от полной версии.
| Этап | Полная версия | Демо |
|---|---|---|
| Ядро чат-бота | есть | есть, в урезанном объёме |
| Интеграция с базой платформы | есть | есть |
| Лингвистический и морфологический разбор | есть | убран целиком |
| Разработка сценариев | полный набор | сокращённый |
| Связь с техотделом | есть | убрана |
| Оценка по смете | полная (~3 недели) | демо (~1,5 недели) |
Числа в часах остались в самих файлах сметы, но это была именно оценка под согласование. Ни счёта, ни акта по ТЗ не выставлялось, поэтому в кейс выносим не трудозатраты, а саму логику: где проходит граница между «попробовать» и «сделать как надо».
Почему в продакшен не вышло
ТЗ и обсчёт были готовы 4 июля 2022 — дальше всё упёрлось в согласование на стороне заказчика. В сентябре он сформулировал это прямо: «По чат-боту пока медленно идёт согласование. Но думаю, в итоге мы дойдём до его реализации» (2022-09-02). Не дошли.
Параллельно шли задачи, которые согласовывались быстрее: виджет для amoCRM с документами по ИНН/ОГРН, доработки общего отчёта, дальше таблица аккредитованных лиц и ферма парсинга. Бюджет и внимание уходили туда. К Telegram-боту возвращались разговором, но в текущий объём работ так и не включили.
Тема всплывала ещё дважды. В 2024-м мы делали прототип ИИ-аналитика: запросы к базе на естественном языке закрыли ту же боль с другой стороны (это отдельный кейс). А в августе 2025-го, спустя 3 года после ТЗ, к идее бота вернулись снова: «по чат-боту делал поиск готовых решений, пока ничего нормального не нашёл». Идея живёт, а проработанное ТЗ так и лежит.
Результаты (на сегодня)
| Метрика | Значение |
|---|---|
| Статус | Прототип. В продакшен не вышел. |
| Артефакты | ТЗ с двумя вариантами оценки (полная и демо), сценарии диалога, обсчёт по этапам |
| Заказы | 1 отдельный ТЗ |
| Что зафиксировано | Архитектура диалога, перечень свойств, граница демо/полной версии, раскладка по этапам |
| Что не сделано | Разработка. Согласование застряло, заказ не открыли. |
Команда
- Антон Херсун, Xaver Pro: руководитель проекта, написание ТЗ и обсчёт в двух вариантах
- Разработчик не назначался. ТЗ остался на стадии оценки: согласование на стороне заказчика не завершилось, заказ в работу не открывали.
Скриншоты и материалы
Не применимо: прототип, продакшен-интерфейса нет.
Если у вас ТЗ, которое полгода лежит без движения, но всё ещё кажется полезным, покажите. Скажем, что в нём устарело, что можно поднять за минимальный объём как прототип и стоит ли его вообще размораживать. Первичная оценка бесплатна.