Начните с событий и ответственности. Основной этап показывает место заказа в процессе, отдельные состояния — оплату и доставку, причина блокировки и задача — что требуется сделать дальше.
Почему список статусов ещё не управляет заказами
В магазине установили CRM, загрузили заказы и выдали сотрудникам доступ. Но руководитель по-прежнему спрашивает в чате: «Это уже собрали? А покупатель оплатил?» Обычно проблема начинается раньше автоматизации: команда не договорилась, какое событие означает переход между этапами.
Я начинаю со схемы реального заказа. Что магазин обещал покупателю, кто сейчас выполняет работу, что мешает следующему шагу? Статусы должны помогать отвечать на эти вопросы. Название «В работе» подходит только тогда, когда за ним стоит один определённый процесс. Если там одновременно лежат неподтверждённые, собранные и неоплаченные заказы, управлять такой очередью трудно.
Ниже — моя базовая управленческая модель. Это заготовка для обсуждения с командой, а не обязательный набор полей конкретной CRM. Её нужно адаптировать под предоплату, оплату при получении, собственный склад и поставки под заказ.
Разделите обработку, оплату и доставку
Один заказ может быть подтверждён, частично оплачен и ещё не собран. Попытка записать всё одним названием приводит к десяткам комбинаций. Удобнее хранить несколько независимых состояний и связывать их правилами перехода.
| Контур | На какой вопрос отвечает | Пример |
|---|---|---|
| Обработка заказа | На каком этапе работа магазина? | Подтверждён → Комплектуется → Готов к передаче |
| Оплата | Какие деньги получены и что ещё требуется? | Не оплачен / Частично оплачен / Оплачен / Возврат |
| Доставка | Что происходит с конкретной отправкой? | Создана → Передана перевозчику → Доставлена |
| Задача | Что сотрудник должен сделать и к какому сроку? | Уточнить адрес до 15:00 |
| Блокировка | Почему следующий шаг пока невозможен? | Ожидаем согласования замены |
«Позвонить клиенту» — задача с исполнителем и сроком. «Ожидаем ответа клиента» — причина остановки. «Подтверждён» — результат согласования заказа. Эти сущности полезно различать даже тогда, когда интерфейс системы позволяет оформить их иначе.
Сама идея разделения поддерживается возможностями продуктов. RetailCRM описывает статусы заказа, товара и оплаты. У Битрикс24 есть отдельные настройки заказа и доставки в режиме «Сделки + Заказы». Но конкретные допустимые переходы и ограничения зависят от системы и интеграций.
Готовая матрица: событие, ответственный и следующий шаг
Сначала заполните таблицу вне CRM. Для каждого этапа нужны наблюдаемое событие входа, условие выхода, владелец и правило просрочки. Значения срока ниже — тип контрольной точки, а не универсальный норматив: время магазин назначает по своим обещаниям, загрузке и рабочему календарю.
| Этап | Событие входа | Условие выхода | Ответственный | Срок контроля | Исключение |
|---|---|---|---|---|---|
| Новый | Заказ создан, получен его идентификатор | Проверены состав, наличие, контакт и условия | Менеджер либо проверенная автоматизация | От создания до первичной проверки | Дубль, неверные данные, нет связи |
| Подтверждён | Согласованы товары, цена, оплата и доставка | Выполнены условия передачи на сборку | Менеджер | До обещанного старта сборки | Не получена требуемая предоплата |
| Комплектуется | Склад принял задание | Проверены товары и количество, упаковка завершена | Склад | До времени готовности | Недостача, повреждение, требуется замена |
| Готов к передаче | Сборка принята, документы готовы | Подтверждена фактическая передача | Склад / логистика | До согласованного окна передачи | Перевозчик не забрал отправление |
| В доставке | Товар принят перевозчиком | Есть подтверждение вручения либо возвратного события | Логистика | По обещанной дате доставки | Неудачная попытка, утрата, отказ |
| Доставлен | Получено подтверждение вручения | Сверены итог заказа и расчёты | Логистика / финансы | По сроку сверки расчётов | Ожидается перечисление наложенного платежа |
| Завершён | Зафиксированы исполнение и финансовый результат | Последующая претензия открывает отдельный процесс | Владелец заказа | По правилам сверки и контроля | Возврат или претензия после исполнения |
| Отменён | Зафиксировано решение не исполнять заказ и причина | Сняты резервы, урегулированы расчёты | Менеджер / финансы | До освобождения резервов и расчётов | Возврат денег ещё не завершён |
«Создана накладная» не означает «передан перевозчику». «Доставлен» не всегда означает «деньги перечислены магазину». Отменённый заказ также может требовать действий финансовой службы. Эти различия стоит сохранить в данных, иначе отчёт будет показывать удобную картину вместо фактического положения дел.
Куда отправлять проблемные заказы
Проблемный заказ не становится новым. Сохраните его этап, время создания, историю переходов и владельца. Добавьте причину остановки, срок следующего действия и ответственного за решение. Это может быть отдельное поле, признак или связанная задача — способ зависит от системы.
Для начала достаточно короткого справочника причин: нет ответа, требуется оплата, расхождение по остатку, согласование замены, проблема адреса, сбой доставки. Причина должна помогать действовать. Формулировка «Другое» требует комментария, иначе вскоре станет самым популярным и самым бесполезным вариантом.
Необязательно делать отдельный основной статус для каждой причины. Если недостача обнаружилась на сборке, сохранённый этап «Комплектуется» покажет место остановки, а причина объяснит препятствие. Отдельная очередь покажет все просроченные блокировки независимо от этапа.
Пример: неоплата и частичная отправка
Условный покупатель заказал два товара с предоплатой. Наличие подтвердили, но платёж не поступил. Заказ остаётся подтверждённым, оплата — «Не оплачен», сборка заблокирована по принятому правилу. Менеджер получает задачу проверить ситуацию. Срок ожидания и дальнейшие действия определяет политика магазина; автоматическая отмена без согласованного правила здесь опасна.
После оплаты склад обнаруживает повреждение одного товара. Покупатель согласен получить второй сразу, а замену — позже. Теперь нужны сведения по каждой позиции и отправке: что передано, что ожидается, какие суммы оплачены. Не отмечайте весь заказ доставленным после вручения первой посылки.
Если CRM и интеграция поддерживают несколько отправлений, ведите их раздельно. Если не поддерживают, заранее согласуйте другую модель, например связанные заказы, с сохранением общей связи, оплат и резервов. Иначе разделение породит двойное списание товара или искажённую выручку. В аналитике один исходный заказ не должен незаметно превратиться в две независимые покупки.
Кто меняет статусы и что автоматизировать
За изменение отвечает тот, кто первым получает достоверное подтверждение события. Склад знает о готовности упаковки, платёжный сервис — о платеже, перевозчик — о вручении. Для каждого перехода определите источник, время события и запасной способ проверки при сбое обмена.
Автоматизация полезна, когда её входные данные надёжны. До включения проверьте повторные и запоздавшие уведомления, возврат денег, частичную оплату и повторную отправку. Старое событие доставки не должно откатывать новое состояние. Действие при конфликте нужно спроектировать заранее: запись в журнал, очередь проверки и назначенный сотрудник.
Не каждый переход обязан быть доступен всем. Право отменять оплаченный заказ или подтверждать финансовую сверку лучше назначать по роли. При этом ограничение должно сопровождаться понятным маршрутом: кому передать задачу, если сотрудник не может решить её сам.
Какие показатели покажут потери
Ежедневный контроль начинается с очередей: сколько заказов просрочено на этапе, как долго длится блокировка, у каких заказов нет владельца или следующего действия. Смотрите медиану и верхние процентили времени, а не только среднее: несколько длинных задержек могут теряться за благополучным общим числом.
Для анализа результата возьмите заказы, созданные за один период, и дайте им сопоставимое время на исполнение. Посчитайте долю доставленных, отменённых, возвращённых и ещё открытых заказов. Отдельно покажите причины отмен и оплаченные суммы после возвратов. Недавнюю незавершённую когорту нельзя напрямую сравнивать с полностью исполненным прошлым месяцем.
Само сокращение времени в статусе не доказывает рост продаж: сотрудники могли начать отмечать события раньше. Сверяйте CRM с данными склада, оплаты и доставки. Если после внедрения меняются продажи, учитывайте сезон, ассортимент, рекламу и условия доставки, прежде чем связывать результат только со статусной моделью.
Как внедрить модель без потери истории
- Разберите реальные заказы: успешный, с отменой, неоплатой, заменой, частичной отправкой и возвратом. Найдите места, где текущий статус не объясняет происходящее.
- Согласуйте матрицу с менеджерами, складом, логистикой и финансами. Определите источники событий, правила времени и ответственных.
- Составьте соответствие старых и новых статусов. Сохраните историю и заранее проверьте влияние на отчёты, уведомления и обмен с другими системами.
- Прогоните сценарии на тестовых заказах. Убедитесь, что клиент получает правильные сообщения, резервы снимаются корректно, а оплаты не дублируются.
- Начните с ограниченной очереди и ответственного за разбор ошибок. После проверки расширьте применение и закрепите правила в инструкции команды.
Хорошая модель узнаётся по простому признаку: сотрудник открывает заказ и понимает, что уже произошло, чего ждём и кто делает следующий шаг. Скачайте матрицу ниже, замените роли и сроки своими и проверьте её на нескольких реальных историях до изменения настроек.
Источники и методика
Рекомендации связывают задачи покупателя с работой магазина. Учебные примеры иллюстрируют способ расчёта и не описывают результаты клиентских проектов.
Нужно связать наблюдения с процессами и данными вашего магазина? Разберём задачу и определим, что проверять первым.
Обсудить задачу ↗