Понеділок, ранок. До служби підтримки пишуть кілька компаній-клієнтів. Хтось не бачить учорашнього звіту, хтось - нічних операцій, хтось не може додати нового користувача. Жодна з цих компаній не знає, що в інших той самий збій.
Саме так до підтримки доходить збій у продукті, яким користуються компанії. У кожному зверненні йдеться про дані компанії, яка його надіслала: її звіти, її операції, її користувачів. Якщо читати їх по черзі, вони здаються різними проблемами. Насправді в них спільна причина.
Один збій - багато акаунтів
Коли звернення про той самий збій надходять від кількох компаній одразу, завдання першої лінії - помітити, що вони повʼязані. Обʼєднати їх в один інцидент, повідомити команду продукту, яких акаунтів стосується інцидент, і надіслати кожній із цих компаній однакове коротке повідомлення про статус. Тоді інцидент - це одне розслідування. Якщо ж розбирати кожне звернення окремо, те саме розслідування повторюється для кожної компанії, яка написала.
Щоб таке помітити вчасно, дві речі варто вирішити заздалегідь: як повʼязувати звернення у вашій системі підтримки і хто з боку продукту підтверджує, що це інцидент, а не збіг. Якщо збій зачепив і тих клієнтів, які ще не написали, повідомлення про статус може дійти до них раніше, ніж вони звернуться.
Підтримка B2B-клієнтів: звернення, що стосуються акаунта
На питання, як працює продукт, можна відповісти статтею з довідки. На питання, що сталося в конкретному акаунті, відповідь можна знайти лише в самому акаунті: в операціях, налаштуваннях, користувачах, історії змін. Ця стаття про такі звернення, бо саме від них залежить, з яким доступом має працювати перша лінія.
Відповісти на таке звернення - це спершу розслідування, а вже потім лист. Хтось має відкрити акаунт, знайти операцію, побачити, де вона зупинилася, і лише тоді писати клієнтові.
Ми ведемо підтримку, у якій звернення надходять від компаній, а не від споживачів, тож наша перша лінія працює саме зі зверненнями про акаунт.
Більшість B2B-клієнтів очікує, що підтримка знає їхню особисту інформацію
В опитуванні Gartner, яке охопило понад 5800 клієнтів і проводилося в грудні 2021 року, 86% B2B-клієнтів очікували, що компанія, до якої вони звертаються по підтримку, буде добре обізнана з їхньою особистою інформацією. Серед B2C-клієнтів таких - сімдесят один відсоток.
У прес-релізі Gartner ідеться про особисту інформацію. Те, що це очікування поширюється й на дані акаунта, - наше тлумачення, а не висновок Gartner. Самі ж цифри показують ось що: серед бізнес-клієнтів частка тих, хто цього очікує, вища, ніж серед споживачів. Ми розуміємо це так: вони чекають, що їх упізнають без пояснень, хто вони, а в B2B це ще й означає, що хтось із вашого боку бачить, від імені якої компанії пише людина і що ця компанія вже повідомляла.
Те саме опитування показало, що клієнти водночас очікують, що їхні дані лишаться конфіденційними й захищеними і використовуватимуться лише за призначенням. Для першої лінії це аргумент за обмежений доступ до акаунта, а не за відкритий доступ до всього.
Крім того, від імені однієї компанії можуть писати різні люди: хтось із фінансового відділу - про рахунок на оплату, адміністратор - про права доступу, операційний керівник - про збій. Якщо сказане кожним із них лишається тільки в памʼяті одного агента, наступна людина з цієї компанії починає з нуля. Історія має зберігатися в акаунті, де її прочитає будь-хто, хто відповідатиме наступним.
Що має бачити перша лінія і що вона передає далі
У дослідженні Salesforce 26% представників служби підтримки кажуть, що їм часто бракує відомостей про ситуацію клієнта, а 80% вважають, що від кращого доступу до даних інших відділів їхня робота виграла б.
Для першої лінії, яка відповідає компаніям, ці відомості цілком конкретні: журнал операцій, налаштування акаунта, умови договору з клієнтом, нотатка акаунт-менеджера після останнього дзвінка. Агент, який не може цього відкрити, може зробити зі зверненням лише одне - переслати його далі. Пересилання - це не робота першої лінії. Це поштова скринька, перед якою сидить людина.
Чого перша лінія не може відкрити, того вона не може перевірити. А все неперевірене лягає на вашу команду пересланим зверненням.
Коли перша лінія працює поза вашою компанією, доступ стає питанням договору, і це питання треба вирішити до першої зміни: до яких систем, лише на читання чи також на редагування, з чиїми обліковими даними входять агенти і на яких умовах обробки даних. Питання власності ми розібрали окремо: хто володіє інструментами, у яких працює зовнішня команда підтримки. Там же описано правило: платіжні дані лишаються поза доступом зовнішньої команди, якщо робота цього не потребує. Дані про операції - це теж платіжні дані, і саме їхня перевірка є тією роботою, яку це правило передбачає: доступ до них дають лише на читання, окремим задокументованим рішенням.
Частину звернень перша лінія не закриє навіть за найкращого доступу: відповідь є у вашого фінансового відділу, у розробників, у платіжного провайдера або в системі самого клієнта. Для цього й існують наступні лінії підтримки. Як вони ділять роботу між собою, ми пояснили в матеріалі про рівні підтримки L1, L2 і L3. Візьмімо звернення: «Виплата у вашій системі позначена як відправлена, а до нас не надійшла. Чиї дані правильні?» Ескалація з таким зверненням має передавати результат перевірки, а не лише переказ самого звернення: що перша лінія перевірила, що виключила і чого ще бракує. Тоді наступна людина починає там, де зупинилася перша, а не перечитує лист клієнта з початку.
B2B і B2C: що змінюється, коли клієнт - компанія
| Що змінюється | Що закласти | Чому |
|---|---|---|
| Хто пише | Працівник компанії-клієнта, який користується продуктом у роботі | Коли питання про дані його компанії, відповідь є лише в її акаунті |
| Що потрібно для відповіді | Доступ до акаунта на читання: операції, налаштування, користувачі, нотатки | Без нього перша лінія може лише переслати звернення |
| Де зберігається історія | В акаунті, а не в памʼяті одного агента | Від однієї компанії можуть писати різні люди |
| Що містить ескалація | Що перевірено, що виключено, чого ще бракує | Наступна лінія починає там, де зупинилася перша |
| Що потрібно під час інциденту | Один спільний інцидент і однакове повідомлення про статус для кожного зачепленого акаунта | Звернення від багатьох компаній надходять водночас, кожне про свої дані |
Про що домовитися, перш ніж зовнішня команда почне відповідати вашим B2B-клієнтам
- До яких систем перша лінія матиме доступ на читання з першої зміни і з чиїми обліковими даними. Усе, що лишилося поза доступом, стає пересланим зверненням.
- Хто з вашого боку приймає ескалацію, у якому інструменті і що вона має містити, перш ніж її надіслати.
- Хто оголошує інцидент і хто надсилає повідомлення про статус компаніям, чиї акаунти зачепив збій.
- Строки відповіді для кожного акаунта, зафіксовані письмово, якщо за вашими договорами різні клієнти мають різні умови.
- Де зберігається історія акаунта, щоб наступна людина з компанії-клієнта не починала з нуля.
Що робить IMMIDO
Ми ведемо першу лінію підтримки 24/7 у ваших власних інструментах. Звернення, з якими ми працюємо, надходять від компаній, а робота саме така, як описано вище: перевірка звернень і операцій, робота з інцидентами - у Jira та інших системах, якими вже користується ваша команда.
Працюємо як команда з фіксованою місячною платою, а не з оплатою за кожне звернення. Строки відповіді фіксуємо в договорі з кожним клієнтом.
Якщо ви продаєте компаніям і хочете зрозуміти, чи може зовнішня перша лінія закривати звернення ваших клієнтів, а не пересилати їх, почніть із того, як ми ведемо першу лінію. Або запишіться на дзвінок, і почнемо з першого пункту списку: які системи ваша перша лінія зможе відкрити вже на першій зміні.
Джерела: Gartner, прес-реліз про опитування клієнтів, проведене в грудні 2021 року (очікування B2B- і B2C-клієнтів під час взаємодії зі службою підтримки) · Salesforce, Latest Customer Service Statistics (представники служби підтримки про брак відомостей і доступ до даних).