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

Чтобы согласовать статусы заказа и уведомления клиенту, опишите для каждого перехода событие, подтверждение, ответственного и текст сообщения. Разделите ход выполнения, оплату и доставку уведомления. Тогда кнопка «Принять» не будет означать одновременно получение заявки, начало работы и обещание готового результата. Ниже — учебная карта переходов и интерактивный чек-лист, по которым можно проверить свой сценарий до разработки.

Что означает каждый статус заказа

Статус описывает подтверждённое состояние заказа в выбранной части процесса. Событие объясняет, что произошло; переход показывает, как изменилось состояние. Например, сотрудник подтвердил возможность выполнить работу — событие. Заказ перешёл из «на проверке» в «принят» — переход. Сообщение клиенту сообщает об этом, но само по себе не выполняет работу.

Начните с одного обычного заказа и выпишите, что сотрудники действительно знают в каждый момент. «Новый» означает, что запись создана? «Принят» — что данные проверены или уже назначен исполнитель? «Готов» — что закончил работу сотрудник или что результат передан заказчику? Ответы должны совпадать у команды, интерфейса и автора уведомлений.

Для каждого названия составьте короткое определение, условие входа и признак завершения. В условной услуге подготовки макета «на проверке» может означать, что запрос сохранён, но состав ещё не согласован. Это учебный процесс, а не описание готового сервиса Nazara. Выберите собственные условия и не переносите пример буквально в договорённости с клиентом.

Не добавляйте статус ради каждой внутренней операции. Открытие карточки, исправление опечатки и просмотр вложения обычно не меняют обещаний заказчику. Их можно отражать в истории действий. Статус нужен, когда меняются доступные действия, ответственность или информация, которую важно получить клиенту.

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

Почему выполнение и оплата требуют отдельных признаков

Ход работ и расчёты с клиентом могут изменяться независимо. Заказ бывает принят, но не оплачен; оплачен, но ещё не выполнен; выполнен, но передача результата ожидает согласования. Если все сочетания превращать в один длинный список, легко потерять допустимый случай или отправить неправильное сообщение.

В документации Shopify о статусах заказа отдельно рассматриваются состояние заказа, оплаты, исполнения и возврата. Это конкретная модель Shopify, а не обязательный шаблон для любой компании. Полезен сам вопрос: какие независимые обстоятельства Вы сейчас пытаетесь спрятать в одном слове?

Для учебного процесса можно оставить состояние работы «на проверке / принят / выполняется / готов / отменён» и отдельно признак оплаты. Набор оплаты согласуйте по реальному способу расчётов. Не добавляйте «частично оплачен» или «возврат выполнен», если источник не позволяет подтвердить эти факты. Неизвестное состояние честнее случайной галочки.

Отдельно храните состояние уведомления: запланировано, передано каналу, ошибка или иной подтверждаемый этап. Отсутствие сообщения не должно возвращать выполненную работу в незавершённую. И наоборот, успешно отправленное сообщение не является доказательством того, что заказ оплачен или результат принят.

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

Как составить карту разрешённых переходов

Запишите переходы как строки «откуда → событие → условие → куда → кто подтверждает». Укажите запрещённые переходы или правило отказа. Стрелка между двумя названиями без условия оставляет разработчику слишком много догадок. Особенно важно определить, кто может подтвердить готовность и можно ли вернуть заказ на предыдущий шаг.

Это условная схема услуги, не универсальный порядок покупки. Оплата, доставка товара и возврат денег здесь намеренно не объявлены автоматически выполненными. Для своей работы дополните условия реальными зависимостями: наличием материалов, подтверждением оплаты, согласованием даты или возможностью отмены.

Отдельно опишите обратные переходы. Возврат результата на доработку может требовать причины и нового ответственного; повторное открытие завершённого заказа — отдельного решения. Не меняйте старое событие так, будто оно не происходило. Запись о готовности может остаться в истории, а текущее состояние измениться на согласованное новое.

Уточните, что произойдёт при двух действиях одновременно. Если один сотрудник отменяет заказ, а другой начинает исполнение, система не должна молча принять оба несовместимых решения. Какой переход разрешён и на основании какой версии состояния, решают при проектировании. В приёмке нужен пример конфликта, а не только правильная последовательность на схеме.

На основании чего подтверждать событие

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

В карточке события укажите идентификатор заказа, идентификатор события, время получения, источник и результат обработки. Не требуется собирать весь текст переписки или секреты доступа. Важно суметь ответить, почему именно этот заказ получил этот статус и не применялось ли то же событие раньше.

Документация Stripe о webhook-событиях предупреждает о повторных доставках и отсутствии гарантии порядка получения. Это свойства указанного механизма Stripe, не обещание интеграции Nazara с оплатой. Для своего источника проверьте аналогичные условия, прежде чем строить переходы на предположении «каждое сообщение приходит один раз и по очереди».

