Любой агрегатор — это сервис, который позволяет выбрать продукт по самой выгодной цене. Страховой агрегатор — такой же сервис, но со специализацией на страховых продуктах. Запуск агрегатора — тема сегодня популярная, особенно большой спрос на запуск агрегаторов в конкретных нишах. Но сразу возникает вопрос: сколько стоит запустить свой агрегатор, и сколько времени придется потратить на запуск?
С чего все начиналось
К 2019 году мы решили запустить страховой агрегатор. На тот момент на рынке страхования я работал более 10 лет. Начинал с оффлайн‑продаж — работал страховым агентом, менеджером по продажам ОСАГО и КАСКО в автосалоне. Преимущество такого опыта — изучил все нюансы страхового рынка, плюсы и минусы продуктов, проанализировал конкурентов. Узнал фишки страховых компаний, сделал выводы, с кем действительно стоит сотрудничать в качестве партнера — агрегатора страхования.

Было четкое понимание, что за агрегаторами — будущее в виде развития рынка страхования. Это быстро, удобно и выгодно. Но на тот момент тема агрегаторов не то что бы была новой для рынка. Скорее дело в том, что не все клиенты были готовы оформлять электронные полисы. Не говоря уже о том, чтобы оформить его через онлайн‑площадку без известного имени.
Типичное оформление страхового полиса происходило через страхового агента или проверенного менеджера в офисе страховой компании. Почти у каждого уже был свой специалист, который продавал ему страховки. Именно поэтому мы решили ориентировать площадку в первую очередь на агентов, которым было бы удобно оформлять страховку для клиентов в пару кликов.
Первый этап разработки. Подготовка бренд‑платформы
Да, бренд‑платформа — это база, на которой я сформулировал суть того, что делаем, чем сервис будет полезен рынку. Я сразу решил, что суперважно сделать площадку очень простой, так, чтобы было интуитивно понятно, как и что делать. И пользователь не тратил много времени на оформление. Пять минут на один полис, не больше. И главное — онлайн.
Это ключевое преимущество легло в основу всей бренд‑платформы. На его основе выстроились правила и ценности будущей компании, сформировался уникальный образ бренда. Разработка бренд‑платформы заняла около трех‑четырех месяцев.
Тогда же мы выбрали фирменный дизайн компании в желто‑зеленых цветах. Нам важно было визуально выделиться, так как все основные цвета уже были заняты другими участниками рынка. Синий — Ингосстрах, зеленый — РЕСО‑Гарантия. Были варианты космической тематики, современных технологий в духе фильма “Tron”. С неймингом вопрос был решен гораздо раньше, когда я купил домен Polis.Online и понял, что это идеальное название для агрегатора страховых продуктов.
Так агрегатор приобрел свой внешний вид и сформировалась суть продукта.
Второй этап: создание прототипа
После разработки бренд‑платформы мы приступили к визуальной составляющей проекта — его прототипу. Опыт создания прототипа у меня уже был, в рамках другого проекта — финансовой экосистемы INFULL. Тогда мы подготовили сразу несколько прототипов с помощью ребят из крупного интегратора digital‑решений. Разработка дизайна сайта обошлась примерно в 1,5 млн ₽. Это был 2015 год, то есть готовые прототипы сайта и интерфейсов “лежали” 4 года и ждали своего часа.
Прототип — это фундамент сайта, на котором строится интерфейс. Чтобы сделать работающий прототип, мы долго анализировали конкурентов (в первую очередь страховые компании), путь пользователей, смотрели их логику поведения. Для этого использовали данные с основного сайта экосистемы. Далее провели опросы среди самих агентов, что для них будет удобным, как бы они использовали сервис. То есть, как это сейчас называется, провели кастдевы.
В интерфейсе мы сразу предусмотрели личные кабинеты для клиентов и страховых агентов, страницу регистрации, функции сохранения черновиков страховых продуктов, списка проданных полисов, статистику продаж. На подготовку прототипа у нас ушло около полугода.
Третий этап: дизайн сайта агрегатора
На то, чтобы “поженить” наш фирменный стиль с прототипом сайта, с учетом анализа конкурентов, мы потратили еще около 6 месяцев. За это время мы подготовили полноценный дизайн агрегатора со всей его структурой.
По затратам вышло примерно 1,5‑2,0 млн ₽. Цифра очень приблизительная. Дизайн докручиваем до сих пор, поэтому на сегодня потрачена еще более существенная сумма.
Четвертый этап: верстка
Предстояла верстка сайта, которая по сути является программированием. Нам нужно было превратить готовые дизайн‑макеты из Figma в HTML‑страницы, которые уже можно будет редактировать. На верстку мы потратили около 3‑4 месяцев.

