Упс! Не вдала спроба:(
Будь ласка, спробуйте ще раз.

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

Ольга Головко
Ольга Головко Support Team Lead у продуктовій IT-компанії Futurra Group
5 липня 2024 17 хвилин читання

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

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

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

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

Можливо, ви очікували, що ми одразу почнемо наймати людей і ставити їм задачі, але це не так. 

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

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

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

Приклад: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приклад: 

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

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

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

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

  • 1
    Кнопка “Support” у продукті;
  • 2
    Комунікація через email;
  • 3
    Соціальні мережі (Facebook, Instagram, Tik-Tok тощо);
  • 4
    Месенджери (WhatsApp, Telegram, Skype тощо);
  • 5
    Гаряча лінія (телефонні дзвінки);
  • 6
    Відгуки (App Store, PlayMarket, TrustPilot, ScamAdviser тощо);
  • 7
    Кнопка зворотного звʼязку у платіжних системах (наприклад, у PayPal).

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

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

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

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

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

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

  • 1
    Zendesk

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

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

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

  • ticketing system; 
  • підключення каналів комунікації (еmail, X, Meta);
  • логи інформації по клієнту;
  • налаштування і контроль часу відповіді;
  • API для побудови базової наскрізної аналітики; 
  • можливість налаштувати шаблони відповідей агентів (макроси) на типові запитання для ще швидшого реагування.

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: Прописати інструкції та шаблони відповідей

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

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

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

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

  • 1
    покрокового плану онбордингу агента підтримки;
  • 2
    розгорнутого огляду продукту (що отримує юзер, якщо натисне тут чи тут тощо);
  • 3
    всіх цін на продукт (в залежності від гео, пристрою тощо);
  • 4
    шаблонів відповідей на типові запитання клієнтів (для початку хоча б базові – як зареєструватись, оплатити і тому подібне);
  • 5
    SLA – у вас чітко має бути прописано, що ви очікуєте від агента (наприклад, відповідь до 5 хвилин, вирішення типових запитів за 10 хвилин і так далі);
  • 6
    гайдів по інструментам, якими буде користуватись агент (вони повинні бути написані так, щоб дитина 5 років змогла розібратись, де і що треба натиснути, щоб отримати бажаний результат).

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

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

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

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

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

Ну і не забувайте час від часу робити власні перевірки саппорту як юзер:)

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

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

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

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

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

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

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

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

Наприклад: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • бажаного графіку робот у команди підтримки (24/7,  9:00-18:00, тільки робочі дні і так далі.); 
  • прогнозованого навантаження та швидкості обробки запиту. 

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

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

Наприклад:

  • Можливі проблеми з електропостачанням, якщо агенти працюють з України;
  • Різниця в часових поясах. Наприклад, до технічної підтримки клієнти зі Штатів частіше звертаються в проміжку з 00:00 до 08:00 (16:00-00:00 за Києвом);
  • Середній час закриття типового тікета – до 10 хвилин (таких тікетів близько 90%).

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

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

  • 1
    Заробітна плата агентам;
  • 2
    Вартість розробки та впровадження необхідних для роботи інструментів (включно із вартістю сторонніх сервісів, наприклад Jira/Confluence, Zendesk тощо);
  • 3
    Вартість закупки необхідних для роботи девайсів (якщо ви плануєте надавати девайси від компанії агентам);
  • 4
    Вартість створення робочого місця в офісі (якщо вам потрібна оффлайн команда);
  • 5
    Вартість додаткових бонусів від компанії на агентів підтримки (опціонально);
  • 6
    Вартість найму агентів підтримки (робота HR, розміщення вакансії на джоббордах тощо);
  • 7
    Вартість керування відділом підтримки (заробітна плата керівника підтримки).

У підсумку

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

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

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

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

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.
50 UAH 150 UAH 500 UAH 1000 UAH 3000 UAH 5000 UAH
0
Прокоментувати
Інші матеріали

Протоколи Python у дії: застосування, типізація та відмінності від абстрактних класів

IT-команда NIX 2 години тому

Як використовувати метод “Брили, каміння, пісок” на практиці. Частина 2/3: пісок

Валерія Вольвач 5 годин тому

Коли замовники не платять за ІТ-контрактами

Максим Носарев 23 липня 2024 16:42

Kharkiv IT Cluster: бронювання, критичність та «Дія.Сіті» — як айтівцям працювати у 2024-му?

Olga Sukhorukova 23 липня 2024 07:36

Zero HR: інноваційний підхід до управління персоналом — Kharkiv IT Cluster

Olga Sukhorukova 22 липня 2024 16:04