Будуємо Customer Support ІТ-продукту з нуля: покроковий гайд

Customer Support — важлива складова ІТ-продукту, що не лише впливає на загальний імідж сервісу та трастовість користувачів до нього, а й дозволяє приносити вагомі результати бізнесу, у тому числі фінансові. 

За майже семирічний досвід у диджиталі, на моєму рахунку 5 створених з нуля або повністю реструктурованих команд клієнтської та технічної підтримки, команди продажів, а також команди по роботі з фінансовими претензіями Visa та Mastercard.

Долучившись до Futurra Group, моєю задачею було побудувати ефективну команду саппорту під новий продукт у ніші лайфстайл освіти, що тільки запускався, а також реструктуризувати вже існуючий на головному продукті компанії – MathMaster. 

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

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

Крок 1: Визначити, навіщо нам потрібен саппорт

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

Приклад: 

1) Нам потрібна команда підтримки, бо це підвищить довіру юзерів при виникненні запитань в процесі користування продуктом. В подальшому це потенційно вплине на їх повторні покупки і в результаті принесе нам більше прибутку.

2) Нам потрібна команда підтримки, аби обробляти фінансові скарги юзерів. Це допоможе нам знизити fraud rate. Низький fraud rate дозволить уникнути складнощів із відкриттям нових мідів для прийняття оплат від юзерів, або вбереже нас від проблем із транзакціями, що в перспективі принесе більше коштів нашому бізнесу.

3) Нам потрібна команда підтримки, аби наш продукт був максимально юзер френдлі, що позитивно вплине на його імідж.

Тож здебільшого все зводиться до таких цілей:

У нашій компанії до саппорту були саме такі запити. 

Крок 2: Прописати критерії роботи команди 

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

Ось деякі з критеріїв:

Спойлер — чим більше вимог до критеріїв, тим:

а) більша кількість агентів буде необхідна; 

б) більше коштів буде витрачатися на кожного з агентів. 

Кожен критерій повинен мати свої прямі або опосередковані показники ефективності: середня швидкість відповіді, середня швидкість вирішення тікету, зменшення рефанд/кенсел/чарджбек рейту, рівень задоволенності користувача тощо.

Важливо: показники повинні бути реалістичними. 100% якості роботи не буває навіть у машин. 

Приклад: 

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

Крок 3: Вибрати канали комунікації юзера із командою підтримки

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

Приклади варіантів, які можуть слугувати каналами комунікації:

Я не буду казати, що кращим рішенням буде підключити всі канали звʼязку. Звичайно, ідеальний варіант комунікації із командою підтримки для юзера – це коли в будь-який момент він може без проблем знайти варіант звʼязку.

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

На мою думку, для початку гарним комбо буде кнопка “Support” у продукті + комунікація через email + якісна обробка відгуків релевантної для вашого продукту платформи. Та канали комунікації – це все ж індивідуальна історія. Обирайте найкращі для вашого продукту та аудиторії.

Крок 4: Вибір інструментів для роботи агентів – CRM

Насправді для початку вам буде достатньо двох продуктів: CRM система та база знань. І ось, що я рекомендую:

Підписуйтеся на наші соцмережі

Можна почати із мінімального тарифу Support Team ($19 за агента в місяць на липень 2024го). 

У вас будуть доступні:

Zendesk в тарифі Support Team дає весь необхідний функціонал для розподілення всіх запитів на окремі views в залежності від правил та тригерів, які ви налаштуєте під свій продукт.

Приклад: 

Запит повинен відповідати всім або одному із критеріїв: прийшов із мобільної версії продукту, прийшов на пошту support@, має тег #math_master_IOS, це новий запит від юзера не доданий в жодний ланцюжок запитів до цього.

Окрім того, в самому ж Zendesk можна налаштувати час відповіді по SLA (Service Level Agreement), який буде підсвічувати тікети, на які треба відповісти в першу чергу.

Втім, для реально якісної роботи, я б все ж радила стартувати з тарифу Professional ($55 за агента в місяць). В ньому додається повний доступ до Zendesk Explore – це 100% маст хев для побудови більш точної і вузької звітності та контролю за всім, що відбувається у комунікації з юзером.

Наприклад, ви можете побудувати графіки часу відповіді на запит юзера (як перший, так і повторний):

або ж графік дотримання SLA (у нашого саппорту це відповідь протягом 5 хвилин):

Також ви можете відправляти юзерам, чий запит вже вирішено, повідомлення для оцінки якості саппорту – CSAT (Customer Satisfaction Score) – та виводити в окремі звіти їхні коментарі: 

