На второй линии фронта: наш опыт развития технического отдела поддержки
Наверняка почти у каждого есть парочка любимых историй об общении с саппортом компаний, товарами или услугами которых мы пользуемся каждый день. Во многих случаях нас раздражает долгое ожидание ответа и его поверхностное содержание, а проблемы, в свою очередь, редко находят быстрое и действенное решение. Корень этих проблем обычно лежит в организации процессов поддержки.
Бизнес, который предоставляет поддержку и сопровождение своего продукта или сервиса, должен продумать, как это сделать максимально эффективно и удобно. С этой целью многие компании формируют многоуровневую систему саппорта, в которой все общение с клиентом берет на себя технически не сведущий специалист. При этой схеме для любого агента поддержки достаточно минимального набора знаний в технических областях — если потребуется, он сможет перенаправить заявку к нужному «технарю» для продолжения работы по конкретной проблеме (это специфика работы так называемых «колл-центров»). При переходе на другой уровень процесс, как правило, существенно замедляется или даже стопорится. К тому же, дробление поддержки не слишком полезно в плане оптимизации затрат и организационного управления: в общую структуру привносится больше «бюрократии», качество услуги в целом падает, а затраты возрастают.
Ниже мы расскажем, как с ситуацией справились в 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 желания и отзывы клиентов в конечном итоге определяют внешний вид и суть продукта, поэтому нам очень важно, чтобы связь с потребителем была всегда четко налажена, в особенности на технической стороне. Ну и конечно, важно помнить, что поддержка в целом — это лицо бизнеса, и то, как оно будет выглядеть зависит только от нас.