Определите реакцию на старое или неподходящее событие. Оно может требовать проверки текущего состояния, регистрации конфликта или ручного решения. Нельзя переводить завершённую работу обратно в ожидание лишь потому, что позже пришло старое сообщение. Технический способ согласуется с разработчиком, а бизнес-ожидание нужно описать владельцу процесса.

Если подтверждение недоступно, показывайте неопределённость и дальнейшее действие. «Проверяем оплату» отличается от «Оплачено». Сотрудник должен понимать, когда требуется ручная сверка и где искать источник. Тайм-аут не доказывает, что операция не состоялась, поэтому повтор не должен безусловно создавать второй заказ.

Как написать уведомление без ложного обещания

Сообщение сообщает только подтверждённое событие и объясняет следующий шаг. Включите узнаваемый номер заказа, новый смысловой статус и действие клиента, если оно требуется. Не заставляйте человека расшифровывать внутренние коды. Фраза «ваша заявка в обработке» мало помогает, если непонятно, нужно ли ждать согласования или работа уже началась.

Учебный текст после регистрации: «Запрос № DEMO-17 сохранён. Условия ещё не согласованы; ответственный проверит описание и свяжется с Вами выбранным способом». Здесь нельзя добавлять обещание времени ответа, если оно не утверждено. После готовности нужен другой текст: что именно готово и где проверить результат. Эти примеры не являются реально отправленными сообщениями.

Согласуйте уведомления по событиям, а не по каждому открытию страницы. В руководстве Shopify по уведомлениям сообщения привязаны к определённым событиям магазина. В собственном сценарии выберите только нужные человеку уведомления и доступные каналы, не копируя автоматически весь перечень возможностей другой платформы.

Отделяйте внутреннюю причину от клиентского текста. Сотруднику может требоваться технический код ошибки, а клиенту — понятное объяснение, что заказ не потерян и как уточнить состояние. Не включайте в сообщение пароли, платёжные реквизиты или чужие сведения. Ссылка на результат должна соответствовать согласованным правилам доступа.

Проверьте текст вместе с целевой страницей. Сообщение «скачайте результат» не подходит ссылке на общий каталог. Если действие пока недоступно, не предлагайте его. Формулировку об отмене также проверяйте по смыслу: отменён заказ, запись на время или только отправка уведомления? Это разные события с разными последствиями.

Что делать при сбое, повторе и ручном решении

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

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

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

Границы эскалации диалога отдельно разобраны в статье как передавать сложный вопрос бота человеку. Здесь передаётся проблема конкретного заказа с его состоянием. Не пересылайте всю переписку всем участникам: достаточно минимального контекста для нужного решения и разрешённого способа связаться с клиентом.

Сначала проверьте сценарий на учебной записи без настоящего платежа и внешней отправки. Имитируйте недоступность канала, повтор и конфликт, а не создавайте реальные заказы ради статьи. Наш каталог ботов Nazara содержит самостоятельные проекты и демо; наличие карточки не подтверждает готовность универсальной системы статусов или платёжной интеграции.

Приёмка карты статусов

Для каждого перехода подготовьте положительный и запрещённый пример. Затем пройдите обычный заказ, отмену, повтор события, задержанное подтверждение и ошибку доставки. Проверяйте состояние записи и текст сообщения, а не только цвет плашки. Результат обсуждения — версия карты и список подтверждённых проверок.

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

Частые вопросы

Нужно ли показывать клиенту все внутренние статусы

Нет. Сотрудники могут видеть подробности, а клиент — понятное обобщение. Составьте соответствие заранее и проверьте, что обобщение не меняет смысл подтверждённого события.

Можно ли менять название статуса после запуска

Можно, но проверьте смысл, старые записи, фильтры и шаблоны сообщений. Переименование не должно автоматически превращать прежнее состояние в другой факт.

Что делать с частично выполненным заказом

Определить, что является единицей выполнения: весь заказ, позиция или этап услуги. Если части независимы, это должно отражаться в модели, а не скрываться под общей отметкой готовности.

Доказывает ли отправленное сообщение его прочтение

Нет. Используйте только те подтверждения доставки или чтения, которые действительно предоставляет канал. Не называйте отправку доказательством согласия клиента.

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

Когда согласованы точное условие, надёжное подтверждение и исключения. Для спорного результата или отсутствующего подтверждения предусмотрите ручную проверку.

Нужна ли полная CRM для такой карты

Нет. Правила можно сначала согласовать в таблице. Выбор инструмента зависит от объёма и задач, но таблица не заменяет техническую реализацию и проверку переходов.