// чат-бот для обращений и колл-центра

Техническое задание на чат-бот для колл-центра: что обычно упускают

Чат-бот для обращений — одна из самых частых закупок последних лет: госорганы и крупные компании хотят разгрузить колл-центр, закрыть типовые вопросы ботом в Telegram и на сайте, а на операторов оставить только сложные случаи. На бумаге задача выглядит простой: бот отвечает на частые вопросы и принимает обращения. На практике это система с базой знаний, логикой передачи диалога человеку, хранением переписки и требованиями к качеству ответов — и именно эти части типовое ТЗ описывает хуже всего.

Заказчиком обычно выступает ведомство или компания с действующим колл-центром, которая хочет снизить нагрузку на операторов, а не построить что-то принципиально новое. Отсюда и ловушка: техническое задание пишут исходя из того, что «бот и так всё знает», забывая, что знания в бота должен кто-то заложить и обновлять.

Качество готового бота определяется не тем, насколько красиво он написан на демо, а тем, насколько точно ТЗ описало источник ответов, сценарий эскалации к оператору и критерии, по которым приёмка скажет «бот работает». Если этого нет в документе, спор на приёмке почти неизбежен — и решать его придётся уже после оплаты.

Что обычно упускают в ТЗ

Бот «отвечает на частые вопросы», но база знаний не приложена

Чем оборачивается. Подрядчик на свой страх и риск формулирует ответы от имени заказчика, а на приёмке выясняется, что часть ответов неточна или устарела — спор о том, кто виноват, тянется дольше самой разработки.

Как написать правильно. В ТЗ должна быть приложена база знаний: перечень тем, формулировки ответов или хотя бы исходные документы, из которых подрядчик их составляет. Если базы нет, нужно явно прописать, кто и в какой срок её готовит, и выделить это отдельным этапом с отдельной приёмкой.

Не описана передача разговора живому оператору

Чем оборачивается. Бот либо зацикливает пользователя на неподходящих ответах, либо просто обрывает диалог без передачи — обращение теряется, а колл-центр об этом не узнаёт.

Как написать правильно. Нужен отдельный раздел со сценарием эскалации: по каким триггерам бот передаёт диалог оператору, куда уходит передача (конкретная очередь, канал, система колл-центра), что видит оператор из истории переписки и что происходит, если оператор недоступен.

Не сказано, где хранится переписка и сколько

Чем оборачивается. Без этого требования данные обращений могут храниться где угодно и сколько угодно — от переписки в облаке подрядчика до отсутствия логов вовсе, что создаёт риски при проверках и спорах с пользователями.

Как написать правильно. ТЗ должно фиксировать место хранения переписки (на чьей инфраструктуре), срок хранения, кто имеет доступ к логам и в каком формате заказчик может их выгрузить.

Качество ответов нечем проверить на приёмке

Чем оборачивается. Приёмка превращается в произвольное тестирование: каждая сторона задаёт боту свои вопросы и трактует результат по-своему, что затягивает подписание акта.

Как написать правильно. В ТЗ нужен список контрольных вопросов с эталонными ответами — тот самый чек-лист, по которому обе стороны прогоняют бота на приёмке и фиксируют результат построчно.

Языки общения не перечислены

Чем оборачивается. Бот запускается только на одном языке, а когда выясняется, что нужен ещё один, это оформляется как доработка сверх контракта — с дополнительной оплатой и сроком.

Как написать правильно. Прямо указать в ТЗ, на каких языках бот должен понимать вопросы и отвечать, и включить проверку этих языков в контрольные вопросы на приёмке.

Что даёт хорошее ТЗ

Заказчику ТЗ с готовой базой знаний, сценарием эскалации и контрольными вопросами даёт предсказуемую приёмку без споров о том, что считать «рабочим ботом».

Подрядчику такое ТЗ позволяет оценить объём работы по существу, а не додумывать содержание ответов и языки общения самостоятельно.

Чёткое описание хранения переписки снимает вопросы на будущих проверках и избавляет обе стороны от доработок, не предусмотренных контрактом.

В итоге бот закрывает реальную часть обращений колл-центра, а не становится системой, которую включили и забыли.

Сколько стоит и сколько занимает

Техническое задание — от $400, 1–4 недели: цена зависит от сложности системы, архитектуры, стека и интеграций. Разработка на субподряде — по объёму контракта, оценка до подачи заявки.

ТЗ для тендера или субподряд — подробнее →

Заказчиков и закупки не называем: разбираем типовое ТЗ, а не чей-то тендер.

Готовите закупку или уже выиграли тендер?

Обсудить тендер