Куда попадает обращение, пока клиент ждёт ответа
Пока обращение ищет нужного менеджера, клиент уже ждёт ответа.
Когда сообщения приходят из разных каналов, один администратор часто становится живым маршрутизатором: читает, решает, кому передать, отмечает срочное. Пока он разбирается, обычный вопрос и жалоба могут выглядеть одинаково. Мы собрали сценарий, который помогает разобрать этот входящий поток и передать его по назначению.
Сначала задаём правила маршрута
До запуска я настраиваю категории обращений, отделы и ответственных. Отдельно определяем признаки срочности: например, жалоба, отказ, вопрос об оплате или повторное обращение.
Это не универсальная таблица, которую можно бездумно поставить любой компании. Нужно понять, какие сообщения приходят именно вам, кто должен их разбирать и что для вас действительно срочно. Иначе агент будет уверенно сортировать поток по чужим правилам.
Как обращение проходит сценарий
Входящее сообщение попадает в CRM. Агент определяет его категорию и адресата, а затем оценивает срочность по заданным признакам. После этого сценарий предлагает назначение.
На первом этапе решение подтверждает администратор. Мы смотрим на реальный поток и проверяем, как агент различает категории и кому направляет сообщения. Когда маршрутизация проверена, сценарий может распределять обращения самостоятельно. Спорные случаи он передаёт человеку.
Здесь важен не эффектный ответ модели, а понятный маршрут: обращение пришло → получило категорию и оценку срочности → попало к ответственному. Если правила категорий не совпадают с работой отдела, автоматизация просто ускорит неправильную сортировку.
Где сценарий встречается с CRM и каналами
Готовая версия сейчас работает как интеграция с amoCRM. Входящие сообщения из мессенджеров подключаются через Wazzup. Для Битрикс24 готового пакета пока нет, поэтому говорить, что сценарий там уже работает, нельзя.
Сам стык начинается с того, что обращение должно попасть в CRM в виде, пригодном для обработки. Дальше сценарий определяет категорию и адресата, а CRM становится местом, где обращение получает ответственного. Телефония и другие каналы требуют отдельной проверки конкретной схемы подключения: в текущей карточке сценария подтверждены amoCRM и мессенджеры через Wazzup.
Что происходит с текстом обращения
В открытом контуре классификацию выполняет облачная модель, которой передаётся текст сообщения. Значит, до запуска нужно определить основание для обработки персональных данных. Этот вопрос нельзя закрыть одной настройкой маршрута: его нужно решить для конкретного процесса и компании.
Закрытый контур спроектирован под запрос. Это отдельный вариант размещения, а не свойство уже работающей открытой интеграции. Условия обработки данных нужно учитывать при выборе контура до запуска сценария.
Что он берёт на себя, а что остаётся человеку
Практический эффект здесь простой: обращение быстрее попадает к тому, кто должен его разобрать. Администратору не нужно вручную решать судьбу каждого сообщения в общем потоке. При этом сценарий не разбирает ситуацию вместо менеджера и не отвечает клиенту за него.
Точность категорий настраивается на потоке конкретной компании, поэтому начинать нужно с режима подсказки. Нестандартные и спорные обращения остаются за человеком. Если проверка показывает, что правила маршрута надо поправить, сначала меняем их — и только потом расширяем самостоятельное распределение.
Начать можно с одного входящего потока: задать категории и ответственных, включить подсказку, проверить назначения на реальных обращениях. Так видно, где правила уже работают, а где администратору всё ещё нужно принять решение самому.
На своей заявке проверить, как агент классифицирует обращение и отвечает в CRM, можно в боте: ответ приходит за 30 секунд, регистрация не нужна, данные не сохраняются.