Ключові показники звітності служби підтримки

Основні метрики звітності служби підтримки — це обсяг заявок, час до першої відповіді, середній час до вирішення (MTTR), вирішення з першого звернення (FCR), CSAT, дотримання SLA, накопичені та застарілі заявки, частка повторного відкриття, частка ескалацій, завантаженість користувачів, вартість однієї заявки та обсяг звернень за каналами. Відстежуйте їх разом як єдиний набір, а не як меню, з якого можна щось вибирати, адже ізоляція будь-якого окремого показника створює хибні стимули: зосередьтеся лише на швидкості — і частка повторних відкриттів зросте; зосередьтеся лише на CSAT — і вартість однієї заявки може збільшитися.

Мета зведення метрик звітності служби підтримки в одному представленні — одночасно охопити чотири завдання: ефективність, якість, робоче навантаження та витрати. Випустіть з уваги хоча б одне — і керуватимете, спираючись на неповну картину.

Ось робочий список, який варто додати на інформаційну панель уже сьогодні:

Обсяг заявок: загальний і за каналами, щоб чисельність команди відповідала попиту
Час до першої відповіді (FRT): скільки клієнти чекають на першу змістовну відповідь
MTTR: медіанний час до вирішення з розподілом за пріоритетами
FCR: відсоток заявок, вирішених без ескалації або подальших звернень
CSAT: оцінка задоволеності після завершення роботи із заявкою
Дотримання SLA: відсоток заявок, для яких виконано цільові показники відповіді та вирішення
Накопичені та застарілі заявки: відкриті заявки, згруповані за тривалістю очікування
Частка повторного відкриття: заявки, які після закриття було повторно відкрито протягом визначеного періоду
Частка ескалацій: відсоток заявок, переданих на другий або вищий рівень підтримки
Завантаженість користувачів: час активної роботи порівняно з доступною потужністю
Вартість однієї заявки: загальні витрати на підтримку, поділені на обсяг заявок
Обсяг звернень за каналами: розподіл між електронною поштою, чатом, телефоном і самообслуговуванням

Ваш наступний крок: створіть односторінкову щотижневу інформаційну панель, на якій відображатимуться обсяг заявок, FRT, MTTR, CSAT і вік накопичених заявок. Це найшвидший спосіб за п’ятнадцять хвилин зрозуміти, чи пішов тиждень не за планом.

Ключові висновки

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

Пункт	Деталі
Відстежуйте повний набір	Поєднуйте FRT, MTTR, FCR, CSAT, дотримання SLA, вік накопичених заявок, частку повторного відкриття, частку ескалацій, завантаженість і вартість однієї заявки.
Поєднуйте FCR із часткою повторного відкриття	Високий FCR сам по собі може приховувати передчасне закриття; частка повторного відкриття виявляє те, що не показує FCR.
Створюйте інформаційні панелі для різних аудиторій	Керівникам потрібні тенденції та витрати; менеджерам — робоче навантаження та ризики; користувачам — їхня власна черга.
Використовуйте дані в реальному часі для операційної роботи, а історичні — для стратегії	Глибина черги й таймери SLA визначають рішення протягом дня; дані про тенденції допомагають ухвалювати рішення щодо найму та змін процесів.
Автоматизуйте конвеєр даних	Deskhero структурує заявки з електронної пошти, форм і свого AI-чат-бота в одній системі та надає фіксовані подання статистики з експортом до Excel.

Зміст

Що таке метрики та KPI звітності служби підтримки?
14 основних метрик служби підтримки: визначення, формули та дії
Чим мають відрізнятися інформаційні панелі для керівників, менеджерів і користувачів?
Звітність у реальному часі проти історичної: яка вам потрібна?
Як встановити реалістичні цілі SLA та CSAT?
Яких помилок у звітності мають уникати менеджери?
Що має входити до щотижневого звіту, а що — до щомісячного?
Як насправді розрахувати ці метрики на основі необроблених даних?
Чим мають відрізнятися метрики IT-підтримки від метрик обслуговування клієнтів?
Чи можуть аналіз тенденцій і прогнозування покращити планування роботи служби підтримки?
Чому цей набір метрик працює для сучасних служб підтримки?
Застосуйте ці практики звітності у своїй службі підтримки
Джерела
FAQ

