Начните с правила: пока клиент уточняет один запрос, чат-бот дополняет одну заявку. Для этого боту нужен черновик, в котором он собирает сведения из разных сообщений, учитывает исправления и отмечает, чего ещё не хватает. Перед отправкой менеджеру бот показывает итог и просит подтверждение. Ниже разберём, как настроить такой диалог, когда задавать уточняющие вопросы и что передавать в CRM. По этому плану можно составить задание разработчику и проверить сценарий до запуска.
Как объединить несколько сообщений в один запрос?
Клиент пишет так, как ему приходит в голову: сначала называет услугу, затем добавляет подробности, потом вспоминает про срок. Если бот воспринимает каждую реплику как отдельное обращение, менеджер получает несколько неполных заявок вместо одной.
Возьмём учебный пример для мастерской. Клиент последовательно отправляет: «Нужен ремонт дивана», «Просел слева», «Фото сейчас пришлю», «И ещё заменить ткань». Здесь один предмет и несколько пожеланий к работе. Боту нужно собрать их в общий черновик, а фотографию прикрепить к тому же запросу.
Сначала определите, что менеджеру нужно знать для следующего действия. Для предварительной оценки ремонта это предмет, описание проблемы и желаемые работы. Если от адреса зависит выезд, бот уточняет населённый пункт. Полный опросник на все случаи запускать сразу не нужно.
- Задайте поля черновика под конкретную услугу: что нужно сделать, с каким предметом и к какому сроку.
- После каждой реплики добавляйте сведения в подходящее поле, сохраняя связь с текущим обращением.
- Отмечайте пробелы, которые мешают передать запрос специалисту.
- Задавайте следующий вопрос только после того, как бот учёл уже полученные ответы.
Разделите обязательные и дополнительные сведения. Без описания задачи менеджеру придётся начинать разговор заново. А отсутствие фотографии не всегда мешает принять обращение: это зависит от вашей услуги. Если бот собирает запрос на предварительный расчёт, пригодится отдельный сценарий сбора данных для сметы и передачи заявки специалисту.
Когда боту отвечать и завершать сбор заявки?
Пауза между сообщениями не означает, что клиент закончил. Он мог искать фотографию или проверять размеры. Поэтому в настройках разделите два события: бот готовит ответ после паузы, а клиент подтверждает готовность заявки. Одно не заменяет другое.
Разработчику стоит заложить короткое ожидание перед ответом и отмену этого ответа, если приходит продолжение. Длительность подберите на тестовых переписках: бот не должен перебивать человека после каждого слова, но и оставлять его без реакции на законченную фразу тоже не стоит.
После серии сообщений бот задаёт только недостающий вопрос. Например: «Записал: просела левая часть дивана, также нужна замена ткани. Пришлите фото дивана целиком и места просадки». В таком ответе видно, что бот уже понял, а клиенту понятно, что прислать дальше.
Когда сведений достаточно, покажите сводку: «Ремонт дивана: устранить просадку слева и заменить ткань. Фото приложено. Можно передать запрос мастеру?» Рядом подойдут кнопки «Передать мастеру» и «Исправить». Текст «Да, отправляйте» должен вести к тому же действию, что и кнопка подтверждения.
Если клиент перестал отвечать, оставьте обращение в статусе черновика. Когда по правилам бизнеса даже неполный запрос нужно показать сотруднику, помечайте его явно: «Не подтверждён, не хватает фото». Менеджер увидит, на чём остановился разговор, и не примет черновик за готовую заявку.
Как учитывать исправления и отличать новый заказ?
Слова «ещё», «нет» или «лучше» сами по себе не определяют, что делать с заявкой. Боту нужен контекст. Фраза «И ещё заменить ткань» дополняет ремонт того же дивана, а «Ещё нужен ремонт кресла» требует уточнения: добавить второй предмет в обращение или оформить его отдельно.
Для исправлений задайте правило: новое явное значение заменяет прежнее в текущем черновике. В учебном диалоге клиент пишет «Нужно к пятнице», затем «Нет, лучше на следующей неделе». В итоговой сводке остаётся следующий согласованный срок. Старый вариант не должен попасть в задание мастеру как второе пожелание.
При неоднозначности бот задаёт короткий вопрос. Например: «Кресло добавить в этот запрос или оформить отдельно?» Самостоятельно объединять все обращения одного клиента тоже нельзя: у них могут быть разные сроки и исполнители.
Отдельно предусмотрите сообщения после подтверждения. Если клиент дописал «Ткань хочу светлую», бот сообщает, что добавил пожелание, а система передаёт его в уже созданную карточку. Если работа началась и изменение требует согласования, бот направляет уточнение сотруднику, не обещая, что мастер его принял.
Для голосовых сообщений действует тот же порядок: сначала получить текст и проверить смысл, затем дополнить черновик. Если в записи неясно название предмета или срок, лучше переспросить. Подробнее этот переход разобран в материале о том, как чат-боту расшифровать голосовое и собрать заявку.
Как передать одну заявку в CRM без дублей?
В задании на интеграцию опишите правило: первое подтверждение создаёт карточку, дальнейшие уточнения обновляют её. Для этого системе нужен идентификатор обращения, который связывает переписку с карточкой CRM. Связи только с клиентом недостаточно, ведь у него могут быть разные заказы.
Повторное нажатие на кнопку «Передать мастеру» не должно создавать ещё одну сделку. Разработчику нужно предусмотреть проверку уже выполненного действия. То же касается повторной доставки события, когда сервисы обмениваются сообщениями после сбоя связи.
Успешную отправку бот подтверждает только после ответа системы о том, что она приняла заявку. Если CRM недоступна, корректный текст выглядит так: «Пока не удалось передать запрос. Повторю отправку». Сотруднику при этом нужен сигнал о сбое, чтобы обращение не осталось без внимания.
В карточку передавайте краткую сводку, вложения и доступ к исходной переписке. Менеджеру важно сразу увидеть задачу и то, что ещё нужно уточнить. Одна длинная лента сообщений без итога заставит его заново разбирать разговор.
Такую работу полезно делить на настройку диалога и интеграцию с CRM. Сначала согласуют поля и правила подтверждения, затем подключают создание и обновление карточки через API. При передаче задачи подрядчику попросите показать весь путь на тестовом обращении: от фразы клиента до исправления уже созданной заявки.
Типичные ошибки: что проверить перед запуском?
Проверяйте сценарий в том канале, где будут писать клиенты. Переписка в тестовом окне конструктора не покажет, как интеграция принимает вложения и реагирует на повторное нажатие кнопки. Заранее запишите ожидаемый итог каждого диалога.
- Бот отвечает на каждую короткую реплику. Отправьте описание задачи отдельными сообщениями подряд: ожидаемый результат — общий ответ с учётом всей серии.
- Бот повторно спрашивает известное. Укажите услугу и срок в первом сообщении: в следующем вопросе он должен запросить только недостающие сведения.
- Исправления остаются рядом со старыми данными. Измените срок до подтверждения: в сводке и карточке должен остаться актуальный вариант.
- Повторное подтверждение создаёт дубль. Нажмите кнопку отправки повторно и проверьте, что в CRM появилась одна карточка.
- Бот объявляет об успехе при сбое. Попросите разработчика имитировать недоступность CRM: бот должен сообщить о задержке, а система — сохранить возможность повторной отправки.
Сценарий готов к пробному запуску, когда эти проверки проходят от начала до конца, а сотрудник видит в карточке тот же запрос, который подтвердил клиент. Если диалог проходит проверку, но карточки дублируются, исправлять нужно передачу событий. Если карточка одна, но в ней старый срок, проверьте обновление черновика и данные перед отправкой.
За две минуты напишите тестовую переписку с исправлением: «Нужен ремонт дивана» → «Просел слева» → «К пятнице» → «Нет, на следующей неделе». Под ней запишите ожидаемый итог: одна заявка с актуальным сроком. Это первый готовый тест для вашего чат-бота.
