Сообщение клиента через карточку обращения передается менеджеру для продолжения разговора

ИИ собрал обращение, отправил его в CRM и не дождался подтверждения. Первое желание - повторить отправку. Но запись уже могла появиться. Тогда повторное создание может дать две карточки одного обращения, а вопрос клиента все еще останется без ответа.

Это условный сценарий для проверки процесса. Само сообщение об ошибке еще не показывает, где остановилась передача. Ниже порядок действий, который помогает выяснить состояние обращения и продолжить работу.

Сначала сохраните то, что уже собрано

До повторной попытки должны сохраниться исходный диалог, содержание карточки и сведения о передаче: ее идентификатор, время попытки и полученный результат. Идентификатор здесь нужен, чтобы отличить повтор той же операции от новой заявки.

Если система этого не сохраняет, восстановление придется начинать с ручного поиска. Такой пробел полезно выявить на учебном обращении до запуска: клиенту не должно требоваться заново отвечать на все вопросы из-за сбоя интеграции.

Не отправляйте в карточку догадки вместо потерянных данных. Неизвестное лучше обозначить прямо и сохранить доступ к разговору.

Проверьте принимающую систему

Откройте CRM и выясните, появилась ли запись, относящаяся к этой передаче. Проверять нужно содержание, место сохранения и доступ принимающего сотрудника. Одного уведомления или результата функции недостаточно.

Дальнейшее действие зависит от того, что удалось подтвердить.

Карточка найдена, данные верны, доступ есть. Повторно создавать ее не требуется. Теперь нужно проверить, назначен ли ответственный и принял ли он обращение. Причину отсутствующего подтверждения доставки разбирают отдельно.

Карточка найдена, но данные неполные или доступ закрыт. Сначала определите, что требуется исправить в существующей записи или правах доступа. Еще одна карточка с той же проблемой не поможет менеджеру продолжить разговор.

Установлено, что запись не создана. Повтор выполняют как ту же передачу, с сохранением связи с исходным обращением. Конкретный способ защиты от повторов зависит от интеграции. Наличие такой защиты нужно проверить, а не подразумевать.

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

Один контакт не всегда означает одну заявку

Проверять дубли только по телефону рискованно. Один человек может обратиться с новой задачей. Это отдельное обращение, даже если контакт совпал.

И наоборот: две попытки передать один и тот же запрос не должны превращаться в две независимые заявки. Поэтому правило повторов должно учитывать саму передачу и ее связь с исходным разговором.

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

Если запись есть, а сотрудника нет

Это уже другая причина остановки. Пересоздание карточки не назначит того, кто продолжит разговор.

Нужна видимая очередь непринятых обращений и конкретный ответственный за ее разбор. Команда заранее определяет, когда обращение должно быть принято и когда клиент должен получить содержательный ответ. Это два отдельных внутренних срока с учетом рабочего времени.

Клиенту сообщают фактическое состояние. «Менеджер подключился» допустимо только после подключения. Удобное время клиента тоже нельзя превращать в обещание компании: «могу после 15:00» не означает «мы ответим после 15:00».

При смене сотрудника передают актуальный контекст и незавершенные действия, затем фиксируют прием новым ответственным. Смена фамилии в CRM сама по себе не подтверждает, что человек начал работу.

Нет сотрудника: очередь и ответственный. Сбой передачи: проверить принимающую систему до повторной отправки

Два разных сбоя: нет сотрудника - нужна очередь с ответственным; не подтверждена доставка - сначала проверяем запись.

Где заканчивается восстановление передачи

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

Например, отправленный запрос плана помещений подтверждает запрос. Получение плана подтверждается файлом. Эти факты нельзя заменять одним статусом «обработано».

Шесть подтверждений передачи: сформировано, доставлено, назначено, принято, ответили по существу, выполнили следующий шаг

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

После подключения менеджера проверьте и поведение ИИ: автоматические ответы должны соответствовать принятому режиму работы. Отдельно стоит посмотреть на отложенные сообщения и условия возврата ИИ в разговор.

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

Какую информацию сохранять для менеджера и какими фактами подтверждать каждый участок передачи, разобрал в статье ALIOT: шаблон карточки и проверки приема обращения.