WP: вебхуки доставки СДЭК, Boxberry, Почта России — все статусы и уведомления

Клиент звонит, посылка молчит, менеджер горит

Ближе к вечеру телефон в отделе поддержки превращается в будильник на нервной почве: где моя посылка, она уже в пункте, а мне никто не пишет, на сайте висит какой-то старый статус, а курьер сказал одно, трекер показывает другое. Кто работал с доставкой в России, тот знает этот теплый ламповый хаос. И ведь обидно, когда магазин на WordPress вроде работает, WooCommerce считает, чек выбивается, а дальше начинается ручной танец с бубном. Менеджер копипастит трек-номера, бегает по кабинетам СДЭК, Boxberry и Почты России, и все это ради того, чтобы поставить заказу всего один простой статус. А клиенты у нас хорошие, но терпение у людей конечное, и если уведомления не приходят вовремя, начинается тот самый концерт заявок, который сжигает день. Я однажды поймал себя на том, что успокаиваю покупателя, параллельно обновляю три вкладки трекинга и печатаю номер на бумажке, чтобы не потерять, и понял — нужно сделать так, чтобы система говорила первой. Доставки дают статусы, WordPress умеет их хранить, а make.com связывает одно с другим без истерик. С этого и начнем, пока не поздно. Да, и кофе лучше налить сразу — пригодится.

Что такое вебхуки статусов доставки и почему магазину на WP они экономят нервы

Службы доставки вменяемые и вполне современные, просто у каждой свои привычки и форматы. СДЭК, Boxberry и Почта России предоставляют API, из которых можно получать свежие статусы отправлений, а дальше уже дело техники — принять эти данные, распарсить и обновить заказ в WooCommerce. В идеальном мире все три сервиса присылают уведомления сами, но иногда нужна периодическая проверка по расписанию, это нормально и решается на одном сценарии. Вебхук в контексте доставки — это как смс от курьера, только для вашей системы: пришел статус, мы сохранили, клиент узнал, все довольны. WordPress можно подключить через REST API, вебхуки плагинов или собственный обработчик — важнее согласовать единый словарь событий, чтобы не плодить зоопарк типов. Заказу нужен набор полей — трек-номер, код перевозчика, статус, дата, место, причина — а самому магазину нужны три простые вещи: обновить статус, оставить заметку, уведомить клиента. Когда эти кирпичики становятся на место, жизнь выравнивается и поддержка больше не живет в трекерах. Есть один нюанс — аккуратно с кириллицей и часовыми поясами, иначе чудес с датами будет больше, чем хотелось бы.

Как это бежит по проводу в make.com — путь события от перевозчика до статуса заказа

В сценарии все начинается с входящего вебхука — модуль принимает JSON от службы доставки или от вашего промежуточного обработчика. Дальше идет блок разветвления по перевозчику, потому что у СДЭК и Boxberry формат полей и названия статусов различаются, а Почта России любит подробные коды с уточнениями. Ветвь приводит событие к единому виду — например, status_code, status_text, location, datetime, track, internal_order — и тут же добавляет idempotency ключ, чтобы задвоения не заводили хаос. Затем выполняется поиск заказа в WooCommerce — кто-то ищет по мета полю _tracking_number, кто-то по номеру заказа, который изначально отправлялся перевозчику в reference, оба пути работают. Обновление в WooCommerce можно делать через REST V3 на эндпоинт заказа, а для заметок использовать order notes, чтобы история шла ниткой и была видна менеджеру. Уведомления клиенту уходят в тот канал, который вам ближе — письмо, SMS, мессенджер, или даже бот в Telegram, если хотите современности без позерства. На финише сценарий записывает событие в отдельный лог — хоть в Google Sheets, хоть в таблицу в БД — чтобы спорные ситуации закрывались одной строкой истории.

СДЭК, Boxberry, Почта России — характеры разные, результат один

СДЭК обычно дает понятные коды статусов и моментально их обновляет, так что нотификации бегут быстро и внятно, особенно когда вы отправляете им номер заказа как reference и потом просто ловите его обратно. Boxberry аккуратная, но иногда присылает статусы для ПВЗ с подробностями по адресу — проверьте, как вы храните код пункта выдачи, пригодится для сообщений клиенту. Почта России детальна до боли, там и сортировки, и прибытия, и попытки вручения, и отложенная выдача — лучше заранее составить таблицу соответствий ваших клиентских статусов и их транспортных кодов, иначе превратите кабинет менеджера в бургер из статусов. Полезно договориться о нескольких ключевых состояниях — создано, в пути, на выдаче, выдано, возврат — и остальное прокидывать в заметки, чтобы не перегружать карточку заказа. Если у вас наложенный платеж, добавляйте флаг COD и не забудьте про событие money_received — бухгалтер улыбнется, а вы перестанете искать деньги в письмах. Разницу между событиями по отправлениям и по заказам удобнее сгладить через трансформацию в make.com, пусть там и живет ваша мини-правда. И да, тестовые отправления очень выручают — одна бандероль в демо и день настроек экономят неделю нервов позже.

