Как составить отчет по тикетам службы поддержки: пошаговое руководство

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

Стоит четко зафиксировать правила подсчета, и отчет составится сам собой. Пропустите этот шаг, и два честных сотрудника, выгрузив одни и те же данные, получат результаты с разницей в несколько часов.

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

Что должно входить в отчет по тикетам поддержки

Сам по себе объем обращений почти ни о чем не говорит. Только правильная структура делает эти цифры пригодными для анализа.

Элемент	Зачем он нужен
Создано тикетов за период	Сторона спроса
Решено тикетов за период	Сторона предложения (на основе заданного правила статуса)
Бэклог на конец периода	Все тикеты, которые не были решены или закрыты
Время первого ответа	По выбранной шкале времени и конкретному определению
Время разрешения	Первое или полное (с четким указанием)
Повторно открытые тикеты	Показатель качества, который скрывают другие цифры
Тикеты без ответа	Точки, где процесс полностью дал сбой
Указанный временной базис и охват	Какие каналы, бренды и очереди включены в отчет

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

Zendesk публикует формулы расчетов, что позволяет проверять определения, а не спорить о них. В справочнике метрик и атрибутов подробно описана каждая из них.

Начнем с самого простого. Решенные тикеты — это «количество решенных или закрытых тикетов», то есть эта метрика охватывает сразу два статуса, а не один.

У «времени первого ответа» есть два официальных определения

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

В документации по SLA от Zendesk об этом сказано одной строкой: «Не путайте время ответа по SLA с собственной метрикой времени ответа Zendesk».

Собственная метрика строго учитывает, кто именно отвечает. Zendesk указывает, что «время первого ответа рассчитывается исключительно на основе ответов агентов». Автоматические действия и действия ботов «не учитываются при расчете времени первого ответа».

Метрика SLA устроена иначе. В ней время первого ответа — это «время между созданием тикета и первым публичным комментарием агента (или автоответом)». Zendesk добавляет, что «метрики времени ответа считаются выполненными, если вы настроили триггер для автоответа с публичным комментарием».

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

Таким образом, отчет, показывающий 98% выполнения SLA и четырехчасовую медиану первого ответа, не содержит в себе противоречия. Он просто отражает два разных показателя, и оба — верно.

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

Кроме того, общие тикеты не учитываются. Zendesk отмечает, что когда агент оставляет публичный комментарий из другой учетной записи, используя функцию совместного доступа к тикетам, «это не засчитывается во время первого ответа вашего аккаунта».

У «времени разрешения» тоже есть два

Такое же разделение характерно и для метрик разрешения, причем в данном случае обе версии доступны по умолчанию.

Время первого разрешения — это «промежуток времени между созданием тикета и его первым разрешением», который завершается в «момент, когда статусу тикета впервые присваивается значение solved».

Время полного разрешения — это «промежуток времени между созданием тикета и его самым последним разрешением». Оно завершается в «момент, когда статусу тикета в последний раз было присвоено значение solved».

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

Именно поэтому повторно открытые тикеты должны быть в отчете. Zendesk определяет их как тикеты, «открытые повторно после того, как они были решены», и отмечает, что эта метрика «не включает тикеты, которые были решены и снова открыты в рамках одного и того же обновления».

Существует и вторичный эффект, который часто упускают из виду. Среднедневное количество решенных тикетов учитывает их «только в том случае, если на данный момент они решены или закрыты». Таким образом, тикет, открытый повторно сегодня, незаметно исчезает из числа решенных за прошлый месяц.

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

Еще две метрики позволяют отделить время ожидания от времени работы. Время ожидания запрашивающего — это суммарное время в статусах new, open и on-hold, а время ожидания агента — это суммарное время в статусе pending.

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

Календарные или рабочие часы

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

Zendesk сохраняет оба значения. После первого публичного ответа «система рассчитывает время первого ответа в календарных и рабочих часах». Обе метрики «сохраняются вместе с данными тикета».

Настройки по умолчанию не всегда оптимальны. Zendesk отмечает, что готовые отчеты Explore «отображают информацию в календарных часах». Метрики рабочих часов «доступны и могут быть использованы в ваших собственных отчетах».

Таким образом, команда, работающая с девяти до пяти, в стандартном отчете будет выглядеть медлительной. Тикет, поступивший в пятницу в 18:00, до утра понедельника накопит около 63 календарных часов и практически ноль рабочих часов.

Каналы живого общения добавляют еще один нюанс. Метрика «Время первого ответа (сек)» для обмена сообщениями и чатов «игнорирует ваши настройки рабочих часов для сообщений и часов работы живого чата».

А соглашения об уровне обслуживания (SLA) по времени ответа в чате требуют ручного включения. Zendesk указывает, что SLA по времени ответа для живого чата «выключены по умолчанию», поэтому их отсутствие в отчетах — это лишь особенность настроек, а не показатель идеальной работы.

Как сделать это вручную

Вариант 1: Отдельная вкладка для каждой группы метрик

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

Держите колонки с календарными и рабочими часами рядом, а не выбирайте какую-то одну при экспорте. Рано или поздно у вас обязательно попросят вторую.

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

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

Вариант 2: Вкладка с определениями, составленная в первую очередь

