Почему нельзя автоматизировать контакт-центр «как есть»: кейс объединения 17 стоматологических клиник

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

Вместо того чтобы сразу настраивать amoCRM, сначала разобрали, как на самом деле работает контакт-центр, нашли 29 проблемных зон и перевели их в 43 функциональных блока будущей системы.

Когда «настроить CRM» - слишком простая задача

Компания управляла единым контакт-центром для сети из 17 стоматологических клиник - от Калининграда до Иркутска. С обращениями пациентов работали операторы, чат-менеджеры, координаторы и супервайзеры. При этом сотрудники находились в разных часовых поясах, а процесс обработки заявок проходил сразу через несколько систем.

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

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

Например:

1. кому передавать заявку, если в ней не хватает данных;
2. что делать, если оператор уже начал звонок, а система пытается перераспределить сделку;
3. как учитывать рабочее время клиники в разных регионах;
4. когда считать обращение обработанным;
5. сколько раз нужно перезванивать пациенту;
6. кто должен отвечать за результат после передачи сделки;
7. как связать обращение с фактической записью на прием;
8. какие данные сотрудник может изменить, а какие должны фиксироваться навсегда.

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

Поэтому мы приняли принципиальное решение: сначала исследование и проектирование, затем настройка CRM.

От анализа процессов - к целевой модели

Для проекта использовали последовательный подход:

исследование → описание текущих процессов → проектирование целевой модели → согласование → настройка.

На первом этапе анализировали не только настройки amoCRM. Мы смотрели, что сотрудники реально делают в течение рабочего дня.

Изучили воронки, этапы, Salesbot, триггеры и задачи. Затем прошли весь путь пациента: от первого обращения до записи, визита, отказа или повторного контакта. Особое внимание уделили операциям, которые не были формализованы в CRM: ручным проверкам, исключениям, договоренностям между сотрудниками и решениям «по ситуации».

Именно здесь обнаружилась большая часть будущих изменений. В итоге сформировали 29 проблемных зон. Но просто составить список проблем было недостаточно.

Для каждой из них зафиксировали три уровня:

1. Проблема - что происходит сейчас и к чему это приводит.
2. Целевое поведение - как должна работать система.
3. Способ реализации - какие функции amoCRM, интеграций и дополнительных инструментов потребуются.

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

В результате 29 проблемных зон превратились в 43 функциональных блока, объединённых в 10 направлений автоматизации: от поступления заявки и распределения до записи, визита, закрытия сделки, реактивации и контроля.

Что оказалось сложнее обычного распределения заявок

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

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

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

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

Разные часовые пояса ломают универсальные правила

Еще одна проблема возникла из-за географии сети. Если контакт-центр работает сразу с несколькими регионами, правило «ночное обращение - это заявка, пришедшая после определенного времени» становится некорректным.

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

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

Когда автоматизация зависит от пяти условий

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

Система должна понимать:

1. когда заявку можно распределить сразу;
2. когда не хватает данных;
3. когда нужно подождать;
4. когда требуется ручное вмешательство;
5. что делать после уточнения информации.

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

Так исключение перестает быть ручной «особой ситуацией» и становится частью нормального бизнес-процесса.

Семь недозвонов - тоже бизнес-процесс

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

Поэтому правило вынесли из человеческой памяти в систему.

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

Сначала нужно определить само бизнес-правило, а уже потом решить, каким инструментом его реализовать.

Почему нельзя позволять сотруднику «исправлять историю»

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

Например, поле «Координатор» могло изменяться уже после визита пациента. Формально это просто редактирование поля. Но с точки зрения бизнеса изменение означало возможность задним числом изменить данные о том, кто сопровождал пациента.

Аналогичная проблема возникала с признаком «День в день». Он влиял на оценку работы, но заполнялся вручную. При этом повторное обращение нельзя автоматически считать новым уникальным лидом. Поэтому для каждого критичного показателя определили момент его фиксации.

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

