Автоматизация
Бот продаж: ТЗ на диалог, остановку и передачу менеджеру
Как описать продающего бота без навязчивых и повторных сообщений: события, каталог, активные заказы, ручная работа, очередь и проверка остановок.
Определите роль бота в продаже
ТЗ на бота продаж должно объяснять, какую часть разговора система может вести самостоятельно и в какой момент нужен сотрудник. Название «продающий бот» слишком широко: один сценарий помогает выбрать товар, другой собирает данные для расчёта, третий напоминает о согласованном следующем шаге. Начните с конкретного результата и допустимых действий. Бот может подготовить заявку, но не обязательно вправе обещать срок, подтверждать оплату или менять цену. Эти полномочия следует определить до выбора модели и платформы.
Разделите готовые правила и генерацию текста. Приветствие, проверка обязательного поля и подтверждение получения заявки часто не требуют языковой модели. Свободный разговор может быть полезен для понимания задачи, но его результат должен оставаться в границах утверждённого каталога и бизнес-правил. В брифе укажите, какие ответы формируются по шаблону, какие создаются как подсказка сотруднику и какие разрешено отправлять автоматически. Это разные режимы, с разными требованиями к контролю, стоимости и доказательствам качества.
Опишите первую версию через один путь: входящий вопрос, уточнение потребности, подходящее предложение и передача следующего действия ответственному. Не обещайте автоматизировать любую беседу до оформления заказа. Для сложной услуги правильным результатом может быть подготовленный контекст для менеджера. Учебный пример: клиент сообщает площадь и тип помещения; бот сохраняет эти данные и не спрашивает их снова, но индивидуальный расчёт передаёт сотруднику, если утверждённого правила цены для такой задачи нет.
Согласуйте каналы и достоверные события
Для каждого канала зафиксируйте подключённый аккаунт, доступные события, ограничения API и владельца доступа. Нельзя считать любую пустую историю новым обращением. Системное уведомление, обычное сообщение клиента, изменение статуса и просмотр контакта имеют разный смысл. Если сценарий зависит от конкретного события, приложите его реальный обезличенный пример с идентификатором и исходным временем. Локальная дата создания записи не должна подменять дату события внешней платформы, особенно при импорте старой истории.
Документация Telegram Bot API описывает объект Update и способы получения событий, а FAQ уточняет ограничения взаимодействия ботов с пользователями и группами. Это пример того, почему поведение нужно проверять для конкретного канала. Возможность одной платформы нельзя автоматически переносить на другую. В ТЗ сохраните подтверждённые типы входящих данных и сценарии, которые технически недоступны. Если источник события не подтверждён, соответствующую автоматическую отправку следует оставить выключенной, а ограничение показать владельцу проекта.
Опишите повторную доставку и восстановление после перезапуска. Событие должно иметь устойчивую связь с чатом и аккаунтом, а обработанное действие — сохранённый результат. Совпадение имени клиента не является основанием объединять переписки разных аккаунтов. Для неоднозначного сопоставления предусмотрите ручной разбор. На приёмке повторите одно событие, измените порядок получения и перезапустите обработчик. Бот должен сохранить выбранное поведение и не превращать технический повтор в ещё одно приветствие, предложение или задачу менеджеру.
Подготовьте каталог и правила ответа
Утверждённый каталог должен содержать услуги или товары, ограничения, необходимые уточнения и допустимые формулировки. Если цена зависит от нескольких параметров, опишите правило расчёта либо передачу сотруднику. Не позволяйте боту дополнять каталог вымышленными бонусами ради убедительного ответа. Для акций нужны условия, срок и область применения. Скидка не должна появляться только потому, что клиент сомневается или давно не отвечал. В ТЗ укажите источник актуальных условий и владельца изменения этих данных.
Ответ должен учитывать уже известную информацию. Клиент может сообщить задачу, срок, бюджет и контакт в одном сообщении или в нескольких репликах. Система должна сохранить контекст и уточнить только недостающее. Задайте понятный стиль: обычно короткий ответ, один основной вопрос и конкретный следующий шаг. Не превращайте разговор в длинную анкету после каждого сообщения. Если информация противоречива, обозначьте одно нужное уточнение, а не выбирайте удобную версию без объяснения и подтверждения пользователя.
Добавьте правила для вложений и недоступного содержания. Факт получения файла не означает, что бот смог его прочитать. Если нет доступа к документу, фотографии или внешней переписке, нельзя писать «всё посмотрел». В ответе следует честно обозначить, что известно, и предложить допустимый способ продолжения. Для передачи сотруднику сохраните ссылку на исходное сообщение и описание проблемы доступа. Такие случаи должны входить в тестовый набор, потому что внешне они часто выглядят как обычная успешная загрузка.
Разделите продажу и обслуживание действующего заказа
Фраза «мы уже заказывали» не подтверждает завершение, оплату или новую продажу. Бот должен проверить доступную историю и статус, сохраняя источник каждого факта. Если клиент сообщает о заказе в другом канале, не отрицайте его из-за отсутствия записи в CRM. Сохраните сведения как сообщение клиента, включая названный канал. При неясном статусе задайте один вопрос о том, завершена ли работа. Если ответ уже содержится в переписке, повторное уточнение только ухудшит разговор.
Завершённый заказ и текущая работа требуют разных маршрутов. После завершённой услуги допустимо одно уместное предложение из каталога, если нет запрета и активной передачи менеджеру. При ожидании результата, недавней оплате, исправлениях, претензии или возврате нужна помощь сотрудника без дополнительной продажи. Не предлагайте повторно уже выполненную для того же объекта работу. Если прошлую услугу установить нельзя, лучше уточнить нынешнюю потребность, чем создавать впечатление, будто бот видел историю, к которой у него нет доступа.
Если клиент сразу описал новую задачу, отвечайте по существу и учитывайте её отдельно от старого заказа. Историческая завершённая сделка не должна навсегда блокировать новую консультацию. В то же время новая формулировка не отменяет действующий запрет автоматизации или ручную работу менеджера. В брифе задайте приоритет правил и примеры конфликтов. Это позволяет проверить, что система различает новую потребность, обслуживание старой покупки и попытку продолжить нежелательную рассылку под видом дополнительной помощи.
Опишите остановки и ручную работу
Просьба не писать имеет приоритет над коммерческими сценариями. Зафиксируйте, какие формулировки и действия создают запрет, где он хранится и как учитывается при следующих обходах базы. Не снимайте его автоматически после перезапуска или появления нового системного уведомления. Отдельно предусмотрите явное принятие чата сотрудником и ручную паузу. Бот не должен конкурировать с менеджером, который уже ведёт разговор, даже если очередное сообщение по времени подходит под ранее запланированное правило.
Передача должна сохранять контекст: задача, известные данные, причина остановки, последние сообщения и ожидаемое действие. Одной отметки «нужен менеджер» недостаточно, если сотрудник вынужден заново читать весь разговор, чтобы понять проблему. При этом краткое резюме не должно превращать предположение в подтверждённый факт. Разделите сведения из CRM, слова клиента и вывод системы. Назначьте ответственного за очередь передачи и правило замещения, чтобы сложный разговор не исчезал между автоматизацией и ручной командой.
Если бот предлагает подсказку, отделите готовый текст для клиента от служебного объяснения сотруднику. Фраза «уточнить площадь» не является ответом, который можно отправить. В интерфейсе должен быть виден рекомендуемый текст, возможность изменить его и ручная отправка, если выбран такой режим. Сохраняйте исходную подсказку, правку и окончательный результат в согласованных пределах. Эти данные помогают улучшать ответы, но не должны автоматически использоваться для обучения без оценки доступа, состава данных и утверждённого процесса.
Согласуйте повторные касания и расписание
Повторное сообщение требует основания: содержательного обращения, подходящего состояния разговора и отсутствия стоп-правил. Пустое системное уведомление и собственное приветствие не должны сами запускать длинную серию напоминаний. Для каждой ступени задайте интервал, точку отсчёта, текст и условия отмены. Если используется время первого обращения, сохраните исходный часовой пояс и правило переноса за рабочее окно. Это позволяет объяснить конкретное назначенное время, а не только показать число дней в настройке.
Различайте «создано задание», «назначено на сегодня», «готово к отправке», «передано сервису» и «подтверждено отправленным». Эти показатели нельзя объединять в одно число рассылок. В отчёте отдельно показывайте отменённые, ошибочные и неопределённые попытки с причинами. При неизвестном результате не делайте слепой повтор. У задания должны сохраняться выбранное время, идентификатор серии и состояние после перезапуска, чтобы повторный обход базы не возвращал клиента в уже остановленную последовательность сообщений.
Ответ «подумаю» требует понимания контекста. Он может означать отложенное решение, отказ, ожидание бюджета или конкретную договорённость связаться позже. Не собирайте только огромный список фраз: задайте поведенческие категории, приоритет явной даты и проверку последующих сообщений. Если клиент сам назвал срок, согласованное действие должно учитывать его. После одного предложения дополнительной помощи молчание не является основанием заново запускать всю серию. На приёмке проверяйте сочетания формулировок, истории и статусов заказа.
Проверьте очередь и транспортную отправку
Запланированное сообщение должно проходить повторную проверку непосредственно перед отправкой. Между созданием задания и его исполнением клиент мог ответить, менеджер — начать работу, а заказ — перейти в активный статус. Проверки только на этапе планирования недостаточно. Очередь должна сохраняться в базе и поддерживать защиту от повторов. Для одного диалога определите порядок ручных и автоматических сообщений, чтобы быстрое отображение в интерфейсе не приводило к перестановке реплик и потере смысла разговора.
Тестовый набор должен включать новый вопрос, ответ сотрудника, вложение, запрет писать, активный заказ, завершённую покупку, жалобу, повтор события и перезапуск. Дополните его потерей доступа к аккаунту и неполной историей. Если история не загрузилась, отсутствие данных нельзя считать доказательством, что никто не ответил. Для рискованных отправок выбирайте безопасную остановку и разбор. Проверки выполняйте в изолированной очереди или на согласованном тестовом получателе; имитацию транспорта нельзя называть реальной доставкой клиенту.
Сохраняйте фактический ответ и причину выбранного маршрута для каждого сценария. Отчёт «все тесты зелёные» не показывает, что именно увидит клиент. Для генеративных подсказок проверяйте несколько формулировок одной ситуации, опечатки, длинную историю и конфликтующие сведения. При этом не требуйте обещания охватить все возможные человеческие фразы. Надёжность складывается из категорий поведения, границ полномочий, повторной проверки состояния и возможности передать неопределённый случай человеку, сохранив его контекст.
Передайте бота вместе с журналом решений
В комплект передачи включите каталог, тексты, расписание, стоп-правила, карту событий, тесты и инструкцию отключения отдельных сценариев. Укажите владельца каждого источника данных и ответственного за ручную очередь. Для изменения акции или услуги должен существовать понятный процесс проверки. Нельзя считать настройку завершённой, если актуальные правила спрятаны только в длинном промпте и их невозможно сопоставить с фактическими отправками. Команда должна уметь объяснить, почему конкретный клиент получил сообщение или почему задание было отменено.
Наблюдайте за качеством разговора отдельно от количества отправок. Полезны доля исправленных подсказок, причины передачи, повторные вопросы и ошибки классификации. Продажи учитывайте по подтверждённому бизнес-источнику, а не по уверенной фразе модели или клику на кнопку. Стоимость генерации оценивайте по реальным вызовам и объёму контекста. Готовые шаблоны, повторное использование актуального результата и ограничение ненужных запросов могут сократить расход, но конкретный эффект необходимо измерить на выбранном сценарии.
Заполняемый бриф в источниках помогает согласовать эти правила до включения отправок. Начните с узкого проверенного маршрута, покажите фактические ответы и убедитесь, что ручная работа сохраняет приоритет. Затем расширяйте сценарии с тем же порядком проверки. Хороший бот продаж помогает человеку перейти к полезному следующему действию, не выдумывает условия и умеет вовремя остановиться. Именно это следует принимать как рабочее поведение продукта, сохраняя различие между подсказкой, автоматическим сообщением и подтверждённым результатом продажи.
Источники
- Telegram Bot API: Update
Telegram / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Bots FAQ
Telegram / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Можно ли считать открытие любого пустого чата основанием для приветствия?
Нет. Требуется подтверждённое событие и проверка условий. Пустая локальная история может означать неполную загрузку, а не отсутствие переписки.
Что делать, если клиент уже заказывал у компании вне CRM?
Сохранить сведения как сообщение клиента и уточнить статус только при его неизвестности. Текущую работу или проблему передать менеджеру; отсутствие записи в CRM не является доказательством отсутствия заказа.
Чем готовая ИИ-подсказка отличается от автоматического ответа?
Подсказка готовит текст для проверки сотрудником и не должна сама отправлять сообщение. Автоматическая отправка требует отдельного разрешённого сценария, очереди, актуальных условий и защиты от повторов.
