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