Действительно интересно, спасибо за то, что поделились ценным опытом привлечения dev к процессу контактов с клиентом — нам крайне интересна такая тема, т.к. иногда чувствуется необходимость «сблизить» клиентскую и инженерную стороны сервиса. Идея с «разогревом девки» и привлечением к работе в саппорте разработчиков очень понравилась :)
Ваши действительно достойны отдельной статьи, тема это всегда актуальна для ориентированных на клиента IT компаний, на мой взгляд.
Наверное, если разработка и саппорт у вас в компании так близки, не возникает особых сложностей в понимании нужд клиента и их адаптации в продукте. Всегда интересовал вопрос, каким образом лучше донести клиентские жалобы до ушей разработки — любой фидбэк из саппорта все же обычно воспринимается не слишком «близко к сердцу», но когда сам творец оказывается на передовой, то наверное и ответственность ощущается лучше.
Денис, спасибо за вопросы и за то, что поделились собственным опытом! Также рады услышать, что пользуетесь Wrike :)
Постараюсь ответить на всё так же максимально развернуто:
1. Если я правильно понял ваш вопрос, интересно количество «простых» инцидентов и «сложных». Мы не ведем отдельный подсчет для каждого агента, но чтобы вы получили представление о масштабах:
— в среднем в неделю нагрузка по всем каналам на всех агентов > 2k тикетов
— как правило 10% процентов от общего числа тикетов составляют различного рода проблемные инциденты (категория product issue, по вашей классификации можем назвать их L2 инцидентами)
— большинство вопросов по продукту невольно затрагивают некую «проблему», которую клиент не может решить (в нашей статистике такие вопросы обозначаются как product question). Их доля ок. 40% от общего числа запросов.
В Т2 эскалируется в среднем 40-50 проблем в неделю, равномерно распределенная нагрузка на каждого агента при этом получается 6-7 проблем, хотя, конечно все работаю по-разному. Интересно, что с нашей новой системой все эти проблемы уже как правило валидные случаи для дальнейшей эскалации или же вопросы, на которые только Т2 сможет ответить (API, интеграции), т.к. Т2 работает напрямую с агентами первого уровня и консультирует уже «на подходе».
2. Каждый суппортер обязан разбирать новые тикеты из очереди по мере поступления, при этом ответ на них приоритетнее работы над «реактивированными», открытыми тикетами. Плюс в нагрузку даются чаты и звонки (в зависимости от роли агента). У нас действует «ассайн» новых тикетов, соотв. каждый имеет некое портфолио открытых, с которыми он ведет переписку. В итоге, по «реактивированным» тикетам ответственность личная, а по новым запросам – групповая.
3. У нас на самом деле по live каналам (чат, телефон) нет очередей, поэтому такое прогнозирование не ведется :) Вообще мы пользуемся эффективной SLA метрикой, которая устанавливает следующие целевые показатели: 90% чатов должны быть взяты за 30 секунд, 90% звонков за 20 с, 90% email тикетов получить первый ответ в течение часа.
4. Интересно, что вы имеете в виду под «утаиванием»? Передача проблем осуществляется через задачу в Wrike, в ней же хранятся технические записи для dev (в кач-ве подзадачи). Т2 агент составляет подробное и четкое описание, прилагает скриншоты, видео, логи и т.д. К тому же у нас прямая коммуникация ведется, всегда можно что-то уточнить лично.
5. Т2 выполняет функцию мостика между саппортом и другими отделами, не только инженерами. Мы пытаемся доводить до команды любые новости по развитию продукта и изменениям в нем, часто работаем с PM-ами (предоставляем фидбэк), присутствуем на митингах различных команд разработки. Knowledge-sharing через личный контакт также неотъемлемая часть работы – мы проводим тренинги, обучаем новичков процессам напрямую.
P.S. У нас есть свежее видео с выступления менеджеров, где рассказывается о базовых организационных вещах по работе Саппорта в целом, если вам интересно, можете глянуть: https://www.youtube.com/watch?v=YY5Bm3kDw-M
К вам также возникли вопросы:
1. Как в вашем случае все-таки различаются L1 и L2 уровни саппорта? Если работают одни и те же сотрудники, это лишь формальное деление по сложности задач?
2. Очень интересен опыт ответов разработчиков на тикеты, вовлечения их в «customer-facing» роль – насколько сложно это было воплотить в жизнь и есть ли какие-то хитрости в «приобщении»? Все-таки тяжело «технических» людей привлечь к клиентской работе.
Спасибо за комментарий — интересный опыт! В вашей ситуации отдел «разработчиков поддержки» действительно видится хорошей разгонной площадкой для новых разработчиков. Быть может, такой отдел на самом деле видится престижным для определенной категории сотрудников с интересом к техническим темам и разработке, не имеющих большого опыта в этой среде. К тому же взращенные у себя кадры всегда ценнее в плане уникальных знаний и приспособленности под конкретную работу. Еще главный плюс в таком подходе в том, что порой инженерам как раз не хватает понимания проблем и чаяний клиентов — а так выходит, что человек уже и с этой стороны подготовлен.
1. Обучение Т2 проходило постепенно, по ходу работы: некоторое время мы провели в изучении правил эскалаций, знакомстве с основными инструментами и рабочими ситуациями (т.е. изучали сам процесс); параллельно с этим запускали обучающие сессии по конкретным техническим темам (несколько итераций, от простого к сложному) — обучние работе с API, плагинам, интеграциям Wrike.
Что касается общего «траблшутинга», никакого особого тренинга наши агенты не получали — здесь, скорее, многое родилось само в процессе контактов с QA и dev и из опыта решения разного рода проблемных ситуаций. Мы также запустили свою внутреннию документацию для саппорта на основе этих знаний.
Насчет требований: во главу угла для Tier 2 агентов мы поставили навыки локализации и анализа проблемы (аналитические способности, умение отделить важное от второстепенного, умение грамотно и четко донести суть). Отдельно выделили важность коммуникативной составляющей — умение наладить общение как с людьми инженерного скалада ума, так и с клиентами. Ко всему прочему Т2 агент должен был стать опорой для товарищей из поддержки — здесь пригодится наличие менторских качеств, а также стремление помогать и объяснять (такой 'support for support' прицнип практикуется в поддержке Wrike и на уровне менеджмента).
2. Нашему Т2 процессу чуть больше года на данный момент, за это время мы расширили состав Т2 только единожды (+2 человека для прикрытия ночной смены, т.к. поддержка у нас 24/7) — никаких специальных тестов не проводили, но, безусловно, был важен опыт на первом уровне, интерес к технчиеским знаниям и аналитический склад ума. Я бы еще сравнил отбор в Т2 с собеседованием на роль помощника Шерлока Холмса — есть в процессе исследований клиентских проблем и багов что-то детективное :) И требования соответствующие.
3. Спасибо за ссылку, по этой статье Т2 относится скорее к Уровню-Линии 2 («аналитические методы решения», «оказание помощи первой линии» говорят прямо в его пользу).
В то же время в характеристике Уровня 3 указна ответственность «за исследования и развитие решений для новых, появляющихся, неизвестных ранее проблем» — все-таки в нашем случае Т2 иногда может взять на себя и эту функцию. Часто бывает, что Т2 агент сам находит проблему, выявляет ее источник, стабильный способ воспроизведения и передает напрямую разработчикам для фикса (QA остается только лишь официально подтрведить баг). В общем и целом, наши инженеры квалифицируются как Tier 3 в общей системе эскалаций, т.к. за ними всегда фикс любых багов, что, к сожалению, не в компетенции Tier 2 спецов.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Ваши действительно достойны отдельной статьи, тема это всегда актуальна для ориентированных на клиента IT компаний, на мой взгляд.
Наверное, если разработка и саппорт у вас в компании так близки, не возникает особых сложностей в понимании нужд клиента и их адаптации в продукте. Всегда интересовал вопрос, каким образом лучше донести клиентские жалобы до ушей разработки — любой фидбэк из саппорта все же обычно воспринимается не слишком «близко к сердцу», но когда сам творец оказывается на передовой, то наверное и ответственность ощущается лучше.
Постараюсь ответить на всё так же максимально развернуто:
1. Если я правильно понял ваш вопрос, интересно количество «простых» инцидентов и «сложных». Мы не ведем отдельный подсчет для каждого агента, но чтобы вы получили представление о масштабах:
— в среднем в неделю нагрузка по всем каналам на всех агентов > 2k тикетов
— как правило 10% процентов от общего числа тикетов составляют различного рода проблемные инциденты (категория product issue, по вашей классификации можем назвать их L2 инцидентами)
— большинство вопросов по продукту невольно затрагивают некую «проблему», которую клиент не может решить (в нашей статистике такие вопросы обозначаются как product question). Их доля ок. 40% от общего числа запросов.
В Т2 эскалируется в среднем 40-50 проблем в неделю, равномерно распределенная нагрузка на каждого агента при этом получается 6-7 проблем, хотя, конечно все работаю по-разному. Интересно, что с нашей новой системой все эти проблемы уже как правило валидные случаи для дальнейшей эскалации или же вопросы, на которые только Т2 сможет ответить (API, интеграции), т.к. Т2 работает напрямую с агентами первого уровня и консультирует уже «на подходе».
2. Каждый суппортер обязан разбирать новые тикеты из очереди по мере поступления, при этом ответ на них приоритетнее работы над «реактивированными», открытыми тикетами. Плюс в нагрузку даются чаты и звонки (в зависимости от роли агента). У нас действует «ассайн» новых тикетов, соотв. каждый имеет некое портфолио открытых, с которыми он ведет переписку. В итоге, по «реактивированным» тикетам ответственность личная, а по новым запросам – групповая.
3. У нас на самом деле по live каналам (чат, телефон) нет очередей, поэтому такое прогнозирование не ведется :) Вообще мы пользуемся эффективной SLA метрикой, которая устанавливает следующие целевые показатели: 90% чатов должны быть взяты за 30 секунд, 90% звонков за 20 с, 90% email тикетов получить первый ответ в течение часа.
4. Интересно, что вы имеете в виду под «утаиванием»? Передача проблем осуществляется через задачу в Wrike, в ней же хранятся технические записи для dev (в кач-ве подзадачи). Т2 агент составляет подробное и четкое описание, прилагает скриншоты, видео, логи и т.д. К тому же у нас прямая коммуникация ведется, всегда можно что-то уточнить лично.
5. Т2 выполняет функцию мостика между саппортом и другими отделами, не только инженерами. Мы пытаемся доводить до команды любые новости по развитию продукта и изменениям в нем, часто работаем с PM-ами (предоставляем фидбэк), присутствуем на митингах различных команд разработки. Knowledge-sharing через личный контакт также неотъемлемая часть работы – мы проводим тренинги, обучаем новичков процессам напрямую.
P.S. У нас есть свежее видео с выступления менеджеров, где рассказывается о базовых организационных вещах по работе Саппорта в целом, если вам интересно, можете глянуть: https://www.youtube.com/watch?v=YY5Bm3kDw-M
К вам также возникли вопросы:
1. Как в вашем случае все-таки различаются L1 и L2 уровни саппорта? Если работают одни и те же сотрудники, это лишь формальное деление по сложности задач?
2. Очень интересен опыт ответов разработчиков на тикеты, вовлечения их в «customer-facing» роль – насколько сложно это было воплотить в жизнь и есть ли какие-то хитрости в «приобщении»? Все-таки тяжело «технических» людей привлечь к клиентской работе.
1. Обучение Т2 проходило постепенно, по ходу работы: некоторое время мы провели в изучении правил эскалаций, знакомстве с основными инструментами и рабочими ситуациями (т.е. изучали сам процесс); параллельно с этим запускали обучающие сессии по конкретным техническим темам (несколько итераций, от простого к сложному) — обучние работе с API, плагинам, интеграциям Wrike.
Что касается общего «траблшутинга», никакого особого тренинга наши агенты не получали — здесь, скорее, многое родилось само в процессе контактов с QA и dev и из опыта решения разного рода проблемных ситуаций. Мы также запустили свою внутреннию документацию для саппорта на основе этих знаний.
Насчет требований: во главу угла для Tier 2 агентов мы поставили навыки локализации и анализа проблемы (аналитические способности, умение отделить важное от второстепенного, умение грамотно и четко донести суть). Отдельно выделили важность коммуникативной составляющей — умение наладить общение как с людьми инженерного скалада ума, так и с клиентами. Ко всему прочему Т2 агент должен был стать опорой для товарищей из поддержки — здесь пригодится наличие менторских качеств, а также стремление помогать и объяснять (такой 'support for support' прицнип практикуется в поддержке Wrike и на уровне менеджмента).
2. Нашему Т2 процессу чуть больше года на данный момент, за это время мы расширили состав Т2 только единожды (+2 человека для прикрытия ночной смены, т.к. поддержка у нас 24/7) — никаких специальных тестов не проводили, но, безусловно, был важен опыт на первом уровне, интерес к технчиеским знаниям и аналитический склад ума. Я бы еще сравнил отбор в Т2 с собеседованием на роль помощника Шерлока Холмса — есть в процессе исследований клиентских проблем и багов что-то детективное :) И требования соответствующие.
3. Спасибо за ссылку, по этой статье Т2 относится скорее к Уровню-Линии 2 («аналитические методы решения», «оказание помощи первой линии» говорят прямо в его пользу).
В то же время в характеристике Уровня 3 указна ответственность «за исследования и развитие решений для новых, появляющихся, неизвестных ранее проблем» — все-таки в нашем случае Т2 иногда может взять на себя и эту функцию. Часто бывает, что Т2 агент сам находит проблему, выявляет ее источник, стабильный способ воспроизведения и передает напрямую разработчикам для фикса (QA остается только лишь официально подтрведить баг). В общем и целом, наши инженеры квалифицируются как Tier 3 в общей системе эскалаций, т.к. за ними всегда фикс любых багов, что, к сожалению, не в компетенции Tier 2 спецов.