AI delivery exceptions: verify the problem before promising a solutionAI при сбоях доставки: сначала проверка, затем новое обещание

Start with a verified exception eventНачните с проверенного события

Define the events that open an exception: a missed agreed window, a failed delivery attempt, a reported problem or conflicting tracking states. Preserve the order, shipment and event identifiers, source, event time and processing time. One customer order can have several parcels; a problem with one parcel does not establish the status of the others.Определите события, открывающие разбор: пропущенное согласованное окно, неудачная попытка вручения, сообщение о проблеме или противоречивые статусы. Сохраняйте идентификаторы заказа, отправления и события, источник, время события и время обработки. В одном заказе бывает несколько посылок; проблема с одной из них не определяет состояние остальных и не отменяет весь заказ.

Check how fresh and complete the source is. A tracking feed that stopped updating is different from a confirmed delay. A customer report is important evidence, but record it as a report until the relevant facts are checked. If the feed is unavailable, create a data-check task instead of inventing the driver’s position or the reason for the stop.Проверяйте актуальность и полноту источника. Остановившийся обмен статусами отличается от подтверждённого опоздания. Сообщение клиента важно, но до проверки сохраняйте его именно как сообщение. Если источник недоступен, создайте задачу на уточнение данных, а не придумывайте положение курьера или причину остановки. В записи должно быть видно, что известно, а что ещё проверяется.

Classify the problem without guessing its causeОпределите тип проблемы без выдуманных причин

Use a small, operational set of categories: timing, address or access, recipient availability, damaged or incomplete delivery, and unknown status. Distinguish the observed event from the suspected cause. “Attempt failed” does not prove that the customer was absent. Save the supporting event or message beside the classification so the dispatcher can correct it.Используйте небольшой рабочий набор категорий: срок, адрес или доступ, доступность получателя, повреждение или неполная доставка, неизвестный статус. Отделяйте наблюдаемое событие от предполагаемой причины. «Попытка не удалась» не доказывает отсутствия клиента. Сохраняйте подтверждающее событие или сообщение рядом с категорией, чтобы диспетчер мог проверить и исправить вывод.

Identify the immediate operational consequence: which commitment is at risk and which decision cannot wait. Apply the business’s agreed priority rules rather than inferring urgency from emotional wording alone. Keep claims that need investigation open, and route cases outside the dispatcher’s authority to the designated owner with the facts already collected.Укажите непосредственное последствие: какое обязательство под угрозой и какое решение нельзя откладывать. Применяйте согласованные правила приоритета, не определяя срочность только по эмоциональной формулировке. Сохраняйте требующие проверки утверждения открытыми. Вопросы вне полномочий диспетчера направляйте назначенному владельцу вместе с уже собранными фактами, чтобы клиенту не пришлось повторять всё заново.

Offer only alternatives that can be carried outПредлагайте только выполнимые варианты

Before suggesting another window, check current dispatch capacity, route constraints, receiving hours and any applicable item restrictions. A previous route plan cannot confirm today’s availability. If a replacement shipment is considered, verify stock and the authorized fulfillment decision separately. Present an option as provisional until the people or systems responsible for execution confirm it.Перед предложением другого окна проверьте текущую загрузку доставки, ограничения маршрута, часы приёма и особенности товара. Прежний маршрут не подтверждает сегодняшнюю доступность. Если рассматривается замена отправления, отдельно проверьте остаток и решение уполномоченного сотрудника. Вариант остаётся предварительным, пока возможность исполнения не подтвердили ответственные люди или рабочие системы.

A change of address, delivery method or recipient can require additional checks and approval. Do not infer permission from the desire to resolve the incident quickly. Keep refunds, compensation and new charges in their own authorized processes. If no option is confirmed, explain the unresolved point and assign the next check rather than promising a convenient outcome.Смена адреса, способа доставки или получателя может требовать дополнительных проверок и согласования. Желание быстро решить проблему не заменяет разрешение. Возврат, компенсация и новые начисления относятся к отдельным согласованным процессам. Если подтверждённого варианта пока нет, обозначьте нерешённый вопрос и назначьте следующую проверку, вместо обещания удобного, но необеспеченного результата.

Assign one owner and keep the customer informedНазначьте владельца и согласуйте связь с клиентом

Give the exception one operational owner, with a backup for an unavailable shift. The case should show the problem, affected commitment, evidence, current action and next review time. Sending a message to several teams does not assign responsibility. Record who accepted the case and where it goes if the first team cannot resolve it.Закрепите за исключением одного рабочего владельца и замену на время отсутствия смены. В задаче должны быть проблема, затронутое обязательство, основания, текущее действие и время следующей проверки. Сообщение нескольким командам не назначает ответственность. Фиксируйте, кто принял случай и куда он переходит, если первая команда не может его решить.

Handle repeated events and late informationОбработайте повторы и запоздалые сведения

Group repeated notifications under the same shipment and exception. Check the current state before applying a late tracking event: a delayed “failed attempt” must not reopen a case already resolved by verified delivery. Preserve the event history and the rule that determines which state takes precedence. Do not discard contradictory evidence simply because another event arrived later.Объединяйте повторные уведомления по отправлению и исключению. Перед применением запоздалого события проверяйте текущее состояние: старая «неудачная попытка» не должна открывать случай, уже закрытый подтверждённым вручением. Сохраняйте историю и правило приоритета состояний. Не отбрасывайте противоречивое основание только потому, что другое сообщение поступило позже.

After a timeout, verify whether the action succeeded before retrying a reassignment or customer message. For partial completion, show what changed and what remains pending. Close the exception only on the agreed evidence, such as a verified delivery outcome or an approved alternative completed. “No new alerts” is not a resolution criterion.После таймаута проверьте результат до повтора переназначения или сообщения клиенту. При частичном выполнении покажите, что изменилось, а что ожидает действия. Закрывайте исключение по согласованному основанию: например, подтверждённому результату доставки или выполненному утверждённому варианту. Отсутствие новых уведомлений само по себе не означает, что проблема решена.

Accept the process from first alert to resolutionПринимайте процесс от сигнала до решения

Test stale tracking, an ambiguous address, a customer who cannot accept the suggested window, a split shipment and an unavailable dispatcher. Add duplicate events, a message timeout and a delivered event arriving out of order. Check the evidence, feasible option, permissions, owner and customer wording for each case, including the expected absence of an action when prerequisites are missing.Проверьте устаревший статус, неоднозначный адрес, отказ от предложенного окна, частичную отправку и недоступного диспетчера. Добавьте дубли, таймаут сообщения и событие вручения, пришедшее не по порядку. В каждом примере проверьте основания, выполнимость варианта, права, владельца и текст клиенту, включая ожидаемое отсутствие действия при недостающих условиях.

A SABSUS audit should map the actual carrier events, dispatch decisions and communication approvals. Deep implementation connects those sources and responsibilities, defines recovery and verifies the complete route. Accept the configuration when an employee can trace why an exception opened, which option was authorized and what evidence justified closing it.На аудите SABSUS следует разобрать реальные события перевозчика, решения диспетчеров и согласования связи с клиентом. Глубокое внедрение связывает источники и ответственность, задаёт восстановление и проверяет весь маршрут. Принимайте конфигурацию, когда сотрудник может проследить причину открытия, разрешённый вариант и основание, по которому случай закрыт.

Quick answersКороткие ответы