Чтобы описать процесс продаж перед внедрением CRM, разберите несколько конкретных обращений от первого контакта до выбранного результата. Для каждого шага запишите событие, исполнителя, действие, передаваемые данные и подтверждение завершения. Затем отдельно согласуйте возвраты, ожидания и отказы. Результат — карта процесса и исключений, по которой сотрудники одинаково понимают, кто и что делает дальше.
Начинать удобнее с одного направления продаж. Если одновременно обсуждать тендеры, розничные заказы и сопровождение действующих клиентов, получится слишком общая схема. Ниже — методика рабочего обследования и учебный образец карты; это рекомендации редакции, а не обязательный стандарт или готовая конфигурация CRM.
Сначала определите начало и конец процесса
Запишите границы одним предложением: «От получения запроса на расчёт до подтверждённой оплаты и принятия заказа исполнением». В другой компании продажа может завершаться подписанием договора. Выберите смысл результата до обсуждения названий колонок и отчётов.
Уточните единицу учёта: одна сделка — это отдельный заказ, проект или запрос на определённую услугу? Один клиент может обсуждать несколько независимых заказов. Без этого решения участники будут спорить о дублях и возвратах, имея в виду разные объекты.
Отделите три слоя: как сотрудники работают сейчас, как договорились работать после запуска и как это будет реализовано в системе. Например, «менеджер пишет бухгалтеру в личный чат» — наблюдение о текущей работе. «Оплата должна подтверждаться по согласованному источнику» — целевое правило. Способ получения подтверждения через интеграцию выбирается позднее.
Кого приглашать на обследование
- Владельца процесса. Руководителя, который может утвердить границы ответственности, приоритеты и спорные правила. Интегратор не должен самостоятельно решать, что компания считает завершённой продажей.
- Менеджеров, работающих с разными типами обращений. Они показывают фактические действия, ручные обходы и случаи, которые не помещаются в регламент.
- Получателей результата. Представителей расчёта, бухгалтерии, производства или сервиса — тех, кому передают работу. Они объяснят, каких сведений обычно не хватает.
- Администратора или технического специалиста. Он проверит доступность данных и ограничения систем. Технические вопросы фиксируются отдельно и не подменяют обсуждение процесса.
Если один человек совмещает несколько ролей, обозначьте их раздельно. Сегодня руководитель одновременно согласует скидку и распределяет заказы, но это две разные ответственности. Отсутствующего участника нельзя считать согласовавшим правило: пометьте соответствующую передачу как открытую до проверки с ним.
Как восстановить реальную последовательность действий
Подготовьте обезличенные истории: обычная успешная продажа, отказ, зависшее согласование, повторный заказ и случай возврата на доработку. Это набор для обсуждения, не статистическая выборка. Для каждой истории нужны доступные подтверждения: переписка, документы, задачи, записи об оплате. Не переносите пароли и лишние персональные данные в общую карту.
- Пройдите историю по времени. Что запустило работу? Кто первым увидел запрос? Что произошло дальше? Просите показать конкретное действие вместо ответа «обычно мы делаем так».
- Отметьте передачу между людьми. Какие сведения отправлены, кто получил их и как подтвердил, что принял работу? Отправленное сообщение само по себе ещё не доказывает принятия.
- Выделите ожидания. Кто ждёт клиента, кто — внутреннего согласования? Укажите владельца ожидания и момент следующей проверки.
- Запишите расхождения. Если регламент и фактическая история различаются, сохраните обе версии и причину. Не превращайте удобный обход в утверждённое правило автоматически.
На схеме достаточно ясных действий: «Уточнить состав заказа», «Проверить возможность поставки», «Подтвердить оплату». У развилки должен быть вопрос с понятными исходами. Такой принцип ясных названий, условий и конечных результатов описан в рекомендациях Camunda по читаемым моделям процессов. Для первого обсуждения достаточно таблицы или простой схемы: освоение полной нотации BPMN не является условием старта.
Карта процесса: заполненный учебный пример
Учебный пример, не клиентский кейс. Компания продаёт оборудование с предварительным расчётом. Единица учёта — отдельный заказ. Ниже показан основной путь; в реальном проекте сроки и правила нужно согласовать со своей командой.
| Шаг и событие | Исполнитель и действие | Результат и принимающая сторона | Исключение и контроль |
|---|---|---|---|
| P1. Получен запрос | Менеджер уточняет предмет заказа и контакт для связи | Описание потребности и согласованный следующий контакт; менеджер продолжает работу | Клиент не отвечает: причина ожидания и дата повторной проверки |
| P2. Данных достаточно для расчёта | Расчётчик проверяет состав и возможность исполнения | Версия расчёта с допущениями передана менеджеру; получение подтверждено | Не хватает параметров: возврат менеджеру с перечнем вопросов, а не пустая отметка «доработать» |
| P3. Расчёт проверен | Менеджер обсуждает предложение с клиентом | Зафиксирована согласованная версия либо конкретные замечания клиента | Скидка вне полномочий: отдельное решение руководителя до обещания клиенту |
| P4. Условия согласованы | Менеджер организует оформление заказа; бухгалтерия проверяет поступление оплаты | Основание платежа и подтверждённый факт оплаты доступны менеджеру | Частичная или неидентифицированная оплата: бухгалтерия уточняет статус; заказ не объявляется полностью оплаченным |
| P5. Условия передачи выполнены | Менеджер передаёт заказ исполнению | Исполнение принимает состав, версию условий и обязательства; фиксируется получатель и время принятия | Исполнение отклоняет неполный комплект: менеджер получает причину возврата и сохраняет ответственность за исправление |
Скопируйте структуру и добавьте к каждой строке срок, источник данных, ссылку на подтверждение и правило замещения отсутствующего исполнителя. Срок задавайте вместе с точкой отсчёта и календарём: «до конца следующего рабочего дня после получения полного комплекта» понятнее, чем «быстро». Временные нормы этой компании определяет её руководитель, а не шаблон статьи.
Строка карты не обязана становиться отдельным этапом CRM. Несколько действий могут выполняться внутри одного состояния сделки. В документации amoCRM описаны настраиваемые этапы и отдельные воронки; это инструменты представления процесса, но распределение ответственности между отделами всё равно нужно согласовать самостоятельно. Настройка воронки amoCRM. Подробные критерии колонок разобраны в статье об этапах воронки продаж.
Как описывать нестандартные сценарии
Заведите отдельный реестр исключений и свяжите каждое с номером шага карты. Карточка исключения содержит условие обнаружения, ответственного за решение, допустимое действие, запрет, срок контроля и путь возврата. Формулировка «разобраться вручную» без владельца оставляет работу ничейной.
Например, для P3: клиент изменил состав заказа после согласования расчёта. Менеджер сохраняет прежнюю версию, собирает изменения и возвращает запрос расчётчику. Пока новая версия не подтверждена, её нельзя выдавать исполнению за согласованную. После пересчёта предложение снова обсуждается с клиентом. Это учебное правило, которое показывает и возврат, и условие продолжения.
Проверьте минимум типы ситуаций, которые есть именно у вас: новый заказ прежнего клиента, отказ после согласования, смена контактного лица, отсутствие исполнителя, частичная оплата, задержка ответа, ошибка передачи данных. Не требуется заранее перечислить всё возможное. Для неизвестного случая предусмотрите очередь разбора с владельцем и датой решения; в ней нельзя бессрочно скрывать активные сделки.
Как согласовать карту между руководителем и отделами
Если продажи говорят «заказ готов», а исполнение отвечает «ещё нет», попросите каждую сторону назвать наблюдаемый факт. Часто спор относится к разным событиям: клиент подтвердил предложение, бухгалтерия увидела оплату, производство приняло комплект. Дайте этим событиям разные названия и договоритесь, какое из них запускает конкретное действие.
Затем проведите проход по карте: менеджер объясняет, что отдаёт; получатель показывает, чего достаточно для продолжения; руководитель утверждает спорное правило. Проверяйте также отказ в приёме и обратную передачу. Если решение пока невозможно, запишите вопрос, владельца, срок и какие настройки оно блокирует.
В конце встречи сохраните версию карты, дату, участников согласования и список открытых вопросов. Для каждого изменения укажите причину и затронутые шаги. Рабочая версия должна быть одна; фотографии доски и пересказы в чатах не заменяют согласованного документа.
Когда карту можно передавать в настройку
- Для каждой контрольной истории видны начало, завершение или объяснённое ожидание.
- На каждой передаче названы отправитель, получатель, состав данных и подтверждение принятия.
- Менеджер и получатель одинаково объясняют условия продолжения на одном примере.
- У возврата есть адресат; отказ не выглядит успешным завершением; повторный заказ отделён от повторной доставки тех же данных.
- У открытого вопроса есть владелец и срок, а критичные решения не скрыты под статусом «согласовано».
Карта ещё не доказывает техническую выполнимость. Параллельные согласования, правила доступа, рабочие календари и обмен с другими системами требуют отдельной проверки. Не обещайте автоматизацию только потому, что удалось нарисовать стрелку. Согласованные шаги, данные и исключения затем переносятся в техническое задание на CRM и проверяются на прототипе.
Если CRM уже работает, карту можно использовать для постановки улучшений в рамках сопровождения; состав работ зависит от согласованного объёма. Для нового запуска она станет основой проекта внедрения amoCRM. Начать стоит с одного процесса и подтверждённых разрывов между его участниками.