Смена этапов воронки CRM: как не сломать задания ИИ-агентов

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

При смене этапов CRM определяют смысл новых состояний, соответствие старых карточек, правила переходов и судьбу незавершённых поручений. Переименование не подтверждает готовность процесса. Агентам передают актуальные условия, отчёты сохраняют объяснимость, а случаи без достаточного основания получают владельца проверки. Технический перенос принимают отдельно от правильности коммерческого решения по каждой затронутой истории клиента.

Переименовали колонку — изменили работу целого отдела

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

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

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

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

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

Этап — это условие, а не название

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

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

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

Карта соответствия старой и новой схемы

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

Разделение одного этапа на несколько требует правила распределения. Объединение нескольких может потерять полезное различие. Удаление промежуточного состояния меняет ожидания задач. Даже если карточки удалось перенести, это не доказывает сохранение работы: в старом этапе могли жить напоминания, фильтры и условия запуска роли.

В проекте сохраняют исходные значения и версию карты переноса. Это не повод хранить бесконечные копии всех данных без необходимости; нужен достаточный след, чтобы объяснить конкретное изменение. Если сотрудник спрашивает, почему клиент попал в новый этап, ответ должен восстанавливаться по правилу и фактам.

Неизвестные случаи не стоит автоматически отправлять в конец воронки или записывать как проигранные. Такая операция улучшит видимость чистой доски и ухудшит содержание отчёта. Для ручной сверки нужен собственный маршрут с владельцем, а не «техническая» колонка, в которой клиенты исчезнут на неопределённый срок.

Что проверить у работающих агентов

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

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

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

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

Поручения, которые уже выданы по старому этапу

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

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

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

Важно подтвердить доставку обновления исполнителю. Новая запись в CRM не всегда меняет отдельную очередь телефонии. Если процесс подключён к Фонексу, сценарий и контекст действия должны получить актуальную согласованную версию. Само наличие интеграции не освобождает от проверки отмены и обновления поручения.

Как сохранить сравнимость отчётов

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

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

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

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

Подготовить переход без остановки смысла работы

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

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

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

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

Набор карточек для приёмки

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

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

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

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

Кто поддерживает новую схему после запуска

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

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

Паспорт изменения двух похожих этапов

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

Далее выбирают три условные карточки. В первой расчёт готов, документ не отправлен. Во второй есть подтверждение отправки. В третьей сохранилась только заметка «КП почти готово». Третья не должна попадать во вторую колонку ради красивой статистики. Она получает конкретную сверку с владельцем. Такое распределение делает неизвестное управляемым, а не прячет его в широком статусе.

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

Итог упражнения — карта решений и принятые примеры. Она остаётся доступной владельцу процесса и используется при будущих изменениях. Если через месяц сотрудник не может объяснить причину переноса, паспорт неполон. Хорошая миграция сохраняет не только количество карточек, но и возможность восстановить, почему каждая из них оказалась в новом состоянии и что теперь следует делать.

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