Как восстановить диалог после сбоя связи бота с CRM
Пример расчёта (условные цифры): если на обработку каждого из 30 запросов по теме «восстановление диалога» уходит по шесть минут, за месяц это три часа работы до учёта исключений. Проверьте свои числа до выбора решения. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно разобрать процесс и первый пилотный сценарий.
Результат, который нужен по теме «восстановление диалога»
Отделите частый путь от исключения. В обычном процессе пользователь ждёт понятного следующего шага, но сейчас cRM временно недоступна, бот подтверждает заявку, но карточка не создаётся. Укажите точку, где требуется подтверждение системы или человека.
Ошибки сценария видны в реальных формулировках и переходах, а не в красивом демонстрационном диалоге. Сохраняйте вопрос, версию правила, источник ответа, решение о передаче и итог. Тогда можно выяснить, где возникла проблема: в тексте, данных, правах или обмене с другой системой.
При недоступной CRM сохраните событие в очереди с устойчивым ключом. Повторная передача должна завершить старую операцию, а не создать дубль; зависшие события нужны в отдельном списке для ответственного.
Перед запуском сопоставьте разговор с записью в источнике «Журнал событий бота и CRM». Если одни и те же данные расходятся, выберите главный источник и правило исправления до автоматической рассылки.
Вопрос к вам: сколько минут сотрудник тратит на сбор одних и тех же данных по каждому обращению?
Лайфхак: возьмите пять последних обращений и отметьте, какую информацию человек уже сообщил. Из этих данных получится короткий первый экран бота.
Какие данные и решения подготовить
Проверяйте формат только там, где от него зависит действие системы. Слишком строгая маска ввода может отклонять корректный случай, который специалист легко распознал бы по контексту.
Предусмотрите ситуацию «повторная отправка создаёт дубль» до запуска. Если бот не может доказать правильность действия, он сохраняет ввод и передаёт его специалисту с объяснением причины остановки.
Для персональных данных выбирайте минимальный доступ и срок хранения по правилам компании. Когда источник недоступен или ответ не подтверждён, бот должен прямо указать ограничение. После обновления базы знаний проверяйте не только новый ответ, но и соседние сценарии.
Повторное нажатие должно находить прежнюю запись. Если система создаёт дубль, сотрудник потом разбирает два статуса по одной задаче. Используйте устойчивый ключ операции и журнал подтверждений.
Перед тестом назначьте владельца исходных сведений и владельца текста бота. Когда правило меняется, оба проверяют одну и ту же цепочку: что введено, что сохранилось, кто получил задачу и каким сообщением она завершилась. Дата обновления без ответственного не защищает от старого ответа.
Два способа обработать запрос
Вручную. Эксперт замечает контекст и тонкую ошибку, которую правило не поймало. Ручной просмотр без журнала охватывает мало случаев и не показывает их частоту.
Через бота. Тесты и мониторинг находят повторяющиеся сбои и дубли. Риск - принять прохождение формальной проверки за доказательство, что пользователь получил верный результат.
При выборе масштаба автоматизации учитывайте стоимость ошибки. Для редких и спорных случаев лучше явный ручной маршрут, чем длинное дерево правил.
Как запустить сценарий по шагам
Шаг 1. Сохранять событие до отправки
Укажите наблюдаемый результат шага и ответственного за его проверку. Пройдите обычный, ошибочный и повторный вариант до запуска.
Шаг 2. Отмечать подтверждение CRM
Укажите наблюдаемый результат шага и ответственного за его проверку. Пройдите обычный, ошибочный и повторный вариант до запуска.
Шаг 3. Повторять с ключом идемпотентности
Укажите наблюдаемый результат шага и ответственного за его проверку. Пройдите обычный, ошибочный и повторный вариант до запуска.
Шаг 4. Разбирать зависшие записи
Укажите наблюдаемый результат шага и ответственного за его проверку. Пройдите обычный, ошибочный и повторный вариант до запуска.
Пройдите весь маршрут на нескольких реальных ситуациях. В тесте нужны успешный вариант, неполные данные, повтор, изменение исходной записи и исключение «повторная отправка создаёт дубль». Смотрите одновременно на экран пользователя и запись исполнителя. Если они говорят о разных итогах, сценарий ещё не готов к широкому потоку.
Таблица проверки результата для «восстановление диалога»
Для этой задачи контролируйте показатель «доля событий восстановленных без потерь». Зафиксируйте его определение, период и источник до запуска. Дополните его временем до результата и числом случаев, которые пришлось исправлять вручную. Иначе отчёт может объявить успехом отправку сообщения, за которой не было нужного действия.
Пример расчёта (условные цифры): если 60 обращений за месяц проходят через бот, но шесть не получают подтверждённого результата, доля проблемных случаев составляет 10%. Это важнее числа отправленных автоответов. Это оценка для проверки процесса, а не обещание эффекта внедрения.
Сверяйте итог не только в день запуска. Через неделю легко обнаружить старую ссылку, изменённый статус или право доступа, которое не было отозвано.
Вопрос к вам: сколько похожих задач в месяц завершается без повторного уточнения и сколько возвращается с той же проблемой?
Лайфхак: храните три проверочных случая рядом с описанием сценария. После каждого изменения прогоняйте их заново и добавляйте новый случай, если обнаружили повторяющуюся ошибку.
Что ещё связано
Сценарий опирается на качество исходных данных и понятную передачу исключений. В A3bot можно собрать маршрут вокруг вашей рабочей системы. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
У задачи «восстановление диалога» есть проверяемое завершение. Бот полезен, когда он приближает к этому завершению и не скрывает задержку или ошибку. Начните с небольшого потока, подтвердите итог в основной системе и только затем расширяйте сценарий.
Напишите, какой процесс хотите автоматизировать: A3bot