Що таке метрики та KPI звітності служби підтримки?

Метрика — це будь-яке число, яке ви вимірюєте. KPI — це метрика, пов’язана з цільовим показником, яка показує, чи є результат прийнятним. Обсяг заявок — це метрика; «вирішити 90% заявок протягом 8 робочих годин» — це KPI, побудований на основі метрики.

Метрики звітності служби підтримки зазвичай поділяються на чотири групи, і розуміння того, на яку саме групу ви дивитеся, допомагає не зосереджуватися надмірно на одному вимірі:

Метрики продуктивності: обсяг заявок, завантаженість користувачів, кількість заявок, закритих одним користувачем за день
Метрики ефективності: час до першої відповіді, MTTR, час до першої відповіді за каналами
Метрики якості: CSAT, FCR, частка повторного відкриття, оцінки контролю якості
Метрики витрат: вартість однієї заявки, вартість вирішеної проблеми, понаднормові години, пов’язані зі стрибками кількості накопичених заявок

Найпоширеніша помилка команд — обирати метрики тому, що певний інструмент їх відображає, а не тому, що вони відповідають бізнес-цілі. Якщо керівництво дбає про утримання клієнтів, CSAT і частка повторного відкриття можуть мати більше значення, ніж сама кількість заявок. Якщо керівництво дбає про планування чисельності команди, обсяг заявок і завантаженість користувачів можуть бути важливішими за CSAT. Почніть із рішення, яке вам потрібно ухвалити, а потім оберіть метрику, що допоможе його прийняти.

14 основних метрик служби підтримки: визначення, формули та дії

Кожна з цих метрик є інструментом менеджера, а не таблицею результатів. Ось що означає кожна з них, як її розрахувати, у яких розрізах аналізувати та що саме робити, коли її значення змінюється.

Обсяг заявок. Загальна кількість заявок, отриманих за певний період. Формула: кількість нових заявок із розподілом за каналом, пріоритетом і категорією. Якщо обсяг різко зростає без відповідних змін у продукті, перевірте наявність помилки, збою або маркетингової кампанії, що спричинила сплеск трафіку. Стабільне зростання обсягу без збільшення чисельності команди — це найперша ознака майбутніх проблем із накопиченими заявками.

Обсяг звернень за каналами. Розподіл обсягу заявок за джерелом надходження: електронна пошта, вбудовані вебформи, чат, телефон. Це показує, куди варто інвестувати для зменшення кількості звернень. Якщо обсяг чату потроюється, а якість вирішення погіршується, це прогалина в навчанні, а не нестача персоналу.

Час до першої відповіді (FRT). Час від створення заявки до першої змістовної відповіді користувача. Формула: сума (час першої відповіді мінус час створення) поділена на кількість заявок. Аналізуйте за каналом і пріоритетом. FRT корисний, оскільки вимірює перше очікування клієнта. Якщо FRT зростає, перевірте маршрутизацію, чисельність команди та попит, перш ніж обирати спосіб виправлення ситуації. Автоматичні підтвердження слід вимірювати окремо від змістовних відповідей. AI-автовідповіді Deskhero зараховуються як перша відповідь і позначаються окремо від відповідей людей.

Середній час до вирішення (MTTR). Середній або медіанний час від створення до вирішення. Формула: сума (resolved_at мінус created_at) поділена на кількість вирішених заявок. Використовуйте медіану разом із середнім значенням, коли багатоденні викиди спотворюють середній показник. Аналізуйте за пріоритетом і категорією. Зростання MTTR для заявок низького пріоритету, коли термінові заявки залишаються на тому самому рівні, може вказувати на проблему з тріажем або потужністю команди.

Вирішення з першого звернення (FCR). Відсоток заявок, закритих під час однієї взаємодії без подальших звернень або ескалації. Формула: кількість заявок, вирішених під час першого звернення, поділена на загальну кількість заявок, помножена на 100. FCR і частку повторного відкриття завжди слід розглядати разом. Високий FCR при зростанні частки повторного відкриття може означати, що користувачі закривають заявки передчасно.

