Интеграция телефонии с CRM: как не терять звонки

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

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

Цепочка почти везде одинаковая, различаются детали реализации. Клиент набирает ваш номер, звонок приходит на АТС, АТС передаёт номер в CRM и спрашивает, знаком ли этот контакт. CRM отвечает, кто у клиента ответственный, АТС направляет вызов ему, а на экране менеджера всплывает карточка. После разговора телефония отдаёт в CRM длительность и ссылку на запись, и они ложатся в дело внутри сделки. Если никто не ответил, срабатывает сценарий пропущенного.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сторону CRM закрывает наша практика внедрения Битрикс24: воронки, права доступа и бизнес-процессы настраиваются под тот же маршрут звонка, а не отдельно от него. Телефония и CRM при этом идут одним договором, поэтому на стыке не остаётся зоны, за которую формально никто не отвечает.

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