Заказы в RetailCRM: оплата, доставка и возвраты

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

RetailCRM помогает организовать обработку заказов и обмен с подключёнными системами. Здесь разбираем путь заказа от входящего состава до оплаты, доставки и возврата. Возможности платформы — в общем обзоре RetailCRM, бонусный процесс — в руководстве о лояльности, выбор аналогов — в разделе CRM. Приведённая схема не означает готовый обмен с любой CMS, кассой или службой доставки.

Разделите состояния заказа, позиции и расчёта

Заказ объединяет покупателя, товары, условия и историю общения. Позиция описывает конкретный товар и количество; платёж — движение денег; доставка — исполнение передачи. Эти части могут меняться независимо. Клиент оплатил всё, но один товар отсутствует; часть отправлена, часть ожидает поставку; доставка возвращена, а деньги ещё не возвращены. Один общий цвет не объясняет эти случаи.

Для каждого этапа определите владельца и основание перехода. Менеджер подтверждает состав, склад — возможность исполнения, платёжный участник — состояние расчёта, перевозчик — свою часть движения. CRM собирает информацию, но не превращает предположение сотрудника в подтверждённый факт. Если статус меняется вручную, должно быть понятно, какой результат сотрудник проверил перед этим действием.

Не стройте длинную последовательность только ради отражения каждого звонка. Статус полезен, если меняет ответственность, следующее действие или правило обработки. «Ждём ответа по замене» — понятное ожидание, когда назначен владелец; несколько похожих промежуточных названий без различий лишь усложняют выбор. Отдельные события и комментарии можно сохранять в истории, не превращая их все в состояния заказа.

Входящий заказ и качество исходных данных

При поступлении проверьте внешний идентификатор, канал, покупателя, состав, количество, цены и условия доставки. Сайт и CRM могут использовать разные обозначения товара. Если сопоставление выполнено по названию, похожие варианты способны смешаться. Нужны устойчивые идентификаторы, а при их отсутствии — явная ручная проверка, а не автоматическая подстановка ближайшего совпадения.

Повторная передача того же заказа не должна незаметно создавать второй. Проверьте обычную загрузку, обновление существующей записи и восстановление после ошибки обмена. Для своего коннектора выясните, какие поля можно изменять с каждой стороны и что произойдёт при одновременной правке. Нельзя считать универсальным правило «CRM всегда главная», если сайт или склад продолжает самостоятельно менять часть данных.

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

Изменение состава после подтверждения

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

Сохраните причину и согласие на замену в допустимой форме. Сообщение «аналог согласован» должно позволять понять, какой именно вариант предложили и какие условия принял клиент. Для нескольких позиций полезно видеть результат по каждой, а не один общий комментарий. После изменения проверьте итог на всех связанных сторонах обмена.

Резерв и физическое наличие

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

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

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

Оплата: план, подтверждение и распределение

Выбор способа оплаты не означает поступление денег. Зафиксируйте ожидаемую сумму, источник подтверждения и связь платежа с заказом. Для предоплаты, частичной оплаты и оплаты при получении нужны разные условия продолжения. Сотрудник не должен менять статус «оплачен» только по скриншоту, если принятый порядок требует подтверждения платёжной стороны.

Если оплата приходит из внешнего сервиса, проверьте идентификаторы, суммы и поведение повторного уведомления. Задержка сообщения может оставить заказ в ожидании, хотя деньги уже получены. Не запускайте повторный расчёт наугад. Назначьте способ сверки и ответственного, который может подтвердить состояние у платёжного участника без доступа всех операторов к финансовым настройкам.

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

Оплата при доставке

В такой схеме передача заказа перевозчику не подтверждает получение денег магазином. У перевозчика и платёжного участника может быть собственный цикл перечисления и удержаний. Определите, какие статусы и отчёты подтверждают расчёт и кто их сверяет. Нельзя закрывать финансовое обязательство только потому, что заказ отмечен как доставленный.

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

Доставка как самостоятельный процесс

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

Создание отправления, передача перевозчику и вручение получателю — разные события. Для каждого определите источник состояния. Если накладная создана, но посылка ещё на складе, клиент не должен получать сообщение, что заказ уже едет. Обещания сроков должны учитывать фактическое исполнение и условия службы, а не только переход внутреннего статуса менеджером.

При изменении адреса после оформления доставки выясните, где редактируется отправление и требуется ли подтверждение внешнего сервиса. Изменение поля в CRM может не изменить уже созданную накладную. Аналогично стоимость доставки и дополнительные услуги могут пересчитываться отдельно. После правки сопоставьте согласованный адрес с тем, который видит сборка и перевозчик.

Возврат недоставленного заказа

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

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

Отмена и возврат: четыре проверки вместо одного статуса

При отказе клиента проверьте товар, деньги, доставку и документы. Если заказ только создан, действий может быть немного; если отгружен и оплачен — обязательств больше. Общее состояние «отменён» удобно для списка, но не доказывает завершение всех связанных операций. Для каждого незавершённого действия нужны владелец и способ подтверждения результата.

Официальная инструкция связки с Frontol описывает возврат относительно исходной продажи, а возврат денег выполняется кассой, терминалом или провайдером по конкретному порядку. Эти особенности нельзя приписывать любой кассовой интеграции. Выясните, какое действие инициируется из CRM, какое выполняется отдельно и откуда приходит подтверждение, прежде чем обещать персоналу возврат «одной кнопкой».

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

Контроль обмена и ручные исключения

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

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

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

Сверка после окончания рабочего дня

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

Пилот обработки заказа

1. Подготовьте контрольный заказ с устойчивыми идентификаторами и ожидаемыми результатами по товару, деньгам и доставке.
2. Проверьте входящий обмен и повторную передачу той же записи без создания дубля.
3. Испытайте резерв и изменение состава в конкретной складской связке.
4. Сопоставьте обычную и частичную оплату с внешним подтверждением, включая задержку уведомления.
5. Создайте доставку, измените допустимое поле и проверьте результат у перевозчика.
6. Выполните разрешённый сценарий отмены или возврата и подтвердите каждую зависимую операцию отдельно.
7. Передайте проблемный заказ другому сотруднику: он должен восстановить состояние и следующее действие без устного пересказа.

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

Вопросы о заказах в RetailCRM

Официальные источники

Настройки доставки описаны в документации типов доставки, конкретный резерв — в настройке коннектора МойСклад, возвраты — в инструкции Frontol. Примеры относятся к указанным связкам и не подтверждают универсальную совместимость RetailCRM со всеми внешними системами.