Введение
Каждый владелец небольшого магазина знает это сообщение: "Где мой заказ?" Обычно оно приходит тогда, когда ничего плохого не случилось: посылка собрана, упакована и уже у курьера. Статусы заказа в интернет-магазине - это короткие и понятные подписи, которые отвечают на этот вопрос ещё до того, как покупатель его задаст. А если вопрос всё-таки прозвучал, это проблема статусов, а не логистики.
Мы разрабатываем и поддерживаем интернет-магазины, и чаще всего нас просят добавить побольше статусов. Обычно мы советуем обратное. Статусы нужны, чтобы ответить покупателю раньше, чем он спросит, и каждый лишний статус, который вы ему показываете, порождает новый вопрос - отвечать на него потом кому-то придётся по телефону. Небольшому магазину хватает четырёх-пяти статусов для покупателя, привязанных к реальным этапам заказа, а всё остальное остаётся в админке.
Ниже разберём четыре этапа, через которые на самом деле проходит каждый заказ, границу между тем, что видит покупатель, и тем, что остаётся внутри, правила названий, настройку цепочки в админке и ошибки, которые мы встречаем на реальных проектах.
Почему цепочки статусов разваливаются в небольших магазинах
Цепочки статусов ломаются по трём причинам, которые мы видим снова и снова: статус не меняют вовремя, названия ничего не говорят покупателю, и об изменении ему не сообщают. Все три - проблемы процесса, а не программы, поэтому переезд на другую админку почти никогда их не решает.
Магазины приходят к нам с просьбой добавить статусов. На деле им нужно меньше статусов и понятное правило, кто какой из них меняет. Прежде чем трогать настройки, мы просим владельца вспомнить три последних разговора в духе "где мой заказ". Ответы каждый раз попадают в одни и те же три корзины, и ниша здесь роли не играет: те же три причины мы слышим и от магазина товаров для дома, и от проектов, которые выросли из разработки сайтов для салонов красоты.
- Статус отстаёт от реальности. Посылка уехала со склада вчера, а в заказе до сих пор написано, что его собирают. Покупатель заходит на страницу отслеживания курьерской службы, видит движение посылки и теперь доверяет курьеру больше, чем магазину.
- Название ничего не значит. "В обработке", "В работе", "Статус 3" - ни одно из них не говорит покупателю, ждать ему, доплатить или взять телефон. Статус, который приходится объяснять, - это будущий звонок в поддержку.
- Ничего не отправлено. Менеджер поменял статус в админке, покупателю об этом не сказали, и изменения как будто не было. Магазин сделал работу и не получил за неё никакого зачёта.
Небольшому магазину эти три ошибки обходятся дороже, чем крупному. Отдела поддержки, который примет вопросы на себя, нет, поэтому владелец берёт трубку сам - обычно вечером и обычно из-за заказа, с которым всё в полном порядке. Исследования юзабилити про индикаторы прогресса в интерфейсах говорят то же самое об ожидании вообще: человек переносит ожидание гораздо легче, когда видит, где он в нём находится, и гораздо хуже - когда на экране об этом нет ни слова.
Смена ракурса, которая лечит все три причины, лежит в основе остальной части статьи. Проектируйте цепочку от того, что должен знать покупатель, и уже потом накладывайте на неё внутреннюю работу: что произошло на складе, какому статусу это соответствует, что об этом говорят покупателю - именно в таком порядке.
Четыре этапа, через которые проходит каждый заказ
Любой заказ в небольшом магазине проходит одни и те же четыре этапа заказа: корзина, оплата, склад и доставка. Отмена и возврат - не пятый этап, а выходы, которые возможны с любого из четырёх. Вся конструкция статусов вырастает из этих этапов, потому что статус - это просто название точки на этом пути.
Корзина и оформление заказа
На этом шаге заказ уже есть в вашей системе, но ничего ещё не зафиксировано: деньги не двигались, товар не отложен. Покупателю здесь нужно одно - подтверждение, что заказ вообще дошёл. Магазин, который молчит первые десять минут после оформления, получает своё первое сообщение за день именно здесь.
Оплата
Предоплата и оплата при получении дают разные цепочки, и именно здесь большинство магазинов копирует шаблон, который им не подходит. При предоплате покупатель действительно чего-то ждёт и заслуживает отдельный статус. При оплате при получении деньги отдают курьеру, поэтому оплата - не этап ожидания, и статус про оплату превращается здесь в подпись, которую никто не читает.
Склад и сборка
Складской этап создаёт больше всего внутреннего шума. Товар резервируют, наличие сверяют с полкой, заказ собирают, потом упаковывают, потом он ждёт курьера. Сборка здесь - это просто снятие товаров одного заказа с полок. Именно на этом этапе сильнее всего тянет показать покупателю каждый подстатус, и именно здесь это вредит больше всего.
Доставка
Доставка включает передачу курьеру, посылку в пути и момент вручения. Граница важна: как только посылка у перевозчика, магазину стоит отправлять покупателя на его собственное отслеживание, а не дублировать его плохо и с опозданием на несколько часов. Словарь ParcelDelivery на schema.org смотрит на отправление так же - как на отдельный объект с номером отслеживания и ссылкой на трекинг. Эту же разметку читают поисковые системы и ассистенты, когда покупатель спрашивает у них, где его посылка, поэтому мы относим её к продвижению в AI, а не к техническим мелочам.
Отмена и возврат
Заказ может сойти с пути на любом этапе: до оплаты, после сборки или через неделю после доставки. Общее у этих выходов одно: настоящий вопрос покупателя перестаёт быть про посылку и становится про деньги. Любая отмена или возврат, где ничего не сказано про возврат денег, оставляет самый важный вопрос открытым.
Что видит покупатель и что остаётся внутри
Покажите покупателю четыре-пять статусов, остальное держите в админке. Проверка простая: если после прочтения статуса покупатель не может сделать ничего иначе, показывать этот статус ему не нужно. Поэтому статус доставки со ссылкой на отслеживание перевозчика своё место оправдывает, а подстатус сборки - нет.
Для небольшого магазина, который продаёт, скажем, товары для дома с одного склада и одной курьерской службой, видимая покупателю цепочка у нас выглядела бы так:
- Заказ принят - мы его получили, от вас пока ничего не требуется.
- Оплачен - деньги пришли, заказ окончательно встал в очередь.
- Готовим к отправке - склад занимается заказом.
- В пути - посылка у курьера, вот ссылка для отслеживания.
- Доставлен - закрыт, со сроком возврата в тексте.
- Отменён и Деньги возвращены - два выхода, всегда в паре с состоянием денег.
Всё остальное живёт в админке и никогда не попадает в письмо: товар зарезервирован, проверка оплаты, ждём поставщика, собран, упакован, ждём забора курьером, доставка не удалась. Это подстатусы, то есть внутренние состояния, которые нужны вашей команде для работы и не несут покупателю никакой инструкции. Словарь статусов заказа, который читают поисковые системы, специально сделан коротким по той же причине: в нём горстка состояний - ожидает оплаты, в обработке, в пути, доставлен, проблема и возвращён. Держать видимую цепочку близко к этому короткому списку - ещё и одно из самых дешёвых вложений в сео продвижение сайтов в Москве: это словарь, который поисковики уже понимают.
Здесь мы расходимся со школой "радикальной прозрачности", которая показывает покупателю каждый внутренний шаг. Механику легко упустить: каждый видимый статус - это неявное обещание по срокам. "Ждём поставщика" сообщает покупателю, что что-то не так, и одновременно не даёт ему никакой возможности на это повлиять, поэтому он пишет вам, чтобы выяснить, насколько всё плохо. Исключение, которое стоит сделать, - настоящая задержка, и правильная форма для неё - датированное сообщение по конкретному заказу, а не новое постоянное звено в цепочке.
Есть упражнение на десять минут. Выпишите все внутренние состояния, которыми пользуется команда, и рядом с каждым напишите фразу, которую покупатель отправит вам, увидев его. Если полезной фразы нет, состояние остаётся внутренним.
Как называть статусы, чтобы никто не гадал
Хорошее название статуса говорит, что произошло, и там, где это важно, что покупателю делать дальше. Пишите названия короткими фразами на языке покупателя, а не ярлыками, взятыми из складского процесса: вашего склада покупатель никогда не видел.
Пять правил закрывают почти все случаи:
- Используйте словарь покупателя. Он знает отправку и доставку. Он не знает сборку, резервы и фулфилмент.
- Говорите, что произошло, а не какая система это сделала. Покупателю не нужно знать, что платёжный шлюз синхронизировался с вашей учётной системой; ему нужно знать, что он ничего больше не должен.
- Никогда не нумеруйте статусы. "Статус 3" - это внутренний код, который сбежал в почтовый ящик покупателя.
- Держите одно время и один залог во всей цепочке, чтобы последовательность читалась как последовательность, а не как шесть несвязанных подписей.
- Делайте названия достаточно короткими, чтобы они пережили SMS и узкую колонку статуса в списке заказов.
| Избегайте | Используйте вместо этого | Почему |
|---|---|---|
| Статус 3 | Заказ принят | Номер не говорит покупателю о его заказе ничего. |
| В обработке | Оплачен | "В обработке" покрывает половину цепочки, поэтому никогда не отвечает на настоящий вопрос. |
| Собран | Готовим к отправке | Сборка - складское слово; покупатель ждёт отправку. |
| Передан в логистику | В пути | Называет ваш отдел вместо события, которое важно покупателю. |
| Закрыт | Доставлен | "Закрыт" описывает конец вашего процесса, а не приезд посылки. |
| Отменён | Отменён, деньги возвращаем | После отмены вопрос покупателя - про деньги. |
Если магазин работает на нескольких языках, пишите названия статусов заново на каждом языке, а не переводите английские слово в слово. Подпись, которая естественно звучит по-английски, в другом языке легко превращается в сухой канцелярит, а покупатель, споткнувшийся о формулировку, напишет вам именно об этом.
Как настроить статусы в админке
Обработка заказа сводится к трём решениям: какие статусы есть, кому разрешено менять каждый из них и что говорят покупателю при изменении. Если эти три решения приняты правильно, инструмент почти не важен - любая приличная админка умеет их выразить. А если не умеет, это и есть тот момент, когда разработка сайтов в Москве окупается быстрее, чем ещё год обходных путей.
Начните со списка заказов: это тот экран, в котором живёт ваш менеджер. С одного взгляда там должны читаться номер заказа, покупатель, текущий статус, сумма и дата, а цвет должен отделять заказы, требующие внимания, от тех, что идут своим ходом. Если менеджеру приходится открывать заказ, чтобы понять, нужен ли он ему сегодня, список не выполняет свою работу. Это тот экран, которым стоит заняться вместе с дизайном сайта: сэкономленный час в день достаётся вашему менеджеру.
Кто и когда меняет статус
У каждого перехода должен быть ровно один владелец. Склад переключает складские статусы, статусы доставки переключает тот, кто занимается передачей курьеру или интеграцией со службой доставки, и никто не меняет статус ради того, чтобы список выглядел опрятно. Общая ответственность - это как раз тот случай, когда заказ помечает отправленным менеджер, решивший, что склад уже всё сделал.
Правило, на котором мы настаиваем в каждом магазине: статус меняется в момент, когда произошло физическое событие, а не в конце смены. Складывать обновления статусов в один вечерний заход - самая частая причина того отставания, о котором шла речь выше, и исправляется она бесплатно, одной привычкой.
Уведомления на каждое видимое изменение
У каждого видимого покупателю статуса ровно одно сообщение. У каждого внутреннего - ни одного. Канал выбирайте под статус, а не под всю цепочку: письмо подходит тем статусам, к которым покупатель может захотеть вернуться позже, - подтверждению заказа и возврату денег, а SMS или мессенджер - срочным, вроде приезда курьера завтра. Это то же разделение каналов, которым мы пользуемся в интернет-маркетинге в Москве: канал выбирается под срочность сообщения, а не наоборот.
В каждом сообщении должны быть четыре вещи: номер заказа, что именно произошло, что будет дальше и куда смотреть или кого спросить. Сообщение, которое рассказывает об изменении, но молчит о том, что за ним последует, просто переносит вопрос из одного канала в другой.
Как держать цепочку в порядке со временем
Пересматривайте список статусов, когда меняется процесс, а не когда взрывается нагрузка на поддержку. Новый склад, смена курьерской службы или появление пунктов выдачи меняют то, что нужно сообщать покупателю. Убирайте статусы, которыми никто не пользуется, вместо того чтобы оставлять их в выпадающем списке: однажды занятым утром менеджер выберет такой по ошибке.
Ошибки, с которыми мы сталкиваемся постоянно
Дорогие ошибки не экзотические. Устаревшие статусы, их избыток, молчаливые изменения и тупик после неудачной доставки объясняют почти все сообщения "где мой заказ", которые получает небольшой магазин. Каждую из пяти ниже нам приходилось распутывать на живом проекте.
- Статус обновляется на день позже. Покупатель узнаёт новости от курьера первым и делает вывод, что магазин потерял заказ из виду. Привязывайте изменение к событию, а не к концу смены.
- Пятнадцать статусов в выпадающем списке. Менеджеры выбирают не тот, два из них означают примерно одно и то же, и цепочка перестаёт значить хоть что-нибудь. Сократите до пяти видимых, остальное уберите во внутренние пометки.
- Статус изменился, и никому об этом не сказали. Работа сделана, а покупатель получил тишину. Ни один видимый покупателю статус не должен уходить в работу без прикреплённого сообщения.
- "Отменён" без единого слова про деньги. Настоящий вопрос покупателя - про возврат денег, а не про посылку. Продавцов в США правило FTC о торговле по почте, через интернет и по телефону прямо обязывает сообщать покупателям о задержках отправки и предлагать возврат денег, так что связка отмены с состоянием возврата - это и хорошая практика, и, на некоторых рынках, обязанность.
- Неудачная попытка доставки - тупик. Дома никого не было, курьер увёз посылку обратно, и ни один статус этого не описывает, поэтому заказ зависает, а покупатель ждёт. Дайте исключению собственный статус и понятное действие для покупателя.
Диагностика, которой пользуемся мы, занимает минуту. Прочитайте свою цепочку глазами покупателя, который оплатил заказ и три дня ничего не слышал, и найдите статус, который ему отвечает. Если такого статуса нет, именно его и надо добавить - и обычно он единственный, который вам нужен.
Заключение
Статусы заказа в интернет-магазине работают лучше всего, когда вы сначала строите цепочку, которую видит покупатель, а уже потом накладываете на неё внутреннюю работу. Почти всё, с чем сталкивается небольшой магазин, закрывается пятью решениями:
- Каждый заказ несут четыре реальных этапа: корзина, оплата, склад и доставка. Отмена и возврат - это выходы, а не этапы.
- Покупателю показаны четыре-пять статусов. Всё остальное остаётся в админке, где ему и место.
- Название статуса говорит, что произошло и что делать дальше, словами покупателя, а не склада.
- У каждого перехода один владелец, и изменение фиксируется в момент события, а не в конце дня.
- Каждое видимое изменение отправляет ровно одно сообщение: номер заказа, событие, что будет дальше и куда задать вопрос.
Пришлите нам список статусов, с которым вы работаете сегодня, и мы разберём его вместе с вами, этап за этапом, и покажем, какие статусы оправдывают своё место, а какие генерируют ваши звонки в поддержку.