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