Как Sensei помог BestDoctor
ускорить взятие сделок в работу на 67%

BestDoctor – группа компаний на российском рынке InsurTech.
В этом кейсе мы расскажем, как BestDoctor всего за три месяца удалось сократить время взятия сделок в работу на 67%, а срок внесения изменений в процессы – с нескольких недель до одного дня.

Ниже опишем, что было сделано и чем помогли инструменты Sensei. Поделимся ключевыми метриками, скриншотами систем, сложностями проектной команды и отзывами клиента.

BestDoctor – это InsurTech-компания с собственной технологической IT-платформой и двумя экосистемами: «Здоровье» и «Страхование». В 2022 году компания привлекла раунд около 1 млрд рублей от группы российских инвесторов, став лидером инвестиций в российское цифровое здравоохранение. Стратегические партнеры BestDoctor – «Интеррос», Росбанк Страхование, Росбанк Страхование жизни.

Рынок InsurTech и MedTech стремительно меняется. Так же быстро должны меняться и внутренние бизнес-процессы компании, если она хочет идти в ногу со временем. Для этого нужна гибкая BPM-система, в которой можно быстро перестраивать и масштабировать процессы и тестировать новые гипотезы. Однако система управления бизнес-процессами Camunda, которая использовалась в компании, именно для этой задачи не совсем подходила, а ее пользователи время от времени могли сталкиваться с рядом проблем.

Технические проблемы в системе Camunda

Другие проблемы

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

Таким образом, хотя до определенного момента система Camunda позволяла строить процессы, по мере развития бизнеса появилась необходимость в новых инструментах. Клиенту нужно было такое решение, которое позволит автоматизировать процессы с пользой для бизнеса, и он обратился к инструментам Sensei.

Ограничения и особенности текущей системы Camunda и стали исходной точкой для запуска проекта. Именно с изучения состояния «как есть» начала работу проектная команда. Каждая компания уникальна, поэтому нельзя создать с нуля идеальную целевую модель управления бизнес-процессами, не погрузившись сначала в текущее положение дел: особенности бизнеса, связи между отделами, модели продаж и поддержки клиентов, корпоративную культуру.

Чтобы учесть специфику клиента и не потерять текущие сделки в работе, внедрять проект решили на базе методологии As Is – To Be. Рассмотрим подробнее этапы проекта по этой методологии.

Этап 1. As Is: описание текущих бизнес-процессов

Проектная группа тщательно изучила систему Camunda и действующие процессы в amoCRM и разобралась во всех нюансах: как работают процессы, кто какие действия выполняет, какие задачи ставит, какие поля переносит и т. д.

Команда прогнала тестовые сделки в системе Camunda, чтобы посмотреть, как она работает, и выявила ряд ошибок.

Опросили руководителей отделов продаж и андеррайтинга (андеррайтеры занимаются расчетом рисков и стоимости страховки). В ходе нескольких звонков уточнили логическую схему процессов: какие действия выполняются и в какой последовательности, когда общение с клиентами переходит из amoCRM в мессенджеры, какие данные отправляют в Excel и пр.

После того, как руководители отделов поделились своим мнением по поводу улучшения бизнес-метрик, важно заручиться поддержкой конечных пользователей: предлагаемое решение должно не только работать на бизнес, но и быть удобным, комфортным и понятным для пользователей. В результате обсуждений с менеджерами проектная команда выделила несколько особенностей их работы:

Изучив огромный объем информации, команде нужно было собрать все полученные данные в единую макрокартину, чтобы затем приступить к совместной работе по проектированию процессов. Для этой цели выбрали онлайн-доску Miro.

Результат в Miro – схема, где зафиксировано следующее:

После составления подробной карты текущих процессов выбрали целевые отделы: проектирование нового целевого процесса для этих подразделений должно было дать максимальный эффект.

В объем проекта вошло несколько подразделений, но в этом кейсе мы сосредоточимся на отделе продаж, который занимается непосредственно реализацией услуг BestDoctor клиентам.

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

Совместно с клиентом зафиксировали цели проекта:

