Не по гайду

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

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

То есть условный 200 OK от последнего сервиса для нас всё меньше означает «заказ завершён». Скорее это просто один из сигналов. Самый полезный инвариант пока именно ваш: один оплаченный заказ → одна выдача, сколько бы раз мы ни переигрывали цепочку после сбоя.

Да, согласен. Мы как раз упёрлись в то, что технически восстановить заказ оказалось проще, чем восстановить контекст вокруг него.

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

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

Да, очень похожая логика. У нас я бы смотрел не только на частоту, а на связку частота × цена ошибки × повторяемость сценария.

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

То есть условно:
редко + дёшево → задача/комментарий
часто + дёшево → кандидат на автоматизацию
редко + дорого → правило/контроль
часто + дорого → в схему сразу

А «на глаз» оставляю только как первый сигнал. Потом всё равно хочется понять, это реально паттерн или просто три странных заказа подряд.

И да, мысль про 5–7 реальных исключений вместо 30 очень откликается — на старте почти всегда кажется, что бизнес сложнее, чем он есть.

Да, вот на исключениях как раз и начинается самое интересное. Базовый путь заказа мы сначала описали отдельно, а потом уже стали смотреть, где реальный процесс из него выпадает.
Всё, что повторяется и влияет на статус заказа/оплату/исполнение, логичнее постепенно вытаскивать из «памяти менеджера» в явное правило системы. А единичные странные кейсы не хочется сразу превращать в ещё десять статусов — иначе опять получится CRM, под которую начинает работать бизнес, а не наоборот.

Хорошая мысль, кстати. Про «счастливый путь» и исключения отдельный разбор сделаю.