CSAT. Оцінка задоволеності після вирішення, зазвичай рейтинг від 1 до 5, пов’язаний із завершальним опитуванням. Формула: кількість позитивних відповідей, поділена на загальну кількість відповідей, помножена на 100. Аналізуйте за користувачем, категорією та каналом. Падіння CSAT в одній категорії, наприклад у білінгу, за стабільного загального CSAT може показати, де потрібні навчання або перегляд процесу.

NPS або CES, якщо їх відстежують. Net Promoter Score вимірює лояльність, а Customer Effort Score — наскільки складною здавалася взаємодія. Жоден із них не замінює CSAT, але CES особливо корисний для виявлення труднощів у сценаріях самообслуговування ще до того, як клієнти відкриють заявку.

Дотримання SLA. Відсоток заявок, для яких виконано договірні терміни відповіді та вирішення. Формула: кількість заявок у межах SLA, поділена на загальну кількість заявок, помножена на 100. Аналізуйте за рівнем пріоритету, оскільки один узагальнений показник SLA приховує ситуацію, коли дотримання SLA для термінових заявок погіршується, а для заявок низького пріоритету виглядає добре.

Накопичені та застарілі заявки. Кількість відкритих заявок, розподілена за віковими групами (від 0 до 24 годин, від 1 до 3 днів, понад 3 дні). Зростання частки старих заявок може сигналізувати про проблему з потужністю або робочим процесом ще до порушення цільового показника SLA.

Частка повторного відкриття. Відсоток вирішених заявок, повторно відкритих протягом визначеного періоду, зазвичай 48 годин. Формула: кількість повторно відкритих заявок, поділена на кількість вирішених заявок, помножена на 100. Поєднання цієї метрики з FCR допомагає виявити, чи не досягається швидше закриття ціною ненадійного вирішення.

Частка ескалацій. Відсоток заявок, переданих за межі першого рівня. Формула: кількість ескалованих заявок, поділена на загальну кількість заявок, помножена на 100. Зростання ескалацій за стабільного обсягу заявок може вказувати на прогалину в знаннях, проблему з маршрутизацією або зміну складності заявок.

Завантаженість користувачів. Час активної роботи, поділений на запланований доступний час. Формула: час, витрачений на заявки, поділений на заплановані години, помножений на 100. Стабільна надмірна завантаженість може підвищувати ризик вигорання, тому інтерпретуйте цей показник разом із робочим навантаженням і відпустками.

Вартість однієї заявки. Загальні витрати на підтримку (зарплати, інструменти, накладні витрати), поділені на обсяг заявок за період. Це дає менеджерам і фінансовому відділу спільний спосіб обговорювати вартість підтримки.

Оцінки контролю якості. Ручне або за допомогою AI оцінювання розшифровок заявок за певною шкалою, що охоплює тон, точність і дотримання політик. Контроль якості додає контекст, якого можуть не показувати опитування задоволеності, особливо коли кількість відповідей на опитування невелика.

Метрика	Формула	Основна аудиторія
Обсяг заявок	Кількість нових заявок за період	Менеджер, керівник
Час до першої відповіді	Сума(час першої відповіді − час створення) / заявки	Користувач, менеджер
MTTR	Медіана(час вирішення − час створення)	Менеджер, керівник
FCR	Вирішення з першого звернення / загальна кількість заявок × 100	Менеджер
CSAT	Позитивні відповіді / загальна кількість відповідей × 100	Менеджер, керівник
Дотримання SLA	Заявки в межах SLA / загальна кількість заявок × 100	Менеджер, керівник
Вік накопичених заявок	Відкриті заявки, згруповані за віковою групою	Менеджер, користувач
Частка повторного відкриття	Повторно відкриті заявки / вирішені заявки × 100	Менеджер
Частка ескалацій	Ескаловані заявки / загальна кількість заявок × 100	Менеджер
Завантаженість користувачів	Час активної роботи / запланований час × 100	Менеджер
Вартість однієї заявки	Загальні витрати на підтримку / обсяг заявок	Керівник
Оцінка якості	Зважена оцінка за шкалою для кожної заявки	Менеджер, користувач

Щоб отримати повний розбір того, як ці визначення застосовуються до команд різного розміру, перегляньте основні метрики звітності служби підтримки для менеджерів підтримки.

Чим мають відрізнятися інформаційні панелі для керівників, менеджерів і користувачів?

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

Віджети для керівників: тенденція CSAT за 12 місяців, загальне дотримання SLA з порівнянням місяць до місяця, вартість однієї заявки, обсяг заявок у порівнянні з чисельністю команди та короткий список основних ризиків, сформований на основі ескалацій.

Віджети для менеджерів: поточна кількість відкритих заявок за пріоритетом і чергою, дотримання SLA за категоріями, розподіл робочого навантаження користувачів, тенденція FCR, частка ескалацій, розподіл заявок за віком і ковзні середні оцінки якості.

Віджети для користувачів: особисті відкриті заявки, глибина призначеної черги, наближення дедлайнів SLA та відповідні посилання на базу знань.

Порада: Зосередьте кожну інформаційну панель на головному. Додавайте посилання для деталізації замість того, щоб перевантажувати панель плитками, і прибирайте віджети, які не впливають на регулярні рішення.

Періодичність оновлення не менш важлива, ніж вибір віджетів. Глибина черги, дедлайни SLA та призначення заявок користувачам потребують актуальних даних, оскільки на їхній основі ухвалюються рішення протягом дня. Тенденції CSAT, вартість однієї заявки та середні оцінки якості можна оновлювати щодня або щотижня, адже вони інформують про рішення, наслідки яких проявляються протягом довших періодів. Актуальні операційні дані допомагають менеджерам помічати перевантажені черги й перерозподіляти роботу до того, як почнуть порушуватися дедлайни.

Чим мають відрізнятися інформаційні панелі для керівників, менеджерів і користувачів? Оглядова схема

Звітність у реальному часі проти історичної: яка вам потрібна?

Звітність у реальному часі допомагає ухвалювати операційні рішення безпосередньо в момент їхньої появи; історична звітність підтримує стратегічні рішення, які приймаються протягом тижнів або кварталів. Плутанина між ними призводить до того, що команди витріщаються на поточну інформаційну панель під час обговорення найму або дістають квартальний звіт, щоб вирішити, хто працюватиме в післяобідню зміну.

Мета	Частота оновлення	Часовий горизонт	Ключові метрики	Аудиторія
Операційна (маршрутизація, планування персоналу)	У реальному часі або щогодини	Той самий день	Глибина черги, дедлайни SLA, статус користувачів	Менеджер, користувач
Стратегічна (найм, процеси)	Від щоденної до щомісячної	Від тижнів до кварталів	Тенденція MTTR, тенденція CSAT, вартість однієї заявки	Менеджер, керівник

Операційні інформаційні панелі мають допомагати ухвалювати рішення щодо маршрутизації та планування персоналу, тоді як історичні звіти є правильним інструментом для рішень про найм, інвестицій у навчання та змін процесів. Змішування цих двох типів лише створює шумне, реактивне управління.

Щодо даних, три звички усувають більшість проблем зі звітністю: об’єднайте всі джерела заявок в одну систему, перш ніж звітувати за ними; перевіряйте, що часові мітки статусів відповідають реальності; автоматизуйте повторювані експорти, коли вбудованого звіту недостатньо. Заявка, позначена як «вирішена» через кілька днів після фактичного усунення проблеми клієнта, спотворить MTTR незалежно від інструмента звітності.

Щодо вибору інструмента, вирішальним фактором зазвичай є те, де вже зберігаються ваші дані. Power BI часто добре підходить для середовищ, де переважають продукти Microsoft, тоді як Tableau зазвичай використовують для об’єднання кількох джерел. Що б ви не обрали, переконайтеся, що ваш експорт або API містить ID заявки, часові мітки відповідних змін статусу, пріоритет, категорію, виконавця та канал. Перевірте точний набір полів відповідно до розрахунків, які використовуватиме ваша інформаційна панель.

Як встановити реалістичні цілі SLA та CSAT?

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

Виміряйте поточний базовий рівень для кожної метрики щонайменше протягом чотирьох — шести тижнів, щоб згладити вплив одного невдалого тижня.
Оберіть діапазон орієнтирів з галузевих джерел або серед аналогічних команд, скоригувавши його відповідно до вашої моделі підтримки (служба підтримки B2B SaaS і команда електронної комерції з великим обсягом звернень не повинні мати однакову ціль MTTR).
Встановіть поетапну ціль із часовими рамками, наприклад підвищити дотримання SLA з 82% до 90% протягом двох кварталів, а не вимагати 95% уже наступного місяця.
Пов’яжіть цілі з плануванням потужності, щоб цілі покращення супроводжувалися необхідними інвестиціями в персонал або автоматизацію, а не лише наказом.

Задокументуйте визначення, джерело даних, базовий рівень, ціль і дату перегляду для кожного KPI. Звіти з орієнтирами можуть надати контекст, але ваша ціль має враховувати канал, серйозність, обіцянку клієнту, робочі години та доступну потужність.

Яких помилок у звітності мають уникати менеджери?

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

Відстеження середніх значень замість перцентильного часу приховує найгірші випадки. Показуйте медіанний MTTR і MTTR на 90-му перцентилі поруч.
Винагородження лише швидкості (швидке закриття, високий FCR) без контролю частки повторного відкриття може стимулювати користувачів закривати заявки до фактичного усунення проблеми.
Ігнорування частки повторного відкриття створює прогалину в контролі якості; додайте цю метрику, якщо ваша система обліку заявок не показує її за замовчуванням.
Однакове ставлення до всіх каналів приховує той факт, що очікування щодо FRT для чату й електронної пошти кардинально різняться.
Низька якість даних (дублікати заявок, неправильно позначений пріоритет) непомітно спотворює всі подальші метрики; проводьте аудит тегування заявок щоквартально.

Що має входити до щотижневого звіту, а що — до щомісячного?

Щотижневі звіти охоплюють операційний стан; щомісячні — тенденції та вплив на бізнес.

Обсяг заявок і розподіл за каналами за тиждень
FRT, MTTR, CSAT і FCR у порівнянні з цільовими показниками
Дотримання SLA з розподілом за категоріями
П’ять основних категорій заявок за обсягом
Розподіл робочого навантаження користувачів і будь-які сигнали нестачі потужності
Один абзац із підсумком головної події тижня

У щомісячному звіті для керівництва висвітлюйте місячні та річні тенденції CSAT, дотримання SLA і вартості однієї заявки, чисельність персоналу порівняно з попитом, коротку примітку про запущені ініціативи та виміряний вплив від них, а також майбутні ризики, як-от сезонні сплески обсягу.

Придатне для використання формулювання може мати такий вигляд: «Цього тижня обсяг заявок зріс на 14% через помилку в білінгу, дотримання SLA для термінових заявок знизилося до 84%, тому ми рекомендуємо тимчасово залучити додатковий персонал, доки виправлення не буде випущено». Цифри наведено для прикладу, але структура дає читачеві зміну, причину, наслідок і дію. Готові макети дивіться в шаблонах інформаційних панелей підтримки клієнтів Deskhero.

Як насправді розрахувати ці метрики на основі необроблених даних?

Точність розрахунку залежить від одного чинника більше, ніж від будь-якої формули: узгоджених часових міток статусів і чіткого спільного визначення понять «вирішено» та «закрито». Якщо половина команди позначає заявку як вирішену після випуску виправлення, а інша половина — після підтвердження клієнта, ваш MTTR порівнює дві різні речі.

FRT = first_response_at − created_at, усереднене або взяте як медіана за період
MTTR = resolved_at − created_at, медіанне значення з розподілом за пріоритетом
FCR = (заявки з нульовою кількістю перепризначень і повторних відкриттів) / загальна кількість заявок
Частка повторного відкриття = заявки, повторно відкриті протягом 48 годин / вирішені заявки
Завантаженість користувачів = time_spent / scheduled_hours
Дотримання SLA = заявки, що відповідають SLA / загальна кількість заявок

