AI escalation rules: a handoff needs an ownerПравила эскалации AI: у передачи должен быть ответственный

Write concrete reasons for a handoffОпишите конкретные причины передачи

Create a short set of reason codes that employees can understand: the customer requests a person, an action is outside the agent’s permission, required information is missing, sources conflict or a configured risk rule applies. Define the next step for each reason. “The model is uncertain” is too broad to explain what an employee needs to resolve.Составьте короткий набор понятных причин: клиент просит человека, действие выходит за разрешения агента, отсутствуют обязательные сведения, источники противоречат друг другу или сработало согласованное правило риска. Для каждой причины определите следующий шаг. Формулировка «модель не уверена» слишком общая: сотруднику непонятно, что именно предстоит выяснить или решить.

Separate mandatory stops from situations where one clarifying question is useful. A direct request for a person should not trigger an endless sequence of automated questions. A missing order number may be resolved by a permitted identity check. The process owner must decide these boundaries before the agent is given access to operating actions.Разделите обязательную остановку и случаи, где полезен один уточняющий вопрос. Прямая просьба о человеке не должна запускать бесконечную цепочку автоматических уточнений. Отсутствующий номер заказа иногда можно получить разрешённой проверкой. Границы определяет владелец процесса до того, как агент получает доступ к рабочим действиям и данным клиентов.

Decide what stops and what can continueОпределите, что останавливается, а что продолжается

For each escalation reason, specify whether the agent can still provide approved general information, collect a limited missing detail or only confirm that the request has been recorded. Block the disputed action until the appropriate person decides. Escalating an exception must not leave a parallel automation free to perform the same restricted action.Для каждой причины укажите, может ли агент продолжить выдачу утверждённой общей информации, уточнить ограниченный набор сведений или только подтвердить регистрацию обращения. Спорное действие блокируется до решения уполномоченного сотрудника. Передача исключения не должна оставлять параллельной автоматизации возможность выполнить то же ограниченное действие в обход установленной остановки.

Do not use a confidence score as the sole gate. A highly confident response can still be unsupported, and a correctly recognized customer request may require a person regardless of confidence. Evaluate permissions, source availability and business rules directly. Keep the reason visible in the case so reviewers can distinguish a missing fact from a prohibited operation.Не делайте оценку уверенности единственным условием. Уверенный ответ бывает неподтверждённым, а просьба клиента требует человека независимо от оценки модели. Проверяйте права, доступность источника и рабочие правила напрямую. Причину сохраняйте в обращении, чтобы проверяющий отличал недостающий факт от запрещённой операции и выбирал правильный способ разбора.

Send enough context for the next personПередайте контекст для продолжения работы

A transfer packet needs the case identifier, reason, channel, known customer or order reference, relevant facts, attempted actions and the unanswered question. Add source links when they help verification. Describe what has already happened and what is merely proposed. Do not send the entire conversation by default when a precise extract will allow the employee to proceed.Для передачи нужны идентификатор обращения, причина, канал, известная ссылка на клиента или заказ, существенные факты, предпринятые действия и нерешённый вопрос. Добавьте ссылки на источники, полезные для проверки. Отделите уже выполненное от предложенного. Не пересылайте весь разговор по умолчанию, если точной выдержки достаточно, чтобы сотрудник продолжил работу.

Minimize personal information and preserve the access restrictions of the underlying sources. A restricted record should not become visible to an entire channel through an escalation message. When identity is unverified, say so in the packet and leave restricted facts out. The recipient should know what they are allowed to confirm before answering.Передавайте минимум личных сведений и сохраняйте ограничения доступа исходных записей. Закрытая информация не должна становиться доступной всему каналу из-за сообщения об эскалации. Если личность не проверена, прямо укажите это и исключите ограниченные сведения. Получатель должен понимать, какие факты допустимо подтверждать до ответа клиенту.

Define acceptance, deadlines and a fallbackЗадайте приём, сроки и резервный маршрут

Route the case to a responsible role and a staffed queue, not merely a named employee who may be absent. Distinguish “created,” “assigned,” “accepted” and “resolved.” Agree how acceptance is recorded and which waiting time triggers another route. Use the actual operating calendar; an off-hours case needs a different expectation from a staffed live conversation.Направляйте обращение ответственной роли и работающей очереди, а не только конкретному сотруднику, который может отсутствовать. Различайте состояния «создано», «назначено», «принято» и «решено». Согласуйте подтверждение приёма и время ожидания до следующего маршрута. Используйте реальный рабочий календарь: обращение вне смены требует других ожиданий, чем разговор при доступной команде.

Prevent duplicate cases and escalation loopsИсключите дубли и круговую передачу

Use the original event or case identifier when notifications are retried. A delayed acknowledgement should not create another independent case with another owner. Preserve a clear primary record and the history of assignments. If two teams return the same issue to each other, stop the loop and send it to the role responsible for resolving ownership.Используйте идентификатор исходного события или обращения при повторе уведомлений. Задержка подтверждения не должна создавать независимый дубль с другим ответственным. Сохраняйте основную запись и историю назначений. Если две команды возвращают вопрос друг другу, останавливайте цикл и направляйте его роли, которая отвечает за определение владельца спорных задач.

Treat delivery failures separately from unanswered cases. A rejected queue write, an unavailable messaging channel and an unaccepted task require different recovery steps. Check whether the first write succeeded before retrying after a timeout. Keep the customer-facing status aligned with the verified operation, including any failure that affects the promised next step.Различайте ошибку доставки и отсутствие ответа. Отклонённая запись в очередь, недоступный канал и непринятая задача требуют разных способов восстановления. После таймаута сначала проверьте, состоялась ли первая запись. Статус для клиента должен соответствовать проверенной операции, включая сбой, который влияет на ранее согласованный следующий шаг.

Accept the route from trigger to resolutionПринимайте весь маршрут до решения

Test a direct request for a person, a forbidden action, conflicting records, an absent primary owner and a case received outside working hours. Add duplicate notifications, delayed acceptance and a failed queue operation. For each test, verify the stop condition, context, owner, customer wording and fallback result. A correct reason code alone does not prove a functioning handoff.Проверьте прямую просьбу о человеке, запрещённое действие, противоречивые записи, отсутствие основного ответственного и обращение вне рабочего времени. Добавьте повтор уведомления, запоздалый приём и сбой записи в очередь. В каждом примере проверяйте остановку, контекст, владельца, формулировку клиенту и резервный маршрут. Правильный код причины ещё не доказывает работоспособность передачи.

An audit for SABSUS should map the actual responsibility structure and the exceptions employees already handle. Deep implementation connects these rules to queues, permissions, operating hours and recovery. After launch, review cases that waited too long or changed owners repeatedly; update the route only after establishing whether the problem is classification, capacity or an unclear responsibility.Аудит для SABSUS должен описать реальную структуру ответственности и исключения, которые сотрудники уже разбирают. Глубокое внедрение связывает правила с очередями, правами, сменами и восстановлением. После запуска разбирайте долгие ожидания и повторные смены владельца. Меняйте маршрут, установив причину: неверная классификация, нехватка доступных сотрудников или неясное распределение ответственности.

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