Лайфхаки от Haier: с нуля запустили скоростную обработку обращений

Внутреннюю службу поддержки сразу начали делать «по-взрослому»
С середины 2020 года мы стали переносить поддержку во внутреннюю компетенцию и строить колл-центр внутри компании. Мы сразу пошли в сторону создания взрослой унифицированной поддержки, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.

Настроили воронку для входящих обращений, чтобы максимально сократить срок их обработки
Мы сразу настроили воронку для входящего потока сообщений и в итоге у нас получилось очень неплохо: ребята успевают день-в-день обрабатывать запросы и хорошо выполняют SLA. Нам удалось реализовать давнюю мечту всех саппорт-служб — первый ответ клиент получает в течение часа. А вопросы, которые не требуют нескольких итераций, у нас решаются в среднем за сутки. И практически всегда не дольше трёх дней — в ситуациях, когда нужны дополнительная информация от клиента либо участие каких-то других служб.

Подключили трёхуровневую систему автоответов, чтобы снять лишнюю нагрузку с агентов
Чтобы агенты не мониторили состояние тикетов вручную и не занимались «копипастом», мы настроили три уровня автоответов на входящие обращения: стандартная отбивка о приёме заявки, отбивка-напоминание и отбивка-закрытие.

Установили нормативы для сотрудников и следим за числом итераций, чтобы быстро исправлять ошибки
Как с помощью системы настроить распределение простых и сложных кейсов по агентам?
Есть два варианта:
1. Для универсальных бойцов — один норматив для всех, когда система сбалансировано предлагает агенту разные по сложности задачи.
2. Для сотрудников с узкой специализацией — разные нормативы, кто-то делает только простые кейсы, а кто-то — только сложные.

Настроили разные напоминалки для разных задач, чтобы вовремя отвечать на все заявки
В зависимости от темы, бизнес-процесс обработки обращений немного отличается. У нас все бизнес-процессы описаны, поэтому мы знаем не только время, которое в среднем уходит на каждый этап, но и как итерационно его оптимизировать и управлять распределением интервалов между напоминалками.

Используем отчёты Юздеска для контроля за качеством работы поддержки
Мы смотрим ежедневную, еженедельную и ежемесячную аналитику в зависимости от задач по оптимизации процессов, которые мы себе поставили. То есть статистику из Юздеска мы используем и для операционного контроля, и аналитической работы — это два отдельных блока. Задача операционного контроля — вовремя выявить и исправить проблемы в работе операторов, задача аналитической работы — обнаружить системные проблемы в работе поддержки, если они есть, и самое интересное — найти точки роста и зоны для улучшения.

Что дальше
Сейчас мы подключили только почту и отладили процессы на всех почтовых каналах. Теперь по той же схеме готовимся подключать чат на сайте, а за ним — чат в приложении, которое ещё в разработке. А дальше у нас грандиозные планы по оптимизации работы в соцсетях, которые мы тоже планируем подвязать на Юздеск.

Изначально в России бытовую технику Haier продавали через дистрибьюторов. С 2017 компания запустила онлайн продажи и брендшопы.

До пандемии 2020 года объёмы продаж росли плавно, а поддержка была на аутсорсе и состояла из двух частей: поддержка интернет-магазина — заказ, доставка; послепродажное обслуживание — заявки на ремонт, обслуживание. У каждого подразделения были разные кураторы.
Но с началом карантина в 2020 году продажи через интернет-магазин сильно выросли, а за ними начал развиваться и колл-центр. С середины 2020 года мы стали переносить поддержку во внутреннюю компетенцию и строить колл-центр внутри компании. Мы сразу пошли в сторону создания взрослой унифицированной поддержки, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.

Мой опыт работы с Юздеском как с основной хелпдеск-системой начался в Haier. До этого я работала с их конкурентом, но оказалось, что Юздеск — приятная альтернатива зарубежному решению. Причин, почему мы выбрали Юздеск, две: его проще настраивать и он дешевле. У его конкурента достаточно сложная логика настройки правил, а в Юздеске это реализовано более нативно и современно. Приятно было увидеть, что за последние годы ребята сильно шагнули вперед и добавили много полезных фич.
В своей 10-летней практике работы в службе поддержки я настраивала разные хелпдеск-системы — формировала бизнес-требования и бизнес-процессы. Поэтому, присоединившись к команде Haier и начав отстраивать внутренний колл-центр, я уже на старте осознанно настраивала хелпдеск-систему так, чтобы максимально сократить срок обработки обращений.

Мой совет, если вы только внедряете хелпдеск, начните с одного канала: настройте воронку для входящих обращений, подключите систему автоответов, установите нормативы для сотрудников, подключите для них напоминалки и наладьте работу с аналитикой и контролем качества. А когда всё будет готово, подключить остальные каналы по тому же принципу уже проще — неважно сколько их, пять или пятнадцать.

