Интеграция телефонии с CRM связывает звонок с клиентской карточкой и последующей работой менеджера. Чтобы связка помогала контролировать обращения, до настройки описывают маршрут звонка, ответственного за пропущенные и сценарии приёмки. Конкретное поведение зависит от выбранной интеграции и её настроек.
Наличие виджета в CRM ещё не показывает, что руководитель видит все нужные обращения, а менеджеры знают следующий шаг. Тест «позвонили, карточка открылась» проверяет лишь один вариант. Для запуска нужна связная проверка: кто дозвонился, куда попал вызов, какая карточка выбрана, что осталось после разговора и кто действует, если ответа не было. Ниже - методика такой приёмки без выбора оператора за компанию.
Почему подключение не равно учёту звонков
Звонок может успешно пройти по телефонной сети и не стать обработанным обращением. Например, сотрудник ответил, но не записал договорённость; вызов остался в журнале, но задача перезвонить никому не назначена; история прикрепилась к дублю контакта. В каждом случае проблема находится в своём месте. Увеличение числа функций CRM само по себе не объясняет, где оборвалась работа.
Разделите два результата: техническое событие и действие человека. Событие подтверждается журналом и карточкой, действие - исходом разговора и выполненным следующим шагом. Если клиент попросил расчёт, нужно увидеть, кому передана задача и когда её проверяют. Принятая интеграция не освобождает руководителя от правил обработки обращений. Почему сотрудники обходят систему, отдельно разобрано в статье о работе менеджеров в CRM.
До начала настройки запишите, что именно считаете потерей: отсутствие ответа, отсутствие обратной попытки, неверная карточка или незавершённая договорённость. Не складывайте эти события в одну цифру. У компании может быть несколько попыток связаться с одним человеком, поэтому число вызовов не равно числу потенциальных клиентов. Отдельные определения помогают понять, какую проблему должна решить связка и каким отчётом это подтвердить.
Как устроен путь звонка до результата
В рабочей схеме участвуют номер компании, телефонная станция, сотрудники и CRM. Станция управляет маршрутом: например, меню, очередью и переадресацией. Интеграция передаёт согласованные сведения в систему учёта. Затем менеджер определяет итог и следующий шаг. Это описание ответственности, а не обещание, что любой сервис умеет все перечисленные действия без дополнительных настроек.
Нарисуйте маршрут для рабочего и нерабочего времени. Укажите, кто принимает общий номер, куда направляется вызов при занятости и кто разбирает обращения после окончания смены. Если звонок можно перевести другому сотруднику, договоритесь, у кого остаётся ответственность за результат. Права и правила должны соответствовать реальному составу команды, включая замены на время отсутствия, а не только сегодняшнему списку пользователей.
Требования к звонкам входят в проект внедрения CRM, но не заменяют его целиком. Сначала полезно проверить готовность компании к CRM: есть ли владелец процесса, единые этапы и возможность принять результат. Без этих решений телефонная интеграция может аккуратно сохранять события, оставляя дальнейшую работу неописанной.
Как выбрать способ подключения без выбора по обещаниям
Начните с существующих условий: какие номера и АТС уже есть, кто ими управляет, где сотрудники разговаривают и какие данные нужны в CRM. Затем попросите интегратора показать подходящий способ по актуальной справке. Вопрос «есть ли интеграция» слишком общий: нужно узнать, какие события она передаёт, где хранится запись, что происходит при переводе и кто помогает при ошибке.
В справке Битрикс24 названы аренда номера, SIP-коннектор и REST-приложение. Разработчик не рекомендует подключать один номер одновременно через REST и SIP из-за ошибок при звонках. Для amoCRM проверяют возможности выбранного виджета телефонии и его условия. Это разные варианты подключения, поэтому нельзя переносить поведение одного приложения на другое без испытания. Тарифы и текущие ограничения сверяют перед работой.
Систему выбирают под весь процесс, а не только под звонки: сравнение есть в статье amoCRM или Битрикс24. При обсуждении внедрения amoCRM или Битрикс24 подготовьте одинаковый список сценариев. Тогда сравниваются результаты для вашей команды, а не длина перечня функций и не только удобство демонстрационного звонка.
Какие сценарии пройти до приёмки
Для каждого сценария зафиксируйте исходные условия и ожидаемое поведение. Нужны тестовые номера: один уже существует в базе, второй ещё не добавлен. Проверяющий со стороны компании должен увидеть результат сам, а не получить сообщение «всё прошло». Не обязательно проводить испытание всей командой одновременно: важно, чтобы наблюдатель понимал рабочий процесс и мог принять его от имени компании.
| Сценарий | Ожидаемый результат | Кто проверяет | Признак ошибки |
|---|---|---|---|
| Известный входящий | Звонок связан с нужной карточкой | Руководитель продаж | История у другого контакта |
| Новый входящий | Виден согласованный путь нового обращения | Руководитель продаж | Номер нигде не найден |
| Пропущенный | Назначен владелец обратного звонка | Руководитель продаж | Есть событие, нет ответственного |
| Вне рабочего времени | Сработал согласованный маршрут | Руководитель продаж | Ответ не соответствует графику |
| Перевод сотруднику | Понятно, кто ведёт обращение дальше | Руководитель продаж | Ответственность потеряна |
| Повторный звонок | История не разъехалась по дублям | Руководитель продаж | Создан лишний контакт |
| Исходящий | Звонок отражён согласованным способом | Руководитель продаж | Карточка не содержит события |
Сначала сравнивают фактический результат с записанным, затем разбирают расхождения. К таблице приложите время проверки, использованный номер и ссылку на карточку. Для каждого замечания нужен ответственный за исправление и повторный тест. Сам факт отправки ошибки интегратору не означает закрытую проверку. После изменения настроек повторите затронутые сценарии, чтобы убедиться, что исправление не поменяло соседний маршрут.
Как устроить работу с пропущенными
Пропущенный вызов требует не только отметки, но и правила обработки. Назовите владельца, момент начала отсчёта и срок реакции. Срок задаёт компания с учётом графика и процесса: универсальную норму для любой команды здесь подставлять не стоит. Если к общему номеру подключена группа, человек, которому приходит уведомление, не обязательно является тем, кто должен перезвонить. Это различие надо убрать из регламента.
Дальше определите, чем подтверждается работа: попыткой обратного звонка, состоявшимся разговором или другим событием. Не смешивайте эти исходы. Если человек не ответил, задача может требовать дальнейшего действия по принятому правилу, но нельзя обозначать такую попытку как восстановленный контакт. Руководителю нужен способ увидеть открытые обращения и понять, почему срок реакции прошёл.
Автоматическое создание задачи возможно только при соответствующей настройке выбранной связки. Не принимайте желаемую схему за встроенное поведение программы. Проверьте, как назначается задача, кто видит просрочку и когда она считается закрытой. Смысл такого правила тот же, что у автоматизации бизнес-процессов: система помогает передать действие и показать отклонение, а решения и ответственность остаются у людей.
Записи, карточки и доступ: что проверить раздельно
Доступность записи и наличие события о звонке - разные вещи. Запись может зависеть от способа вызова, настроек и условий провайдера. В справке amoCRM об аналитике прямо указано, что звонки из приложения фиксируются без записи. Поэтому демонстрация примечания в карточке не подтверждает возможность прослушивания. Если запись нужна для работы, включите отдельный тест доступа к ней по согласованному сценарию.
Проверьте доступ под ролью менеджера и руководителя. Кто видит чужие разговоры, может скачать запись или изменить данные? Условия хранения, передачи и допустимого доступа согласуйте с ответственными специалистами; правовые вопросы записи и обработки данных - с юристом. Публиковать в общей инструкции телефоны клиентов и реальные записи не требуется: для обучения и приёмки достаточно согласованных тестовых данных.
Историю известных клиентов проверяйте не только по одному удобному контакту. Общий номер организации может относиться к нескольким людям, а один человек способен позвонить с разных номеров. Опишите правило, по которому менеджер уточняет клиента и исправляет ошибочную связь. Автоматический поиск по номеру полезен, но не снимает необходимость проверить, соответствует ли найденная карточка реальному собеседнику.
Какие отчёты нужны руководителю после запуска
Начните с вопросов, на которые нужно получить ответ: какие обращения остались без дальнейшей работы, где не найден клиент и какие задачи просрочены. Не переносите число звонков прямо в оценку выручки. Сначала нужно убедиться, что отчёт считает то же событие, что журнал телефонии, и за тот же период. Несколько вызовов могут относиться к одному обращению, а попытка исходящего ещё не означает разговор.
| Сигнал | Возможное объяснение | Как проверить | Следующее действие |
|---|---|---|---|
| Вызовов в АТС больше | Разный состав событий или нет связи с карточкой | Сверить отдельные вызовы за один период | Уточнить правила и устранить расхождение |
| Пропущенный без задачи | Автоматизация не настроена или неверно назначает | Повторить тестовый пропуск | Исправить правило назначения |
| Задача закрыта, контакта нет | Закрывается попытка, а не результат | Посмотреть исход и следующий шаг | Развести состояния в регламенте |
| Запись не открывается | Права, способ звонка или условия хранения | Проверить сценарий и роль пользователя | Согласовать доступ или способ учёта |
| Много дублей | Номера или правила сопоставления не согласованы | Разобрать несколько повторных обращений | Исправить данные и повторить тест |
Например, отчёт amoCRM «Звонки» учитывает звонки, связанные с карточками; по справке звонок без контакта туда не попадает, а события из «Неразобранного» смотрят отдельно. Это конкретное ограничение отчёта, а не доказательство потери всех отсутствующих в нём клиентов. Сначала найдите расхождение на уровне отдельных событий и только затем делайте вывод о работе сотрудников.
Если нужно понимать ещё и рекламный источник, это задача сквозной аналитики, а не просто учёта разговора. Связка телефонии с CRM сама по себе не обещает определить рекламу, которая привела звонок. Источник и UTM-метки требуют отдельной схемы сбора и сопоставления данных. Такую задачу лучше обсуждать отдельно от приёмки базового маршрута звонка.
Как подготовиться к сбоям и передаче ответственности
До запуска согласуйте действие при недоступности CRM, сбое приложения и отсутствии ответственного сотрудника. В каждом случае нужно понять, продолжает ли телефонная связь работать, где остаётся журнал и как позже восстановить учёт. Не обещайте автоматического восстановления без проверки возможностей конкретного решения. Важен не красивый запасной сценарий на бумаге, а понятная последовательность действий для дежурного сотрудника.
Дайте компании перечень систем и владельцев доступа, контакты поддержки и маршрут обращения при ошибке. Опишите, какие сведения приложить к заявке: время, номер, направление вызова и ожидаемый результат. Секреты в такие сообщения не включают. Когда в связке несколько исполнителей, заранее договоритесь, кто принимает проблему первым и кто координирует разбор, иначе каждое звено может отправлять вопрос следующему.
Коротко
- Принимают путь обращения до следующего действия, а не только открытие карточки.
- Новый, пропущенный, повторный и переведённый вызовы проверяют отдельно.
- У пропущенного должен быть владелец, срок и понятный исход обратной связи.
- Отчёты сверяют по отдельным событиям, не смешивая звонки, обращения и клиентов.
Частые вопросы
Нужно ли менять CRM ради телефонии?
Сначала проверьте способы подключения к существующей системе и нужные сценарии. Замена всей CRM требует отдельного обоснования по процессу компании. Отсутствие одной функции в демонстрации ещё не показывает, что менять нужно всю систему.
По пропущенному звонку всегда создаётся задача?
Нет универсального поведения для всех приложений. Условия назначения зависят от интеграции и настроек. Проверьте известный и неизвестный номер, рабочее и нерабочее время, владельца и срок задачи.
Достаточно ли одного тестового звонка?
Он подтверждает только проверенный маршрут. Для приёмки нужны разные исходные условия: новый и знакомый номер, пропуск, перевод, повторный и исходящий вызов. Ожидаемые результаты запишите заранее и повторите проверку после исправления ошибок.
Почему журнал телефонии и отчёт CRM показывают разные числа?
Может отличаться состав событий, период и правила включения в отчёт. Например, справка amoCRM описывает отдельное условие связи с карточкой. Найдите конкретные вызовы, которых нет в отчёте, прежде чем оценивать работу менеджеров.
Можно ли оценивать менеджера только по числу звонков?
Эта цифра не описывает качество контакта и выполнение договорённости. Показатели нужно связать с задачей сотрудника, определениями исходов и проверяемыми данными. Подход к KPI должен учитывать весь процесс, а не только активность.
Кто должен принимать интеграцию?
Со стороны компании нужен человек, который знает правила обработки обращений и вправе подтвердить результат. Настройщик показывает работу, а представитель компании сверяет её с согласованными сценариями. Состав внедрения телефонии определяют по этим требованиям.