• Создать с нуля и запустить важные процессы целевых отделов.

• Актуализировать старые бизнес-процессы, существенно упростив их логику. Обеспечить возможность легкой и быстрой адаптации процессов к изменяющимся условиям.

• Передать документацию и экспертизу IT-команде BestDoctor, чтобы она могла самостоятельно вносить изменения в процессы всего за 1 день.

• Настроить сбор метрик из amoCRM в таблице с понятной визуализацией данных.

• Не допустить блокировки или остановки процессов в ходе переноса ни на час.

• Оптимизировать адаптацию и онбординг новых пользователей за счет расширенных форм, подсказок по заполнению полей, механизмов проверки, исключающих ошибки из-за человеческого фактора.
  

План проекта с наглядным отражением последовательности и сроков выполнения работ составили в диаграмме Ганта. Здесь четко видно, сколько времени заложено на разные этапы проекта, какие работы уже завершены, процент выполнения работ, наметившиеся отставания. Во избежание разглашения коммерческой информации ниже приводим иллюстративный пример такой диаграммы.

Этап 2. To Be: проектирование образа результата

Когда составлена полная картина текущих процессов, определены цели проекта и ключевые метрики, выбраны целевые департаменты и установлены сроки, начинается работа по проектированию целевых процессов.

На этом этапе ввели новые операционные метрики для оценки работы менеджеров и согласовали подход к их интерпретации. По всем метрикам отрисовали дэшборды.

Для проектирования целевого процесса продаж проектная команда провела ряд встреч со всеми заинтересованными лицами. По итогам обсуждений сформулировали образ результата и зафиксировали его в Miro.

Команда выстроила логику процессов продаж и согласовала ее с клиентом. Учли все пожелания клиента: где должна происходить автосмена статуса, где заполняются поля, какие ставятся задачи и с какими сроками и пр. После утверждения логики отрисовали и согласовали целевой макропроцесс To Be.

Далее команда построила демо-процессы продаж, продемонстрировала их тим-лидам и менеджерам, собрала обратную связь и внесла изменения еще ДО тестирования.

Результат в Miro – схема, где указано следующее:

• спроектированный новый макропроцесс «Продажи»;

• согласованные с клиентом ключевые метрики и подход к их сбору;

• адаптированные и полностью новые воронки;

• подпроцессы: быстрые победы, которые за короткий срок дают положительный прирост по метрикам.
  

Этап 3. Тестирование и пуско-наладка

После завершения проектирования в Miro все отрисованные процессы необходимо спроектировать в amoCRM с использованием инструментов Sensei. На этом этапе проектная команда тестирует все наработки, собирает обратную связь от пользователей.

При помощи конструктора бизнес-процессов в визуальном редакторе Sensei создали эталонный макропроцесс продаж в виде понятной блок -схемы. В схеме описали все возможные сценарии прохождения сделки по воронке.

Для успешного тестирования процессов важно подготовить хороший план с указанием основных этапов и сроков:

• Демо для руководителей, тим-лидов и менеджеров.
  
• Подготовка инструкций.
  
• Сбор обратной связи.
  
• Сессии ответов на вопросы.
  
• Внесение корректировок в процесс.
  
• Оперативная поддержка пользователей в чате.

Подготовка к запуску должна быть тщательно продумана, поэтому на этот этап проекта изначально заложили больше двух недель.

Важный этап в методологии запуска решения – создание фокус-группы. Это необходимо для обкатки новых процессов на выделенной части сотрудников и сбора первых метрик. Состав и профиль фокус-группы для тестирования процесса и сбора обратной связи выглядел так:

• Два опытных менеджера отдела продаж.
  
• Два новых менеджера отдела продаж.
  
• Все специалисты по поддержке продаж

Перед запуском процессов на фокус-группу провели специальное обучение для менеджеров. Записи всех важных встреч сохранялись, чтобы впоследствии с их помощью ускорить онбординг новых сотрудников в системе.

Для обеспечения оперативного решения вопросов и устранения ошибок в ходе тестирования создали чаты, в которых сотрудники BestDoctor напрямую могли взаимодействовать с командой.

