Интеграция с ip-телефонией Sipuni для застройщика — все сценарии работы с входящими звонками
На связи команда CRM-сопровождения из интегратора Интроверт👋 Сегодня рассказываем про процессы работы с входящими обращениями в Hutton Development — как мы «научили» телефонию определять тип входящего звонка и построили процессы работы с клиентом между конкурирующими отделами продаж.
В аккаунте компании работает несколько отделов — за каждым проектом закреплен свой отдел продаж и отдельный менеджер отвечает за коммуникации с брокерами.
Клиент с нами на CRM-сопровождении уже больше года. За компанией закреплен бизнес-аналитик, который собирает KPI показатели еженедельно — это позволяет «держать руку на пульсе» и принимать решения опираясь на цифры, а не на ощущения.
Такой подход позволил найти проблему со сделками в «Закрыто и не реализовано» — их много и среди них есть дубли.
Причина — телефония некорректно идентифицировала тип обращения. В распределении звонков не были учтены уникальные процессы компании — когда с одним клиентом параллельно работают несколько конкурирующих между собой отделов.
Решение — нужно сделать кастомную доработку интеграции телефонии Sipuni с amoCRM
Вот какие шаги мы проделали, чтобы менеджеры получали только целевые обращения, а руководители — видели корректную аналитику работы рекламных каналов и отделов продаж:
Шаг 1 — бизнес-аналитик подготовил подробное ТЗ на создание в amoCRM сделок по рекламным обращениям. Выделили следующие типы входящих:
- Менеджер получает входящий отвеченный звонок от нового клиента. Видит созданные контакт и сделку с тегом #Входящий_звонок и заполненным полем «Проект».
- Менеджер получает входящий пропущенный звонок от нового клиента. Видит созданные контакт и сделку с тегом #Пропущенный_звонок и заполненным полем «Проект».
- Менеджер получает входящий отвеченный/пропущенный звонок от существующего клиента с открытой/закрытой сделкой по тому же проекту. Видит старые контакт и сделку с запущенным процессом Sensei.
- Менеджер получает входящий отвеченный/пропущенный звонок от существующего клиента без открытой сделки по проекту (сделки по другим проектам могут быть). Видит старый контакт и созданную сделку с тегом #Входящий/Пропущенный_звонок и заполненным полем «Проект».
Отдельный тип обращений — это звонки от брокеров. В компании была выделенная линия и менеджер для коммуникаций с брокерами, но они часто обращались по рекламным номерам и звонки распределялись на отделы продаж.
Шаг 2 — бизнес-аналитик готовит техническое описание работы функциональных блоков и подбирает решение проблем в процессах.
На этапе описания функциональных блоков в ТЗ — аналитик учел любой возможный сценарий взаимодействия с клиентом при входящем или пропущенном.
Благодаря тому, что разработка полностью выполнялась на стороне команды Интроверта — вот какие функции телефонии мы смогли добавить, для порядка в процессах и аналитике:
✅ Решили проблему с дублями при повторных обращениях: при входящем звонке добавили условие на проверку закрытых в «отказ» и «успех» сделок.
Если по входящему контакту сделка найдена на этапах «Успешно реализовано» или «Закрыто и не реализовано» — система сама определяет, насколько давно была закрыта сделка, и ведет ее по подходящему процессу:
- Сделка была закрыта недавно — новая сделка не создается. Система ставит задачу в закрытой сделке с вопросом для менеджера: «Нужно вернуть в работу эту сделку?». Это позволяет нам контролировать создание сделок только по целевым обращениям и видеть реальную аналитику работы рекламных каналов.
- Если сделка была закрыта давно — это новая сделка и она создается по описанному аналитиком сценарию согласно типу обращения (см. Шаг 1).
✅ Все входящие под контролем: при входящем — звонок в первую очередь поступает ответственному за активную сделку менеджеру, если у него нет возможности ответить — распределяется на всех. Такой подход позволяет решить проблему с пропущенными.
В случае когда на входящий ответил сотрудник не ответственный за сделку — система сама в активной сделке поставит для него задачу — описать звонок с клиентом. Ответственный менеджер зайдет в сделку и просто прочитает примечание с описанием звонка не тратя времени на выяснение деталей у коллеги.
✅ Научили CRM-систему определять звонки от брокеров: в карточке контакта добавили поле с типом «брокер». При входящем звонке даже на рекламные номера — система определяет брокера и направляет звонок ответственному менеджеру.
Добавили голосовое оповещение для сотрудника — он может подготовится к разговору. Для брокера — также свое оповещение.
Результат — все сценарии работы с входящими звонками проработаны и оцифрованы в amoCRM
⭐ Решили проблему с дублями при повторных обращениях — менеджеры работают по процессу только с целевыми обращениями. Система не создаст сделку если клиент позвонил узнать, когда он получит ключи. Руководители видят правильную аналитику: сколько новых и повторных клиентов реально обратилось в компанию. А система тегирования позволяет собрать показатели работы рекламных каналов.
⭐ Теперь телефония умеет определять тип обращения и работает с любым входящим контактом по строгому сценарию. В CRM-системе параллельно работает несколько конкурирующих отделов продаж — теперь телефония создает сделку, даже если у контакта уже есть активная сделка — проверяет условие в поле «Проект».
⭐CRM-система идентифицирует брокеров и переводит на линию ответственного менеджера, даже если брокер позвонил по рекламному номеру. Менеджерам проектов больше не нужно тратить время на нецелевые для них звонки, а брокеры сразу попадают на своего менеджера.
⭐Теперь для каждого отдела в CRM-системе создаются свои сделки — если клиент рассматривает покупку апартаментов в разных зданиях.
Этим кейсом мы показываем, как может нарушить бизнес-процессы всего один источник входящих лидов. Необходимо регулярно оценивать состояние CRM-системы и анализировать работу процессов — замерять KPI показатели.
То есть в компании есть отдельный сотрудник, который принимает звонки от брокеров? Почему это не делает обычный менеджер, если он закреплен за объектом? И чтобы звонок переасресовался на специального менеджера по работе с брокерами эти самые брокеры должны быть изначально внесены в систему с соответствующей пометкой? Очень странно все это и не понимаю в чем смысл
Думаю, такова специфика работы данного клиента.
Возможно, связано это с тем, что менеджер по брокерам снимает с ОП нагрузку однотипных вопросов от брокеров. В статье подчеркнуто, что менеджерам поступают целевые обращения.
А то звонят, уточняют по несколько раз куда ехать, как добраться, потому что не понятно.
Мы же тут за эффективность боремся, а если действия менеджера сводятся к неэффективной череде консультаций и ответы на однотипные вопросы, то и эффективность менеджера снижается, и загружен он непонятно чем, хотя должен был бы продавать.