Как телефонная станция сама научилась заводить заявки в Bitrix24

01 — Постановка задачиГотовых компонентов много. Готовой связки между ними — нет

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

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

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

02 — АрхитектураТелефония, голос и CRM — как отдельный слой-переводчик

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

• Станция сама выясняет по номеру, кто звонит, ещё до начала разговора — сотрудника не спрашивают, как его зовут, если он уже есть в CRM.
• Голосовая модель ведёт диалог в потоковом режиме: перебивания, паузы и уточняющие вопросы обрабатываются вживую, без задержки, характерной для «озвучки по кускам».
• Категорию обращения — из заранее описанного справочника неисправностей — модель определяет сама, по смыслу разговора, без отдельного шага «выберите категорию тоном».
• Заявка в CRM создаётся автоматически сразу после устного подтверждения сотрудника — без единой строки кода, написанной вручную под каждый новый тип обращения.

03 — Детали, которые обычно опускаютТишина — это тоже данные

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

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

04 — ИтогЧто это дало

Сотрудник больше не тратит время на то, чтобы дозвониться и продиктовать проблему кому-то живому — иногда в ожидании на линии, если диспетчер занят другим звонком. Заявка в Bitrix24 появляется с точным описанием проблемы и корректной категорией уже через минуту разговора, без ручного заполнения карточки.

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