Концепция в том, чтобы максимально тегировать поступающие обращения по тематикам и приоритетности на уровне системы. А дальше на основании этих правил тикеты раскладываются в нужные фильтры-очереди, которые обрабатывают разные скилл-группы сотрудников. Если тикет после автоматической фильтрации попал не туда, то агент уже вручную тегирует его, присвоив нужную тематику обращения, и тикет попадает в нужный фильтр. Если в системе всё правильно настроено, то за счёт правильного распределения тикетов по каналам и грамотной работы с приоритетами — несколько уровней SLA в зависимости от сложности и важности запроса — сильно сокращается срок обработки задач.

У нас внутри каждого из двух направлений есть несколько скилл-групп, которые частично взаимозаменяемы. То есть внутри направления сотрудники универсальные бойцы, и сейчас мы всех агентов, за исключением новичков, включаем во все скилл-группы. С нашей спецификой так удобнее — это позволяет максимально эффективно распределять нагрузку между сотрудниками и быстро реагировать на резкий наплыв обращений по какой-то тематике. Благодаря статистике, которую собирает Юздеск, мы видим ситуацию с входящими обращениями: где сотрудники успевают или не успевают и SLA начинает «проседать», как быстро собирается очередь, сколько времени тратится на обработку. В зависимости от этого мы усиливаем агентами тот или иной канал.

Есть два варианта обработки агентом тикетов:
1. Агент по очереди обрабатывает тикеты из списка, который формируется из всех очередей его скилл-групп в порядке приоритетности по SLA.
2. Агент видит фильтры по тематикам и выбирает, какие обрабатывать в первую очередь. Например, мы видим, что сейчас у нас очень много тикетов упало в фильтр «доставка», поэтому мы операционно повышаем приоритет их обработки, а остальные тикеты, по менее загруженным тематикам, откладываем на несколько часов.

Мы ещё экспериментируем с настройками фильтров, тегов и автоматических правил в Юздеске, чтобы выбрать оптимальную схему с учётом особенностей бизнеса и профиля распределения входящего потока по времени: дням, неделям, месяцам.

Ведь чем меньше объёмы, тем легче лавировать, меньше потребность в потоковых процессах и можно использовать индивидуальный подход к разным ситуациям клиентов. А чем выше нагрузка, тем потоковость важнее — чтобы агент работал с теми тикетами и тематиками, которые предлагает система, не задумываясь над выбором. При высокой нагрузке становится более актуальным распределение агентов по скилл-группам и уровням: первая, вторая и третья линии поддержки.

Например, вы хотите, чтобы несколько агентов постоянно и неизменно занимались только доставкой. Вы создаёте скилл-группу по доставке, добавляете в неё нужных агентов, настраиваете теги и фильтры, чтобы участники видели только список тикетов по доставке. В результате они отвечают только на вопросы по доставке и не берутся за другие задачи. Такой подход помогает агентам скилл-группы работать быстрее, так как экономит время и интеллектуальные силы специалиста на переключения между разными вопросами.
При этом с точки зрения набора знаний агенты могут быть универсальными и из смены в смену их можно переводить из одной скилл-группы в другую. К примеру, сегодня агент в скилл-группе по доставке, а завтра — по гарантийным обращениям и так далее по кругу. Это позволяет очень гибко распределить нагрузку между сотрудниками в зависимости от изменений в потоке входящих обращений и делает их взаимозаменяемыми.

Мы сразу настроили воронку для входящего потока сообщений и в итоге у нас получилось очень неплохо: ребята успевают день-в-день обрабатывать запросы и хорошо выполняют SLA. Нам удалось реализовать давнюю мечту всех саппорт-служб — первый ответ клиент получает в течение часа. А вопросы, которые не требуют нескольких итераций, у нас решаются в среднем за сутки. И практически всегда не дольше трёх дней — в ситуациях, когда нужны дополнительная информация от клиента либо участие каких-то других служб.

Чтобы агенты не мониторили состояние тикетов вручную и не занимались «копипастом», мы настроили три уровня автоответов на входящие обращения: стандартная отбивка о приёме заявки, отбивка-напоминание и отбивка-закрытие.

В зависимости от темы обращения мы понимаем, сколько в среднем нужно времени на его обработку. На этой основе мы и определяем норматив. Например, если для ответа по конкретной теме нужен час, значит, агент может за один восьмичасовой рабочий день обработать максимум семь заявок такого типа. Если обработка заявки занимает минуту, то норматив, соответственно, другой.
А дальше самое интересное — как с помощью системы настроить распределение простых и сложных кейсов по агентам?

Есть два варианта:
1. Для универсальных бойцов — один норматив для всех, когда система сбалансировано предлагает агенту разные по сложности задачи.
2. Для сотрудников с узкой специализацией — разные нормативы, кто-то делает только простые кейсы, а кто-то — только сложные.

К примеру, у нас сейчас нет чёткого распределения агентов по специализации — по набору знаний они у нас универсальные. Поэтому на данном этапе мы устанавливаем нормативы эффективности на основе среднего времени обработки тикета. В будущем, когда объёмы вырастут, думаю, перейдем на другую схему распределения нагрузки и оценки эффективности сотрудников.

Сейчас мы больше смотрим на количество итераций по тикетам — выделяем задачи, которые требуют больше итераций. Это нужно, чтобы разобраться, почему итераций так много, и найти способ сократить их количество. А если это невозможно, то какие-то итерации стараемся автоматизировать и этим ещё больше ускорить обработку обращений.

Например, у нас есть ситуация, когда агенту довольно часто приходится напоминать коллеге из соседнего отдела о том, что мы ждём от него ответ по задаче. Увидев это, мы настроили проактивное автоматическое пингование коллеги на основе SLA. Теперь, если агент, работая с тикетом, запрашивает дополнительную информацию у коллеги, он использует статус «На удержании». Такой ожидающий тикет попадает в отдельный фильтр, в котором настроено правило: когда приближается срок выполнения, коллеге приходит напоминание, что нужно решить вопрос.

В зависимости от темы, бизнес-процесс обработки обращений немного отличается. У нас все бизнес-процессы описаны, поэтому мы знаем не только время, которое в среднем уходит на каждый этап, но и как итерационно его оптимизировать и управлять распределением интервалов между напоминалками.

Если мы понимаем, что железобетонно хотим решить даже сложный вопрос клиента в течение трёх дней, значит, мы внутри устраиваем процессы так, чтобы все итерации уложились в эти три дня. В том числе — внутреннюю коммуникацию с другими департаментами и возможную необходимость получения дополнительной информации от клиента. Например, если мы понимаем, что по теме Х нужно сделать три «приседания», значит, мы выделяем максимум по 12 часов на каждое. То есть в каждой теме есть правила, в которых прописаны сроки автоответов.

Мы смотрим ежедневную, еженедельную и ежемесячную аналитику в зависимости от задач по оптимизации процессов, которые мы себе поставили. То есть статистику из Юздеска мы используем и для операционного контроля, и аналитической работы — это два отдельных блока. Задача операционного контроля — вовремя выявить и исправить проблемы в работе операторов, задача аналитической работы — обнаружить системные проблемы в работе поддержки, если они есть, и самое интересное — найти точки роста и зоны для улучшения.

Операционный контроль. Супервайзеры и руководители групп ежедневно верхнеуровнево проверяют, чтобы сотрудники выполняли SLA, и смотрят на время между итерациями. Например, первый тикет агент взял в 10 утра, второй — в 11 утра. Промежуток между статусом «выполнено» по первому тикету и статусом «в работе» по второму — полчаса. Здесь возникает вопрос, что человек делал полчаса.

А уже в рамках еженедельных и ежемесячных проверок контроль качества подробно анализирует работу поддержки. Мы пользуемся одним из базовых правил Юздеска, по которому после выполнения тикета клиенту уходит автоматическое письмо с просьбой поделиться обратной связью по качеству и скорости решения его вопроса. Руководители групп ежедневно просматривают эти оценки и отдельно проверяют тикеты с плохой оценкой. Можно посмотреть прицельно все тикеты с негативными оценками и дальше сделать разбивку по агентам, у какого агента больше всего негативных отзывов. То же самое по тематикам — сделать разбивку, чтобы понять, какие из них сложные и вызывают негативные оценки. Иногда такие заявки переоткрываются, и агенты их дорабатывают. А иногда они основаны на субъективном мнении клиента, но оно тоже очень помогает работать над тональностью общения и бизнес-процессами в целом.

Аналитическая работа. Регулярная отчётность очень хорошо показывает все назревающие падения основных параметров эффективности в реальном времени. Особенно если вы её настроили под свои потребности, и она становится для вас «говорящей». Это позволяет своевременно либо усилить мощности, либо сделать другие изменения, которые помогают гибко адаптироваться к изменяющейся нагрузке входящего потока обращений.

Сейчас мы подключили только почту и отладили процессы на всех почтовых каналах. Теперь по той же схеме готовимся подключать чат на сайте, а за ним — чат в приложении, которое ещё в разработке. А дальше у нас грандиозные планы по оптимизации работы в соцсетях, которые мы тоже планируем подвязать на Юздеск.