Крок 5: Вибір інструментів – документація та база знань

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

Для нас я обрала Confluence (стандартний тариф $4.89 на місяць за агента).  Це продукт Atlassian, що дає можливість без проблем зметчити його, наприклад, із Jira (якщо вам потрібно, скажімо, аби саппорт ставив задачі на технічну команду). Як альтернативу можна використовувати Notion, або ж Google Docs.

У нашому Confluence можна знайти абсолютно все для швидкого старту роботи та пошуку відповідей на запит юзера – від onboarding плану агентів до огляду продуктів Futurra Group на різних девайсах, щоб агент в будь-який момент міг надіслати юзеру покрокову інструкцію стосовно будь-чого.

Окрім того, Confluence дає можливість побудувати схеми відповідей юзерам без використання сторонніх додатків.

Крок 6: Прописати інструкції та шаблони відповідей

У вас повинні бути інструкції стосовно всього, що може знадобитись вашим агентам. 

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

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

Базова її версія має складатися з: 

Важливо розуміти:

Можу вас запевнити, якщо вам здається, що ваша інструкція зрозуміла на 100%, це не так. Тож краще направити кожному агенту приватне повідомлення із складним запитом, щоб зрозуміти, чи вірно він зрозумів алгоритм дій.

Однією зі зручних практик є створення каналів “новин” у Telegram/Slack, де при всіх оновленнях будуть дублюватися короткі саммері із посиланнями. 

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

Крок 7: Кластеризувати запити в залежності від складності

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

Дієвим методом є прописування шляху клієнта від реєстрації до вирішення питання – всі кроки, які необхідно зробити користувачу і агенту. 

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

Додаю приклад найпростіших запитів, із якими ви можете стикатися:

Звичайно, кожне питання варто розписати в залежності від контексту. Як приклад, Answer Тemplates одного з наших продуктів:

Для більшості продуктів реальною цифрою буде вирішення >70% запитів протягом 10 хвилин без додаткових уточнень від юзера. 

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

Наприклад: 

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

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

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

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

Додам скрін нашої статистики (важливе уточнення – ми ведемо комунікацію із юзером, запитуємо причини його відписки і так далі):

Крок 8: Побудова гіпотез щодо обсягу звернень, які буде обробляти саппорт 

Безумовно, коли проєкт ще не має великих даних роботи команди підтримки з користувачами, досить складно зрозуміти, скільки саме юзерів будуть звертатися до нас щодня. 

Часткове вирішення цього питання реалізується завдяки двом крокам:

1. Якщо саппорту зовсім не було до цього: 

2. Прогнозування зростання/зменшення навантаження: 

Достатньо очевидно, що якщо бізнес очікує збільшення притоку користувачів, то і навантаження буде змінюватись майже пропорційно. Чому майже? Тому що середня кількість звернень від “старих” користувачів, з досвідом, може відрізнятись від середньої кількості звернень від нових. 

Так само навантаження може варіюватися від багатьох інших змінних (стан продукту, сезонність, вік, країна або інші атрибути нових користувачів).

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

Крок 9: Оцінити необхідну кількість агентів клієнтської підтримки

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

Наприклад, ми визначили, що 50 тікетів на день може закрити 1 агент самостійно. Для закриття 5000 тікетів на день необхідне відповідне збільшення кількості агентів + враховуємо, скільки часу ми даємо агентам на відповідь: 5 хвилин, 24 години тощо.

Для більш чіткого і якісного розподілу навантаження і агентів слід також брати до уваги і багато інших факторів.

Наприклад:

Крок 10: Розрахувати бюджет відділу підтримки 

Бюджет саппорту буде включати наступні статті витрат:

У підсумку

Якщо ви виконали всі кроки вище – побудували стратегію, встановили цілі, налаштували основні інструменти, прописали базову інформацію на Confluence – вітаю, тепер можете відкривати вакансії агентів підтримки. Далі вас чекає цікавий світ незвичайних клієнтських звернень! 🙂

Запровадивши цю стратегію, ми у Futurra Group змогли за два місяці покращити CSAT більше ніж на 20%, зменшити середній час відповіді юзерам до двох хвилин, а також спільними зусиллями саппорт та платіжної команд знизити fraud rate на 1 відсотковий пункт. З механізмами контролю ми можемо постійно підтримувати ці результати та щоразу їх покращувати. 

P.S. Памʼятайте, команда саппорту – це живий механізм, який треба постійно вдосконалювати та контролювати. Ця наполеглива праця принесе вам вдячних, лояльних користувачів, готових залишитись з вами надовго.