Автоматизация обработки звонков: AI для Mango Office, Zadarma и Sipuni

Интеграция AI в облачную АТС: где ломается обработка звонков

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

Вторая половина сбоя лежит не в телефонии, а в учёте. Оператор заводит карточку вручную после разговора, и при плотном потоке часть обращений не фиксируется вовсе. Телефония и учёт обращений расходятся: по логам вызовов триста, в системе — двести с небольшим. Пропущенные вызовы и потерянные обращения обнаруживаются постфактум, когда клиент уже ушёл к тем, кто ответил.

Интеграция AI в облачную АТС закрывает это не «роботом на входе», а связкой событий. В облачных АТС — Mango Office, Zadarma, Sipuni — есть уведомления о каждом вызове: сброс в очереди, ожидание дольше сценария, повторный звонок с того же номера. Дальше расшифровка и разметка разговора, автоматическая запись в учётную систему и эскалация на оператора по правилам, а не по интуиции смены.

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

Что меняется после подключения бота к телефонной линии

Интеграция AI в облачную АТС работает на уровне линии и сценария маршрутизации, поэтому первый измеримый сдвиг — время первого ответа. Бот поднимает вызов на первом гудке, а не после того, как освободился оператор: в пиковые часы это разница между «ответили сразу» и «перезвоним». Доля пропущенных вызовов падает не из-за ускорения людей, а потому что часть обращений линия закрывает без человека вообще.

Приём вызовов круглосуточно перестаёт быть отдельной сменой. Ночью, в выходные и в момент, когда все операторы заняты, вызов не уходит в «не ответили»: бот уточняет запрос, фиксирует контакт и либо закрывает вопрос сразу, либо ставит обратный звонок в очередь с готовым контекстом.

Разгрузку операторов считаем по структуре обращений, а не по ощущениям. Типовые обращения — статус заявки, часы работы, адрес, повторный заказ, консультация по услуге — уходят на автоматику целиком; человеку остаётся то, где нужны полномочия и переговоры. На типовых сценариях снимается основная часть нагрузки, и в часы пик уже не нужно расширять смену.

Эффект остаётся управляемым: в отчётах видно долю вызовов, принятых без человека, распределение по темам, число переводов на оператора и причины передачи диалога. По этим данным дописываются сценарии — поэтому доля пропущенных и время ответа продолжают улучшаться после запуска, а не фиксируются на старте.

Сравнение режимов подключения бота к телефонии

Режим подключения определяет, что услышит абонент в момент звонка и как поведёт себя бот при сбое. Он же задаёт ограничения телефонной линии: сколько одновременных соединений держит номер и останутся ли свободные каналы под операторов. Ниже — три схемы, между которыми реально выбирают при интеграции AI в облачную АТС.

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

Этапы внедрения: от аудита линии до передачи в поддержку

Внедрение идёт волнами: сначала снимаем текущее состояние линии, затем проектируем, настраиваем в тестовом контуре и только после этого выводим на боевой трафик. Порядок важен — правки в сценарий без понимания маршрутизации дают эффект «робот мешает», а не разгруженную линию.

1. Аудит сценариев обработки. Выгружаем историю вызовов за период и разбираем путь обращения: где абонент уходит из очереди, сколько ждёт ответа, какие вопросы повторяются чаще всего. На выходе — карта текущих сценариев с точками потерь и перечень обращений, пригодных для автоматизации.

2. Проектирование схемы маршрутизации. Определяем, какие вызовы уходят на голосового ассистента, какие сразу на оператора, по каким правилам происходит эскалация и как обрабатываются нерабочие часы. Схему согласуем до настройки — она определяет логику всех остальных этапов.

3. Настройка сценариев в тестовом контуре. Пишем реплики и ветвления под ответы абонента, задаём передачу контекста разговора оператору при переводе. Тестовый номер изолирован от боевой линии, поэтому правки не задевают реальных клиентов.

4. Проверка на тестовых вызовах. Прогоняем сценарии живыми вызовами: слушаем записи, отмечаем, где ассистент не распознал намерение или преждевременно завершил диалог. Считаем долю корректно определённых запросов и долю обращений, закрытых без оператора.

5. Пилот на ограниченном трафике. Выводим ассистента на часть звонков или на одно направление и сравниваем с контрольной группой: время до ответа, число переводов на человека, доля повторных обращений.

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

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

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

• Конфигурации сценариев — деревья диалогов с условиями перевода на оператора, обработкой молчания и перебиваний, ветками под нестандартные ответы. Отдельным перечнем — фразы, на которых сценарий останавливается и зовёт человека.
• Схемы маршрутизации — распределение по очередям, навыкам и расписанию, резервные маршруты при недоступности группы или перегрузке линии, отдельно ночные и праздничные окна.
• Правила доступа к записям разговоров — кто и на каком основании слушает, сроки хранения, обезличивание записей для тестовых прогонов, журнал прослушиваний.
• Документация по линии — карта обмена с учётной системой, перечень тестовых номеров, порядок откатa к предыдущей версии сценария.
• Регламент для операторов — как принять переведённый звонок, что видно на экране до поднятия трубки, как помечать итог разговора и куда передавать спорные случаи.
• Перечень приёмки — контрольные звонки с ожидаемым поведением по каждому сценарию и условия, при которых линия считается несданной.

