Заказ может быть оплачен, но ещё не собран. Может ждать согласования доставки или требовать проверки платежа. Когда все эти ситуации называют одним статусом, сотрудникам трудно понять следующий шаг. Состояния сайта нужно связать с реальным процессом магазина и отделить от внешних состояний оплаты и доставки.
Сначала опишите действия отдела продаж
Запишите путь обычного заказа: принят, проверен, оплачен, подготовлен, передан покупателю. Отдельно перечислите исключения: отсутствует позиция, клиент просит изменение, платёж не подтверждён, заказ отменён. Это рабочая схема, которую затем сопоставляют с возможностями системы.
Не добавляйте новый статус для каждого комментария менеджера. Статус должен влиять на понятное действие, отчёт или доступную операцию. Частные подробности можно хранить в согласованных полях и истории.
Разберитесь в штатных состояниях
В стандартной логике WooCommerce ожидание оплаты, обработка и завершение имеют разные назначения. Обработка обычно связана с полученной оплатой и ожиданием выполнения, но конкретный маршрут зависит от типа товара и платёжного способа. Не применяйте одно правило без проверки к физическим, виртуальным и скачиваемым товарам.
| Рабочий вопрос | Какие сведения нужны |
|---|---|
| Деньги подтверждены | Состояние связанной платёжной операции |
| Можно начинать сборку | Решение по составу и условиям заказа |
| Товар отправлен | Подтверждённое событие доставки |
| Заказ завершён | Согласованный критерий окончания работы |
| Нужен возврат | Отдельная операция и её результат |
Служебный статус черновика в блочном оформлении не следует считать готовым обращением покупателя. Для передачи в CRM определите момент принятия заказа. Иначе отдел продаж может получать незавершённые записи вместе с настоящими заявками.
Согласуйте переходы и ответственность
Для каждого изменения определите, кто его выполняет: платёжный модуль, сотрудник, склад или внешняя система. Укажите допустимые предыдущие состояния и дополнительные проверки. Случайное событие не должно перескакивать через необходимые этапы.
Если клиент меняет состав после оплаты, согласуйте обработку разницы. Перевод заказа обратно в ожидание не решает вопрос денег. Аналогично отмена доставки не означает автоматическую отмену платежа. Эти связи требуют собственных правил.
Проверьте последствия изменения статуса
Смена состояния может запускать письмо, изменение остатков или внешнюю передачу. Перед добавлением новой логики выясните уже существующие действия. Два расширения могут реагировать на одно событие и отправлять повторные уведомления.
Проверьте ручное и автоматическое изменение. Сотрудник может исправить состояние из админки, а интеграция позже прислать старое событие. Определите, какое изменение допустимо и когда случай требует сверки вместо тихого отката.
Отделите возврат денег от отметки заказа
Ручная отметка о возврате и выполненный возврат через провайдера не одно и то же. Способ обработки зависит от поддерживаемых возможностей платёжного модуля. Сотрудник должен понимать, требуется ли отдельное действие во внешнем кабинете и какое подтверждение сохраняется.
Частичный возврат также не обязательно означает отмену всего заказа. Уточните судьбу остальных позиций, доступа и документов. Не ограничивайте такую ситуацию одной общей галочкой без объяснения состава операции.
Сделайте состояния понятными для покупателя
Внутренний термин склада может быть лишним на публичной странице. Подготовьте понятное объяснение текущего этапа и доступного действия. Если нужен контакт, покажите его. Если информация задерживается, не выдавайте старое состояние за только что проверенное.
В QuickLanding можем описать маршрут заказа и сопоставить его с сайтом, оплатой и CRM. Для оценки нужны способы оплаты, типы товаров и действия сотрудников. Приёмка включает обычный заказ, изменение состава, повтор события и возврат, если он входит в процесс.
Документация и проверка сведений
Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.
Материалы по соседним задачам
Коротко о важном
Можно переименовать статусы без изменения логики?
Изменение названия не гарантирует изменение связанных действий. Проверьте письма, остатки и интеграции. Публичное объяснение и служебное состояние можно разделить, если это соответствует реализации.
Статус «возвращён» подтверждает движение денег?
Не всегда. Важен способ выполнения и подтверждение платёжной операции. Ручная отметка может только фиксировать решение сотрудника. Процесс возврата нужно проверять отдельно.
Нужно ли передавать в CRM каждый черновик заказа?
Обычно сначала определяют момент принятия покупателем или сайтом. Служебные черновики и завершённые обращения имеют разный смысл. Передача должна соответствовать работе менеджера и правилам защиты от дублей.
Разработка и SEO в QuickLanding. Помогаем разобраться в задаче и выбрать подходящий состав работ.
Об эксперте
