Тендеры и лиды
Информация
325 000
Услуги
amoCRM
Июль 2026
Объединить работу контакт-центра.
Компания обеспечивает работу единого контакт-центра для сети из 17 стоматологических клиник - от Калининграда до Иркутска.
В обработке обращений участвуют операторы, чат-менеджеры, координаторы и супервайзеры. При этом сотрудники работают в разных часовых поясах, а процессы зависят сразу от нескольких систем.
На момент начала проекта использовалось 16 аккаунтов amoCRM. Перед командой стояла задача перейти к единой системе и одновременно сократить ручные операции, ограничить произвольные действия сотрудников и устранить ошибки, которые влияли на качество аналитики.
На первый взгляд задача выглядела как стандартная автоматизация CRM. Но за запросом «настроить процессы» скрывалось гораздо больше вопросов:
✔ кому должна передаваться новая заявка;
✔ что делать, если в обращении не хватает данных;
✔ когда запускать повторный звонок;
✔ как контролировать недозвоны;
✔ кто и в какой момент становится ответственным;
✔ как связать обращение с записью на прием;
✔ какие данные должны быть доступны для изменения;
✔ как исключить исправление важных показателей задним числом;
✔ что делать с отказами и клиентами, которых нужно вернуть в работу.
Поэтому мы не стали начинать проект с настройки воронок и автоматизаций.
Сначала нужно было понять, как система должна работать целиком.
Для проекта выбрали водопадную методологию:
исследование → описание текущих процессов → проектирование целевой модели → согласование → настройка.
На предпроектном этапе мы анализировали не только существующую конфигурацию amoCRM, но и реальные действия сотрудников.
Изучили воронку, этапы, Salesbot, триггеры и задачи, после чего прошли путь клиента от первого обращения до записи, визита, отказа или повторной работы.
Особое внимание уделили операциям, которые не были формализованы в CRM: ручным проверкам, договоренностям между сотрудниками, исключениям и решениям «по ситуации».
Такой подход позволил найти проблемы, которые не были очевидны из первоначального запроса.
Например, оказалось, что изменение города или источника могло повлиять на распределение сделки прямо во время разговора с клиентом. В других сценариях сотрудники вручную контролировали количество попыток дозвона, а важные показатели могли изменяться после того, как событие уже произошло.
Отдельный блок анализа касался взаимодействия нескольких систем: amoCRM, внедрения конструктора бизнес-процессов «Прометей», телефонии UIS, системы записи «Кронос», Google Sheets и действующих виджетов.
В результате предпроектная работа показала: прежде чем автоматизировать процессы, необходимо определить правила, по которым они должны работать.
На первом этапе мы сформировали каталог из 29 проблемных зон.
Для каждой проблемы зафиксировали три уровня:
Проблематика - что происходит сейчас и к чему это приводит.
Целевое поведение - как должна работать система после изменений.
Способ реализации - какие возможности amoCRM, «Прометея», виджетов и интеграций понадобятся.
Это принципиально отличалось от обычного списка пожеланий. Мы не просто записали, что «нужно автоматизировать распределение» или «нужно контролировать недозвоны».
Каждую проблему перевели в конкретное требование к будущей системе.
В результате получили 43 функциональных блока в 10 процессных доменах (направлениях автоматизации): поступление заявки, распределение, квалификация, коммуникация и недозвоны, запись, визит, закрытие, реактивация, управление данными и контроль.
Одна проблема могла затрагивать несколько взаимосвязанных процессов, поэтому количество проблемных зон и будущих функциональных блоков не совпадало.
Система могла вернуть сделку в очередь распределения, не учитывая, что оператор уже начал работу и в этот момент разговаривает с пациентом. В результате сделка переходила другому сотруднику, который также мог начать связываться с тем же пациентом.
В целевой модели предусмотрели учет данных телефонии при перераспределении. Если оператор уже совершает звонок, сделка должна оставаться за ним и не передаваться другому сотруднику.
Маркетинговые параметры могли передаваться не полностью. Без города или источника система не могла надежно определить маршрут заявки.
Вместо ручного разбора каждой такой ситуации спроектировали последовательность проверок: система анализирует доступные данные, при необходимости использует технические параметры URL, а если определить маршрут автоматически невозможно - передает заявку ответственному сотруднику для ручного заполнения.
После уточнения данных заявка может вернуться в общий сценарий распределения.
Для сети клиник в разных регионах единое московское время создавало проблему: заявка могла поступить в рабочие часы конкретной группы, но система считала ее ночной.
На предпроектном этапе описали определение нерабочего времени с учетом графика целевой группы. Для таких обращений предусмотрели ожидание начала рабочего времени и последующую передачу операторам.
То есть вместо общего правила «ночь - это определенное время» появилась логика, учитывающая реальный график работы.
На назначение заявки одновременно влияли источник поступления заявки, город, группа для распределения, смена сотрудника и очередность.
При большом количестве условий исключения быстро превращаются в ручную работу.
Мы разложили маршрутизацию на последовательные проверки и описали альтернативные сценарии: когда заявка распределяется сразу, когда должна подождать и в каких случаях требуется участие руководителя.
Сам факт постановки задачи не означал, что сотрудник действительно начал работу.
Поэтому в целевой модели заложили последовательный контроль: предупреждение оператору, эскалация супервайзеру и перераспределение сделки при отсутствии реакции.
При этом отдельно определили событие, которое считается началом обработки. Это важно: автоматизация контроля невозможна, если система не знает, какое действие считать фактическим стартом работы.
Количество попыток дозвона и интервалы между ними во многом зависели от сотрудника.
При смене ответственного было сложно гарантировать, что новый оператор понимает, сколько попыток уже сделано и когда нужно звонить снова.
Поэтому спроектировали единый учет попыток и времени контактов независимо от смены ответственного.
В будущей системе должны работать автоматический счетчик, последовательность повторных задач и завершение обработки после достижения установленного лимита.
Один сотрудник мог оставить подробное примечание, другой - несколько слов, третий не зафиксировать договоренности вообще.
При передаче сделки следующему оператору приходилось заново изучать историю или прослушивать звонки.
Мы предусмотрели единый шаблон саммари: что обсудили, о чем договорились, следующий шаг и возражения клиента.
Таким образом, результат коммуникации должен стать частью процесса, а не зависеть от личного подхода сотрудника.
Отдельным направлением стала работа с данными, которые влияют на оценку сотрудников и качество аналитики.
Например, поле «Координатор» можно было заполнить или изменить уже после визита пациента. Теоретически это позволяло приписать результат сотруднику, который фактически не сопровождал запись.
Другой пример - признак «День в день». Он влиял на оценку работы, но заполнялся сотрудником вручную. При этом повторное обращение нельзя было автоматически считать новым уникальным лидом.
Для таких сценариев мы определили момент, когда данные должны фиксироваться, и предусмотрели ограничения на их последующее изменение.
Получился общий принцип:
Критичные для аналитики данные не должны зависеть от возможности сотрудника исправить их задним числом.
Поэтому часть показателей должна рассчитываться автоматически, часть - фиксироваться в определенной точке процесса, а изменения, которые действительно требуют пересмотра, проходить через согласование с руководителем.
Еще одна группа проблем возникала на стыке CRM и системы записи «Кронос».
Заявка от промоутера могла выглядеть как уже состоявшаяся запись, хотя фактически человек только оставил обращение. Разделение этих событий было необходимо для корректной аналитики.
Отдельно обнаружили ситуацию, когда запись в «Кроносе» могла существовать без связи со сделкой в amoCRM.
В целевой модели закрепили правило: запись создается через сделку, а система контролирует наличие ее идентификатора. Для исключительных ситуаций предусмотрено уведомление руководителю.
Так мы связали два события, которые раньше могли существовать независимо:
обращение клиента → сделка → запись на прием.
Это важно не только для удобства сотрудников. Такая связь позволяет сохранить целостную историю клиента и в дальнейшем корректно анализировать путь от первого обращения до визита.
На этапах amoCRM уже существовали подсказки, которые предупреждали сотрудников о неправильных действиях.
Например, система могла сообщать, что сделку нельзя переводить в определенный статус без прохождения предыдущего этапа.
Но подсказка не является ограничением: сотрудник технически мог обойти правило.
Поэтому на этапе проектирования мы описали допустимые переходы и условия их выполнения.
Для реализации предусмотрели сочетание сценариев «Прометея» и виджета «Запрет смены этапа», а также синхронизацию с «Кроносом».
В результате будущая система должна не просто подсказывать сотруднику, как правильно работать, а контролировать выполнение обязательных условий процесса.
Еще одна важная часть проекта - работа с закрытыми сделками.
Супервайзеры вручную просматривали закрытия, включая спам и дубли. Подходящие для повторной обработки обращения возвращались в работу через ручную выборку.
Мы разделили причины закрытия и определили, какие из них:
✔ требуют проверки;
✔ исключаются из повторной обработки;
✔ позволяют реактивировать клиента;
✔ должны запускать отдельный сценарий «дожима».
Так первичный поток заявок отделили от повторной работы с клиентской базой.
Подходящие сделки должны возвращаться в работу автоматически по заданным причинам и срокам, переходить в отдельный контур обработки и проходить собственный сценарий квалификации.
Анализ показал, что задача не сводится только к настройке amoCRM.
В проекте взаимодействуют:
amoCRM — единая CRM-среда для работы с обращениями и клиентами.
«Прометей» — управляющий контур бизнес-процессов: проверки, распределение, контроль SLA, эскалации и взаимодействие между системами.
UIS — сквозная аналитика,телефония и данные о звонках.
«Кронос» — запись клиентов и связанные с ней статусы.
Google Sheets и виджеты — дополнительные инструменты работы с данными и процессами.
При таком подходе каждая система сохраняет свою роль, а бизнес-процесс проходит через них последовательно.
Именно поэтому «Прометей» в целевой архитектуре должен выступать своеобразным мозгом процесса: определять допустимый следующий шаг, проверять данные и координировать действия других систем.
Дополнительная сложность заключалась в том, что над системой работали две команды: Генезис и внутренний интегратор заказчика.
При изменении одной системы могли меняться распределение заявок, ответственные или движение сделки в другой.
Поэтому уже до начала настройки мы зафиксировали границы ответственности и зависимости между командами.
Предпроектная документация стала общей точкой отсчета: для каждого изменения было понятно, какое поведение ожидается, какие настройки затрагиваются и чье участие необходимо.
Это снизило риск ситуации, когда каждая команда корректно выполняет свою часть задачи, но на стыке систем возникает ошибка.
Главным результатом предпроектного этапа стала не отдельная настройка CRM, а согласованная модель будущей системы.
Заказчик получил:
29 проблемных зон - с описанием текущей ситуации и рисков.
43 функциональных блока - с описанием целевого поведения и способов реализации.
10 направлений автоматизации - от поступления заявки до реактивации и контроля.
Архитектуру взаимодействия систем - с понятными зонами ответственности amoCRM, «Прометея», UIS, «Кроноса» и других инструментов.
Границы работ двух интеграторов - чтобы изменения в одной части системы не создавали неожиданных проблем в другой.
Основу для последующей реализации - с пониманием приоритетов и последовательности внедрения функциональности.
При этом мы сознательно не называем предпроектный результат ростом продаж или сокращением времени обработки. Эти показатели можно объективно оценить только после запуска и накопления фактических данных.
Итог
Сложные CRM-проекты редко начинаются с кнопки «настроить автоматизацию».
Сначала нужно понять, как бизнес работает сейчас, где процесс зависит от человека, какие данные можно изменить, где системы конфликтуют между собой и что должно происходить в нестандартной ситуации.
В данном проекте такой подход позволил перейти от общего запроса на автоматизацию к конкретной модели будущей системы:
17 клиник → единый контакт-центр → 29 проблемных зон → 43 функциональных блока → 10 направлений автоматизации → согласованная архитектура.
Для нас предпроектная аналитика стала не подготовительным этапом перед внедрением, а самостоятельной частью решения. Именно она позволила определить, что должна делать CRM, какие действия оставить сотрудникам, где нужен контроль руководителя и как связать между собой несколько систем в едином процессе.
Человеческий фактор стоит миллионов: как заставить ИИ считать 100% объектов на скоростной ленте
Telegram-бот заказа бытовых услуг для жилого комплекса с оплатой по СБП
