Задача
Компания ведёт абонентское обслуживание: десятки организаций на договорах технической поддержки, у каждой свои базы, филиалы и магазины. Обращения приходят тремя разными путями – кто-то звонит, кто-то пишет в рабочий чат мессенджера, кто-то стучится через 1С-Коннект прямо из своей программы.
Диспетчер разрывается между каналами. Звонок в нерабочее время просто теряется: перезвонить некому, а клиент утром начинает разговор заново. Заявка, поданная голосом, живёт отдельно от заявки, поданной текстом, и связать их может только человек, который помнит оба разговора.
Отдельная боль – новые клиенты. Их около одного процента от всех звонков, но это единственный входящий поток продаж, и терять его нельзя. При этом новый клиент и действующий требуют совершенно разной обработки: первому нужен менеджер и сделка, второму – заявка в системе учёта.
Решение
Мы собрали единый приёмник обращений, за которым стоит голосовой бот и два текстовых канала. Точка входа у каждого своя, дальше все три сходятся в общую логику: опознать клиента, понять тип обращения, собрать недостающее и положить результат в нужную систему.
Голосовой агент отвечает на звонок, представляется и дальше говорит обычным языком – без тонального меню и без «нажмите единицу». Его можно перебивать: он замолкает и слушает. Такой голосовой бот держит четыре сценария разговора и сам определяет по словам звонящего, какой из них сейчас нужен.
Текстовые каналы – мессенджер MAX и 1С-Коннект – работают в групповых чатах, где сидят представители одной организации. Бот читает все сообщения без упоминания и сам решает, где обращение, а где обсуждение между коллегами.
Развилка: кто звонит, тот и определяет маршрут
Это главная механика проекта. Опознание идёт по номеру телефона через карточки клиентов, и от его результата зависит всё дальнейшее.
Действующий клиент. Агент выясняет, что именно не работает, к какой организации, базе или филиалу это относится, при необходимости уточняет детали. Заявка уходит в Service Desk на 1С вместе с транскрипцией разговора, аудиозаписью и структурированным описанием.
Новый клиент. В рабочее время агент коротко уточняет цель обращения, переводит звонок на ответственного сотрудника и заводит сделку в Битрикс24. В нерабочее – собирает контакты, создаёт сделку и прощается, не обещая несуществующего дежурного.
Опознать не удалось. Если номера нет в базе, но звонящий говорит, что обслуживается по договору, агент спрашивает ИНН, затем название организации. Обращение принимается в любом случае: не опознали – значит передали человеку с полным набором данных, а не отправили клиента искать другой телефон.
Как это работает
- Обращение приходит в один из трёх каналов: звонок, сообщение в MAX или в 1С-Коннекте.
- Агент опознаёт клиента – по номеру телефона, по привязке пользователя к контрагенту либо по чату, за которым закреплена организация.
- Определяется тип обращения: новая заявка, комментарий к открытой, отмена или вопрос не по сопровождению.
- Для комментария и отмены агент запрашивает список открытых заявок клиента и сопоставляет обращение с конкретной. Не удалось однозначно – не угадывает, а отдаёт человеку.
- Результат уходит в целевую систему: заявка в Service Desk на 1С либо сделка в Битрикс24. Вместе с ней – транскрипция, аудиозапись, номер телефона и краткое описание.
- Клиент получает номер заявки. В голосовом канале агент проговаривает его по цифрам и повторяет дважды, чтобы было время записать.
Что сделано, чтобы обращение не потерялось
Учётная система может лежать. Обновление, обрыв связи, перегрузка – и запись заявки не проходит. Поэтому между ботом и системой стоит собственная очередь: обращение сохраняется на диск, повторы идут по нарастающей паузе, и если за полминуты записать не удалось – в оперативный чат уходит тревога, один раз на обращение, без спама.
Клиенту при этом отвечают сразу: номер придёт отдельным сообщением, как только заявка зарегистрируется. Повторная отправка идёт с тем же ключом идемпотентности, поэтому дублей не возникает даже когда система ответила пустотой, а на самом деле заявку приняла.
Ещё одна мелочь, которая вылезла только на живых разговорах: постановщик заявки и тот, кому по ней отчитываться, – часто разные люди. Поэтому после каждой регистрации бот отдельно спрашивает, кто контактное лицо, и ищет названного человека в базе по последним цифрам номера – формат записи телефона у всех разный.
Результат
Обращение больше не зависит от того, каким путём клиент решил его подать и в какое время суток это случилось. Диспетчер получает готовую заявку с описанием, записью и контактом вместо пересказа по памяти, а входящий поток продаж не смешивается с потоком поддержки.
Стек
Связка собирается под конкретный набор систем заказчика. Вместо Service Desk на 1С может стоять любая учётная система с доступным API – логика маршрутизации от этого не меняется.
Грабли, на которые уже наступил
Голосовые в MAX боту недоступны. Самая дорогая находка проекта. Голосовое сообщение приходит боту пустым событием – без текста, без отправителя и без идентификатора чата. Бот не может даже попросить продублировать текстом: он не знает, в каком чате это произошло. Поддержка мессенджера подтвердила ограничение и сообщила, что доработок не планирует. Вывод для архитектуры: голос живёт в телефонии, мессенджер остаётся текстовым каналом. Это стоило пересборки части сценариев.
Управляющая часть 1С-Коннекта работает по SOAP. Входящие события приходят обычным POST с JSON, а всё, что бот отправляет обратно, идёт через SOAP-вызовы. На осуществимость это не влияет, на сроки – влияет. Зато опознание там проще, чем в мессенджере: пользователь изначально привязан к контрагенту, а границы обращения сервис размечает сам.
Вебхуки не всегда лучше опроса. Для отслеживания изменений в учётной системе мы сознательно не стали просить заказчика поднимать вебхуки: агент раз в минуту спрашивает, что поменялось с прошлого раза, и хранит курсор у себя. Условие тут одно, но жёсткое – дата изменения заявки обязана обновляться при любом изменении, включая комментарий. Не обновляется – схема слепнет.
Где хранить привязку «аккаунт в мессенджере – контакт – клиент». Сначала она жила у бота в файле состояния. Это плохо по двум причинам: потеря файла означает, что бот заново опрашивает сотни людей про их организацию, а диспетчер эту связь не видит и не может поправить. Плюс персональные данные оказываются вне контура заказчика. Перенесли в учётную систему, добавив два метода в API.
Вопросы и ответы
Клиент понимает, что говорит с роботом?
Агент представляется электронным помощником в первой же фразе. Выдавать бота за человека мы не беремся: это ломает доверие ровно в тот момент, когда клиент догадается сам.
Что будет, если учётная система недоступна?
Обращение сохраняется в собственной очереди на диске и отправляется повторно по нарастающей паузе. Клиенту сразу говорят, что номер придёт отдельно. Через полминуты неудачных попыток дежурный получает тревогу. Обращение не теряется даже при перезапуске бота.
Можно ли подключить не 1С, а другую систему?
Да. Приёмником может быть любая учётная система с доступным API – Битрикс24, ПланФикс, собственная разработка. В этом проекте заявки действующих клиентов уходят в Service Desk на 1С, а сделки по новым – в Битрикс24, и это две разные системы в одном контуре.
Бот сам поймёт, к какой из открытых заявок относится комментарий?
Он запрашивает список открытых заявок клиента и сопоставляет обращение по смыслу. Это самый сложный сценарий, и правило здесь жёсткое: при малейшей неоднозначности агент не выбирает наугад, а передаёт обращение человеку.
Сколько занимает запуск такого проекта?
Сама разработка быстрая: один канал с одной учётной системой – примерно два дня, три канала с двумя приёмниками, как здесь, – около пяти. Недели уходят на другое: согласовать методы API с командой заказчика, получить доступы и дождаться, пока на его стороне доделают свою часть. Планировать срок нужно по этому этапу, а не по написанию бота.
Что происходит с записями разговоров?
Транскрипция и аудиозапись прикладываются к заявке в системе заказчика. Обработка персональных данных оформляется отдельно: это часть проекта, а не приложение к нему.