медиа про еком + ии
Главная / Материалы
Гайд · CRM-маркетинг

Как проверить CRM-цепочку от ИИ до рассылки

Коротко

  • Проверьте AI-черновик на вымышленных событиях до подключения отправки: оплата должна остановить цепочку, отсутствие согласия — запретить вход, повтор — не создать дубль, истёкший промокод — не попасть в сообщение.
  • Ниже — учебная цепочка и CSV-карта с сохранёнными результатами: их можно разобрать без аккаунта CRM.
  • Успешная карта проверяет логику упражнения, а не готовность реальной рассылки.

Редакция Кометы · опубликовано · обновлено 17 октября 2026

Проверено 16 октября 2026 · учебный пакет, версия r2 · Python 3.14.4. Интерфейс CRM не проверялся.

В справке RetailCRM AI-помощник описан как инструмент создания и редактирования черновика сценария. Цепочку для упражнения придумала редакция. Способ пригодится CRM-маркетологу интернет-магазина, которому нужно проверить условия и остановки до переноса сценария в рабочую систему.

Что понадобится

Скачайте архив упражнения и распакуйте в отдельную папку. Внутри — правила, вымышленные события, заранее записанные ожидания, пустая карта, заполненный пример и код автоматического прохода. Откройте CSV в локальном табличном редакторе с кодировкой UTF-8 и разделителем-запятой; JSON — в текстовом редакторе. Контактов и данных покупателей в пакете нет: входы.

Аккаунт, тариф CRM и платная модель для упражнения не нужны; отдельной платы за файлы и локальный запуск нет. Для автоматического варианта нужен уже установленный Python 3.9 или новее, без дополнительных пакетов; редакция прошла опубликованный архив на Python 3.14.4. Запись прохождения. Для ручного прохода Python не нужен. Это локальные файлы: инструкция не требует подключения к зарубежному сервису или обхода ограничений. Требования к локальному запуску.

Заложите отдельный рабочий подход: сначала разберите обязательные ветви, затем остальные события. Время ручного прохождения не замеряли. Один запуск кода из распакованного архива на машине редакции занял 0,0972 секунды: без скачивания, распаковки и чтения карты. Это не оценка времени всей инструкции; на другой машине результат будет отличаться. Условия замера. Метки времени в файле заменяют реальное ожидание — оставлять программу на сутки не нужно. Инструкция к пакету.

Шаг 1. Зафиксируйте правила до проверки

Откройте scenario.txt. В нашем упражнении магазин сначала напоминает о корзине без скидки, затем предлагает учебный код DEMO-CODE. Правила, интервалы и ключ повторного входа придуманы для обучения.

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

Первый срок — час от входа. Второй — более поздний из двух: сутки от входа или 23 часа от фактического первого напоминания. Если первый шаг задержался, второй тоже переносится. Эти интервалы — условия упражнения. Правила сроков.

Как посчитать перенос: пример из late-reminder. Отсчитываем часы от входа, это нулевая отметка. В сохранённых входах первое напоминание произошло через 24,5 часа, а не через час. По правилу второго срока получаем max(24; 24,5 + 23) = 47,5 часа от входа. Значит, в момент первого напоминания второе ещё запрещено; его срок наступит лишь через 23 часа. Это наш расчёт по учебным данным: исходные отметки, правило.

В заполненной карте попытка второго шага сразу после первого получила wait / not_due, а через 23 часа — would_send / eligible. Допущения расчёта: оплата и согласие не меняются, учебный код к этому моменту ещё действует. Не переносите этот результат на случай, где хотя бы одно условие отличается. Проверочные строки late-reminder-3 и late-reminder-4.

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

Шаг 2. Подготовьте входы, которые меняются по ходу цепочки

Откройте inputs.json. Каждый случай начинает с пустого журнала; события внутри него идут по порядку. Значения оплаты и согласия относятся к моменту события, а не навсегда сохраняются при входе. Идентификаторы клиента, корзины и версии — учебные обозначения.

Сначала найдите обязательные случаи: описание и входы.

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

Локальное представление входов четырёх ветвей, не интерфейс CRM

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

Шаг 3. Заполните карту, не отправляя сообщений

  1. Откройте пустой CSV-бланк, рядом — входы и expected.csv.
  2. Для каждого события запишите фактическое действие, причину и обозначение условного сообщения. Сравните с expected_*.
  3. Ставьте pass только при совпадении всех этих значений; при отличии — fail и пояснение в mismatch. В checked_by укажите, кто заполнил строку. Порядок работы.

В учебной модели accept означает принятый вход, wait — срок ещё не наступил, skip — повтор пропущен, stop — цепочка закрыта, would_send — записано намерение сообщения. Последнее не означает отправку или доставку. M1 — напоминание без скидки, M2 — предложение с действующим учебным кодом. Словарь результатов.

Для автоматического варианта откройте терминал в распакованной папке и выполните:

python3 walkthrough.py --out result

Появятся result/actual.csv, result/check-map.csv и result/summary.json. Нулевой код завершения означает совпадение событий с сохранёнными ожиданиями; код 1 — найденное расхождение. Ошибочный вход может прервать запуск: отсутствие выходного файла не считайте успешной проверкой. Инструкция запуска.

Заполненная карта проверки учебной цепочки

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

Шаг 4. Разберите ошибки, которые легко пропустить

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

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

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

Второе сообщение догнало запоздалое первое. Исправление: отталкиваться также от фактического времени первого шага. Контроль: в случае задержки второе сообщение ждёт перенесённого срока, а не идёт сразу. Ранний вызов возвращает ожидание и сам по себе не закрывает цепочку. Карта событий.

Срок кода закончился ровно сейчас. В упражнении код действителен только до срока, не в сам момент окончания. Исправление: строгое сравнение времени; неизвестный срок — запрет второго предложения. Контроль: отдельно просрочка, точная граница и неизвестное значение. Автоматической замены предложения нет. Правила кода.

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

Как мы прошли упражнение

В сохранённом офлайн-проходе совпали с ожиданиями 39 из 39 событий. Из них 14 относятся к четырём обязательным ветвям, ещё 25 — к девяти дополнительным. Модель записала 12 условных намерений; реальных отправок не было. Это проверка согласованности нашей модели, а не процент качества AI-помощника: сводка, полная карта.

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

Мы не генерировали этот черновик в RetailCRM, не подключали CRM и не измеряли продажи. Не проверены доставка, сбои записи, конкурентная обработка и частота контактов по разным корзинам. Четыре обязательные ветви не заменяют остальные проверки вашей рабочей цепочки. Границы упражнения.

Что проверить перед переносом в CRM

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

Перед реальным запуском составьте отдельный список проверок:

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

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

Источники

Исправлено при обновлении: для автоматического прохода нужен Python 3.9 или новее, как указано в инструкции к файлам. Прежнее «Python 3» не называло минимальную версию. Сохранённый проход выполнен на Python 3.14.4; результаты упражнения не менялись. Требования к запуску.

Редакция Кометы

Сообщить об ошибке