Кейс: сокращение потерянных звонков и времени ответа

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

Разбор записей показал, что 4 из 10 обращений типовые: статус заявки, перенос визита, адрес, часы работы. К облачной АТС на Mango Office мы подключили слой обработки речи — без замены провайдера и номеров.

Как работает маршрутизация

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

После запуска доля принятых вызовов выросла до 96%, среднее время ответа сократилось до 7 секунд, 41% обращений закрывается без оператора. Пиковая нагрузка на смену выровнялась: разброс между утренними и вечерними часами сократился вдвое, повторные звонки по одному вопросу почти исчезли, а ночные обращения фиксируются как заявки. Переход занял три недели, линия при этом не останавливалась.

Чем AI-бот на линии отличается от голосового меню?

Голосовое меню — это дерево, где каждый шаг задан заранее: абонент слышит список пунктов и нажимает кнопку, вызов уходит в нужную группу. Работает предсказуемо, но ровно до тех пор, пока абонент точно знает, что ему нужно, и узнаёт свой вопрос в формулировке меню.

Ломается на первом же нестандартном обращении. Абонент не понимает, к какому пункту отнести свой случай, жмёт ноль или первую попавшуюся цифру — вызов уходит не к тому специалисту, и его переадресуют второй и третий раз. Дерево при этом растёт: под каждый новый повод добавляются уровни, а навигация становится длиннее самого разговора.

AI-бот на линии работает не по веткам. Он ведёт свободный диалог с абонентом, а распознавание речи идёт по потоку, без повторного ввода и пауз: из фразы «второй день не проходит платёж по счёту» извлекается смысл — тема, срочность, признак проблемы с оплатой — и маршрутизация обращения строится по этому смыслу, а не по нажатой кнопке.

Инженерно это переносит работу со схемы меню на модель: вместо перерисовки дерева под новый повод достаточно дополнить набор намерений и правила приоритета. Обратная сторона — бот обязан передавать оператору контекст разговора и расшифровку, а для критичных веток (блокировка карты, спор по списанию) остаётся жёсткий перевод на человека.

Дальше разбираем, как такая интеграция AI в облачную АТС собирается на практике — от подключения к потоку вызовов до правил передачи диалога оператору.

Технические сомнения перед внедрением

Эти вопросы инженеры задают на технической сессии почти всегда — и правильно: каждый из них меняет схему интеграции AI в облачную АТС. Отвечаем так, как отвечаем на встрече, без общих слов.

Сложный разговор уходит оператору?

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

Где хранятся записи разговоров и расшифровки?

В вашем контуре. Аудио остаётся в хранилище телефонии или в вашем объектном хранилище, текст — в базе с разграничением доступа. Сроки хранения и правила удаления задаются политикой под ваши требования, а не настройкой по умолчанию.

Что будет при сбое связи или распознавания?

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

Кто отвечает за систему после запуска?

Мы. Следим за метриками распознавания, обновляем словари под новые продукты и кампании, разбираем спорные звонки вместе с вашей командой. Регламент реакции и точки контроля фиксируем в договоре.

Обсудим вашу задачу по обработке звонков

Опишите задачу — сколько линий и операторов, какая облачная АТС используется, что происходит с пропущенными и короткими звонками сейчас. Мы снимем текущую схему прохождения вызова, посмотрим записи и логи, отметим места, где обращения теряются, и вернёмся с оценкой сроков и планом внедрения. Никаких общих слов про «цифровую трансформацию» — разбор вашей линии и порядок работ.

Что вы получите из разговора:

• Разбор текущей схемы: очереди, группы операторов, правила переадресации, ночные и праздничные сценарии.
• План внедрения по этапам: что делаем первым, что после пилота, где точки контроля на каждом шаге.
• Оценку сроков по каждому этапу и список данных, которые нужны от вас.
• Порядок пилотного запуска на одной линии: ограниченный поток звонков, понятные критерии приёмки результата.
• Метрики пилота — доля корректно обработанных обращений, время до соединения с оператором, число потерянных вызовов.
• Варианты развития: возврат клиента в очередь, передача оператору с готовым контекстом, отчёт по причинам обращений.

Дальше решаете вы: запускать пилот на одной линии или расширять сразу на все. Порядок работ прозрачный — текущая обработка вызовов не останавливается ни на одном этапе. Обсудим задачу — вернёмся с оценкой и планом.