На чистой WooCommerce после установки заказы обрабатываются вручную: зашел в админку, посмотрел список, поменял статус, написал клиенту в мессенджер. Пока их 5-10 в день, схема работает. Когда счет переходит на 50-100 заказов в сутки, ручная обработка заказов в WooCommerce превращается в отдельную работу на полный день, а ошибки вроде забытого статуса, неотправленного трек-номера или дважды подтвержденной оплаты начинают стоить реальных денег. Я настраивал такие процессы для нескольких интернет-магазинов на WooCommerce и ниже разложил, из каких частей состоит нормальная обработка заказов и что автоматизировать в первую очередь.
По теме статьи
Готовое решение
Ограничение применения промокода в корзине Tilda
Промокод в Tilda не действует на выбранную категорию (например, «Распродажа»). Готовый скрипт + инструкция по подключению.
от6 000 ₽
Интернет-магазин
Интернет-магазин под ключ
Интернет-магазин под ключ — на Tilda, WordPress + WooCommerce, Next.js Commerce или кастомный бэкенд. Подберу платформу под бюджет, ассортимент и
от80 000 ₽
Статусы заказов WooCommerce и что с ними делать оператору
В базовой поставке у заказа семь статусов, и большинство проблем в магазине начинаются с того, что персонал меняет их как попало или вообще не понимает разницу между «В обработке» и «На удержании».
| Статус | Что означает | Действие оператора |
|---|---|---|
| Ожидает оплаты | Заказ создан, оплата не подтверждена | Ждать вебхук от платежной системы или отменить через 24 часа |
| На удержании | Оплата наличными или переводом, нужна ручная проверка | Проверить поступление денег и перевести в «В обработке» |
| В обработке | Оплата подтверждена, товар нужно собрать и отправить | Передать на склад, сформировать накладную, отдать в доставку |
| Выполнен | Товар передан покупателю | Сверить трек-номер и статус доставки с реальностью |
| Отменен | Покупатель или магазин отменили заказ | Вернуть товар на склад, если резервировали |
| Возврат средств | Деньги возвращены после отмены или брака | Сверить сумму возврата с банком, закрыть заявку |
| Не удался | Платеж не прошел или прервался | Не удалять, а анализировать причину сбоя |
Ошибка, которую я вижу чаще всего: статус «Не удался» воспринимают как мусор и чистят из базы раз в месяц. На деле по нему видно, где именно отваливается оплата: у одного банка эквайринг может резать платежи с мобильных операторов, у другого 3D-Secure не срабатывает на старых версиях браузеров. Если таких заказов больше 5% от общего числа, чаще всего дело не в клиентах, а в настройке платежного модуля.
Автоматизация обработки заказов через вебхуки и n8n
WooCommerce умеет отправлять вебхук на любое событие: создание заказа, смену статуса, обновление данных клиента. Дальше это можно завести в n8n и построить цепочку без единой строчки кода на PHP.
Рабочий сценарий, который я собирал для магазина с 300 плюс заказами в месяц: вебхук о новом заказе прилетает в n8n, там проверяется сумма и способ оплаты, заказ с наличными сразу уходит в Google Таблицу для склада, а данные покупателя уходят в CRM, развернутую на сервере в России. Отдельная ветка следит за статусом «Не удался» и через час автоматически отправляет клиенту письмо с предложением попробовать другой способ оплаты. Из 40 таких заказов в месяц около 12 удавалось спасти только за счет письма, отправленного вовремя.
Такие цепочки я собираю как часть настройки автоматизации бизнес-процессов на n8n, включая связку с CRM, доставкой и мессенджерами.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Синхронизация статусов оплаты: T‑Bank и WooCommerce
Официальный плагин T‑Bank для WooCommerce меняет статус заказа на «В обработке» после успешного вебхука об оплате. На практике заказ иногда так и остается в «Ожидает оплаты», хотя деньги списались, и вот где чаще всего искать причину.
- Вебхук от T‑Bank указывает на адрес с http вместо https, банк такие запросы не отправляет
- Сумма заказа с учетом скидки или купона не совпадает до копейки с суммой, пришедшей от банка
- Хостинг режет исходящие запросы банка по User-Agent или блокирует IP-адреса платежной системы через файрвол
- Заказ создан с валютой, отличной от рублей, а модуль настроен только на рубли
Проверить это можно логами: в T‑Bank в личном кабинете есть история вебхуков с кодами ответа, а в WooCommerce лог заказа с отметками о смене статуса. Если в кабинете банка вебхук ушел с кодом 200, а статус заказа не изменился, проблема почти всегда в самой WooCommerce или в конфликте с другим плагином, который перехватывает хук раньше нужного обработчика.
Заказы и доставка: интеграция WooCommerce с СДЭК
Второй по частоте затык в обработке заказов - передача данных в СДЭК. Схема, которая нормально работает в 2026 году: при переходе заказа в статус «В обработке» модуль автоматически создает заявку в СДЭК через API, получает номер накладной и трек-номер, записывает их в примечание к заказу и меняет статус на кастомный «Передан в доставку».
Кастомные статусы в WooCommerce добавляются через код или готовые плагины, и это то место, где стоит остановиться и не плодить статусы без нужды. Обычно достаточно трех дополнительных: «Передан в доставку», «В пути» и «Готов к выдаче». Больше десяти статусов в списке, и операторы начинают путаться, какой из них выбрать, а отчеты по воронке заказов превращаются в кашу.
Трек-номер стоит сразу пробрасывать клиенту в письмо или в Telegram, а не оставлять только в личном кабинете сайта, туда после покупки заходят единицы.
Уведомления клиентов о статусе заказа через Telegram
Email-уведомления WooCommerce читают плохо: письма падают в спам, а клиенты в 2026 году привыкли получать статус заказа в мессенджере. Рабочая связка - бот на aiogram, который подписан на тот же вебхук о смене статуса заказа и рассылает короткое сообщение: заказ принят, оплачен, передан в доставку, трек-номер такой-то.
Для магазина с активным Telegram-каналом это снижает число обращений в поддержку с вопросом «где мой заказ» примерно вдвое, потому что клиент видит статус сам, без звонка менеджеру. Плюс бот берет на себя рассылку по брошенным корзинам и заказам со статусом «Не удался», о которых я писал выше.
Частые ошибки в обработке заказов WooCommerce
За несколько лет работы с разными магазинами на WooCommerce я собрал список ошибок, которые встречаются почти у всех.
- Статусы меняют вручную без единого регламента: один оператор переводит заказ в «Выполнен» сразу после отправки, другой - только после подтверждения от покупателя
- Нет SLA по времени на каждый статус, поэтому заказ может неделю висеть «В обработке», и никто это не замечает, пока клиент не напишет сам
- Заказы со статусом «Не удался» просто игнорируют, хотя по ним видно проблему с оплатой
- Каталог кастомных статусов растет бесконтрольно, потому что каждый новый плагин добавляет свой
- Данные клиентов из заказов выгружают в зарубежные таблицы и сервисы вместо серверов на территории России, что прямо противоречит требованиям 152-ФЗ о локализации персональных данных
Каждая из этих ошибок по отдельности не критична, но вместе они превращают обработку заказов в источник постоянных мелких потерь: несколько отмененных заказов в неделю, пара недовольных отзывов в месяц, лишний час работы оператора на разбор путаницы.
Как выстроить обработку заказов с нуля
Если магазин только запускается или процесс уже разъехался по швам, порядок действий такой.
Выписать реальный путь заказа
От создания до выдачи, с указанием, кто и когда меняет статус. Обычно на бумаге это занимает пять минут, но именно на этом шаге вскрываются нестыковки вроде того, кто проверяет оплату наличными, если менеджер в отпуске.
Свести статусы к минимуму
Стандартных семи плюс двух-трех кастомных под доставку обычно хватает любому магазину до нескольких тысяч заказов в месяц.
Автоматизировать смену статусов по вебхукам
Оплата, доставка и уведомления клиенту не должны зависеть от того, вспомнил оператор нажать кнопку или нет.
Завести логи и алерты на нештатные ситуации
Заказ, застрявший в одном статусе дольше суток, должен сам прилетать ответственному в Telegram, а не находиться руками при разборе жалоб.
Полное внедрение такой схемы для среднего интернет-магазина под ключ обычно укладывается в разработку от 80 000 ₽, а точечная автоматизация уже существующего магазина на WooCommerce чаще стоит дешевле, потому что не требует переделки каталога и оформления заказа.
Частые вопросы
Сколько кастомных статусов заказов стоит добавлять в WooCommerce
На практике достаточно двух-трех сверх стандартных семи, обычно под этапы доставки. Больше десяти статусов усложняют отчетность и путают операторов, которые не успевают запомнить разницу между похожими вариантами.
Почему заказ висит в статусе «Ожидает оплаты», хотя деньги списались
Чаще всего вебхук от платежной системы не долетел до сайта: неправильный адрес обработчика, конфликт с другим плагином или блокировка запроса на уровне хостинга. Проверяется по логам вебхуков в личном кабинете банка и по логу заказа в WooCommerce.
Нужно ли хранить данные покупателей из заказов в Google Таблицах для удобства склада
Персональные данные клиентов, такие как имя, телефон и адрес, стоит хранить только на серверах, расположенных в России, это требование 152-ФЗ о локализации персональных данных. Для внутренней отчетности склада без привязки к конкретному покупателю таблицы допустимы, но само хранение контактов клиента лучше вести в CRM на российском сервере.
Что делать с заказами в статусе «Не удался»
Не удалять и не игнорировать. Такие заказы стоит анализировать: если их доля выше 5% от общего числа, вероятная причина в настройке эквайринга или в конфликте плагинов, а не в самих покупателях. Части клиентов можно вернуть автоматическим письмом с предложением оплатить другим способом.