Запуск бота за 10 дней: этапы работ и типичные ошибки

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

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

Что считается «запуском»

Полезно сразу договориться о границах, иначе проект никогда не закончится. Первый релиз — это не «бот, который делает всё», а рабочий инструмент, который:

принимает обращения и отвечает на них автоматически;
задаёт квалифицирующие вопросы по согласованному скрипту;
передаёт диалог человеку по понятному правилу;
сохраняет заявки туда, где с ними работают (CRM, таблица, канал уведомлений);
имеет утверждённые тексты и сценарии, которые можно править.

Всё остальное — второй и третий релизы: расширенная аналитика, сложные ветки диалога, дополнительные интеграции. Если этот объём не зафиксирован письменно до старта, сроки уезжают почти гарантированно.

Этапы работ по дням

План ниже — типовой для бота с одним сценарием квалификации и интеграцией с CRM. При более сложной логике часть этапов удлиняется.

Дни	Этап	Что происходит	Кто участвует
1	Аналитика	Разбор текущих обращений, выбор сценариев, фиксация критериев лида	Руководитель, менеджеры
2	Проектирование	Схема диалогов, тексты, логика передачи менеджеру	Исполнитель, ответственный от бизнеса
3–5	Сборка	Реализация бота, меню, кнопок, базы ответов	Исполнитель
6–7	Интеграции	Подключение CRM или таблицы, уведомления без задержек	Исполнитель, админ CRM
8	Тест на сценариях	Прогон типовых и нестандартных обращений	Исполнитель, менеджеры
9	Правки и тексты	Уточнение формулировок, исправление логики	Совместно
10	Запуск и обучение	Вывод в работу, инструкция для команды, доступы	Совместно

Ориентир по срокам для более крупного объёма: каждый дополнительный сценарий добавляет 1–3 дня, сложная интеграция с учётной системой — от 3 до 7 дней.

Что нужно подготовить до старта

Основная причина срывов — не техническая. Проект стоит, потому что бизнес не может быстро дать входные данные. Собрать это стоит заранее:

Перечень услуг с ценами и сроками. В виде, пригодном для отправки клиенту, а не «спросите у менеджера».
15–30 частых вопросов с ответами. Проще всего выгрузить из переписки за последние месяцы.
Логика квалификации. Какие вопросы задаём, в каком порядке и какой ответ считаем целевым.
Правила эскалации. В каких случаях бот зовёт человека и куда приходит уведомление.
Доступы. CRM, канал уведомлений, права на создание записей.
Ответственный с правом решения. Человек, который за один день согласует текст, а не соберёт совещание.

Если ответственного нет, срок 10 дней превращается в 25: ожидание правок занимает больше времени, чем разработка.

Типичные ошибки и как их избежать

Старт без зафиксированного объёма. «Сделайте нормального бота» — самый дорогой запрос. Нужен список сценариев первой версии.
Автоматизация несогласованного процесса. Если два менеджера отвечают по-разному, бот придётся переделывать. Сначала — единый скрипт.
Слишком длинная квалификация. Оптимум — 3–6 вопросов. Всё, что длиннее, теряет клиентов.
Отсутствие выхода на человека. Обязательна кнопка «позвать менеджера» и понятный ответ на нераспознанный запрос.
Тексты, написанные «для галочки». Сухой канцелярит в мессенджере читается как автоответчик. Пишите так, как говорит ваш менеджер.
Тест только на идеальном сценарии. Нужно прогонять и странные обращения: опечатки, голосовые, вопросы не по теме, молчание клиента.
Запуск без обучения команды. Менеджеры должны понимать, как перехватывать диалог и где смотреть историю.
Отсутствие владельца после запуска. Без человека, который смотрит диалоги, качество падает уже в первый месяц.

Отдельно стоит упомянуть соблазн «доделать всё сразу». Каждая новая идея в процессе сборки — это плюс день-два к сроку и минус фокус. Идеи лучше складывать в список для второго релиза.

Как принять работу

Приёмка не должна сводиться к «вроде работает». Проверять стоит по чек-листу:

все согласованные сценарии проходятся от начала до конца;
данные корректно попадают в CRM или таблицу, без дублей и пустых полей;
уведомления о горячих лидах приходят вовремя;
тексты соответствуют утверждённым;
есть инструкция для команды и доступы у ответственного;
понятно, как вносить правки в тексты без разработчика.

Эффект стоит мерить по трём метрикам: время первого ответа, доля обращений, доведённых до квалифицированного лида, и объём времени, который перестали тратить вручную. Сравнивайте с состоянием «до запуска», а не с ожиданиями: на практике прирост по конверсии в квал обычно лежит в диапазоне 10–25%, и это зависит от качества трафика не меньше, чем от бота.

Что дальше

Если срок 10 дней кажется агрессивным, начните с честного аудита: сколько сценариев действительно нужно в первой версии, какие данные уже есть, а какие придётся собирать. Часто выясняется, что первый релиз можно ужать до одного сценария — и тогда десяти дней хватает с запасом.

Второй шаг — назначить ответственного и договориться о ритме согласований: правки раз в день, а не раз в неделю. Именно скорость решений, а не скорость кода, определяет, уложится проект в срок.

И третий — планировать вторую итерацию заранее. Через 2–3 недели работы на реальных обращениях всегда становится видно, каких вопросов не хватает и где клиенты отваливаются. Это нормальный процесс, а не признак недоработки: бот — инструмент, который донастраивается по факту, а не сдаётся один раз и навсегда.