Часть показателей должна рассчитываться автоматически, часть - фиксироваться в конкретной точке процесса, а изменения действительно важных данных должны проходить через дополнительный контроль.

Заявка, запись и визит - не одно и то же

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

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

В другой ситуации запись могла существовать в «Кроносе», но не иметь связи со сделкой в amoCRM. Поэтому в целевой архитектуре зафиксировали последовательность:

обращение → сделка → запись на прием.

При этом система должна контролировать наличие связи между CRM и записью и сигнализировать об исключениях. Это позволяет сохранить целостную историю пациента и в дальнейшем корректно анализировать путь от первого обращения до визита.

Подсказки сотруднику - еще не автоматизация

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

Для реализации предусмотрели сочетание сценариев «Прометея», специальных ограничений в amoCRM и синхронизации с «Кроносом».

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

Что происходит с отказавшимися пациентами

Еще один процесс, который часто остается за пределами первоначального ТЗ, - работа с закрытыми сделками.

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

Мы разделили причины закрытия и определили для каждой дальнейшее действие:

1. исключить из повторной обработки;
2. отправить на дополнительную проверку;
3. реактивировать;
4. передать в отдельный сценарий повторной коммуникации.

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

CRM оказалась только частью системы

Еще один важный вывод проекта: сложный контакт-центр нельзя рассматривать как задачу одной CRM. В архитектуре будущей системы участвуют несколько инструментов. amoCRM отвечает за работу с обращениями и клиентами.

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

- UIS обеспечивает телефонию, данные о звонках и сквозную аналитику.

- «Кронос» отвечает за запись клиентов и связанные с ней статусы.

- Дополнительные данные и отдельные процессы работают через Google Sheets и виджеты.

Такой подход позволяет не пытаться заставить одну систему делать всё. У каждой системы появляется своя роль, а бизнес-процесс проходит через них последовательно. И именно поэтому архитектуру необходимо проектировать до настройки отдельных автоматизаций.

Две команды - одна система

Дополнительную сложность создавало то, что над проектом работали две команды: «Генезис» и внутренний интегратор заказчика. Это означает, что изменение одного сценария может повлиять на другую часть системы.

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

Для каждого изменения было понятно:

1. что должно происходить;
2. какие настройки затрагиваются;
3. с какими системами есть зависимость;
4. кто отвечает за реализацию.

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

Что получил заказчик еще до начала внедрения

Главным результатом предпроектной работы стала не настроенная воронка. Заказчик получил согласованную модель будущей системы:

29 проблемных зон - с описанием текущей ситуации и рисков.

43 функциональных блока - с описанием целевого поведения и способов реализации.

10 направлений автоматизации - от поступления заявки до реактивации и контроля.

Архитектуру взаимодействия систем - с понятным распределением ролей между amoCRM, «Прометеем», UIS, «Кроносом» и другими инструментами.

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

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

Почему предпроектная аналитика - это не «подготовительная работа»

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

Поэтому главный вопрос перед внедрением должен звучать не так: «Какие автоматизации нам настроить?». А так: «Как должен работать процесс в каждой типовой и нестандартной ситуации?»

В проекте контакт-центра для 17 стоматологических клиник именно этот подход позволил перейти от общего запроса «объединить CRM» к конкретной архитектуре:

17 клиник → единый контакт-центр → 29 проблемных зон → 43 функциональных блока → 10 направлений автоматизации → согласованная архитектура.

И это, пожалуй, главный вывод проекта. Хорошая CRM не начинается с настройки CRM. Она начинается с понимания того, как бизнес должен работать после внедрения.

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

Если вы хотите увеличить эффективность отдела продаж, сократить рутину или разобраться, как автоматизировать процессы именно в вашей компании — подробнее о наших решениях на gnzs.ru.

Хотите понять, что можно автоматизировать именно в вашей компании?

Оставьте заявку на сайте gnzs.ru — проведем аудит текущих процессов, покажем точки роста и предложим план автоматизации.

erid: CQH36pWzJqVJK2qJpCWqWejKQjpuctMEXDAhC3VJA4xndX