После проведения обучения участники фокус-группы приступили к работе с новым макропроцессом «Продажи». Для получения чистого результата на протяжении месяца фокус-группа работала параллельно и с платформой Sensei, и с платформой Camunda. Таким образом, сравнивались именно системы, а не менеджеры. Вся обратная связь оперативно бралась в работу: устранение ошибок и улучшение процесса реализовывались в течение одного дня.

По окончании этапа клиент получил следующие результаты работ:

• обучающие видео по работе с процессами каждого отдела;
• текстовые инструкции по процессам;
• документация по внедренным кастомным решениям;
• схемы в Miro с подробным описанием всех выстроенных процессов.

Быстрые победы

В ходе проекта создали и запустили в работу три дополнительных подпроцесса. Они позволили клиенту увидеть прирост по ключевым метрикам еще до окончания проекта.

Для визуализации приоритета сделок и определения дедлайна для взятия сделок в работу менеджером создали подпроцесс по типу «Светофор». Все создаваемые сделки проверяются по заранее установленным критериям для определения срочности их обработки. Например: красный цвет – горячий клиент, дедлайн для взятия в работу – два часа. Желтый цвет – средняя срочность, срок – неделя. Голубой цвет – холодный клиент, срок – 30 дней.

Одна из причин упущения сделок – потеря коммуникации с клиентом. Для минимизации этого риска установили лимит времени нахождения сделки на разных этапах. Так, для взятых в работу сделок на этапе квалификации клиента определили лимит 7 дней с даты последней коммуникации. Это отличный инструмент контроля зависания сделки: когда сделка приближается к нарушению установленного лимита, менеджер по продажам (а на следующий день и тим-лид) получает уведомление.

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

Полноценный запуск сбора метрик и их визуализации в дэшбордах на базе ранее созданных шаблонов.

Для наглядной визуализации метрик использовали удобный и понятный инструмент, с помощью которого можно анализировать показатели в разных разрезах и создавать гибко настраиваемые диаграммы и графики.

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

Аналитики заметили, что менеджеры регулярно заполняют скоринг в Яндекс.Таблицах, а для этого вручную переносят информацию из полей, ранее заполненных в amoCRM. В результате такой неавтоматизированной двойной работы какие-то данные теряются, какие -то искажаются. Команда решила написать кастом, чтобы перенести заполнение скоринга в amoCRM, упростив таким образом работу менеджеров и минимизировав человеческий фактор. Сотрудникам не только облегчили работу, но и предложили выбрать наиболее комфортное цветовое оформление новой формы. Победила фуксия :)

На подобных проектах аналитики компании Sensei рекомендуют закладывать на риски около 30% от изначального плана. Срок выполнения проектных работ может увеличиваться по целому ряду причин, например:

• необходимость вносить корректировки в процессы в ходе тестирования на фокус-группе на базе полученной обратной связи;
  
• отпуск руководителей и сотрудников клиента: на старте обязательно нужно уточнить график отпусков для правильного планирования встреч по AS IS / TO BE и обучению;
  
• необходимость кастомных доработок ввиду особенностей функционала клиентских систем.
  

Не обошлось без сложностей и на проекте BestDoctor:

Текущие и целевые процессы приходилось уточнять и согласовывать с большим количеством сотрудников из разных отделов. На индивидуальных встречах каждый со своей стороны дополнял общую картину. Это крайне полезно для детальной проработки As Is и To Be, но требует много времени.

Из-за большого числа заинтересованных лиц согласование и настройка метрик заняли больше времени, чем изначально ожидалось. Клиент всегда был в курсе задержек, так как любые отставания фиксировались в плане проекта в диаграмме Ганта.

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

Коротко

Подробнее о результатах

Результат по метрикам: налажен сбор ключевых и операционных метрик в таблицы и их визуализация.

Улучшения по ключевым метрикам к окончанию проекта:

Для руководителей.
Руководители получили новые инструменты контроля:

Для IT-команды
Специалисты IT-отдела клиента могут самостоятельно и оперативно: