S — Situation

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

SLA отсутствует в принципе и в результате пользователи с реально важными проблемами могут ожидать обратной связи дольше, чем стояло бы.

T — Task

A — Action

Делю задачу на две больших части:

Приоритезация тикетов на основании категорий обращений + проработка SLA

  1. Готовлю опросник для сотрудников поддержки (цель опроса выяснить с какими типами запросов по их мнению пользователи обращаются в поддержку)

    1. На основании полученных ответов выделяю несколько основных категорий (проблемы с платежами, проблемы с учетной записью, вопросы технического характеры, вопросы о работе приложения, идеи и пожелания, политики конфиденциальности, иное)

    2. Выдвигаю ряд предложений стейкхолдерам по части связки “Категория обращения” → “Приоритет” → “SLA на время первого ответа” → “SLA на решение тикета” и согласовываю с ними один из вариантов. Пример: Обращения с связанные с платежами классифицируются как срочные. Сотрудник поддержки должен отреагировать на обращение в течении двух часов, и решить его течении 4 часов.

    3. Приступаю к технической части:

      1. Добавляю кастомное поле с категориями обращений в Zendesk

        image.png

      2. Настраиваю их автоматическую приоритезацию на основании категории через Triggers conditions

        image.png

      3. Настраиваю SLA для First Reply и Resolution

        image.png

    4. Готовлю кастомные дашборды для работы сапорта с сортировкой обращений по приоритетам и визуализаций SLA

  2. Автоматическая категоризация обращений

    1. Ищу готовые “коробочные” решения, которые бы позволили автоматически (по тексту обращения пользователя) определять категорию его запроса. Нахожу ряд подходящих плагинов для Zendesk под данную задачу, но все они выходят за рамки установленного бюджета

    2. Провожу ресерч и принимаю решение попробовать самостоятельно сделать AI-агента под эту задачу. В качестве flow manager решаю использовать open-sourse решение n8n, для распознавания и категоризации текста bart-large-mnli модель от Facebook. Она заточена под задачи категоризации, а еще распространяется по лицензионной модели MIT, что позволяет ее бесплатно использовать в коммерческих целях

    3. В итоге AI агент был мной настроен следующим образом: n8n через webhook от Zendesk выявляет момент регистрации тикета в системе → через GET запрос агент получает список всех возможных категорий (доступных в Zendesk) → преобразует этот список в формат “читаемый” моделью → немного ждет → через GET запрос получает текст обращения пользователя → преобразует этот текст в формат “читаемый” моделью → передает в модель два блока с данными (пользовательский текст + варианты категорий к которым нужно этот текст отнести) → получает ответ от модели с вероятностными весами к какой именно категории относится это текст → агент выбирает из ответа наиболее вероятную категорию по мнению модели и присваивает ее обращению.

      image.png

      Далее срабатывает автоматизация из раздела 1d и 1e и тикету присваивается приоритет и время на реагирование согласно SLA.

    4. Далее мной был подготовлен внутренний документ, описывающий SLA и принципы разбора обращений, который был доведен до команды поддержки.

R — Result