SaaS-компанія, з якою ми спілкувалися минулого року, вже пробувала передати підтримку на аутсорс. Три місяці, один постачальник і рівень вирішення на першому контакті, який так і не піднявся вище 50%. Вони назвали це невдалим експериментом і повернули всю підтримку всередину.
Коли ми розібралися, що сталося насправді, виявилося, що проблема була не в постачальнику. Близько 80% невирішених звернень потребували відповіді, яка існувала лише в одному місці - у голові старшого інженера. Ніхто її не записав. Жодна команда підтримки у світі не закрила б ці звернення за наданою документацією, бо документації не існувало.
Саме так провалюється більшість аутсорсу підтримки клієнтів. Не на постачальнику. На передаванні. Цей матеріал - про те, як зробити передавання правильно: як зрозуміти, що ви готові, що вам справді потрібно до першого дня і як обрати партнера, який закриває прогалину в знаннях, а не тоне в ній.
Чому аутсорс підтримки клієнтів насправді провалюється
Введіть у пошук «як передати підтримку клієнтів на аутсорс» - і кожен гайд дасть ті самі чотири кроки: визначте потреби, дослідіть постачальників, підготуйте матеріали для введення в роботу, відстежуйте показники. Усе це не помилкове. Усе це - обовʼязковий мінімум. І жодне з цього не вирішує, чи спрацює співпраця.
Один чинник передбачає результат краще, ніж розташування постачальника, ціна чи кількість людей: чи записані ваші знання про підтримку десь, окрім памʼяті конкретної людини. Якщо так - компетентний постачальник виходить на робочий ритм за тижні. Якщо ні - навіть найкраща команда показує низький рівень закриття звернень, ви вирішуєте, що вони погані, і розриваєте договір.
Нас чотири рази залучали виправляти провалений аутсорс. Щоразу коренева причина була однакова - попередньому постачальнику давали логін і розмите завдання, а потім очікували, що він закриватиме звернення, відповіді на які ніколи не були задокументовані. Провал був закладений ще до першого звернення.
| На чому наголошують гайди | Що насправді визначає успіх |
|---|---|
| Розташування та погодинна ціна постачальника | Чи записані ваші найчастіші типи звернень |
| Кількість агентів у команді | Чи відповідає один внутрішній відповідальний на питання в перший тиждень |
| Скільки каналів вони покривають | Чи визначена межа ескалації |
| Панель звітності | Чи видобуваються знання під час введення в роботу |
Тест пʼяти звернень
Щоб зрозуміти, чи готові ви, консультант не потрібен. Потрібні пʼять звернень і десять хвилин.
Візьміть пʼять найчастіших типів звернень - не рідкісні винятки, а ті, що щотижня наповнюють чергу. Для кожного поставте одне питання: чи зможе навчена людина поза вашою компанією вирішити це, користуючись лише тим, що записано, - без повідомлення інженеру, без «спитай засновника», без знань, які живуть тільки в чиїйсь голові? Порахуйте, скільки проходять.
Бал - це не оцінка «склав чи завалив». Це карта. Пʼять із пʼяти означає, що можна передавати зараз і просто надати доступ. Три-чотири означає, що ви готові - за умови, що постачальник задокументує решту прогалин під час введення в роботу. Нуль-два означає, що ваша підтримка тримається на знаннях, які живуть у людях, а не на сторінках, - і аутсорс провалиться, поки ці знання не видобуто. Хороша новина в останньому випадку: видобування знань - це робота, яку справжній постачальник виконує разом із вами. Це не привід чекати ще рік.
Що вам справді потрібно до першого дня
Загальні чек-листи перебільшують вимоги. Вам не потрібна вилизана, повна база знань до аутсорсу. Потрібні чотири конкретні речі, а решту допоможе зібрати хороший партнер.
- Доступ - ваша служба підтримки, ваші інструменти і можливість переглянути минулі звернення, щоб команда бачила, як вирішували раніше.
- Межа ескалації - що вирішує L1, а що передається на L2 чи розробку. Якщо це можна записати за 20 хвилин - формулювання достатньо чітке. Якщо ні - це перше, що треба виправити.
- Один внутрішній відповідальний - людина, яка відповідає на питання постачальника в перші тижні. Без неї передавання знань зупиняється.
- Визначені найчастіші типи звернень - 20-40 типів звернень, що становлять основну частину обсягу. Саме їх документують першими.
Зверніть увагу, чого немає в цьому переліку: готової бази знань. Саме ця відсутня річ - найпоширеніша причина, чому компанії відкладають аутсорс на рік, який не треба було чекати.
Передавання знань - це спільний результат, а не передумова
Більшість постачальників вважають вашу документацію вашою проблемою. Вони просять надіслати повну базу знань, а потім почати, коли вона надійде, - тобто ніколи, бо причина аутсорсу саме в тому, що ні в кого не було часу її написати. Кращі постачальники роблять навпаки. Вони сприймають видобування знань як частину роботи, яку виконують у перші тижні, разом.
Ось як це виглядає на практиці. У перший тиждень нова команда отримує доступ і спостерігає за тим, хто вирішує звернення сьогодні, - часто це засновник або старший спеціаліст підтримки. Команда фіксує найчастіші типи звернень, поки бачить, як їх вирішують. На другому-третьому тижні команда починає вирішувати під наглядом і пише коротку інструкцію з вирішення для кожного типового звернення. До четвертого тижня задокументовані типи звернень обробляються самостійно, а нотатки про ескалації повертаються до вашого внутрішнього відповідального з повним контекстом. Бази знань раніше не було. Тепер вона є - і побудована з реальних звернень, а не з припущень.
Ми проходимо саме цю послідовність на власній лінії L1. Для клієнта з індустрії iGaming наша команда має глибокі робочі знання ігор на платформі - від Aviator і аж до конкретних перевірок транзакцій та історії раундів, яких потребує спірне звернення гравця. Нічого з цього не надійшло в документі. Це було видобуто, записано і перетворено на інструкції з вирішення під час введення в роботу, а потім підтримувалося щоразу, коли продукт змінювався. Безладна або відсутня документація - це наша відправна точка, а не причина відмовитися від роботи.
Як обрати постачальника, який вас не підведе
Більшість порад щодо вибору постачальника - про ціну та відгуки. Це важливо, але не скаже вам, чи переживе співпраця передавання. Скажуть три питання.
- «Як ви працюєте зі знаннями, які ми ще не задокументували?» Слабкий постачальник каже «надішліть вашу базу знань». Сильний - описує, як він видобуває її разом із вами. Це найпоказовіше питання.
- «Як насправді виглядає перший тиждень?» Вам потрібні спостереження за роботою, фіксація типів звернень і призначений відповідальний за введення в роботу - а не «надішліть доступи, і ми почнемо».
- «Хто володіє базою знань після введення в роботу?» Правильна відповідь - вона спільна й жива: оновлюється щоразу, коли змінюється продукт, а не заморожується в день завершення введення.
Ще один сигнал - як вони рахують ціну. Оплата за звернення винагороджує кількість звернень, а не їх вирішення: постачальник заробляє більше, коли ваші клієнти змушені звертатися частіше, - а це протилежне тому, що вам потрібно. Фіксована місячна абонплата узгоджує інтерес постачальника з тим, щоб питання залишалися вирішеними, а обсяг падав. Ми використовуємо лише цю модель - саме з цієї причини.
Де тут IMMIDO
Ми ведемо шар L1: вирішення на першому контакті по ваших каналах, розширене або цілодобове покриття, тріаж ескалацій і щотижнева звітність у вашому стеку. Введення в роботу починається з видобування знань - ми документуємо ваші типові звернення з реальних рішень, тож рівень закриття зростає, а не застрягає. Ціна - фіксована місячна абонплата, зазвичай €7 000-14 000 за розширене або цілодобове покриття, яку ми називаємо після оцінки обсягу робіт: обсяг, години, мови та складність продукту.
Якщо вас цікавить саме вартість, ми розкладаємо цифри в нашому матеріалі про те, скільки насправді коштує аутсорс підтримки. А якщо хочете зрозуміти, яка модель покриття пасує вашому обсягу й ризику, - це та розмова про оцінку, яку ми проводимо з кожним клієнтом. Замовте дзвінок і отримайте пропозицію →