Журнал исключений заказа растений

Продажи · exception log · недостача · замена · перенос · эскалация

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

Без order exception log такие ситуации остаются в чатах и памяти людей. Сегодня команда героически исправила недостачу, завтра повторила её снова, а через месяц никто не знает, где узкое место: в наличии, сборке, продажах, упаковке, SLA или ожиданиях клиента.

Что считать исключением заказа

Исключение заказа — это не любая мелочь. Это событие, которое меняет обещание клиенту, нагрузку команды, качество handoff или риск претензии. Если заказ идёт по стандарту, лог не нужен. Если появляется недостача замена перенос, owner или эскалация — нужна запись.

Примеры: позиция отсутствует при сборке, клиент просит замену в день выдачи, заказ готов не к тому окну, packing list не совпал с фактом, фото до отгрузки не сделано, клиент пришёл раньше ready status, менеджер обещал срок до проверки наличия.

Чем это отличается от журнала партии

Журнал партии отвечает на вопрос, что происходило с растениями. Журнал исключений заказа отвечает на вопрос, что произошло с обещанием клиенту и выполнением заказа.

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

Минимальные поля журнала

Если журнал не показывает owner-а и статус, он превращается в список неприятностей. Ценность появляется, когда каждая строка говорит, что делать дальше.

Типы исключений: не смешивать всё в одну корзину

Тип исключения нужен для статистики. Если все строки называются «проблема с заказом», улучшать нечего. Разделите хотя бы пять классов: наличие, сборка, клиент, логистика/выдача, коммуникация.

• Наличие. Позиция была обещана, но её нет или она не той стадии.
• Сборка. Ошибка количества, пересорт, неверная упаковка, не тот документ.
• Клиент. Опоздание, no-show, изменение в последний момент.
• Окно. Выдача, отгрузка или приёмка не попали в согласованный слот.
• Коммуникация. Менеджер пообещал больше, чем подтверждено процессом.

Severity: что нужно эскалировать сразу

Severity помогает не перегружать владельцев. Не каждое исключение требует директора или агронома. Но часть случаев нельзя оставлять менеджеру без права решения.

Пример локальной шкалы:

1. S1. Ошибка до клиента, решается внутри смены.
2. S2. Клиент ждёт решения, нужен owner канала.
3. S3. Риск потери клиента, денег или массового повторения.
4. S4. Юридически, репутационно или финансово чувствительный случай.

Эскалация заказа нужна там, где менеджер не имеет полномочий: спор по гарантии, крупная недостача, конфликт по B2B-документам, публичный негатив, повторяющийся сбой у ключевого клиента.

Статусы: open, waiting, resolved, learned

Статус исключения показывает, где застрял случай. Удобная схема: open, waiting customer, waiting internal, resolved, learned. Последний статус важен: он означает, что причина внесена в процесс, а не только клиент успокоен.

Если исключение закрыто заменой, но причина не разобрана, оно вернётся. Если причина разобрана, но customer handoff не завершён, случай всё ещё открыт с точки зрения клиента.

Связь с document pack

Когда заказ сложный, документ-пак B2B-заказа даёт доказательную базу: спецификация, packing list, фото, маркировка, окно расхождений. Журнал исключений использует эти данные, чтобы не спорить на уровне «нам кажется».

Если packing list показывает 4 места, а клиент говорит, что получил 3, исключение можно разобрать по номеру места. Если фото партии есть, спор о состоянии становится конкретнее. Если нет ни документа, ни фото, exception log всё равно фиксирует случай, но root cause уже включает «доказательная база отсутствовала».

Самовывоз и no-show: отдельный источник исключений

Окна самовывоза часто дают много мелких исключений: клиент приехал раньше, заказ не был готов, клиент не приехал, заказ стоял слишком долго, handoff занял весь слот. Подробный процесс описан в статье про окна самовывоза и выдачи.

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

Когда исключение становится претензией

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

Для клиентской рамки используйте политику гарантии на живой товар. В exception log фиксируйте связь: какая строка стала претензией, какие доказательства есть, какой результат и какую причину нужно исправить.

Разбор исключений заказа: искать паттерн

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

Раз в неделю сгруппируйте строки по типу и причине. Если 10 случаев выглядят разными, но у всех одна причина «остаток не обновлён до обещания», проблема не в клиентах. Проблема в контроле доступности и SLA канала.

Weekly owner review: кто чинит процесс

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

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

Так журнал перестаёт быть архивом ошибок. Он становится входом в обучение менеджеров, обновление базы знаний, настройку окон самовывоза, корректировку packing list и пересмотр capacity. Если owner review не назначен, даже хороший exception log постепенно превращается в склад неприятных историй.

Мини-SOP exception log

1. Записывайте исключение сразу, пока факты свежие.
2. Укажите тип, канал, impact, owner-а и статус.
3. Свяжите строку с заказом, документом, фото или партией.
4. Разделите срочное решение для клиента и root cause.
5. Эскалируйте только случаи выше полномочий менеджера.
6. Закрывайте строку только после решения и отметки причины.
7. Раз в неделю смотрите топ-3 повторяемых класса.

Типовые ошибки

• Писать только крупные скандалы. Мелкие повторяющиеся сбои часто дороже одного большого.
• Не назначать owner-а. Исключение превращается в общее раздражение.
• Смешивать причину и решение. «Заменили» не объясняет, почему недостача возникла.
• Закрывать без learning. Клиент успокоен, но процесс не улучшен.
• Использовать журнал как наказание. Тогда команда начнёт скрывать исключения.
• Не связывать с evidence. Без фото, packing list и заказа разбор становится слабее.

Словарь терминов

Журнал исключений заказа

Рабочий список отклонений заказа с типом, owner-ом, статусом и решением.

Order exception log

Английское название журнала исключений по заказам.

Исключение заказа

Отклонение от стандартного маршрута, требующее решения.

Severity

Уровень серьёзности исключения и срочности эскалации.

Owner

Ответственный за закрытие конкретного исключения.

Impact

Влияние исключения на клиента, срок, качество, маржу или репутацию.

Root cause

Повторяемая причина, которую нужно исправить в процессе.

Эскалация заказа

Передача исключения владельцу с полномочиями принять решение.

На чём основана статья

• ASQ: check sheet — структурированная фиксация повторяемых событий.
• ASQ: root cause analysis — разбор повторяемых причин.
• Atlassian: incident management — owner, status и эскалация.
• Zendesk: escalation management — логика поддержки и передачи сложных случаев.
• ISO: quality management — процессная согласованность.