Служба підтримки продуктової IT-компанії Quarks налічує 45 співробітників, які щомісячно обробляють від 75 000 до 100 000 звернень шістьма мовами. Брати під контроль такий потік запитів допомагає автоматизація роботи з тікетами. За 10 років роботи команда знайшла декілька рішень, що суттєво спростили та пришвидшили роботу сапорту. Що саме зробили, та як це вплинуло на фінальні показники — розповідає Роман Власенко, Support Team Lead у Quarks.
Як працює служба підтримки в продукті
Команда Quarks створює продукти та технології, які допомагають людям з усього світу знайомитися та спілкуватися онлайн. Основний продукт — платформу для онлайн-знайомств Kismia — завантажили понад 45 мільйонів користувачів у понад 20 країнах.
На перший погляд, автоматизація роботи агентів — це лише автоматичні відповіді та боти. Частково це справді так: впровадивши ці два підходи, ми зменшили навантаження на першу лінію підтримки на 50%, а отже суттєво оптимізували витрати компанії. Ефективна автоматизація запитів передбачає цілий комплекс заходів, які передують автовідповідям та допомагають їх оцінити. Про них і йтиметься далі.
Зазначу, що описані методи автоматизації звернень базуються на досвіді роботи з SaaS-сервісом Zendesk, але із залученням продуктової розробки їх можна інтегрувати й для інших сапорт-систем.
1. Використання макросів
Макроси — це стандартизовані відповіді на типові запитання. Їх можна надсилати без редагування або зі змінами залежно від запиту користувача. Підхід дає змогу просто й швидко відповісти на запитання клієнта, й водночас економить час працівників підтримки та запобігає випадковим помилкам.
Макроси — один із головних інструментів роботи агентів, тож зі старту варто дотримуватися єдиної системи їхніх назв та сортування. Особливу увагу приділіть тегуванню кожного макроса. Так ви спростите процес побудови аналітики й зможете розбудувати тригери для автовідповідей.
2. Створення категорій та тегів
Це основа, на якій будується майже вся автоматизація. Тегами можуть стати певні події на продукті або ж тема звернення юзера в сапорт — наприклад, «відновлення пароля», «запитання щодо оплати», позначки з інформацією про платформу, користувача тощо. Їх можна підв’язувати автоматично, додавати вручну чи передавати безпосередньо з продукту за допомогою АPІ. Вивчення запитів допоможе визначити ключові проблеми в продукті та прописати точніші відповіді.
Наприклад, після подібного аналізу ми додали до макросів інформацію, що перед видаленням анкети варто відключати платну підписку й прописали інструкцію, як це зробити. Також стандартизували пояснення, як шукати співрозмовника на сайті. Раніше підказки та рекомендації давали самі агенти. Однак подібних запитів було багато, а рекомендації майже не змінювалися — і ми «делегували» відповідь на ці питання боту.
3. Створення автоматичних відповідей
Вони робляться за допомогою тригерів і бізнес-правил в Zendesk та базуються на тегах чи подіях, як-от відправка листа з певного домену, наявність конкретного тексту, ключових слів або ж зміна статусу тікета. Ще один варіант — давати автоматичну відповідь за допомогою бота. Тут є нюанс: бот здатний реагувати на більшу кількість подій, особливо всередині продукту, але працювати з ним складніше. Аби його створити, потрібно буде залучати команду розробників та налаштовувати запити до вашої бази даних.
Найперше варто подбати про повідомлення, яким ви підтверджуєте, що одержали запит користувача. Пропишіть у ньому не лише деталі запиту, а й орієнтовний час на вирішення проблеми. Так людина впевниться, що її питання під контролем — а це зменшить кількість повторних листів.
Якщо запит складний, і його потрібно передати, наприклад, на другу лінію підтримки чи в інший відділ — створіть повідомлення про зміну статусу тікета. Далі ви зможете формувати гілки автоматичних відповідей, базуючись на власних потребах, а також на тегах всередині софту для роботи сапорту. Ось так, наприклад, виглядає одна з гілок нашого чат-бота:
4. Перенаправлення тікетів на відповідальних осіб або відділи
Щоби прискорити обробку тікетів, їх можна автоматично перенаправляти на відповідальних осіб згідно з категоріями та встановленими тегами. Так запит одразу потрапляє до релевантного співробітника, який знає, як вирішити проблему. В нашій команді процес такий: тікети спочатку направляють до тек, а потім всі запити обробляють відповідальні.
Приблизно 75% розподіляється автоматично за тегами, а інші 25% агенти опрацьовують вручну. Останнє трапляється, якщо, наприклад, агент розуміє, що має справу зі складним фінансовим запитом — і тоді він власноруч передає його до потрібної теки.
На які теки ми розподіляємо запити?
- Командні теки. Усього їх чотири: дві з новими тікетами різного спрямування й дві з тікетами в «режимі очікування». Останні — це ті, де для вичерпної відповіді недостатньо інформації від користувача. Тоді ми уточнюємо деталі у юзера й переводимо тікети до відповідної теки.
- Друга лінія підтримки. Тут все просто: до теки потрапляють складні запити, а також запити від регуляторів та юридичних осіб.
- Модерація. Команда модерації в Quarks належить більше до продукту, ніж до сапорту, тому всі пов’язані з нею запити автоматично направляються сюди.
- Білінг. Тут знаходяться запити від платіжних систем.
5. Створення бази знань для користувачів (FAQ)
Це ще один спосіб автоматизувати обробку запитів від клієнтів. FAQ має містити відповіді на популярні запитання про продукт та рішення проблем, які можуть виникнути у юзерів. Наприклад, як додати фото, замінити пошту чи пароль, користуватися пошуком на сайті.
Від того, де розміщена база знань, може залежати частота запитів до сапорту. Ось декілька можливих практик:
- FAQ разом з контактами сапорту додають у розділ «Підтримка»;
- FAQ разом з контактами сапорту додають до налаштувань;
- у продукт додають лише FAQ. Подібна практика популярна в багатьох глобальних та масштабних продуктах, як-от Tinder. Вона суттєво зменшує кількість звернень, однак підхід дуже ризиковий: до сапорту дійдуть тільки найвпертіші користувачі, розлючені через тривалий пошук контактів агента. Це точно не про хороший сервіс та утримання користувачів.
Також подумайте про створення внутрішньої бази знань для агентів. У ній має бути зібрана уся внутрішня кухня продукту — як провести верифікацію користувача, як працювати з потрібними сервісами, кому адресувати різні питання тощо.
6. Використання автоматичної системи оцінювання
Після вирішення проблеми клієнта варто автоматично надіслати запит на оцінку якості обслуговування. Це дає можливість отримати зворотний зв’язок про якість роботи сапорту та визначити слабкі місця в роботі. Zendesk дає змогу оцінити роботу агента або позитивно, або негативно (лайк чи дизлайк). Подібна функція створюється за допомогою правила автоматизації, яке дозволяє одразу відправити запит на оцінку при закритті тікета або налаштувати потрібний час.
Якщо дозволяють технічні можливості, варто запропонувати клієнту оцінити якість продукту та якість роботи підтримки окремо. Ідеально надати для цього хоча б 5-бальну шкалу, де 1 — це погано, 2 — потрібні покращення, 3 — задовільно, 4 — нормально, 5 — добре. Ці пункти потрібно розділити, аби зрозуміти, з чим варто попрацювати. Часто буває так, що в продукті щось не сподобалося, але сапорт нівелює неприємний осад.
Додавати опитувальник на 5-10 питань сенсу немає — користувачі швидко втратять інтерес до розлогої анкети, й ви ризикуєте не отримати жодних відповідей. Також не треба зловживати відкритими питаннями: ймовірно, ви уже знаєте, з яким запитом прийшла людина, тому не варто змушувати її дублювати інформацію. Ми використовуємо відкриті питання здебільшого в чатах, і не тоді, коли користувач приходить з проблемою, а коли він, наприклад, хоче видалитися. Відправляти запит на оцінку можна і одразу після відповіді агента, і через певний час.
7. Аналіз даних
Інформація про найбільш поширені проблеми та питання клієнтів допомагає покращити якість всього сервісу. Наприклад, раніше наші агенти самостійно відповідали на запити від забанених користувачів. Переглянувши аналітику, ми стали давати автоматичну відповідь цим юзерам або адресувати їх до команди модерації, де вони одержують більш детальну інформацію щодо блокування.
Використовувати можна вбудовану аналітику вашої CRM-системи або інформацію, записану в загальнопродуктову базу даних. Все залежить від того, які дані вам потрібні, та чи надає їх ваша СRM-система. Як показує практика, варіант трекінгу даних через загальнопродуктову аналітичну базу значно ліпший, бо дозволяє робити максимально детальний аналіз юзерів та їх запитів, враховуючи повну інформацію щодо користувацького досвіду на продукті.
На що я раджу звернути увагу:
- динаміка щодо типів запитів;
- швидкість обробки тікетів;
- мова звернення;
- платформа звернення;
- кількість переходів до бази знань;
- навантаження на агента. Його бажано розбити погодинно — так ви зможете чіткіше формувати графік роботи агентів, якщо вони працюють не за цілодобовим плаваючим графіком).
Завдяки якісному фідбеку користувачів можна робити багато змін у вашому продукті. Так, завдяки проханням користувачів ми впровадили нові методи оплати в продукті , і окрім кредитної картки, додали сервіси Boleto, OXXO, M-Pesa, Sofort. Або ще один приклад. Якось ми помітили, що маємо багато скарг на тарифні плани в Бразилії. Ми провели дослідження, й виявилося, що наші тарифи надто завищені, порівняно з прямими конкурентами. Це дало нам можливість швидко скорегували ціни в регіоні.
Як бачимо, автоматизація обробки запитів суттєво впливає на швидкість та якість роботи сапорту. За грамотної організації, сапорт обробляє запити швидше та якісніше, навантаження на службу підтримки менше, а рівень задоволення клієнтів — виший. Наприклад, медіана швидкості першої відповіді в командах змінилась з 29 хвилин до 9 хвилин. Використовуючи прості підходи та інструменти, які є у Zendesk чи інших системах, ви зможете побудувати сучасний та гнучкий сапорт, що відповідає інтересам клієнтів та створює позитивний імідж продукту.