CRM копирует правила, которые ей дали
Менеджер открывает новую CRM и видит знакомую воронку: «Новый», «В работе», «Предложение», «Договор». Названия выглядят аккуратно, но на планёрке начинается старый разговор. Один сотрудник переводит сделку после первого звонка, другой — после подтверждения бюджета, третий держит всё перспективное в начале воронки до подписания договора.
Система работает без ошибки. Она честно автоматизировала три разных понимания процесса.
Исследования CRM много лет сходятся в одном: это не отдельная программа для отдела продаж, а сочетание стратегии, процессов, людей, информации и технологии. Payne и Frow описывают CRM как межфункциональную процессную систему, а Mendoza и соавторы связывают внедрение сразу с человеческим фактором, процессами и технологией. Эти работы международные и не задают российской компании готовую воронку. Их переносимый вывод проще: экран не разрешит управленческую неоднозначность.
Интегратор может провести интервью, показать варианты и предупредить о последствиях. Но только коммерческая функция решает, что означает квалифицированная сделка, когда начинается обязательство по сроку, кто принимает клиента и какой факт считается победой. Если эти решения не приняты, настройка закрепит текущие разночтения и сделает их быстрее.
Семь решений до начала настройки
Ниже — минимальный управленческий контракт. Он не заменяет обследование и техническое задание, но не даёт проекту начать с декоративных статусов.
1. Где начинается и заканчивается продажа
Зафиксируйте событие старта. Это может быть подтверждённая потребность, принятый в работу лид или другое наблюдаемое условие. Затем определите два финала: что именно считается победой и когда работа признаётся проигранной.
«Клиент согласился» — не событие. «Подписан договор ответственными сторонами» или «получена оплата по правилам конкретного процесса» уже можно проверить. Столь же важно определить причины проигрыша и разрешённый порядок повторного открытия. Иначе незавершённые сделки будут годами поддерживать красивую, но недостоверную воронку.
Официальная документация BPMSoft показывает отдельные финальные состояния «завершена с победой» и «завершена с проигрышем» и связывает финальные данные с аналитикой продаж. Это возможность платформы, а бизнес-смысл победы и причины потери определяет компания.
2. Какие стадии нужны и чем доказан переход
Для каждой стадии ответьте на четыре вопроса:
- Какое решение уже принято?
- Какой факт это подтверждает?
- Что должен сделать ответственный дальше?
- При каком исключении сделка остаётся или возвращается назад?
Стадия должна описывать состояние работы с клиентом, а не настроение менеджера. Переход может подтверждаться заполненным результатом квалификации, согласованным коммерческим предложением или другим артефактом процесса. Количество стадий не является показателем зрелости: лишняя ступень полезна только тогда, когда меняет ответственность, данные или следующее действие.
В обзоре стадий BPMSoft этапы связаны с задачами ответственного менеджера, данными и сценарием переходов. Преднастроенную последовательность не нужно копировать буквально. Она показывает важный принцип: за названием стадии стоят действия и результат, который может проверить другой человек.
3. Какие данные обязательны именно сейчас
Составьте не общий список полей, а матрицу «стадия — решение — необходимые данные». Если поле не помогает принять решение, выполнить обязательство, передать работу или построить согласованный отчёт, его обязательность нужно обосновать отдельно.
Так менеджеру не приходится заполнять двадцать полей до первого разговора, а руководитель получает данные в тот момент, когда они уже должны быть известны. В примере квалификации BPMSoft вместе со стадией появляются ответственный, потребность, бюджет, участник принятия решения и следующие задачи. Это пример продуктового процесса, а не универсальный набор полей.
Если CRM хранит персональные данные, действует дополнительная граница. Статья 5 Федерального закона № 152-ФЗ требует соответствия состава данных заявленным целям, неизбыточности, точности и актуальности. Поэтому подход «соберём всё на будущее» нельзя превращать в техническое требование без проверки цели и правового основания.
4. Что считать одним клиентом
До миграции и интеграций определите:
- какие признаки однозначно идентифицируют организацию и контакт;
- какие совпадения считаются только подозрением на дубль;
- кто выбирает верное значение при конфликте;
- что происходит со сделками, коммуникациями и согласиями после объединения;
- какая система остаётся источником истины для каждого типа данных.
BPMSoft умеет искать похожие записи по настраиваемым правилам при сохранении и массово, а затем объединять их. Но алгоритм не знает, являются ли однофамильцы одним человеком, относятся ли филиалы к одному коммерческому клиенту и кому принадлежат конфликтующие договорённости. Это управленческое решение, которое платформа только исполняет.
5. Кто владеет сделкой и принимает передачу
Для каждого перехода укажите текущего владельца, получателя и факт приёмки. Особенно внимательно проверьте стыки «маркетинг — продажи», «продажи — пресейл», «продажи — договор», «сделка — исполнение».
Фраза «ответственный назначается автоматически» неполна. Нужны правило выбора, замещение на время отсутствия, обработка перегрузки, право вернуть неполную передачу и владелец исключения. Иначе CRM быстро раздаст работу, но не подтвердит, что её действительно приняли.
Роли доступа и роли процесса также не совпадают автоматически. Человек может иметь право изменить карточку, но не иметь полномочия обещать срок или скидку. Эти два слоя нужно проверить раздельно.
6. Когда действие считается просроченным
SLA продаж — не универсальное число из презентации. Для каждого обязательства задайте:
- событие, от которого начинается отсчёт;
- календарь и допустимые паузы;
- владельца действия;
- событие завершения;
- адресата и форму эскалации;
- правило для исключения.
Например, «связаться быстро» нельзя проверить. «Срок начинается после принятия лида менеджером и останавливается после зафиксированного результата контакта» — уже рабочая конструкция, даже если сама длительность различается по сегментам.
Не каждое нарушение нужно превращать в красную карточку руководителю. Эскалация должна приводить к действию: перераспределить, помочь, уточнить данные или изменить приоритет. Иначе уведомления станут ещё одной очередью, которую команда научится не замечать.
7. На какой вопрос отвечает каждый отчёт
До построения дашборда запишите решение руководителя и знаменатель показателя. «Конверсия» без выборки и момента среза неоднозначна. Это может быть доля всех созданных лидов, принятых в работу лидов или сделок, дошедших до конкретного этапа за период.
Для каждого отчёта нужны пять полей:
- Управленческий вопрос.
- Состав выборки.
- Дата или событие среза.
- Владелец качества исходных данных.
- Действие при отклонении.
Если график не меняет решение, его можно не строить в первой версии. Если меняет, команда должна одинаково понимать, из каких событий он собран. Иначе новая CRM просто быстрее выпустит старый спорный отчёт.
| Решение | Вопрос, который нельзя оставить интегратору | Доказательство готовности | Владелец |
|---|---|---|---|
| Границы и финалы | Какое событие открывает продажу, что считается победой и проигрышем? | Перечень наблюдаемых событий и причин завершения | Коммерческий директор |
| Стадии и переходы | Какой факт разрешает каждый переход? | Карта стадий с входом, выходом и исключениями | Владелец процесса продаж |
| Обязательные данные | Что должно быть известно для следующего решения? | Матрица полей по стадиям с целью использования | Владелец процесса и ответственный за ПДн |
| Идентичность клиента | Какие записи относятся к одному субъекту и кто решает конфликт? | Правила поиска, слияния и источников истины | Владелец клиентских данных |
| Роли и передачи | Кто отвечает до и после перехода? | Матрица ответственности и факт приёмки | Руководители участвующих функций |
| Сроки и исключения | От какого события идёт время и что делает эскалация? | SLA-карта с паузами и исключениями | Руководитель продаж |
| Отчётность | Какое решение принимает руководитель по показателю? | Паспорт отчёта с выборкой и знаменателем | Коммерческий директор |
Как провести рабочую сессию
Не пытайтесь описать все модели продаж за один раз. Возьмите один целевой процесс и одну типовую сделку: например, новый B2B-клиент или повторный заказ действующего клиента.
До встречи
Подготовьте три обезличенных примера: успешно завершённую сделку, проигранную и зависшую. Соберите используемые таблицы, отчёты и правила передачи. Пригласите людей, которые принимают решения на стыках, а не только будущих пользователей CRM.
На встрече
Идите по одной реальной сделке слева направо. На каждом шаге записывайте событие, доказательство, данные, владельца, срок и исключение. Если два участника дают разные ответы, не голосуйте за название поля. Зафиксируйте разногласие как управленческое решение и определите того, кто имеет полномочие его принять.
Полезное правило: не открывать интерфейс CRM, пока команда не может заполнить строку таблицы без слов «обычно», «по ситуации» и «менеджер сам понимает». Исключения допустимы, но у них должны быть признаки и владелец.
После встречи
Прогоните по будущим правилам три подготовленные сделки. Победившая должна пройти маршрут без заднего числа. Проигранная — завершиться с причиной, которая объясняет следующее действие. Зависшая — показать владельца, срок и допустимое исключение.
Затем можно обсуждать реализацию. Для российского CRM-контура НТА работает с BPMSoft Управление продажами: воронкой, задачами, данными, дедупликацией и аналитикой. Если процесс требует дополнительных форм, правил и маршрутов, их можно реализовать на BPMSoft Конструкторе. Но low-code сокращает путь от решения до настройки, а не отменяет само решение.
Что поручить интегратору
Хороший интегратор не приносит «лучшую практику» как готовую истину. Он помогает сделать последствия выбора видимыми.
Интегратору можно поручить:
- обследовать текущий процесс и показать расхождения;
- предложить несколько вариантов воронки и модели данных;
- проверить реализуемость переходов, прав, интеграций и отчётов;
- подготовить прототип на обезличенных данных;
- связать каждое требование со сценарием приёмки;
- настроить, протестировать, обучить и сопровождать изменение.
Нельзя молча передавать ему право решить:
- что компания считает квалифицированной продажей;
- какой результат допускает обещание клиенту;
- какие персональные данные нужны коммерческому процессу;
- кто принимает работу на межфункциональном стыке;
- какая причина проигрыша требует изменения продукта, цены или дисциплины;
- какой показатель будет основанием для управленческого действия.
Это не недоверие к исполнителю. Это разделение ответственности. Интегратор отвечает за качество решения и прозрачность вариантов. Коммерческая функция — за смысл процесса и последствия его применения. Если нужен внешний модератор рабочей сессии и последующая реализация, команда НТА может пройти этот путь от обследования до проверяемого пилота.
Тест понедельником
В понедельник возьмите одну активную сделку и отдельно спросите менеджера и руководителя:
- На какой стадии она находится?
- Какой факт подтверждает эту стадию?
- Какое действие обязательно дальше и кто его владелец?
- Когда действие станет просроченным?
- Какие данные нужны для решения, а какие собраны «на всякий случай»?
- Что произойдёт при обнаружении дубля клиента?
- В какой отчёт попадёт результат и какое решение он изменит?
Если ответы совпали и подтверждаются событиями, у проекта есть основа для настройки. Если ответы различаются, CRM пока не нужна новая кнопка. Ей нужен согласованный процесс.
Будущее должно выдержать понедельник. Для CRM это означает простую вещь: система помогает команде одинаково принять следующее решение даже тогда, когда привычная сделка пошла не по демонстрационному сценарию.
Важное уведомление
Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.
«Менеджер открывает новую CRM и видит знакомую воронку: «Новый», «В работе», «Предложение», «Договор».»
- 01CRM не устраняет разные трактовки стадий, данных и ответственности: без управленческого решения она закрепляет их в настройке.
- 02До проекта коммерческая функция фиксирует семь решений — границы, стадии, данные, идентичность клиента, роли, сроки и отчётность — а интегратор превращает их в проверяемую систему.
- 03Готовая таблица не заменяет обследование и юридическую проверку персональных данных, но позволяет начать настройку с согласованного смысла, а не с набора полей.