Когда очередь обращений в поддержку трудно контролировать, возникает соблазн начать с вопроса об инструментах: «Что можно автоматизировать?» Но более полезный первый вопрос связан с процессом: «Что происходит с обращением с момента поступления до того, как за него начинает отвечать нужный человек?»
Это различие важно. Очередь — не просто набор сообщений. В ней есть обращения с разной срочностью, контекстом, ожиданиями клиента и уровнем риска. Если эти различия не видны в процессе, автоматизация очереди может лишь быстрее распространить неразбериху.
Для руководителя поддержки первая цель триажа обращений в поддержку — выстроить поток с понятной ответственностью: у каждого обращения должен быть ясный маршрут, назначенный владелец и безопасный способ выделить исключение. И только после этого имеет смысл оценивать, можно ли автоматизировать ограниченные части такого потока.
Начните с той очереди, которая есть на самом деле
Обращения в поддержку могут поступать через несколько одобренных каналов и в разных форматах. Прежде чем менять процесс, соберите репрезентативную выборку и задайте несколько практических вопросов:
- Какие типы обращений приходят чаще всего?
- Какая информация обычно нужна, прежде чем кто-то сможет действовать?
- Какие признаки определяют срочность или ответственного?
- В каких местах сотрудникам приходится останавливаться и просить помощи?
- Какие обращения никогда не следует обрабатывать автоматизированным шагом?
Цель не в том, чтобы создать идеальную классификацию. Нужно сделать явными решения, которые люди уже принимают: иногда последовательно, а иногда только на основе опыта. Рабочая карта входящего потока показывает само обращение, доступный контекст, предполагаемый маршрут, ответственного владельца и момент, когда дело должен взять человек.
Здесь же руководитель поддержки может отделить стабильное, повторяемое обращение от ситуации, где требуется оценка человека. Для обычного запроса на обновление следующий шаг может быть ясно определён, если есть нужная информация. Жалоба, спорная ситуация или обращение клиента в уязвимом положении могут с самого начала требовать участия человека. Если считать оба случая одинаковыми «тикетами», необходимые команде механизмы контроля останутся незаметными.
Как проводить триаж обращений: определите решения до автоматизации
Команды, которые выясняют, как проводить триаж обращений, часто начинают со списка приоритетов. Приоритет полезен, но это лишь одна часть решения. Более полный подход к триажу может учитывать:
- Тему: о чём спрашивает клиент?
- Язык и потребности доступности: нужен ли обращению особый канал коммуникации или проверка специалиста?
- Срочность: есть ли зависящая от времени операционная причина действовать быстрее?
- Контекст аккаунта: есть ли сведения, которые уполномоченный проверяющий должен учесть до выбора маршрута?
- Уверенность: достаточно ли данных, чтобы следовать известному правилу, или требуется уточнение?
- Ответственного: какая команда или какой человек отвечает за следующий шаг?
- Условие эскалации: что делает обычную обработку небезопасной или неуместной?
Если процесс стабилен, зафиксируйте эти решения в явных правилах. Если нужна интерпретация, отметьте неопределённость и предусмотрите путь проверки. Так команда сможет тестировать рабочий процесс, а не полагаться на непрозрачную рекомендацию.
Например, предложенный поток может определить тему обращения и вероятного ответственного, а затем направить его по маршруту, доступному для проверки. Не следует молча считать неопределённую классификацию фактом. То же относится к черновику ответа или ограниченной проверке статуса: для каждого нужны одобренная информация, чётко разрешённое действие и маршрут для всего, что выходит за заданные рамки.
Сделайте процесс эскалации обращений в поддержку видимым
Эффективный процесс эскалации обращений в поддержку — не признак сбоя. Это часть дизайна, которая защищает клиентов и сотрудников, когда обращение требует оценки человека.
Опишите триггеры эскалации простым языком. Например: низкая уверенность, отсутствие информации, эмоциональная или тревожная коммуникация, спор, уязвимый клиент или вопрос со значимыми последствиями. Для каждого триггера определите, кто получает случай, какой контекст передаётся вместе с ним и кто уполномочен решить, что делать дальше.
Контекст не менее важен, чем маршрутизация. Человек, получающий эскалированный случай, должен видеть обращение, относящуюся к нему одобренную историю, уже рассмотренный маршрут и причину эскалации. Это уменьшает количество ненужных повторных объяснений, сохраняя контроль над решением у ответственного человека.
Не менее важно предусмотреть ручной запасной путь. Если правило приёма неясно, вышестоящая система недоступна или рабочий процесс столкнулся с исключением, команде нужен известный способ продолжить обслуживание клиента без догадок. Процесс, который можно безопасно остановить, надёжнее процесса, продолжающего действия после того, как его предположения перестали быть верными.
Ищите ограниченные возможности в триаже клиентской поддержки
После того как существующий процесс описан, триаж клиентской поддержки можно оценивать как последовательность ограниченных шагов рабочего процесса, а не как один крупный проект автоматизации. В зависимости от результатов изучения и проверки рабочий процесс может объединять одобренные обращения, определять тему, язык, срочность или вероятного ответственного и передавать неопределённые либо высокорисковые случаи человеку.
Некоторые команды также захотят оценить, может ли одобренная база знаний помочь подготовить черновик ответа или может ли чётко ограниченная проверка статуса подготовить следующий шаг. Это не решения для автоматического внедрения. Необходимо проверить одобренные входные данные, права доступа, правила процесса, ожидания к проверке и обработку исключений в среде клиента.
Именно такова уместная роль ознакомительной работы с управляемым сервисом. KeepSolid Automations может оценить текущий процесс, задействованные системы и права доступа, доступные данные, уровень риска и необходимый команде результат. Итогом может стать дизайн рабочего процесса, рекомендация сначала стабилизировать процесс или решение оставить предлагаемый шаг полностью за людьми.
Свяжите решения по триажу с управлением очередью поддержки
Хорошее управление очередью поддержки не означает, что каждое обращение нужно заставить пройти один и тот же маршрут. Оно означает, что маршрут должен быть понятен: что поступило, как это оценили, кто отвечает за него сейчас, какое исключение применяется и когда должен вмешаться человек.
Проверяйте рабочий процесс вместе с теми, кто работает в нём каждый день. Руководители поддержки, агенты, владельцы эскалаций и другие операционные владельцы должны иметь возможность оспорить правила и отклонить небезопасный маршрут. До внедрения изменений согласуйте назначение, запрещённые способы использования, владельца процесса, владельца данных, проверяющего, путь эскалации и измеримые критерии приёмки.
Предусмотрите и контролируемую фазу тестирования. Проверяйте типичные рутинные случаи и сложные пограничные ситуации. Посмотрите, что происходит, когда информации недостаточно, уверенность низкая или обращение приходит в формате, которого команда не ожидала. Поддерживайте очередь ошибок, ручной запасной путь и назначьте человека, уполномоченного остановить рабочий процесс при неожиданном поведении.
Такая работа может казаться более медленной, чем начало со списка функций. На практике она даёт команде более ясную основу для решения, какие части очереди достаточно повторяемы для оценки, а какие зависят от человеческого контекста, эмпатии, полномочий или профессиональной оценки.
Практический чек-лист для ознакомительной работы руководителя поддержки
Перед обсуждением рабочего процесса приёма и триажа с сервисным партнёром подготовьте:
- Примеры распространённых типов обращений, из которых удалена чувствительная информация или которые обрабатываются по одобренным внутренним правилам.
- Информацию, которую агенты используют, чтобы определить тему, срочность и ответственного.
- Список решений, которые должны оставаться за людьми.
- Действующие триггеры эскалации и ответственного владельца для каждого из них.
- Одобренные системы, ограничения доступа и владельцев данных, которые потребуется проверить.
- Определение приемлемого результата для команды и условия, при которых процесс должен остановиться или вернуться к ручной обработке.
KeepSolid Automations может использовать эту отправную точку, чтобы вместе с вашей командой оценить повторяемый процесс приёма обращений в поддержку. Разговор должен быть сосредоточен на текущем потоке, ответственности, исключениях, одобренных системах и критериях успеха, а не на общем обещании, что каждое обращение в поддержку можно или нужно автоматизировать.
Частые вопросы
Что такое триаж обращений в поддержку?
Триаж обращений в поддержку — это процесс проверки входящих запросов, определения информации, нужной для безопасной маршрутизации, назначения ответственного владельца и эскалации случаев, где требуется оценка человека. Точные правила должны соответствовать процессу обслуживания и границам риска команды.
Что следует автоматизировать в очереди поддержки в первую очередь?
Начните с оценки стабильных, чётко ограниченных шагов с одобренными входными данными и явными маршрутами для исключений. Подходящий кандидат зависит от процесса, данных, прав доступа и требований команды. Случаи, связанные с неопределённостью, спорами, уязвимостью, эмоциями или значимыми последствиями, должны оставаться за ответственными людьми.
Может ли рабочий процесс приёма самостоятельно принимать решения по клиентам?
Его не следует проектировать для самостоятельного принятия решений, связанных с клиентской политикой, правом, финансами или другими значимыми последствиями. Управляемый правилами рабочий процесс может выявлять информацию, предлагать маршрут или готовить черновик в утверждённых пределах, но полномочия по исключениям и решениям, требующим оценки, остаются у людей.
