Для малого интернет-магазина CRM должна получать не каждое техническое событие, а понятные этапы заказа: новый, подтверждён, оплачен, передан в доставку, выдан или отменён. Такая схема помогает менеджеру видеть, что происходит с покупателем, не сверять вручную сайт, платёжный сервис и доставку. В статье разберём, какие статусы передавать, какие поля добавить к заказу и как проверить интеграцию без остановки продаж.
Зачем интернет-магазину передавать статусы заказа в CRM?
Когда сайт и CRM работают отдельно, менеджер переносит заказы руками, уточняет оплату в кабинете платёжной системы, а статус доставки получает из другого источника. На каждом шаге появляется риск ошибки: заказ уже оплачен, но в CRM остаётся «Ожидает оплаты»; посылка выдана, а клиент продолжает получать напоминания; отменённый заказ числится в работе.
Интеграция связывает карточку заказа с действиями магазина. Новая заявка создаёт сделку в CRM, успешная оплата меняет её этап, передача в доставку запускает уведомление, а отмена закрывает дальнейшие задачи. Отдельно полезно передавать номер заказа, сумму, способ оплаты, адрес или пункт выдачи, состав покупки и источник обращения.
Разрыв между платёжной системой и CRM часто возникает именно после нажатия кнопки «Оплатить»: менеджер не видит результат операции, а сделка зависает в ожидании. Такой сценарий разбирается в материале как принимать оплату картами рассрочки в RetailCRM. Для практической настройки достаточно сначала описать путь одного заказа от оформления до выдачи.
Какие статусы заказа нужны в базовой схеме?
Количество этапов зависит от модели продаж. Магазину с одной службой доставки хватит короткой цепочки. Если есть самовывоз, частичные оплаты, возвраты или несколько способов доставки, статусы лучше разделить. При этом каждый этап должен отвечать на один вопрос: что уже произошло и какое действие следует дальше.
| Статус | Когда устанавливать | Что сделать в CRM |
|---|---|---|
| Новый заказ | Клиент оформил покупку на сайте | Создать сделку, назначить ответственного, поставить задачу на проверку |
| Принят в работу | Менеджер проверил контакт и наличие товара | Зафиксировать результат проверки, при необходимости уточнить детали |
| Подтверждён | Клиент согласовал состав, цену и способ получения | Передать заказ на сборку или подготовить его к оплате |
| Ожидает оплаты | Заказ создан, но платёж ещё не подтверждён | Запланировать напоминание и не передавать заказ в доставку |
| Оплачен | Платёжная система вернула успешный статус | Разрешить сборку, сохранить сумму и идентификатор платежа |
| Собирается | Склад начал комплектовать заказ | Показать заказ ответственному сотруднику и зафиксировать дату сборки |
| Передан в доставку | Заказ получил перевозчик или курьер | Сохранить номер отправления и отправить клиенту уведомление |
| Готов к выдаче | Заказ прибыл в пункт самовывоза или готов у продавца | Создать срок хранения и сообщение покупателю |
| Выдан или доставлен | Клиент получил товар | Закрыть сделку, запустить запрос отзыва или предложение повторной покупки |
| Отменён | Клиент отказался, платёж не прошёл или товар недоступен | Указать причину, остановить напоминания и сохранить историю заказа |
| Возврат | Клиент вернул товар после получения | Зафиксировать товар, сумму и этап возврата денежных средств |
Статусы «оплачен», «передан в доставку» и «выдан» лучше менять по событию из соответствующей системы. Менеджер может вручную подтвердить звонок или состав заказа, но результат платежа не стоит вводить с клавиатуры. Для SMS-цепочки с уведомлениями о движении заказа пригодится материал как настроить SMS-цепочку статуса заказа в интернет-магазине.
Какие данные передавать вместе со статусом?
Одного названия этапа мало. CRM должна понимать, к какому заказу относится событие и что именно изменилось. Минимальный набор выглядит так:
- номер заказа на сайте;
- номер сделки или контакта в CRM;
- дата и время изменения;
- новый статус;
- предыдущий статус, если система хранит историю переходов;
- сумма заказа и валюта, например BYN;
- стоимость доставки и скидка;
- способ оплаты и идентификатор платежа;
- способ получения: курьерская доставка, самовывоз или другой вариант;
- номер отправления, если его выдала служба доставки;
- состав заказа с количеством и ценой;
- комментарий менеджера или причина отмены.
Для магазина с повторными покупками полезно передавать в CRM не только текущую сделку, но и связь с клиентом. Тогда менеджер видит прошлые заказы, частоту покупок и причины отказов. Состав товаров пригодится для сегментации: покупателю можно предложить расходный материал или напомнить о повторной покупке, когда для этого есть понятный срок.
Отдельное поле нужно для источника заказа. Если клиент пришёл из рекламы, поиска или формы на сайте, CRM должна сохранить этот источник вместе со сделкой. При телефонном заказе источник можно определить через колл-трекинг, который связывает входящий звонок с рекламным каналом и передаёт данные в CRM (Cropas, «Колл-трекинг для рекламы»).
Как разделить статусы оплаты, сборки и доставки?
Одна длинная воронка часто смешивает разные процессы. Например, статус «В работе» ничего не говорит о том, оплатил ли клиент заказ и где находится посылка. Для небольшого магазина удобнее оставить одну основную воронку, но добавить отдельные поля:
- Оплата: не начата, ожидается, подтверждена, отклонена, возвращена.
- Сборка: не начата, комплектуется, готова, есть проблема с товаром.
- Доставка: не передана, передана, в пути, готова к выдаче, доставлена, не вручена.
Так менеджер видит реальную картину. Заказ может быть оплачен, но ещё не собран. Или собран, однако курьер не смог вручить его клиенту. Если все эти ситуации обозначить одним словом, автоматические задачи начнут срабатывать в неподходящий момент.
Для самовывоза нужен отдельный маршрут: «Готов к выдаче» не должен запускать сообщение о передаче курьеру. Для доставки по Беларуси в CRM стоит хранить город, способ получения и контакт получателя. Город можно передавать отдельным полем, чтобы менеджер не искал его в свободном комментарии.
Как настроить автоматические действия после смены статуса?
Каждый статус стоит связывать с одним понятным действием. После нового заказа CRM назначает ответственного. После подтверждения создаёт задачу на сборку. После оплаты открывает следующий этап. После передачи в доставку отправляет клиенту номер отправления. После отмены закрывает активные напоминания.
| Событие | Автоматическое действие | Контрольный вопрос |
|---|---|---|
| Новый заказ | Создать сделку и задачу менеджеру | Есть ли ответственный и срок реакции? |
| Платёж подтверждён | Перевести заказ в сборку | Сохранился ли идентификатор платежа? |
| Товар недоступен | Поставить задачу связаться с клиентом | Зафиксирована ли причина изменения заказа? |
| Передан в доставку | Сохранить номер отправления и уведомить покупателя | Совпадает ли номер в CRM с данными доставки? |
| Не вручён | Вернуть сделку ответственному менеджеру | Создана ли новая попытка связи? |
| Выдан | Закрыть сделку и запланировать повторный контакт | Не отправляются ли клиенту старые уведомления? |
Если уведомления зависят от SMS, магазин может передавать события через вебхуки. Схема «магазин — CRM — доставка» описана в материале как связать магазин, CRM и доставку через вебхуки для SMS. Перед запуском автоматизации полезно отправить тестовый заказ и проверить, какое событие приходит при каждом переходе.
Какие ошибки ломают передачу статусов?
- В CRM передают только номер заказа. Без идентификатора сделки система может создать дубликат вместо обновления существующей карточки.
- Статусы названы по-разному. Сайт отправляет «Оплата получена», а CRM ожидает «Оплачен». Нужна таблица соответствий между системами.
- Событие не содержит времени. При повторной отправке старое уведомление способно перезаписать новый статус.
- Отмену не считают отдельным событием. Тогда автоматические напоминания продолжают уходить клиенту после отказа.
- Оплату меняют вручную. Менеджер видит успешный экран, но CRM не получает подтверждение от платёжного сервиса.
- Интеграцию не проверяют после обновления сайта. Изменение API-ключа, формы или адреса вебхука может остановить передачу данных.
Для диагностики удобно завести четыре тестовых заказа: с успешной оплатой, с отказом платежа, с отменой и с невыданной доставкой. По каждому сценарию проверьте создание сделки, изменение полей, задачи сотрудникам и уведомления. Если интеграция интернет-магазина с CRM требует нескольких систем, сначала составьте карту событий и только потом выбирайте готовый модуль, вебхук или индивидуальную настройку.
3 шага, которые можно сделать на этой неделе:
- Записать все этапы заказа от оформления до доставки и убрать статусы, которые не меняют действий сотрудника.
- Составить таблицу соответствий: статус на сайте, событие оплаты, этап сборки, состояние доставки и действие в CRM.
- Проверить четыре тестовых сценария и сохранить журнал ошибок, чтобы подрядчик или внутренний специалист исправлял конкретные разрывы.
