На другій лінії фронту: наш досвід розвитку технічного відділу підтримки


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



Бізнес, який надає підтримку і супровід свого продукту або сервісу, повинен продумати, як це зробити максимально ефективно і зручно. З цією метою компанії формують багаторівневу систему саппорта, в якій все спілкування з клієнтом бере на себе технічно не досвідчений фахівець. При цій схемі для будь-якого агента підтримки досить мінімального набору знань в технічних областях — якщо буде потрібно, він зможе передати заявку до потрібного «технарю» для продовження роботи з конкретної проблеми (це специфіка роботи так званих «колл-центрів»). При переході на інший рівень процес, як правило, істотно сповільнюється або навіть зупиняється. До того ж, дроблення підтримки не дуже корисно в плані оптимізації витрат і організаційного управління: в загальну структуру привноситься більше «бюрократії», якість послуги загалом падає, а витрати зростають.

Нижче ми розповімо, як впоралися з ситуацією в Wrike.

Батальйони просять другий фронт
Підтримка компанії Wrike, в якій я працюю, спочатку використовувала багаторівневу структуру а ля «колл-центр» — більш складні технічні запити передавалися прямо до розробників, в той час як обробка всіх проблемних моментів і помилок лягала на плечі відділу QA. Тестувальники Wrike володіли необхідними технічними знаннями і компетенціями, але не могли вступати в діалог з клієнтом (всю переписку вели фахівці саппорта), а також не мали уявлення про те, що відбувається на рівні підтримки.

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

Інженери-тестувальники перестали справлятися із збільшеним навантаженням (в цьому випадку накладалася їх робота по запуску і тестування релізів) і не встигали якісно обробляти всі заявки. Ситуацію погіршували проблеми з комунікацією обидві сторони (агенти підтримки та інженери) часом з працею знаходили взаєморозуміння, буквально кажучи, на «різних мовах». Клієнти ж, у свою чергу, від цього тільки страждали — в процесі налагодження внутрішньої комунікації їхні запити часом кочували з однієї інстанції в іншу і назад, а саме рішення не рухалося з місця. Якщо уявити процес на спрощеною схемою, все виглядало приблизно так:



У цей момент перед нами постало питання: яким чином модифікувати процес і структуру обробки технічних запитів і, не втративши орієнтацію на споживача, додати в якості і швидкості вирішення проблем?

Tier 2: між саппортом і QA
Рішення знайшлося у створенні структурного підрозділу підтримки, що відповідає за технічні питання і ескалацію проблем до інженерам – Tier 2 – тобто «команди другого рівня» (далі Т2). Ідея полягала в тому, що досвідчені агенти підтримки, пройшовши через певний набір тренувань, спробують вийти на новий рівень у вирішенні технічних завдань. Іншими словами, нова команда повинна була стати «спецпідрозділом» підтримки, якому відводилася особлива технічна роль. Головною перевагою цієї ідеї був відхід від дроблення сервісу – Tier 2 полягав досвідчених агентів «першого рівня», які раніше були на передовій і активно допомагали колегам з обробкою клієнтських запитів, але в той же час більшу частину часу присвячували саме запитів і проблем технічного, інженерного характеру.

Як при цьому видозмінилися наша структура і процес? Якщо раніше для того, щоб розібратися в складових проблемного звернення клієнта і грамотно передати його в розробку могло знадобитися кілька днів (час займала обробка запиту інженерами QA, майже завжди зустрічаються повернення на підтримку з уточненнями деталей і т. д.), то тепер весь процес займав набагато менший час, на обробку та передачу йшло 1-2 години. До того ж знижувалася навантаження на обидві сторони – підтримку і QA.

Якщо агент підтримки бачив питання технічного плану, що входить в компетенцію Т2, він з'ясовував необхідні мінімальні деталі і передавав їх «спецам» зі свого відділу. Т2-агенти брали на себе додаткове спілкування з клієнтом і закривали кейс, вичерпно відповівши на питання. При цьому встановлювався часовий інтервал для обробки всіх «вхідних» запитів. Таким чином, у клієнта залишалося почуття задоволення від швидкого і якісного обслуговування. В коло технічних питань входили також найбільш складні теми – робота з Wrike API, налаштування інтеграцій з такими сервісами як Salesforce і конфігурація SAML SSO.

У разі, якщо «справа пахло багом» (або питання вимагало втручання інженерів), то Т2-агент допомагав своєму колезі на передовій зібрати потрібну для тестувальників інформацію (або робив це сам), а потім через контакт з QA і передачу потрібних деталей переконувався, що завдання взята в розробку. Іншими словами, Т2 курував всі баги і технічні проблеми, які надходять від клієнтів, і був у курсі деталей процесу розробки. Крім того, агенти «другого рівня» отримували всю необхідну налагоджувальну інформацію безпосередньо від інженерів, що дозволило їм здобути досвід у вирішенні деяких проблем без ескалації відділ розробки.

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

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



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

1. Метрика «Кількість повернень» гранично знизилася

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

За новою схемою запит не доходив до інженерів і забезпечена докладним коментарем (та, якщо потрібно, поясненням особисто) від агента Т2, який дозволяв агенту першого рівня зрозуміти свою помилку або отримати від клієнта відомості, необхідні для вирішення проблеми. Висока кількість повернень на початковому етапі говорило про проблеми з якістю обробки технічних питань і багів. За час адаптації нової структури Т2-агенти зуміли прищепити «культуру» ескалацій, які б не викликали запитань у інженерів, про що свідчить падіння рівня повернень майже до нульового. На графіку показана динаміка відсотка повернення звернень (від загальної кількості ескалацій) з Т2 з моменту введення нової системи. За 7 місяців існування нового процесу нам вдалося знизити середні показники повернень з 25% до 2%-3% (див. графік нижче).



2. Істотно скоротився час на обробку звернень клієнтів. Раніше відповідь від інженерів займав 24-48 годин, 1 година на обробку Т2, робочий день — на обробку інженерами.

3. Підвищилась якість і швидкість обслуговування технічних питань, зокрема щодо роботи з API і SSO.

4. QA-відділ розвантажив свій графік і зміг зосередитися на питаннях тестування.

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

6. У команді підтримки з'явився ще один вектор для кар'єрного зростання.

знадобилося для введення T2
1. Тренування п'ятьох агентів першого рівня з технічних питань (навчання на теми API, SSO, Salesforce).
2. Введення необхідних змін на технічній стороні для забезпечення безперервності процесу ескалації помилок і проблем у розробку (цей пункт гідний окремої статті).

Підведемо підсумки
  • Введення додаткової структури всередині підтримки не призвело до її розшарування і надмірної бюрократизації», а тільки посилило певні компетенції, роблячи команду більш технічно-орієнтованої в цілому.
  • Це виявилося простіше, ніж думали.
  • Це не вимагало додаткових витрат (крім виділення невеликої ресурсу на навчання).


Ідея зі створенням технічно-спрямованого підрозділи підтримки далеко не нова – багато компаній з успіхом її реалізовували і до Wrike. В кожному окремому випадку можливі свої комбінації та варіанти реалізації – все залежить від конкретної структури і бажаних результатів. Головне в цій справі — розуміння необхідності потрібних змін. У випадку з такими продуктами, як Wrike бажання і відгуки клієнтів в кінцевому підсумку визначають зовнішній вигляд і суть продукту, тому нам дуже важливо, щоб зв'язок з споживачем була завжди чітко налагоджена, особливо на технічній стороні. Ну і звичайно, важливо пам'ятати, що підтримка в цілому – це обличчя бізнесу, і те, як воно буде виглядати залежить тільки від нас.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.