Куда в WordPress складывать статусы и как уведомлять клиента без спама

Самый чистый способ — свой метабокс с технической историей и отображение краткого статуса в шапке заказа, чтобы менеджер видел с первого экрана, а клиент получал только понятные сообщения. Если вы используете кастомные статусы WooCommerce, свяжите их с ключевыми состояниями доставки, а дополнительные нюансы вроде задержки на сортировке пишите в примечание, не грузите этим покупателя. Обновление делайте транзакционно — сначала запись в мета, затем заметка, затем смена статуса, затем уведомление — чтобы при падении интернета не ушло половина данных. Для связи по API включите в WordPress постоянные ключи и ограничьте права только заказами, без админских полномочий, иначе одна ошибка даст слишком широкую дверь в систему. Хорошо работает страница отслеживания для клиента на вашем домене — по номеру заказа и почтовому индексу или телефону — а под капотом она просто читает вашу же историю из меты. Отдельная радость — автоматические уведомления в Telegram менеджеру при возврате или при застревании посылки дольше N часов в одном статусе, это не шум, это реальная экономия времени. Чтобы не превратить почту клиента в ёлку, группируйте события и отправляйте их пачкой или с задержкой, если в течение 15 минут приходит серия мелких обновлений.

Цифры без занудства — где бизнес выигрывает

Когда статусы обновляются сами, падает чистый шум в поддержке, и это чувствуется буквально через неделю, потому что люди перестают звонить просто так. Время на обработку одного заказа сокращается не потому, что вы стали супергероем, а потому, что нет ручного копания в кабинетах и копипаста треков. Ошибка менеджера исчезает вместе с ручной рутиной — если система не просит нажать десять кнопок, нажимать нечего, а значит и промахиваться негде. На уровне маркетинга тоже приятная картина — клиенту не нужно объяснять, почему статус отстаёт, он его видит, и доверие к магазину растет без баннеров и кукушек. Руководитель спокойно смотрит на дашборд и видит сроки прохождения этапов, где тормозим, где узкая горлышко, где реально улучшить SLA, без догадок на кофейной гуще. А еще исчезают те странные ситуации, когда покупатель уже забрал заказ, а у вас он числится в пути и висит в отчете как проблема — статус выравнивается в день выдачи. Не обещаю чудес, просто убираем слабое место и получаем тихую, предсказуемую рутину, которую не стыдно показывать в понедельник утром.

Мелочи, которые спасают выходные

Одна из первых — нормализация часовых поясов, приводите все события к Москве и храните оригинал рядом, чтобы в спорах всегда было от чего оттолкнуться. Вторая — idempotency, не устану повторять, одинаковые события должны аккуратно поглощаться, иначе история превратится в эхо. Третья — понятные человеку тексты, не надо шифровок, если посылка на выдаче в ПВЗ, так и пишите с адресом пункта, клиенту от этого проще. Четвертая — карты соответствий, держите JSON с маппингом кодов статусов у себя в репозитории и меняйте его без правки сценария, это бережет время. Пятая — fallback опрос по расписанию на случай, если у перевозчика вебхуки капризничают, ночью пусть скрипт проверит зависшие отправления и подтянет реальность. Шестая — логирование в отдельное место, где легко искать, таблица в Google Sheets с фильтрами творит чудеса для разборов. Седьмая — тесты в песочнице, не гоните сразу на прод, аккаунты у перевозчиков позволяют играть в пробный теннис без боли и возвратов. Восьмая — не забывайте про русские фамилии и спецсимволы, аккуратно кодируйте строки, иначе вдруг в заметке вместо города будет зоопарк символов, и никто потом не улыбнется.

Короткая история, как это взлетело в живом магазине

У ребят был WooCommerce, две доставки — СДЭК и Boxberry — и пара менеджеров, которые успевали, пока заказы были средними. Потом сезон, и поехало — до ста отправлений в день, телефоны вспухли, клиенты злые, статусы стареют. Сделали сценарий на make.com, приняли вебхуки, для Boxberry включили ночной опрос, потому что их уведомления не всегда доходили, и все привели к единой схеме. Заказ стал показывать в шапке нормальный короткий статус, а заметки аккуратно писали историю с датами и городами, плюс ушел бот менеджера в Telegram на возвраты. Через несколько дней у поддержки стало тихо, а руководитель наконец-то увидел среднее время доставки до ПВЗ и понял, где клинит. Удивительного в истории мало, просто вместо хаоса пришла скучная автоматика, и всем от этого стало чуть легче дышать. Потом они добавили Почту России для части заказов и даже не вздрогнули — маппинг уже лежал, сценарий просто расширили веткой. Да, было пару дней отладки дат, но после правки часового пояса все стало ровно и предсказуемо.