Необхідні необроблені поля: ID заявки, created_at, first_response_at, resolved_at, closed_at, журнал змін статусу, пріоритет, черга, виконавець, time_spent і центр витрат.

Простий запит для FRT і MTTR за діапазон дат виглядає так:

SELECT AVG(first_response_at - created_at) AS avg_frt,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY resolved_at - created_at) AS median_mttr
FROM tickets
WHERE created_at BETWEEN :start_date AND :end_date;

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

Чим мають відрізнятися метрики IT-підтримки від метрик обслуговування клієнтів?

IT-підтримка та клієнтська підтримка вимірюють успіх по-різному, хоча обидві працюють із чергами заявок. Метрики IT-підтримки більше зосереджені на MTTR, частці ескалацій і дотриманні SLA, пов’язаному із серйозністю інциденту, оскільки вартість простою значно перевищує вартість трохи повільної відповіді. Заявка про збій P1 потребує іншого таймера SLA та іншого шляху ескалації, ніж запит на скидання пароля, а об’єднання їх в один показник MTTR приховує обидві відмінності.

Натомість служби обслуговування клієнтів і підтримки електронної комерції можуть надавати більшої ваги CSAT, FCR та обсягу звернень за каналами, оскільки вплив на бізнес проявляється в утриманні клієнтів і повторних покупках, а не в доступності системи. Продавець на Shopify, який обробляє запити про статус замовлення, може більше цікавитися FRT у клієнтських каналах, ніж MTTR рідкісної технічної ескалації. Інтеграція Shopify Deskhero додає до відповідних заявок актуальний контекст про клієнта, замовлення, виконання та відстеження, а каталог продуктів може бути використаний для створення чернеток відповідей AI.

Рішення полягає не у виборі одного набору метрик замість іншого. Якщо ваша команда працює з обома моделями підтримки, сегментуйте інформаційну панель за моделлю підтримки, щоб внутрішня IT-черга та клієнтська черга мали окремі рівні SLA, окремі правила ескалації та окремі цільові орієнтири, а не одне узагальнене число, яке погано підходить до обох.

Чи можуть аналіз тенденцій і прогнозування покращити планування роботи служби підтримки?

Аналіз тенденцій перетворює показник-знімок на інструмент планування, а прогнозування дає змогу заздалегідь сформувати команду відповідно до попиту, а не реагувати на нього постфактум. Незмінний показник CSAT повідомляє, де ви перебуваєте сьогодні; 12-місячна лінія тенденції CSAT показує, чи справді спрацювала зміна процесу минулого кварталу.

Найпрактичніше застосування — прогнозування обсягу. Якщо обсяг заявок стабільно зростає щолистопада через цикл запуску продукту, зіставлення сезонної закономірності з чисельністю команди дає змогу заздалегідь запросити тимчасовий персонал. Та сама логіка застосовується до частки ескалацій: стабільне зростання може спонукати до розслідування ще до погіршення дотримання SLA.

Аналітика підтримки може виконувати два різні завдання: щодня підтримувати здоровий стан черги та аналізувати вміст заявок для виявлення повторюваних тем, які допомагають командам продукту й клієнтського досвіду. Відстежуйте і операційні результати, і повторювані теми, щоб програма звітності підтримувала не лише керування чергою.

Чому цей набір метрик працює для сучасних служб підтримки?

Найчастіша помилка, яку я бачу, полягає не у виборі поганих метрик. Вона полягає у виборі хороших метрик окремо одна від одної. Команда, яка звітує про FCR без частки повторного відкриття, має чудовий вигляд на папері — аж доки клієнти не починають двічі подавати одну й ту саму скаргу. Поєднання показників ефективності з перевіркою якості — саме те, що захищає службу підтримки від оптимізації, яка зрештою погіршує обслуговування.

