CRM для страхового агентства: полисы и пролонгации

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

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

Поэтому CRM в страховании решает не ту задачу, что в проектных продажах. Там система помогает довести сделку до подписания, здесь — не пропустить дату и подтвердить, что касание состоялось. Ключевое слово «подтвердить»: пока в системе нет отметки, кто и когда вышел на клиента, руководитель не отличает «клиент ушёл к конкуренту» от «агент забыл позвонить». Это два разных диагноза и два разных решения.

Честно про границы. Если вы работаете один и ведёте несколько десятков договоров, вам хватит напоминаний в календаре и аккуратной таблицы — платить за внедрение смысла нет. Контур начинает окупаться, когда появляется второй агент, несколько страховщиков с разными правилами оформления и портфель, который один человек уже не держит в голове. Тогда цена забытой даты становится выше цены настройки системы.

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

Рабочая модель данных для агентства выглядит как цепочка: клиент — объекты страхования — полисы — пролонгации и убытки — комиссия. Каждый уровень отвечает на свой вопрос, и именно поэтому уровни нельзя слеплять в один.

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

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

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

Потом идут касания по клиенту: предложение с вариантами, повторное напоминание в другом канале (мессенджер вместо звонка или наоборот) и финальный контакт за несколько дней до даты окончания. Конкретные интервалы зависят от вида страхования и правил страховщика: для годового автополиса и для ипотечного страхования каркас одинаковый, а сроки разные, поэтому их задают при настройке, а не берут из общего шаблона.

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

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

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

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

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

Технически это обычные сегменты и подсказки в CRM, а не искусственный интеллект. AI полезен на другом участке — в первом контакте и разборе входящих заявок, об этом ниже. Сам кросс-продажный список строится из структуры данных, и именно поэтому структуру стоит проектировать до того, как в систему залили базу.

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

Поэтому обращение должно быть объектом учёта, а не перепиской в личном чате агента. В карточке обращения фиксируются дата события, страховщик, что уже сделано, чего ждём от клиента и чего от страховой компании, а также текущий статус урегулирования. Руководитель видит все открытые обращения на одном экране и понимает, где агентство рискует репутацией прямо сейчас.

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

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

Двумя слоями: правами доступа внутри системы и ограничением выгрузки наружу. База страхового агентства — это плотный массив персональных данных: ФИО, паспортные и адресные данные, сведения об имуществе, иногда данные о здоровье. Такая база интересна не только вам, и уходит она обычно не через взлом, а через обычный экспорт в файл накануне увольнения агента.

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

Принцип здесь тот же, что мы заложили в собственный продукт — медицинскую информационную систему, которую строим с нуля (сейчас это MVP, рабочий прототип, а не коробочный релиз). Там изоляция данных разных клиник сделана через PostgreSQL RLS — row-level security, то есть ограничение на уровне самой базы данных, а не условием WHERE в коде приложения. Разница в том, что при ошибке в коде фильтр на уровне СУБД всё равно не даст увидеть чужие записи. Отрасль другая, а архитектурный приём применим и к портфелю страхового агентства.

Про закон — без подмены понятий. Описанные меры (роли, журнал доступа, ограничение экспорта, размещение данных на серверах в РФ) — это техническая реализация, которая закрывает часть требований к обработке персональных данных. Но правила работы агента и брокера задаёт страховщик и регулятор, а юридическую часть — состав согласий, политику обработки, уведомления — нужно готовить с юристом. Мы не даём юридических консультаций по 152-ФЗ и не выдаём внедрение CRM за «соответствие закону»: делаем техническую часть и фиксируем порядок обработки данных в договоре. Что именно обязан сделать бизнес с клиентской базой, мы подробно разбирали в статье журнала «CRM и 152-ФЗ: что обязан сделать бизнес с клиентской базой».

Полезны на двух участках, и ни один из них не заменяет агента. Первый — входящие заявки. Запросы на расчёт приходят с сайта, из мессенджеров и по телефону, часто вечером и в выходные, и уходят к тому, кто ответил первым. AI-помощник для продаж отвечает сразу, задаёт уточняющие вопросы по вашим критериям (вид страхования, объект, регион, срок), заполняет карточку и передаёт агенту структурированный запрос вместо «здравствуйте, сколько стоит?».

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

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

Ещё одна деталь, которая экономит больше, чем кажется: запись и расшифровка разговоров. Условия страхования обсуждаются голосом, а спорят потом о деталях — что именно обещал агент и что уточнял клиент. Когда итог звонка автоматически попадает в карточку полиса, разбор занимает минуту вместо выяснения, кто что помнит.

С модели данных и одной полной цепочки пролонгации, а не с переноса всей базы и подключения всех страховщиков сразу. Рабочий порядок такой: сначала описать сущности (клиент, объект, полис, комиссия), потом перенести портфель с датами окончания, потом включить автоматическую цепочку касаний на одном виде страхования, увидеть результат за один цикл продлений и только после этого расширять контур на остальные виды и добавлять AI-слой.

Фундамент — это CRM: её можно внедрить с нуля или перенести вашу текущую систему вместе с историей и сверить перенесённое с источником. Если агентству нужен в одном контуре не только портфель, но и задачи, телефония и внутренние процессы, обычно речь о внедрении Битрикс24, где полис и пролонгация оформляются отдельными объектами учёта. Если важнее контроль над данными и гибкость структуры — смотрим в сторону CRM на своём размещении. Что подойдёт именно вам, зависит от числа агентов, страховщиков и состояния текущей базы.

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