Ни один полис не заканчивается молча: пролонгация и кросс-продажа приходят вовремя и сами.
Страховой бизнес держится на повторяемости: клиент, у которого закончился полис, либо продлевает у вас, либо уходит к тому, кто напомнил первым. При этом даты окончания обычно лежат в учётной системе, а работа с ними - на памяти агента. Битрикс24 превращает эти даты в расписание касаний и добавляет к нему кросс-продажи по истории клиента.
Если узнали хотя бы два пункта - дело не в дисциплине сотрудников, а в том, что процесс нигде не зафиксирован. Ниже - как он выглядит после настройки.
Даты окончания полисов лежат в учётной системе, работа с ними держится на людях, кросс-продажи не системны.
Календарь пролонгаций с автоматическими касаниями, профиль клиента со всеми полисами и сценарии кросс-продаж.
Розница и корпоративные договоры разводятся: у вторых длинный цикл и тендерные процедуры.
Все продукты одного клиента в одном месте с датами и суммами. Именно отсюда берутся и пролонгации, и кросс-продажи.
Автоматические касания за 60, 30 и 7 дней с разным содержанием. Это ядро выручки страховой компании, и держаться на памяти агента оно не должно.
У клиента с автополисом почти всегда есть имущество и семья. Правила подсказывают агенту следующий продукт в нужный момент, а не наугад.
Отдельный процесс со сроками и ответственными. Клиент в момент убытка - самый чувствительный, и качество этой работы прямо влияет на пролонгацию.
Заявки, распределение, показатели по агентам и вознаграждение. Видно, кто продаёт, а кто только числится.
Структура по продуктам, доля пролонгаций, отвал и его причины.
Состав уточняется после разбора процесса: лишние блоки убираем, недостающие добавляем - платить за «пакет целиком» не нужно.
Главная цифра страхового портфеля - по продуктам и агентам.
Сколько продуктов в среднем у одного клиента и как это меняется.
Кто не продлил и что этому предшествовало.
Заявки, оформленные полисы, пролонгации - по каждому.
Отчёты собираются в BI-конструкторе Битрикс24 по вашим данным - это не готовый дашборд из презентации, а настройка под конкретные вопросы, на которые вы хотите отвечать цифрами.
Одно сообщение за неделю до окончания работает плохо: клиент уже мог получить предложение от конкурента. Работающая схема - три касания разного содержания начиная за два месяца, с переходом в звонок, если реакции нет. Настраивается один раз и дальше идёт само, а агент получает список только тех, кто требует разговора.
Роботы и триггеры →Система знает, какие продукты у клиента уже есть, и предлагает следующий логичный - в момент, когда для этого есть повод: покупка автомобиля, окончание другого полиса, обращение по убытку. Это отличается от массовой рассылки тем, что предложение приходит по поводу, и именно поэтому конвертируется.
Управление клиентской базой →CRM для страховой компании строится вокруг одной даты - окончания полиса. Напоминания о пролонгации полиса в три касания начиная за два месяца дают больше, чем любая акция: клиент уходит к тому, кто напомнил первым. CRM для страхового брокера добавляет вторую сторону - страховщиков с условиями и вознаграждением, - и позволяет увидеть, какой партнёр действительно приносит доход. Кросс-продажи настраиваются на той же базе: система знает, какие продукты у клиента уже есть, и подсказывает следующий по поводу.
Обзвон базы и возвраты →Спросите напрямую - ответим текстом, без созвона и презентаций.
Дата окончания полиса хранится в карточке, и система заранее ставит задачу на пролонгацию - клиент не уходит просто потому, что о нём не вспомнили.
По составу действующих полисов система подсказывает, какой продукт клиенту ещё не продан, и планирует касание.
Да: полисы, обращения, выплаты и переписка ведутся в карточке клиента - при передаче другому менеджеру контекст сохраняется.
Система страховщика оформляет полис. Она не работает с клиентом до и после: не собирает заявки из каналов, не ведёт историю общения, не напоминает о пролонгации по сценарию и не подсказывает кросс-продажу. CRM закрывает именно это, забирая из учётной системы даты и суммы.
Да. В карточке полиса фиксируется страховщик, условия и вознаграждение, а отчётность собирается и по клиентам, и по компаниям-партнёрам. Для брокера это ещё и способ увидеть, какой страховщик реально приносит доход с учётом убыточности и качества сопровождения.
Проходим путь заявки до денег с теми, кто в нём работает. Фиксируем точки передачи и повторный ввод данных.
Описываем процесс «как надо» и собираем состав работ в нормо-часах со сроком - до подписания договора.
Собираем первый рабочий контур и запускаем его на реальных сделках, а не на демо-данных.
Учим команду работать в системе, снимаем замечания и планируем следующую очередь.
С чего начинаем у вас. В страховании пилот - календарь пролонгаций. Он окупается на первом же цикле окончания полисов.
Почему база клиентов в таблицах и телефонах менеджеров - это не актив, а риск. Как навести в ней порядок, сегментировать, защитить от увода и начать зарабатывать на повторных продажах. Практика для РБ.
5 минЧем робот отличается от триггера, какие сценарии автоматизации закрывают рутину в отделе продаж и с чего начать.
8 минПочему обзвон в Google Таблицах не масштабируется, как построить процесс на смарт-процессах Bitrix24, настроить попытки дозвона и автоматически создавать повторные сделки. Практика для РБ.
Ни один полис не заканчивается молча: пролонгация и кросс-продажа приходят вовремя и сами. Посмотрим на ваш случай и скажем, что автоматизируется, что нет и сколько это стоит.