Есть один безотказный способ потратить вдвое больше денег и времени на бота — объяснить задачу на словах вроде «нужен бот, чтобы общался с клиентами и продавал» и понадеяться, что разработчик «сам разберётся». Не разберётся. Не потому что плохой, а потому что «общался и продавал» в голове у заказчика — это одна картинка, а у исполнителя — совсем другая, и совпадают они примерно никогда. Первая версия приходит «вообще не то», начинается череда правок, бюджет ползёт вверх, сроки едут, обе стороны нервничают.
Лечится это одной вещью — внятным техническим заданием. И вопреки страху новичка, ТЗ на бота — это не толстый документ с терминами, а пара страниц понятного текста, который опытный разработчик читает за десять минут и сразу называет честную цену. Ниже — как собрать такое ТЗ блок за блоком, как описать сценарии, какие интеграции прописать и как заранее закрыть тему бесконечных правок.
Эта статья — часть раздела «Разработка ПО». Рядом полезно прочитать, сколько стоит каждый уровень, и определиться, конструктор или код подходит под задачу.
Что вы узнаете из статьи
- Из каких блоков состоит рабочее ТЗ на чат-бота
- Как описать сценарии диалога, даже если вы не программист
- Какие интеграции и технические параметры указать
- Как прописать правки, чтобы не уйти в бесконечную доработку
- Что считать выполненной работой при приёмке
Семь блоков рабочего ТЗ
Хорошее ТЗ на бота держится на семи опорах. Пройдитесь по ним — и документ соберётся сам.
Цель и задача бизнеса. Зачем бот нужен: разгрузить менеджеров, принимать заявки ночью, продавать, консультировать. Без этого разработчик не поймёт, что важно, а что второстепенно.
Площадки. Где живёт бот: Telegram, VK, Max или всё сразу. От этого зависят и возможности, и цена — у каждого мессенджера свои особенности API.
Сценарии диалога. Что бот спрашивает, что отвечает, какие кнопки показывает. Главный блок, ему ниже отдельная глава.
Интеграции. С какими системами бот связан: CRM, оплата, 1С, склад, календарь, база знаний. Без этого списка оценка будет неточной.
Данные и хостинг. Где хранятся данные, есть ли требования по 152-ФЗ, нужен ли свой сервер. Для российских проектов это всё чаще обязательный пункт.
Сроки и бюджет. Дедлайн, промежуточные точки и вилка бюджета. Если сомневаетесь в объёме, посмотрите разбор, сколько стоит каждый уровень.
Приёмка и правки. Что считается готовой работой, какие файлы и доступы вы получаете, сколько кругов доработок входит в цену.
Сценарии решают половину дела
Здесь живёт главное недопонимание заказчиков. «Я же не программист, какие сценарии» — и это ровно та фраза, после которой проект уходит в долгие переделки. Описать сценарий нужно не для того, чтобы вы что-то закодили. Он нужен, чтобы показать логику: бот спросил имя, предложил три кнопки, по первой ведёт в каталог, по второй — к оператору, по третьей — в FAQ. Слова «бот общается с клиентом» каждый понимает по-своему, схема — нет.
Опишите три-пять основных путей пользователя: как человек записывается на услугу, как оформляет заказ, как задаёт вопрос. По шагам, простым текстом или стрелочками — формат неважен, важна ясность. И обязательно продумайте, что бот делает, если пользователь пишет не по сценарию: молчит, переспрашивает, зовёт оператора. Этот «боковой» случай новички упускают, а он определяет, будет бот выглядеть живым или тупым.
Если можете — отметьте, где для вас критична скорость, а где точность. «Здесь важно ответить мгновенно», «здесь нельзя ошибиться с ценой». Такая схема с пометками стоит дороже золота: разработчик видит не абстрактное «пусть продаёт», а конкретные ориентиры. И первая же версия попадает близко к цели, а не в молоко. От того, насколько хитрая логика, кстати, зависит и выбор подхода — конструктор или код.
Интеграции и технические детали
Эту часть новички пропускают, а потом получают сюрприз на финише. Договоритесь заранее, с какими системами бот должен общаться и что именно туда передаёт.
Перечислите все внешние сервисы: CRM вроде Bitrix24 или amoCRM, платёжку (ЮKassa, CloudPayments), 1С, складскую систему, календарь записи, базу знаний для AI-ответов. Для каждой связки уточните направление и состав данных: «бот пишет в CRM имя, телефон и текст заявки», «бот тянет из каталога цену и остаток». Это не придирка — без таких деталей оценка превращается в гадание, а на финише вылезают доплаты. Подробнее механику мы разобрали в материале про то, как работают интеграции.
Отдельный и важный пункт — доступы, исходники и права. Кому принадлежит код после оплаты, отдают ли вам исходники и доступ к серверу, кто платит за хостинг и токены модели — это нужно проговорить сразу. Договариваться задним числом всегда дороже и неприятнее, а без исходников вы привязаны к одному исполнителю навсегда.
Правки и приёмка без споров
Бесконечные правки — главная причина, по которой проекты ссорят заказчика и разработчика. Лечится это одной строчкой в ТЗ. Пропишите конкретно: сколько кругов доработок входит в стоимость, а что считается дополнительной работой. Например, согласованные сценарии плюс два круга правок включены, дальше — по согласованной ставке.
Это честно по отношению к обеим сторонам. Вы понимаете, за что платите и где граница, а разработчик не проваливается в бесконечную доработку без оплаты — а именно от страха перед ней он и закладывает запас в цену. Чёткая формулировка правок нередко сама по себе снижает итоговую смету.
И договоритесь о критериях приёмки заранее: что считается готовым ботом. Все сценарии работают, интеграции проверены на реальных данных, вы получили доступы и исходники. Тогда финал проекта — это спокойная передача рабочего бота, а не выяснение, кто что имел в виду под «бот готов».
Отдельно стоит проговорить, как принимать работу технически. Бот — это не картинка, которую видно сразу: часть проблем вылезает только под нагрузкой или на нестандартных ответах пользователя. Поэтому в приёмку полезно заложить тестовый период: несколько дней, в которые бот работает на реальных людях, а вы смотрите на диалоги и ловите шероховатости. Договоритесь, что мелкие правки этого этапа входят в стоимость, — так вы примете не «бота, который вроде запускается», а бота, который реально держит живой поток обращений.
Как платформа помогает на этапе ТЗ
На Где.Эксперт задачу публикуют сразу с ТЗ и описанием сценариев, и разработчики откликаются, уже понимая объём. Это значит, что оценки приходят точные, а не «вилка от балды», и сравнивать их можно по делу. Видны портфолио, отзывы и история проектов — понятно, кто делал похожих ботов и работал с нужными интеграциями.
Чёткое ТЗ плюс прозрачный профиль исполнителя снимают главный риск: получить «не то» и спорить о доплатах. Можно обсудить детали в переписке до старта, зафиксировать сценарии и сроки, начать с одного этапа. Оплата идёт по факту, без депозитов, а отзывы прошлых заказчиков работают страховкой от случайного выбора.
Часто задаваемые вопросы
Что обязательно включить в ТЗ на бота?
Цель и задачу бизнеса, площадки, основные сценарии, список интеграций, требования к данным, сроки и критерии приёмки. Этого хватает для точной оценки.
Нужно ли расписывать сценарии самому?
Не дословно, но логику и развилки описать стоит: что бот спрашивает, какие кнопки, куда ведёт каждый ответ, что делает при ответе не по сценарию.
Какие интеграции указать?
Все внешние системы: CRM, оплату, 1С, склад, календарь, базу знаний. Для каждой — что передаётся и в какую сторону.
Как ограничить число правок?
Пропишите конкретно: сколько кругов входит в стоимость, дальше — за отдельную плату. Это снимает большую часть конфликтов.
Можно ли обойтись без ТЗ?
Можно, но это почти гарантия переделок и спора о деньгах. Даже пара страниц задания резко снижает риск.
Заключение
ТЗ на чат-бота — это не бюрократия, а способ получить нужный результат с первой-второй версии и не переплатить за переделки. Семь блоков, схема сценариев, список интеграций и прописанные правки — этого достаточно, чтобы разработчик назвал честную цену сразу и попал в цель, а не в ваше воображение.
Запомните главное: описывайте логику схемами, а не общими словами, перечисляйте интеграции с составом данных, запрашивайте исходники и доступы заранее и ограничивайте правки конкретным числом. Час-два на ТЗ экономят недели нервов и заметную часть бюджета.
Опубликуйте задачу на Где.Эксперт — приложите ТЗ и сценарии, получите точные оценки от проверенных разработчиков и платите по факту выполнения.