Как стартануть сегодня вечером и не утонуть завтра

Соберите ключи и доступы — API перевозчиков, доступ к WordPress, токены WooCommerce, и заведите тестовые отправления, чтобы гонять статусы, не трогая живых клиентов. В make.com создайте входящий вебхук, примите первое событие, посмотрите реальный JSON и сразу зафиксируйте маппинг полей. Сделайте преобразование в единый формат, добавьте поиск заказа по треку, обновление статуса и заметку, и не забудьте про лог в отдельное хранилище. Настройте мягкие уведомления клиенту — лучше суммарные и понятные, чем десять писем подряд, пусть система немного подождет и отправит одно-двухстрочное резюме. Прогоните весь путь на тестовом заказе, включите отложенный опрос по ночам на случай, если какой-то перевозчик сегодня не в настроении. Когда все заработало, дайте менеджерам страницу истории, чтобы они видели то же, что у клиента, и могли ответить быстро и без фантазии. А потом просто не трогайте — автоматика любит тишину, максимум раз в месяц поправите словарь статусов, и будет вам спокойный график.

Где поучиться и не сломать мозг

Если хочется сделать не только доставку, но и весь магазин чуть более автоматизированным, приходите за материалами и живыми разборами, это экономит нервы и время. Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей — Подпишитесь на наш Telegram-канал, там регулярно разбираем сценарии и делимся шаблонами. Для системной прокачки есть аккуратный курс с практикой — Обучение по make.com — и готовые сценарии, которые встают за вечер — Блюпринты по make.com. Если только начинаете, регистрируйтесь в make.com, берите тестовый тариф и гоняйте свои первые вебхуки, это лучший способ понять, как все складывается. Ну и если что-то пойдет не туда, пишите, разберем спокойно, без танцев с бубном и криков в ночи. Автоматизация должна быть скучной, иначе она не работает.

Ссылки на официальные спецификации

Документация СДЭК живет здесь: https://cdek.ru/ru/services/api, и там удобно смотреть коды статусов и форматы полей. Boxberry описывает методы и параметры тут: https://boxberry.ru/api, пригодится карта ПВЗ и статусов выдачи. Почта России дает спецификацию сервиса Отправка на этой странице: https://otpravka.pochta.ru/specification, где есть трекинг и события. Поддержку автоматизации и сценариев берите в make.com — регистрации достаточно, чтобы начать собирать рабочие цепочки без программистских подвигов.

FAQ

Вебхуки приходят от всех перевозчиков или нужно опрашивать по расписанию

Зависит от настроек конкретного кабинета и типа интеграции. Если у перевозчика подключена отправка уведомлений, то события можно ловить сразу во входящий вебхук, и это самый быстрый путь. Если вебхуков нет или они приходят не для всех операций, добавляйте опрос по расписанию и подтягивайте статусы раз в N минут, это нормально и хорошо работает ночью. В сценарии спокойно уживаются оба подхода, главное — не плодить дубликаты, используйте ключ уникальности и аккуратный маппинг.

Как сопоставлять событие доставки и заказ в WooCommerce, если в уведомлении нет номера заказа

Обычно в доставку передают reference — собственный номер, и он же возвращается в событии. Если его нет, используйте трек-номер и храните его в мета поля заказа, например _tracking_number, чтобы быстро находить запись. При сложных схемах добавляйте таблицу соответствия отправлений и позиций заказа, это полезно, если один заказ разбивается на несколько отправок. В крайнем случае можно искать по телефону и индексу, но это уже запасной выход, лучше все же передавать reference с первого дня.

Какие статусы стоит показывать клиенту, а какие оставлять только в заметках

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

Что с безопасностью при приеме вебхуков в WordPress

Принимайте вебхуки в make.com, проверяйте подписи и источники, а в WordPress заходите только по REST с минимальными правами. Не давайте сценариям админские ключи, используйте отдельного пользователя с правами на чтение и обновление заказов. Логи храните отдельно, чтобы можно было быстро найти событие без доступа к базе. И не забывайте про часовые пояса, это тоже часть аккуратной истории событий.

Можно ли уведомлять клиента через Telegram и не нарушать привычную почту

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

Сколько времени занимает первичная настройка с нуля

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

Что делать, если магазин работает не только с WooCommerce

Ничего страшного, принцип тот же — любое хранилище заказов, куда можно зайти по API, подойдет, просто меняется конечная точка обновления. Если есть Bitrix или самописный бэкенд, используйте тот же единый формат событий и подпирайте его логом. Главное — не размножать логику по разным местам, держите маппинг и правила в одном сценарии. Тогда перенос и расширение будут стоить минимальных усилий.

Если хочется пойти дальше и собрать автоматизацию без лишней боли, здесь у нас практикум и готовые решения: Обучение по make.com и Блюпринты по make.com. А ежедневные заметки, разборы и советы живут тут — Telegram-канал. Регистрация в сервисе для старта здесь — make.com.