Контакт-центр. Як перетворити скарги на інсайти

Контекст

Контакт-центр банку щодня обробляв сотні й тисячі звернень клієнтів. Команда допомагала розв’язувати проблеми, знімала напругу в складні моменти й фактично утримувала сервіс у робочому стані навіть тоді, коли потік звернень здавався нескінченним.

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

Виклик

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

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

Підхід

Щоб відповісти на запитання керівництва, недостатньо було просто ще раз подивитися на статистику контакт-центру. Проблема починалася вже на рівні логіки обліку звернень. У банку існувала розгалужена система категоризації, яка історично виросла до більш ніж сотні категорій. Частина з них була надто широкою, як-от “Інтернет-банкінг”, частина - надто технічною, як-от “відсутність активації токена”. У такій системі звернення фіксувалися, але не пояснювали, що саме насправді відбувається з клієнтським досвідом.

Ми розглянули три можливі підходи до категоризації клієнтських звернень.

Перший - за відповідальними підрозділами. У цій логіці звернення діляться на теми, пов’язані з кредитами, депозитами, фінансовим моніторингом чи мережею відділень. Для великої організації це зручно, бо кожен департамент бачить “свої” проблеми. Але такий підхід майже не працює для складних клієнтських ситуацій, бо вони часто є кросфункціональними. Проблема виникає саме тому, що не має одного власника: жодна з функцій, залучених до її виникнення, не вважає себе головною.

Другий - за першою виявленою причиною. Наприклад, клієнт каже, що в нього не працює картка, а оператор бачить у системі, що причина - “неактивована опція”, і саме так позначає звернення. Це здається логічним, бо одразу підказує, що робити з конкретним кейсом. Але така категорія описує радше внутрішній діагноз, ніж саму проблему клієнта. За формулюванням “неактивована опція” можуть стояти дуже різні ситуації: технічний збій, погана комунікація, зайва складність продукту або навіть функція, яку варто було б увімкнути за замовчуванням.

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

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

Ключовий інсайт

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

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

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

Рішення

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

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

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

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

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

Результат

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

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

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

Висновок

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