# Post purchase в Mindbox: какие события нужны постпокупочной цепочке и как собрать каскад без техдолга

> Post purchase в Mindbox падает там, где сайт, 1С и CRM не передают нужные статусы. Разбираем карту событий и каскад email–push–SMS без переплат на SMS.

**Рубрика:** Статьи  
**Автор:** Егор Череватенко, CRM-маркетолог, ClientCore  
**Дата:** 2026-09-25

Клиент оплатил заказ — и тишина. Ни письма с подтверждением, ни сообщения о прибытии в пункт выдачи, ни запроса на отзыв. Сценарий в Mindbox при этом живой: просто до него не доходят события. Сайт пишет про оплату одним словом, 1С — другим, CRM не пишет ничего. Постпокупочная механика держится на статусах заказа, и пока карта этих статусов не собрана, цепочка будет падать на первом же нестандартном заказе.

Ниже — разбор Егора Череватенко, CRM-маркетолога ClientCore: какие события должны писать сайт, 1С или CRM, как зафиксировать их так, чтобы через год не пришлось все переделывать, и как выстроить каскад email–push–SMS без сжигания бюджета на последнем шаге.

> **Читайте также:** [KPI post-purchase цепочки: как измерить, что сценарий после покупки приносит деньги](https://clientcore.ru/blog/articles/kpi-post-purchase-cepochki-kak-izmerit-chto-scenariy-posle-pokupki-prinosit-dengi)

## Что входит в post purchase цепочку

Постпокупочный сценарий закрывает четыре задачи: подтвердить заказ и рассказать про статус, собрать отзыв, предложить сопутствующий товар, вернуть человека на повторную покупку. Триггер у всех шагов один — статус заказа. «Оплачен» запускает thank-you-письмо, «передан в доставку» отправляет трек-номер, «прибыл в пункт выдачи» сообщает номер бокса, «выдан» открывает ветку с отзывом и cross-sell через заданное число дней.

Mindbox welcome цепочка провожает человека до первой покупки. Post purchase цепочка подхватывает на том месте, где welcome закончила, — на первом оплаченном заказе. Поэтому постпокупочная механика не стартует, пока у заказа не появится хоть какой-то статус. Нет события — нет входа в сценарий, и маркетинг видит в отчете ноль вместо выручки.

## Какие события должны писать сайт, 1С или CRM

Минимальный набор, который стоит требовать от интеграции:

- order.created — заказ оформлен. Нужен для синхронизации, как триггер почти не используется
- order.paid — оплата подтверждена. Запускает thank-you
- order.shipped — заказ передан в доставку. Письмо с трек-номером
- order.ready_for_pickup — прибыл в пункт выдачи. Сообщение о сроках хранения
- order.delivered — выдан или доставлен. Отсюда стартуют отзыв и cross-sell
- order.cancelled — отмена. Стоп для всех веток
- order.returned — возврат. Отдельный стоп или отдельная ветка коммуникации

Источники разные. Сайт пишет оформление и оплату — обычно через вебхук платежной системы. 1С отдает статусы склада и доставки. CRM становится источником, если доставка живет там. Способы доставки в Mindbox тоже различаются: REST API дает событие в моменте, файловая выгрузка по расписанию привозит статус через час или сутки — и триггер «здесь и сейчас» уже не сработает. Для post purchase цепочки это критично: письмо о прибытии в пункт выдачи, пришедшее через день, просто бесполезно.

> Из десяти неработающих постпокупочных сценариев, которые мы разбирали, в восьми не хватало именно событий. Один проект передавал из 1С только „Новый“ и „Выполнен“, хотя между ними жили еще четыре статуса. Половина цепочки просто не имела входа. Дописали карту из шести событий — сценарий пошел».
>
> — Егор Череватенко, CRM-маркетолог, ClientCore

## Карта событий: как избежать техдолга

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

Второй прием — единая точка входа. Пусть в Mindbox пишет один модуль или middleware, собирающий данные из всех систем. И третий — нейминг: snake_case и фиксированный словарь значений, чтобы order.delivered не превращался в «Выдан», «ВЫДАН» и «done» одновременно. Плюс идемпотентность: уникальный идентификатор события, повторная передача которого не плодит дубли заказов.

**Норма**

- реестр событий в одном месте, доступ есть у маркетинга
- у каждого события — пример payload с реальным заказом
- повторная передача статуса не создает дубликат

**Red flag**

- статусы из 1С приходят сырым текстом без нормализации: «Выдан», «ВЫДАН», «done»
- за события отвечают «и сайт, и 1С, и CRM» без зоны ответственности
- в Mindbox лежат два похожих события, и при настройке выбирают «любое»

## Каскад email → push → SMS без переплат

SMS — дорогой канал, email стоит копейки, push почти ничего. Поэтому в логике каскада SMS должна стоять последней и доставаться тем, кто игнорировал предыдущие шаги. Схема простая: после события отправляем email, ставим wait-узел на 4–6 часов; не открыл — уходит push; если email-адреса нет, ветка сразу уходит в push; когда и push не доставлен, включается SMS. В Mindbox такой каскад собирается на wait-узлах и проверке активности по предыдущим сообщениям — классическая mindbox каскадная рассылка, только внутри триггерного сценария.

Детали решают экономику. Открытие email мы видим по пикселю, по push проверяем доставку. SMS-шаблон держим коротким, со ссылкой. Итог — канал с максимальной стоимостью расходуется на минимальный сегмент.

> Отправлять SMS всей базе — прямой путь в перерасход. Мы выстроили правило: SMS уходит только тем, у кого нет email-подписки и кто не открыл push. В одном проекте бюджет на SMS по постпокупочным сценариям сократился примерно на 70%, охват сохранился».
>
> — Егор Череватенко, CRM-маркетолог, ClientCore

Мы это проверяли на практике: в проекте для «Браво-Оптики» внедрили Mindbox, запустили email-канал и каскадные цепочки, что за 10 месяцев дало +14,62% к выручке от CRM-направления ([кейс](https://clientcore.ru/blog/articles/keis-bravo-optika-rost-vyruchki-crm)).

## Выводим в прод: тестовый заказ и мониторинг

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

> На проекте с тремя сотнями заказов в день один зависший вебхук за выходные — это шесть сотен человек без письма о статусе. Поэтому ставим алерт на нулевой приток событий: реагируем в тот же день, а не по месячному отчету».
>
> — Егор Череватенко, CRM-маркетолог, ClientCore

> **Читайте также:** [Cross-sell после покупки: что предлагать клиенту и когда, чтобы он заказал снова](https://clientcore.ru/blog/articles/cross-sell-posle-pokupki-chto-predlagat-klientu-i-kogda-chtoby-on-zakazal-snova)

---

[Открыть статью на сайте](https://clientcore.ru/blog/articles/post-purchase-v-mindbox-kakie-sobytiya-nuzhny-postpokupochnoy-cepochke-i-kak-sobrat-kaskad-bez-tehdolga)