Специалистов по разработке сайта я начал искать еще в процессе разработки дизайна. Сперва я пригласил поработать своего друга, но без оплаты. То есть договоренность была такая: “Если проект “выстрелит” — заработаешь много денег”.
В итоге я понял, что это было не очень эффективное решение. Потому что работа, выполнялась медленно, так как человек выполнял ее по мере возможности, совмещая с основным местом работы. Но мы достаточно быстро создали базовую архитектуру будущего сервиса и API, которое должно было лечь в основу сервиса, настроили первые две интеграции с страховыми компаниями.
В целом поиск команды разработчиков был достаточно долгим и сложным. Нанимали специалистов, начинали работать, сталкивались со сложностями из‑за больших различий в архитектуре и технологическом стеке разных страховых компаний. Меняли специалистов снова.
В итоге мы нашли специалиста по рекомендации от действующего сотрудника компании, с нужным бэкграундом и, самое главное, с желанием развивать проект практически с нуля. На первой встрече я воодушевленно рассказывал о своей идее, потенциале рынка, возможности масштабирования проекта и гибкость схем монетизации. В итоге мы договорились. MVP проекта (Minimal Viable Product — “минимально жизнеспособный продукт”) сделали достаточно быстро — за 6 месяцев.
Пятый этап: запуск сервиса и работа со страховыми
В тестовой версии проекта мы работали не только со страховыми компаниями напрямую, но и с другими агрегаторами, которые уже запустились и предоставляли API интеграцию нескольких страховых компаний. Причем состав интеграций был разный: у одного агрегатора 5 страховых компаний, у второго 7, у третьего 9. Самое интересное — все они не пересекались даже частично.
Выбрали стратегию: возьмем всех агрегаторов, подключим и сделаем “агрегатора агрегаторов”. И обеспечим себе более широкое покрытие страховых компаний и суперпроходимость. Такая технология помогла быстро найти различия в условиях работы с страховыми компаниями и автоматически найти ошибки в интеграциях. А еще понять, что условия андеррайтинга (сегментации/пропускной способности) разные, есть различия в размерах вознаграждения у агрегаторов. И что анализируя эти данные, можно договориться о более интересных условиях с партнерами (страховыми компаниями).
Так мы смогли быстро расширить список страховых компаний (по сути у нас сразу было самое лучшее покрытие по списку страховых компаний), протестировать сайт агрегатора, наладить его работу, вычистить баги. Поначалу схема сотрудничества с агрегаторами функционировала на “отлично”. Мы работали по более низкому проценту, при этом была проходимость всего рынка и много данных для развития продукта.
Потом, чтобы избежать риска отключения, снизить зависимость от других игроков рынка и повысить рентабельность продаж, решили постепенно заключить прямые контракты со всеми страховщиками и настроить прямые интеграции.
Столкнулись еще с одной проблемой — объяснить страховщикам, что такое API‑интеграция, и что мы хотим работать только онлайн. Проще говоря, без бумажек. Было очень сложно, тем более на уровне филиалов в Санкт‑Петербурге, поэтому я взял “руки в ноги” и поехал в столицу, чтобы найти в страховых компаниях контакты и инструменты для работы в новом технологическом режиме.
Отдельно отмену, что заключение и поддержание договоров — это колоссальная работа, которая растягивается на весь период жизни компании.
Сколько тогда мы потратили денег, можно посчитать лишь приблизительно. Зарплата программиста уровня “джуниор” — от 100 тысяч, среднего — от 150 тысяч, профессионала своего дела — 200 тысяч ₽ и более. При этом мы практически всегда брали специалистов Junior и выращивали у себя в компании.
Штат команды наращивали постепенно:
- руководитель разработки;
- системный администратор;
- плюс еще один программист;
- дизайнер;
- верстальщик;
- SEO специалист;
- контент менеджер;
- SMM специалист;
- маркетолог;
- команда кураторов / партнерщиков;
- бухгалтер.
Часть сотрудников компании работала одновременно сразу в двух проектах — INFULL и Polis.online. Это позволяло сокращать косты и увеличивать рентабельность самого технологического стартапа.
Тестировщиков у нас на тот момент не было. Мы всей командой работали над продуктом и тестировали каждый элемент системы. Проводили brain штормы, обсуждали, как лучше реализовать логику работы системы, сделать ее гибкой. Я взял на себя роль маркетолога, дизайн‑директора, руководителя проекта, собственника продукта, тестировщика, руководителя по развитию, финансового директора.
Итого в проекте в первый год было задействовано около 7 человек, через год — 12, потом — уже около 15 человек. Сейчас в компании работает 25 человек. В целом мы росли по мере технической необходимости, когда имеющихся ресурсов не хватало для поддержания темпов работы. Самым важным было обеспечить рентабельность компании, так как проект был на самоокупаемости, и я работал без инвесторов.
Если говорить об общих расходах на персонал, получилось около 70 млн ₽. Далее прибавляем сюда расходы на офис, серверную архитектуру, рекламу, SEO‑продвижение, другие административные расходы. Получается примерно 100 млн ₽ — столько было потрачено на запуск проекта с учетом всех расходов на бухгалтерию, офисный персонал, ИТ‑специалистов и прочее.
Вообще не советую экономить на анализе конкурентов, брендинге, дизайне, технических специалистах, да и на команде в целом, чтобы на выходе не получился продукт, оторванный от реальности. Важно научить разработчиков думать в разрезе бизнеса. Продукт должен быть удобен и понятен пользователям, решать задачу быстро, и тогда он станет продавать сам себя.
Проблемы, с которыми я столкнулся при построении агрегатора
Факапы были постоянно, но довольно мелкие. Например, приходили мошенники, чтобы работать с нами в качестве страховых агентов. Оформляли страховки, получали за это вознаграждение, а потом расторгали страховые договоры.
Много ошибок было совершено из‑за человеческого фактора. Мы работаем по всей стране, с десятками страховщиков. Сегментация компаний по каждому региону отличается, информации много, поэтому ошибки в огромном массиве данных неизбежны. Еще один пример — страховщик отменил вознаграждение по определенному продукту, а мы не успели оповестить об этом агентов. Пришлось выплачивать вознаграждение самим.
Бывали случаи заказа DDoS‑атаки от конкурентов, парсинга данных, когда роботы с помощью ввода госномера автомобиля получали сведения о страхователях и перепродавали их. А мы за каждый ввод номера должны были заплатить по 5 ₽. И получался глобальный слив бюджета.
Почему агрегатор может не выстрелить?
Мы сразу поняли, что нет смысла привлекать только агентов и клиентов. У нас есть готовое решение, готовый интерфейс, подключены страховые. Поэтому, когда мы протестировали продукт, стали привлекать крупных b2b‑клиентов, которые могут использовать наше решение, интегрировав его на свои площадки. Так мы начали предлагать кастомные решения кабинетов для расчета и оформления страховок, либо запуск своего полноценного агрегатора за несколько месяцев на базе разработок нашей платформы.
Это нам дало серьезный буст по приросту количества пользователей. А главное — мы вышли из‑под конкурентного давления других крупных площадок. Проект получил серьезные шансы на успех.
Заключение
В заключение могу сказать, что продукт получился реально полезным, с классным неймингом, дизайном и UI. Несмотря на то что в один момент хотелось перестать вкладываться и все бросить. Здесь заслуга всей моей команды и, конечно, помогла моя настойчивость и вера в успех. А вы хотя бы раз задумывались о бизнесе в страховании?

















В какой еще области не хватает удобного агрегатора?