+7 (495) 151-93-60
Запишитесь на бесплатную онлайн-демонстрацию Юздеска
Оставьте ваши контактные данные ниже и мы свяжемся с вами в ближайшее время
Нажимая на кнопку, вы соглашаетесь на обработку персональных данных
Кейс внедрения
Haier: с нуля запустили
скоростную обработку
обращений
Производители бытовой техники Haier поставили перед собой задачу — создать максимально скоростную службу поддержки для интернет-магазина и сервисного обслуживания после продажи. Ребята раньше уже работали с хелпдеск-системами, поэтому сразу осознанно подошли к построению схемы обработки обращений и преуспели в этом.
Директор по клиентскому опыту Татьяна Штин на примере одного канала рассказывает и показывает, как и по какому принципу организовала работу с обращениями: воронка входящих обращений, трёхуровневая система автоответов, напоминалки и другие лайфхаки. Ловите готовую схему построения скоростной службы поддержки.
До пандемии 2020 года саппорт был на аутсорсе и состоял из двух отдельных служб: поддержки интернет-магазина и послепродажного обслуживания. Каждая работала сама по себе в своём скоростном режиме — единой поддержки не было.
С началом карантина продажи через интернет-магазин сильно выросли и в компании начали с нуля строить взрослую унифицированную скоростную поддержку, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.
С началом карантина продажи через интернет-магазин сильно выросли и в компании начали с нуля строить взрослую унифицированную скоростную поддержку, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.
Какие проблемы хотели решить:
Все обращения попадают в Юздеск. Сотрудники не тратят время на их сортировку и распределение. Система сама тегирует их по тематике и приоритетности, а потом правилами распределяет в нужные фильтры-очереди, которые обрабатывают разные скилл-группы сотрудников.
После формирования тикета клиенту уходит стандартная отбивка о приёме заявки. Если сотрудник запросил у клиента информацию, а тот пропал — отбивка-напоминание. Если клиент продолжает молчать — отбивка-закрытие.
После формирования тикета клиенту уходит стандартная отбивка о приёме заявки. Если сотрудник запросил у клиента информацию, а тот пропал — отбивка-напоминание. Если клиент продолжает молчать — отбивка-закрытие.
Каких результатов достигли:
“
Концепция в том, чтобы максимально тегировать поступающие обращения по тематикам и приоритетности на уровне системы. А дальше на основании этих правил тикеты раскладываются в нужные фильтры-очереди, которые обрабатывают разные скилл-группы сотрудников. Если в системе всё правильно настроено, то за счёт правильного распределения тикетов по каналам и грамотной работы с приоритетами — несколько уровней SLA в зависимости от сложности и важности запроса — сильно сокращается срок обработки задач.
Внутреннюю службу поддержки сразу начали делать «по-взрослому»
Изначально в России бытовую технику Haier продавали через дистрибьюторов. С 2017 компания запустила онлайн продажи и брендшопы.
До пандемии 2020 года объёмы продаж росли плавно, а поддержка была на аутсорсе и состояла из двух частей: поддержка интернет-магазина — заказ, доставка; послепродажное обслуживание — заявки на ремонт, обслуживание. У каждого подразделения были разные кураторы.
Но с началом карантина в 2020 году продажи через интернет-магазин сильно выросли, а за ними начал развиваться и колл-центр. С середины 2020 года мы стали переносить поддержку во внутреннюю компетенцию и строить колл-центр внутри компании. Мы сразу пошли в сторону создания взрослой унифицированной поддержки, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.
Мой опыт работы с Юздеском как с основной хелпдеск-системой начался в Haier. До этого я работала с их конкурентом, но оказалось, что Юздеск — приятная альтернатива зарубежному решению. Причин, почему мы выбрали Юздеск, две: его проще настраивать и он дешевле. У его конкурента достаточно сложная логика настройки правил, а в Юздеске это реализовано более нативно и современно. Приятно было увидеть, что за последние годы ребята сильно шагнули вперед и добавили много полезных фич.
В своей 10-летней практике работы в службе поддержки я настраивала разные хелпдеск-системы — формировала бизнес-требования и бизнес-процессы. Поэтому, присоединившись к команде Haier и начав отстраивать внутренний колл-центр, я уже на старте осознанно настраивала хелпдеск-систему так, чтобы максимально сократить срок обработки обращений.
Мой совет, если вы только внедряете хелпдеск, начните с одного канала: настройте воронку для входящих обращений, подключите систему автоответов, установите нормативы для сотрудников, подключите для них напоминалки и наладьте работу с аналитикой и контролем качества. А когда всё будет готово, подключить остальные каналы по тому же принципу уже проще — неважно сколько их, пять или пятнадцать.
До пандемии 2020 года объёмы продаж росли плавно, а поддержка была на аутсорсе и состояла из двух частей: поддержка интернет-магазина — заказ, доставка; послепродажное обслуживание — заявки на ремонт, обслуживание. У каждого подразделения были разные кураторы.
Но с началом карантина в 2020 году продажи через интернет-магазин сильно выросли, а за ними начал развиваться и колл-центр. С середины 2020 года мы стали переносить поддержку во внутреннюю компетенцию и строить колл-центр внутри компании. Мы сразу пошли в сторону создания взрослой унифицированной поддержки, опираясь на международные стандарты COPC и лучший опыт отрасли за последние годы.
Мой опыт работы с Юздеском как с основной хелпдеск-системой начался в Haier. До этого я работала с их конкурентом, но оказалось, что Юздеск — приятная альтернатива зарубежному решению. Причин, почему мы выбрали Юздеск, две: его проще настраивать и он дешевле. У его конкурента достаточно сложная логика настройки правил, а в Юздеске это реализовано более нативно и современно. Приятно было увидеть, что за последние годы ребята сильно шагнули вперед и добавили много полезных фич.
В своей 10-летней практике работы в службе поддержки я настраивала разные хелпдеск-системы — формировала бизнес-требования и бизнес-процессы. Поэтому, присоединившись к команде Haier и начав отстраивать внутренний колл-центр, я уже на старте осознанно настраивала хелпдеск-систему так, чтобы максимально сократить срок обработки обращений.
Мой совет, если вы только внедряете хелпдеск, начните с одного канала: настройте воронку для входящих обращений, подключите систему автоответов, установите нормативы для сотрудников, подключите для них напоминалки и наладьте работу с аналитикой и контролем качества. А когда всё будет готово, подключить остальные каналы по тому же принципу уже проще — неважно сколько их, пять или пятнадцать.
Настроили воронку для входящих обращений, чтобы максимально сократить срок их обработки
Концепция в том, чтобы максимально тегировать поступающие обращения по тематикам и приоритетности на уровне системы. А дальше на основании этих правил тикеты раскладываются в нужные фильтры-очереди, которые обрабатывают разные скилл-группы сотрудников. Если тикет после автоматической фильтрации попал не туда, то агент уже вручную тегирует его, присвоив нужную тематику обращения, и тикет попадает в нужный фильтр. Если в системе всё правильно настроено, то за счёт правильного распределения тикетов по каналам и грамотной работы с приоритетами — несколько уровней SLA в зависимости от сложности и важности запроса — сильно сокращается срок обработки задач.
Лучше всего настроить по этой схеме один канал, протестировать работу воронки, а потом по тому же принципу подключать остальные каналы
У нас внутри каждого из двух направлений есть несколько скилл-групп, которые частично взаимозаменяемы. То есть внутри направления сотрудники универсальные бойцы, и сейчас мы всех агентов, за исключением новичков, включаем во все скилл-группы. С нашей спецификой так удобнее — это позволяет максимально эффективно распределять нагрузку между сотрудниками и быстро реагировать на резкий наплыв обращений по какой-то тематике. Благодаря статистике, которую собирает Юздеск, мы видим ситуацию с входящими обращениями: где сотрудники успевают или не успевают и SLA начинает «проседать», как быстро собирается очередь, сколько времени тратится на обработку. В зависимости от этого мы усиливаем агентами тот или иной канал.
Есть два варианта обработки агентом тикетов:
Мы ещё экспериментируем с настройками фильтров, тегов и автоматических правил в Юздеске, чтобы выбрать оптимальную схему с учётом особенностей бизнеса и профиля распределения входящего потока по времени: дням, неделям, месяцам.
Ведь чем меньше объёмы, тем легче лавировать, меньше потребность в потоковых процессах и можно использовать индивидуальный подход к разным ситуациям клиентов. А чем выше нагрузка, тем потоковость важнее — чтобы агент работал с теми тикетами и тематиками, которые предлагает система, не задумываясь над выбором. При высокой нагрузке становится более актуальным распределение агентов по скилл-группам и уровням: первая, вторая и третья линии поддержки.
Например, вы хотите, чтобы несколько агентов постоянно и неизменно занимались только доставкой. Вы создаёте скилл-группу по доставке, добавляете в неё нужных агентов, настраиваете теги и фильтры, чтобы участники видели только список тикетов по доставке. В результате они отвечают только на вопросы по доставке и не берутся за другие задачи. Такой подход помогает агентам скилл-группы работать быстрее, так как экономит время и интеллектуальные силы специалиста на переключения между разными вопросами.
При этом с точки зрения набора знаний агенты могут быть универсальными и из смены в смену их можно переводить из одной скилл-группы в другую. К примеру, сегодня агент в скилл-группе по доставке, а завтра — по гарантийным обращениям и так далее по кругу. Это позволяет очень гибко распределить нагрузку между сотрудниками в зависимости от изменений в потоке входящих обращений и делает их взаимозаменяемыми.
Мы сразу настроили воронку для входящего потока сообщений и в итоге у нас получилось очень неплохо: ребята успевают день-в-день обрабатывать запросы и хорошо выполняют SLA. Нам удалось реализовать давнюю мечту всех саппорт-служб — первый ответ клиент получает в течение часа. А вопросы, которые не требуют нескольких итераций, у нас решаются в среднем за сутки. И практически всегда не дольше трёх дней — в ситуациях, когда нужны дополнительная информация от клиента либо участие каких-то других служб.
Есть два варианта обработки агентом тикетов:
- Агент по очереди обрабатывает тикеты из списка, который формируется из всех очередей его скилл-групп в порядке приоритетности по SLA.
- Агент видит фильтры по тематикам и выбирает, какие обрабатывать в первую очередь. Например, мы видим, что сейчас у нас очень много тикетов упало в фильтр «доставка», поэтому мы операционно повышаем приоритет их обработки, а остальные тикеты, по менее загруженным тематикам, откладываем на несколько часов.
Мы ещё экспериментируем с настройками фильтров, тегов и автоматических правил в Юздеске, чтобы выбрать оптимальную схему с учётом особенностей бизнеса и профиля распределения входящего потока по времени: дням, неделям, месяцам.
Ведь чем меньше объёмы, тем легче лавировать, меньше потребность в потоковых процессах и можно использовать индивидуальный подход к разным ситуациям клиентов. А чем выше нагрузка, тем потоковость важнее — чтобы агент работал с теми тикетами и тематиками, которые предлагает система, не задумываясь над выбором. При высокой нагрузке становится более актуальным распределение агентов по скилл-группам и уровням: первая, вторая и третья линии поддержки.
Например, вы хотите, чтобы несколько агентов постоянно и неизменно занимались только доставкой. Вы создаёте скилл-группу по доставке, добавляете в неё нужных агентов, настраиваете теги и фильтры, чтобы участники видели только список тикетов по доставке. В результате они отвечают только на вопросы по доставке и не берутся за другие задачи. Такой подход помогает агентам скилл-группы работать быстрее, так как экономит время и интеллектуальные силы специалиста на переключения между разными вопросами.
При этом с точки зрения набора знаний агенты могут быть универсальными и из смены в смену их можно переводить из одной скилл-группы в другую. К примеру, сегодня агент в скилл-группе по доставке, а завтра — по гарантийным обращениям и так далее по кругу. Это позволяет очень гибко распределить нагрузку между сотрудниками в зависимости от изменений в потоке входящих обращений и делает их взаимозаменяемыми.
Мы сразу настроили воронку для входящего потока сообщений и в итоге у нас получилось очень неплохо: ребята успевают день-в-день обрабатывать запросы и хорошо выполняют SLA. Нам удалось реализовать давнюю мечту всех саппорт-служб — первый ответ клиент получает в течение часа. А вопросы, которые не требуют нескольких итераций, у нас решаются в среднем за сутки. И практически всегда не дольше трёх дней — в ситуациях, когда нужны дополнительная информация от клиента либо участие каких-то других служб.
Клиент написал через сайт и в теме письма указал, что пишет по поводу претензии, поэтому система сама назначила ему нужный фильтр — вопросы по обмену и возврату, и сразу назначила тикету SLA для этой темы
Подключили трёхуровневую систему автоответов, чтобы снять лишнюю нагрузку с агентов
Чтобы агенты не мониторили состояние тикетов вручную и не занимались «копипастом», мы настроили три уровня автоответов на входящие обращения: стандартная отбивка о приёме заявки, отбивка-напоминание и отбивка-закрытие.
Первый уровень — стандартная отбивка о приёме заявки.
Второй уровень — отбивка-напоминание. Если запрашиваем у клиента информацию, без которой невозможно решить его вопрос, а он не отвечает, система сама ещё раз просит прислать данные.
Третий уровень — отбивка-закрытие. Если клиент продолжает молчать, система отправляет ему сообщение о том, что нам не хватает данных для завершения работы, и если вопрос актуален, мы просим прислать необходимые данные. Если ответа всё равно нет, тикет закрывается, и вопрос переоткрывается только в случае нового письма от клиента.
Установили нормативы для сотрудников и следим за числом итераций, чтобы быстро исправлять ошибки
В зависимости от темы обращения мы понимаем, сколько в среднем нужно времени на его обработку. На этой основе мы и определяем норматив. Например, если для ответа по конкретной теме нужен час, значит, агент может за один восьмичасовой рабочий день обработать максимум семь заявок такого типа. Если обработка заявки занимает минуту, то норматив, соответственно, другой.
А дальше самое интересное — как с помощью системы настроить распределение простых и сложных кейсов по агентам?
Есть два варианта:
К примеру, у нас сейчас нет чёткого распределения агентов по специализации — по набору знаний они у нас универсальные. Поэтому на данном этапе мы устанавливаем нормативы эффективности на основе среднего времени обработки тикета. В будущем, когда объёмы вырастут, думаю, перейдем на другую схему распределения нагрузки и оценки эффективности сотрудников.
Сейчас мы больше смотрим на количество итераций по тикетам — выделяем задачи, которые требуют больше итераций. Это нужно, чтобы разобраться, почему итераций так много, и найти способ сократить их количество. А если это невозможно, то какие-то итерации стараемся автоматизировать и этим ещё больше ускорить обработку обращений.
Например, у нас есть ситуация, когда агенту довольно часто приходится напоминать коллеге из соседнего отдела о том, что мы ждём от него ответ по задаче. Увидев это, мы настроили проактивное автоматическое пингование коллеги на основе SLA. Теперь, если агент, работая с тикетом, запрашивает дополнительную информацию у коллеги, он использует статус «На удержании». Такой ожидающий тикет попадает в отдельный фильтр, в котором настроено правило: когда приближается срок выполнения, коллеге приходит напоминание, что нужно решить вопрос.
А дальше самое интересное — как с помощью системы настроить распределение простых и сложных кейсов по агентам?
Есть два варианта:
- Для универсальных бойцов — один норматив для всех, когда система сбалансировано предлагает агенту разные по сложности задачи.
- Для сотрудников с узкой специализацией — разные нормативы, кто-то делает только простые кейсы, а кто-то — только сложные.
К примеру, у нас сейчас нет чёткого распределения агентов по специализации — по набору знаний они у нас универсальные. Поэтому на данном этапе мы устанавливаем нормативы эффективности на основе среднего времени обработки тикета. В будущем, когда объёмы вырастут, думаю, перейдем на другую схему распределения нагрузки и оценки эффективности сотрудников.
Сейчас мы больше смотрим на количество итераций по тикетам — выделяем задачи, которые требуют больше итераций. Это нужно, чтобы разобраться, почему итераций так много, и найти способ сократить их количество. А если это невозможно, то какие-то итерации стараемся автоматизировать и этим ещё больше ускорить обработку обращений.
Например, у нас есть ситуация, когда агенту довольно часто приходится напоминать коллеге из соседнего отдела о том, что мы ждём от него ответ по задаче. Увидев это, мы настроили проактивное автоматическое пингование коллеги на основе SLA. Теперь, если агент, работая с тикетом, запрашивает дополнительную информацию у коллеги, он использует статус «На удержании». Такой ожидающий тикет попадает в отдельный фильтр, в котором настроено правило: когда приближается срок выполнения, коллеге приходит напоминание, что нужно решить вопрос.
Агент запросил информацию у коллеги и перевёл тикет в статус «На удержании». Коллега, затягивает с ответом — ему автоматически уходит отбивка-напоминание
Настроили разные напоминалки для разных задач, чтобы вовремя отвечать на все заявки
В зависимости от темы, бизнес-процесс обработки обращений немного отличается. У нас все бизнес-процессы описаны, поэтому мы знаем не только время, которое в среднем уходит на каждый этап, но и как итерационно его оптимизировать и управлять распределением интервалов между напоминалками.
Если мы понимаем, что железобетонно хотим решить даже сложный вопрос клиента в течение трёх дней, значит, мы внутри устраиваем процессы так, чтобы все итерации уложились в эти три дня. В том числе — внутреннюю коммуникацию с другими департаментами и возможную необходимость получения дополнительной информации от клиента. Например, если мы понимаем, что по теме Х нужно сделать три «приседания», значит, мы выделяем максимум по 12 часов на каждое. То есть в каждой теме есть правила, в которых прописаны сроки автоответов.
Если мы понимаем, что железобетонно хотим решить даже сложный вопрос клиента в течение трёх дней, значит, мы внутри устраиваем процессы так, чтобы все итерации уложились в эти три дня. В том числе — внутреннюю коммуникацию с другими департаментами и возможную необходимость получения дополнительной информации от клиента. Например, если мы понимаем, что по теме Х нужно сделать три «приседания», значит, мы выделяем максимум по 12 часов на каждое. То есть в каждой теме есть правила, в которых прописаны сроки автоответов.
Напоминалки настраиваются как конструктор: выбираешь условия, при которых напоминание должно сработать, добавляешь текст и, если нужно — файл или картинку. Напоминалка готова.
Используем отчёты Юздеска для контроля за качеством работы поддержки
Мы смотрим ежедневную, еженедельную и ежемесячную аналитику в зависимости от задач по оптимизации процессов, которые мы себе поставили. То есть статистику из Юздеска мы используем и для операционного контроля, и аналитической работы — это два отдельных блока. Задача операционного контроля — вовремя выявить и исправить проблемы в работе операторов, задача аналитической работы — обнаружить системные проблемы в работе поддержки, если они есть, и самое интересное — найти точки роста и зоны для улучшения.
Операционный контроль. Супервайзеры и руководители групп ежедневно верхнеуровнево проверяют, чтобы сотрудники выполняли SLA, и смотрят на время между итерациями. Например, первый тикет агент взял в 10 утра, второй — в 11 утра. Промежуток между статусом «выполнено» по первому тикету и статусом «в работе» по второму — полчаса. Здесь возникает вопрос, что человек делал полчаса.
А уже в рамках еженедельных и ежемесячных проверок контроль качества подробно анализирует работу поддержки. Мы пользуемся одним из базовых правил Юздеска, по которому после выполнения тикета клиенту уходит автоматическое письмо с просьбой поделиться обратной связью по качеству и скорости решения его вопроса. Руководители групп ежедневно просматривают эти оценки и отдельно проверяют тикеты с плохой оценкой. Можно посмотреть прицельно все тикеты с негативными оценками и дальше сделать разбивку по агентам, у какого агента больше всего негативных отзывов. То же самое по тематикам — сделать разбивку, чтобы понять, какие из них сложные и вызывают негативные оценки. Иногда такие заявки переоткрываются, и агенты их дорабатывают. А иногда они основаны на субъективном мнении клиента, но оно тоже очень помогает работать над тональностью общения и бизнес-процессами в целом.
Аналитическая работа. Регулярная отчётность очень хорошо показывает все назревающие падения основных параметров эффективности в реальном времени. Особенно если вы её настроили под свои потребности, и она становится для вас «говорящей». Это позволяет своевременно либо усилить мощности, либо сделать другие изменения, которые помогают гибко адаптироваться к изменяющейся нагрузке входящего потока обращений.
Операционный контроль. Супервайзеры и руководители групп ежедневно верхнеуровнево проверяют, чтобы сотрудники выполняли SLA, и смотрят на время между итерациями. Например, первый тикет агент взял в 10 утра, второй — в 11 утра. Промежуток между статусом «выполнено» по первому тикету и статусом «в работе» по второму — полчаса. Здесь возникает вопрос, что человек делал полчаса.
А уже в рамках еженедельных и ежемесячных проверок контроль качества подробно анализирует работу поддержки. Мы пользуемся одним из базовых правил Юздеска, по которому после выполнения тикета клиенту уходит автоматическое письмо с просьбой поделиться обратной связью по качеству и скорости решения его вопроса. Руководители групп ежедневно просматривают эти оценки и отдельно проверяют тикеты с плохой оценкой. Можно посмотреть прицельно все тикеты с негативными оценками и дальше сделать разбивку по агентам, у какого агента больше всего негативных отзывов. То же самое по тематикам — сделать разбивку, чтобы понять, какие из них сложные и вызывают негативные оценки. Иногда такие заявки переоткрываются, и агенты их дорабатывают. А иногда они основаны на субъективном мнении клиента, но оно тоже очень помогает работать над тональностью общения и бизнес-процессами в целом.
Аналитическая работа. Регулярная отчётность очень хорошо показывает все назревающие падения основных параметров эффективности в реальном времени. Особенно если вы её настроили под свои потребности, и она становится для вас «говорящей». Это позволяет своевременно либо усилить мощности, либо сделать другие изменения, которые помогают гибко адаптироваться к изменяющейся нагрузке входящего потока обращений.
Что дальше
Сейчас мы подключили только почту и отладили процессы на всех почтовых каналах. Теперь по той же схеме готовимся подключать чат на сайте, а за ним — чат в приложении, которое ещё в разработке. А дальше у нас грандиозные планы по оптимизации работы в соцсетях, которые мы тоже планируем подвязать на Юздеск.
Сделайте первый шаг к эффективному клиентскому сервису
В Юздеске есть удобная база знаний и автоматизация, чтобы саппорт работал только с действительно важными обращениями. Наши клиенты обрабатывают на 30% больше обращений без увеличения штата, а скорость ответа увеличивается в 6 раз.
Поделиться с коллегами:
Поделиться с коллегами:
Оцените, пожалуйста, нашу статью
Знаем все о клиентском сервисе
Раз в неделю мы будем присылать статьи о том, что делать с клиентами, чтобы им было хорошо. Вы не против?