Зафиксируйте определение времени ответа, используемую шкалу времени, метрику разрешения, правило статуса для решенных тикетов, входящие в отчет каналы и временной базис.

Затем укажите, какие выводы из отчета делать нельзя. Четкая фиксация того, что выполнение SLA и собственное время первого ответа измеряют разные вещи, убережет ваших коллег от попыток объединить их в одну цифру.

Ограничение здесь стандартное: документирование правила не гарантирует его соблюдения, и в следующем квартале кто-нибудь обязательно соберет сводную таблицу по памяти.

Вариант 3: Сегментация перед расчетом средних значений

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

Затем исключите или пометьте тикеты, которые искажают картину. Тикеты, ожидающие ответа клиента неделями, должны идти отдельной строкой, а не включаться в среднее время разрешения.

Покажите, что именно вы исключили и в каком количестве. Читатель, не видящий фильтра, решит, что данные не фильтровались.

Минус в том, что сегментация увеличивает объем работы в разы. Три канала, умноженные на две шкалы времени и две метрики разрешения, дают двенадцать разных показателей, которые нужно держать в голове.

Общее ограничение. Все три варианта предполагают, что выгрузка охватывает один и тот же диапазон дат на одном временном базисе для каждой очереди. Смешивание разных диапазонов на вкладках — самая частая незаметная ошибка в таких отчетах.

В каких моментах ручной подход буксует

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

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

Затем проявляется эффект повторного открытия. Данные за прошлый квартал больше не сходятся, и объяснение причин занимает больше времени, чем пересборка всего отчета.

Есть и четвертая сложность, которая возникает в критические моменты. Когда кто-то спрашивает, стала ли поддержка работать быстрее в этом квартале, для честного ответа сначала придется уточнить шкалу времени, определение и структуру каналов.

Чтобы оценить ситуацию со стороны удовлетворенности клиентов, ознакомьтесь с нашим руководством по созданию отчета NPS. Если проблема заключается в самом объеме обращений, наша инструкция по созданию AI-агента для предпродажной поддержки клиентов поможет разобраться с вопросом снижения нагрузки.

Как построить отчет с помощью Powerdrill Bloom

Шаг 1: Загрузите выгрузку тикетов

Загрузите выгрузку тикетов или выгрузки тикетов и SLA вместе. Powerdrill Bloom анализирует столбцы при загрузке, поэтому пустые временные метки, разные форматы дат и тикеты без первого ответа будут обнаружены еще до расчета медианы.

Шаг 2: Опишите отчет простыми словами

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

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

Шаг 3: Экспортируйте диаграмму, отчет или презентацию

Выгрузите таблицу метрик по каналам или график созданных и решенных тикетов с бэклогом на заднем плане. Слайды, содержащие определения рядом с цифрами, создаются в рамках того же процесса.

Распространенные ошибки

Использование показателя выполнения SLA вместо времени первого ответа. Первый показатель допускает автоответ, а второй полностью исключает автоматические действия.

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

Использование среднего арифметического для времени ответа и разрешения. Несколько заброшенных тикетов могут сместить среднее значение туда, где не находится ни один реальный тикет.

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

Указание времени разрешения без уточнения его типа. Время первого и полного разрешения — это разные сохраняемые метрики, а не варианты округления.

Отношение к числу решенных тикетов как к окончательному. Количество решенных тикетов включает только те тикеты, которые решены или закрыты на текущий момент, поэтому повторные открытия меняют прошлые данные.

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

Заключение

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

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

Вместо этого отслеживайте динамику относительно собственной истории по фиксированному набору правил. Именно такой подход покажет, улучшилось ли что-то на самом деле.

Если ежемесячная пересборка отчета отнимает у вас целый день, попробуйте Powerdrill Bloom для анализа выгрузки тикетов. Также посетите страницу AI report generator и инструмент voice of customer summarizer.

Часто задаваемые вопросы

Почему показатель выполнения SLA не совпадает со временем первого ответа?

Они измеряют разные события. Время первого ответа по SLA в Zendesk может быть закрыто автоответом, в то время как собственная метрика времени первого ответа полностью исключает автоматические действия и действия ботов.

Что лучше отражать в отчете: время первого разрешения или время полного разрешения?

Отражайте то, что вы указали в определениях. Время первого разрешения фиксируется при первом переводе тикета в статус solved. Время полного разрешения — при последнем, поэтому разница между ними обусловлена повторно открытыми тикетами.

В каких часах измеряются метрики поддержки — в календарных или рабочих?

Сохраняются оба показателя. Готовые отчеты Explore в Zendesk отображают календарные часы, а метрики рабочих часов доступны для отчетов, которые вы создаете самостоятельно.

Почему изменилось количество решенных тикетов за прошлый квартал?

Количество решенных тикетов включает только те тикеты, которые решены или закрыты на текущий момент. Тикет, открытый повторно после окончания периода, исключается из подсчета за этот период.

Можно ли сравнивать мое время разрешения со средними показателями по отрасли?

Только очень приблизительно. Определения, шкала времени и структура каналов гибко настраиваются, поэтому опубликованные показатели, скорее всего, рассчитывались по правилам, отличным от ваших.