Как контролировать обязательные поля CRM перед сменой стадии сделки

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

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

Какую проблему решает контроль перед переходом

У поля есть как минимум три разных состояния:

1. Заполнено: в поле есть значение.
2. Допустимо: значение соответствует типу, справочнику и установленным ограничениям.
3. Достаточно для перехода: значение подтверждает условие именно этого шага процесса.

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

Такой контроль не следует смешивать с квалификацией нового обращения или первоначальным переносом данных из текста в CRM. Здесь система работает с существующей сделкой непосредственно перед запросом на смену стадии.

Составьте матрицу требований для каждого перехода

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

| Текущая стадия | Целевая стадия | Что проверить | Условие допустимости | Источник | Кто исправляет | Исключение и согласующий | | --- | --- | --- | --- | --- | --- | --- | --- | | Уточнение задачи | Подготовка предложения | Основной контакт | Контакт указан и доступен по правилам процесса | Карточка и связанный контакт | Менеджер | По регламенту компании | | Уточнение задачи | Подготовка предложения | Перечень работ | Нет заглушки; состав согласован установленным способом | Поле или связанная запись | Менеджер | По регламенту компании | | Уточнение задачи | Подготовка предложения | Следующее действие | Указаны действие и допустимая дата | Поле или задача | Менеджер | По регламенту компании |

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

В REST API Битрикс24 у сделки stageId обозначает стадию, а список доступных стадий зависит от направления сделки, заданного через categoryId. Это подтверждает модель данных Битрикс24, но не наличие готового контроля по регламенту конкретной компании.

Разделите проверку заполненности и проверку смысла

Проверяйте условие последовательно:

1. Значение присутствует.
2. Значение соответствует типу или справочнику.
3. Значение не является технической заглушкой.
4. Значение согласуется со связанными полями и сущностями.
5. Сведения подтверждены источником, который требует регламент.

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

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

API amoCRM возвращает в модели сделки status_id, pipeline_id и custom_fields_values; связанные контакты можно запросить предусмотренным параметром. Это означает, что интеграция может читать такие сведения в пределах доступных методов и прав. Полноту ответа, доступ к нужным полям и возможность перехватить каждый используемый способ смены стадии проверяют в аккаунте заказчика.

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

Будущее решение можно спроектировать как последовательность:

1. Получить идентификатор сделки и запрошенную стадию.
2. Прочитать актуальную карточку и нужные связанные сущности.
3. Выбрать версию правила для пары стадий.
4. Проверить все условия и сформировать единый результат.
5. При разрешении повторно проверить актуальность данных и выполнить переход.
6. Перечитать карточку и сопоставить фактическую стадию с запрошенной.

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

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

Как вернуть замечания менеджеру

Сообщение должно помогать исправить карточку. Для каждого расхождения укажите:

• какое условие не выполнено;
• где находится значение;
• какая стадия запрошена;
• что нужно исправить;
• что произойдёт после исправления.

Например: «Переход в “Подготовку предложения” остановлен. В перечне работ осталось значение “уточнить”, дата следующего действия не указана. Обновите оба поля и повторите запрос».

Различайте четыре результата: данные не готовы, у пользователя или интеграции нет полномочий, CRM недоступна, правило для перехода не определено. Технический отказ нельзя выдавать за нарушение регламента менеджером. Система также не должна сама дописывать неизвестные сведения.

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

Исключения, полномочия и журнал решения

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

1. Менеджер указывает причину.
2. Уполномоченный сотрудник видит карточку и найденные расхождения.
3. Сотрудник разрешает или отклоняет конкретный переход.
4. Система выполняет разрешённое действие и подтверждает результат повторным чтением.

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

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

Что умеют CRM и что требуется спроектировать

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

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

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

Учебный пример: переход к подготовке предложения

Ниже — синтетическая демонстрация проектируемого поведения. Это не клиентский кейс Switch On AI и не результат теста в реальной CRM.

Сделка находится на стадии «Уточнение задачи». Менеджер запрашивает переход в «Подготовку предложения». Регламент компании требует четыре условия:

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

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

Как проверить решение перед рабочим запуском

Приёмку проводите на фактической конфигурации CRM и правилах заказчика. Для каждого предусмотренного перехода проверьте:

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

Такой контроль не подтверждает перспективность сделки, не заменяет руководителя и не гарантирует качество сведений только потому, что поле непустое.

Что подготовить для оценки внедрения

Для разбора процесса понадобятся:

• название, редакция и конфигурация CRM;
• схема воронок;
• обезличенный пример карточки;
• все используемые способы смены стадии;
• матрица условий для выбранного перехода;
• роли и порядок согласования исключений;
• доступные API, события и права;
• требования к уведомлениям и журналу.

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

Switch On AI разрабатывает автоматизацию операций отдела продаж. На странице ИИ-агента для первой линии продаж описаны границы работы с заявками, CRM и решениями менеджера. Для полностью формализованной проверки может подойти обычная интеграция без ИИ — это определим после изучения вашей CRM и правил.

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