Це групування — ефективність, якість, робоче навантаження та витрати разом — працює, оскільки відображає те, як насправді ухвалюються рішення щодо персоналу та продукту. Ви не наймаєте людей, спираючись лише на CSAT, і не маршрутизуєте заявки, спираючись лише на вартість однієї заявки. Вам потрібен повний набір, який слід щотижня розглядати разом.

Застосуйте ці практики звітності у своїй службі підтримки

Створення звітів вручну з окремих експортів електронної пошти та форм створює зайву роботу. Deskhero перетворює поштову скриньку Gmail або Microsoft 365 на службу підтримки та зберігає заявки з електронної пошти, вбудованої форми й AI-чат-бота в одній системі. Його інформаційна панель показує обсяг заявок, середній час до першої відповіді, середній час до вирішення та час перебування в кожному статусі. Фіксований розділ статистики додає подання тенденцій, перцентилів часу відповіді, SLA, команди, каналів, AI і тем із фільтрами та експортом до Excel для кожної вкладки.

Deskhero

Заявки, створені електронною поштою, через вбудовану форму на вебсайті або вбудований AI-чат-бот, потрапляють до однієї спільної скриньки. Чернетки відповідей AI можуть використовувати ширший пул знань робочого простору, тоді як відповіді чат-бота для клієнтів і AI-автовідповіді використовують лише затверджені публічні FAQ. Багатомовна підтримка допомагає користувачам перекладати заявки та відповіді. Кластер «Теми» виділяє повторювані теми, а експорт статистики та REST API надають можливості для подальшого аналізу. Deskhero не містить конструктора власних звітів, тому командам, яким потрібна спеціальна інформаційна панель, слід використовувати експортовані дані або дані, доступні через API, в інструменті BI.

Якщо ви перебудовуєте робочий процес звітності, можете розпочати 30-денний безкоштовний пробний період без кредитної картки та дослідити подання «Інформаційна панель» і «Статистика» в Deskhero.

Застосуйте ці практики звітності у своїй службі підтримки. Оглядова схема

Джерела

Ці джерела підтверджують наведені вище орієнтири, правила дизайну інформаційних панелей і рекомендації щодо інструментів, а кожне з них докладніше розглядає окрему частину загальної картини.

FAQ

Які ключові метрики використовують у звітності служби підтримки?

Основний набір включає обсяг заявок, час до першої відповіді, MTTR, FCR, CSAT, дотримання SLA, вік накопичених заявок, частку повторного відкриття, частку ескалацій, завантаженість користувачів і вартість однієї заявки. Їх слід відстежувати разом, а не по одному.

Які 5 ключових метрик CX?

Більшість команд будують звітність про CX на CSAT, FCR, часі до першої відповіді, частці повторного відкриття та дотриманні SLA, оскільки ці п’ять показників поєднують швидкість, якість і надійність в одну зрозумілу картину.

Які є приклади KPI для IT-служби підтримки?

KPI IT-служби підтримки зазвичай включають MTTR за рівнем серйозності, дотримання SLA для інцидентів P1, частку ескалацій і вік накопичених заявок, оскільки IT-підтримка надає більшої ваги серйозності інцидентів, ніж загальне обслуговування клієнтів.

Які KPI є ефективними для IT-відділу?

Окрім метрик на рівні заявок, IT-відділи часто відстежують вартість однієї заявки, завантаженість користувачів і вирішення з першого звернення, щоб збалансувати якість обслуговування з витратами на персонал і доступною потужністю.

Як часто мають формуватися звіти служби підтримки?

Операційні віджети, як-от глибина черги та дедлайни SLA, потребують актуальних даних, тоді як метрики тенденцій, такі як CSAT і вартість однієї заявки, часто можна оновлювати щотижня або щомісяця.

Чи може платформа служби підтримки на кшталт Deskhero автоматично обробляти цю звітність?

Deskhero збирає заявки з електронної пошти, вебформ і свого AI-чат-бота в одній системі. Його фіксовані вкладки статистики охоплюють тенденції, час відповіді, SLA, користувачів, канали, AI і теми, а також містять фільтри та експорт до Excel для кожної вкладки. Для команд, яким потрібен подальший аналіз, також доступний REST API.

Показники звітності служби підтримки, які варто відстежувати менеджерам