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