Наш ответ на фидбэк: рецепт практик, которые мы внедряем в клиентский сервис
Привет, Хабр! На связи Наталия Сляднева, руководитель направления сервиса вычислительной инфраструктуры КРОК. Сегодня я расскажу о системе взаимодействия с клиентами и работе с обратной связью. Вы узнаете, что мы предпринимаем для улучшения сервиса, как новые подходы влияют на реакции клиентов и повышают их лояльность, а также как мы справляемся со сложностями и оцениваем результаты.
Вопрос качественной сервисной поддержки ИТ-инфраструктуры на нашем рынке стоит остро — большинство заказчиков привыкли получать прямую, быструю и высококачественную сервисную поддержку от вендоров. Сейчас эти задачи легли на наши плечи и мы стараемся не просто держать марку, а работать даже лучше.
В этой статье я приоткрою внутреннюю кухню и поделюсь 5 практиками, которые помогают нам анализировать, дорабатывать и ускорять внутренние процессы, чтобы быть еще полезнее клиентам. Возможно, они помогут и вам.
Первая практика: CJM как часть методологии работы
Мы используем Customer Journey Map (CJM) в качестве этакой методологии работы. Наш подход к CJM — попытка взглянуть на потребности заказчика его глазами и выявить детали, которые усложняют взаимодействие, и то, что можно изменить или упростить. Ведь путь клиента так или иначе отражается на наших внутренних процессах.
Из желания улучшить customer journey и customer experience возникает необходимость совершенствования наших внутренних процессов. Таким образом, анализ пути клиента и его улучшение происходит не только на внешнем, но и на внутреннем уровне. Мы изнутри смотрим, какие процессы проседают, что можно делать быстрее, и регулярно отслеживаем устаревшие элементы. В результате появляются новые задачи, которые разбирает вся сервисная команда, а не только менеджер по развитию сервиса.
Когда клиент ничего не знает о нас и только ищет исполнителя для своих задач, мы изучаем все факторы, на которые он опирается при выборе и сравнении нашего технического предложения с другими. Для этого у нас есть карта конкурентов, где мы отмечаем, чем они могут привлечь, в чем наши преимущества, а что нужно подтянуть.
После заключения сделки мы отслеживаем процесс адаптации клиента и проектной команды, на каких этапах может возникать трение, и что можно улучшить.
Далее предоставляем сервис уже постоянному клиенту, анализируем, что может пойти не так и как это можно превентивно улучшить.
Для всего этого у нас есть специальная доска, на которой команда оставляет комментарии в ходе работы с заказчиками. Кроме того, мы пользуемся чат-ботом в Telegram, куда быстро можно отправить мысли и идеи, возникающие в процессе работы. Затем бот подтягивает их на доску — так ничего не потеряется.
Время от времени проводятся так называемые CJM-спринты, когда мы обсуждаем накопившиеся идеи и замечания, классифицируем их и ищем исполнителей, если принято решение о реализации.
Задачи распределяются по приоритету: часть берется из бэклога, обычно там более 20 задач, и регулярно добавляется еще 10–15 свежих идей. Задачи берутся в работу в зависимости от сложности — что мы можем сделать и настроить своими силами, написать дополнительный регламент, провести работу с командой или необходимы изменения в системах.
Например, так появился трекер доставки запчасти заказчику на клиентском портале.Мы заметили, что оповещения о статусе доставки, которое отправляют инженеры, не всегда приходят вовремя. Оно и понятно — у специалистов много других забот. Так что в рамках CJM привлекли разработчиков и реализовали автоматические оповещения.
Или вот другая задача. Все заявки, на которые не назначен исполнитель в течение дня, приходят рассылкой на сервисных менеджеров. Чтобы они видели, по каким заказчикам еще нет ответственного и почему, могли подключиться и дополнительно на это повлиять. В этих письмах нужно было маркировать критичные заявки, чтобы отделять реальную важность и срочность запросов на профилактику по графику и других несрочных задач. Эту настройку мы сделали быстро своими силами. А в Telegram-боте для быстрого поиска ресурсов, который подтягивает заявки без исполнителя из Jira в чат, была идея добавить поля, например, с графиком обслуживания, чтобы инженер мог сразу оценить свою загрузку и взять заявку из бота. С этой задачей уже помогали коллеги из соседнего департамента.
В общем, при таком подходе мы получаем улучшенные процессы и доработанную систему. Изменения могут касаться как клиентского портала, так и Jira, или наших внутренних сервисов, про которые заказчик и знать не знает. Это и есть наш подход к улучшению CJM изнутри.
Вторая практика: внимание к первой линии поддержки
Клиенты обращаются к нам тремя способами: звонят, отправляют email или создают заявку через наш клиентский портал. Там аккумулируется вся информация по заявке, от договора до комментариев инженеров.
Оттуда все заявки клиентов поступают в наш сервис-деск в Jira, и с ними начинает работать первая линия поддержки, она же группа клиентского сервиса. Процесс в целом стандартный:
Открываем заявку, вводим данные, которые предоставил заказчик, регистрируем.
Направляем заявку инженерам. Распределением заявок занимается координатор — это отдельная роль в группе, которую мы ввели, переняв практику у вендоров. Исходя из занятости и компетенций инженеров координатор подбирает и назначает исполнителя.
Дальше специалист группы клиентского сервиса контролирует движение заявки, укладываемся ли в SLA и т.д. То есть у нас полностью отслеживается весь цикл жизни заявки до ее закрытия первой линией поддержки.
Сервис-деском пользуются как наша группа инженеров, так и другие команды, которые контактируют по заявкам клиентов. Координаторы передают заявки коллегам из других департаментов, находят ответственных, а те уже работают с заявкой на своей стороне.
Заявки никогда не остаются без внимания — помимо групп клиентского сервиса над ними 24/7 посменно работают дежурные инженеры. Они выполняют роль первой линии и всегда находятся в офисе. Если в ночи поступает заявка с небольшим SLA, дежурный инженер тут же ее обрабатывает, готовит запчасти и вызывает группу быстрого реагирования, которая отправится на объект. Они забирают запчасть, садятся на самолет, вертолет или собачью упряжку (серьезно, до некоторых объектов иначе не добраться) и отправляются к заказчику.
Фиксим организационные баги
Помимо чисто организационных изменений мы обратили внимание на удобство взаимодействия различных групп. Даже сам интерфейс сервис-деска у нас меняется в зависимости от того, кто работает с системой: одной команде нужно видеть одни поля в заявке, а другой группе для работы эти поля не важны.
Типичная заявка на сервисное обслуживание
Сначала мы внедрили инструмент для легкой и быстрой маршрутизации заявок на смежные группы из других проектов. Если раньше в Jira мы полностью перемещали весь запрос в несколько шагов, вручную указывая приоритет, тип и содержание заявки, то сейчас это делается нажатием одной кнопки.
Заявка перемещается в один из уже настроенных проектов, все необходимые поля заполняются автоматически. Коллеги подхватывают запрос, получают уведомление со своей стороны и могут выставить необходимые параметры, а мы дополнительно оповещаем их звонком с комментариями при необходимости.
Таким образом, мы в первую очередь автоматизировали возню, которая сильно замедляла работу. Ведь у каждой заявки есть своя специфика. Например, для заявок на поддержку железа нам нужны поля в Jira, где можно указать заменяемые запчасти. А вот для решения проблем с базой данных такие поля будут только отвлекать внимание инженера от другой важной информации.
Вот что еще мы доработали для удобной работы первой линии поддержки:
Реализовали заявки на внутренний заказ запчастей нажатием одной кнопки. Теперь нужные запчасти подтягиваются из базы автоматически, чтобы инженер мог быстрее оформить заказ и было удобнее работать со складом и выдачей запчастей.
Настроили автоматический вывод информации о сервисных договорах конкретного заказчика по всем направлениям в компании. Так в работе над заявкой сразу видно, что это комплексный проект. Если заявка сложная, на стыке разных систем, наши спецы сразу понимают, кого из коллег подключить к работе.
Добавили в заявки Jira ссылки для перехода в мастер-систему с информацией по конфигурационным единицам и договорам. Это помогает первой линии быстрее их обрабатывать: сразу подтягивается договор, можно в него перейти и посмотреть дополнительную информацию, увидеть смежные документы.
Отслеживаем метрики
В работе первой линии поддержки есть базовые метрики, которые мы наблюдаем поквартально:
скорость реагирования;
время назначения инженера;
попадание в общий SLA;
качество работы с заявками в целом.
Плюс мы используем таймеры, чтобы отслеживать время с момента назначения инженера до начала работы над заявкой относительно сроков, прописанных в договоре, в которые нужно уложиться. Этот показатель тоже можно выгрузить и изучить, есть ли проблемы, можно ли его улучшить.
Еще мы держим на контроле время предоставления запчастей. Когда по заявке не требуется физическое присутствие, инженер на площадку не едет, но отправляет запчасть заказчику по договору. Мы следим, за какое время это нужно сделать, укладываются ли сотрудники в сроки и какие возникают вопросы.
Пожинаем плоды
Все эти изменения в сочетании с внедрением координаторов существенно сократили время обработки заявок и назначения инженеров по сравнению с периодом, когда исполнители сами разбирали заявки из общей очереди. Более того, координатор выполняет контролирующую функцию.
Первоначально мы опасались, что введение координаторов может вызвать негативную реакцию со стороны инженеров. Ведь новый сотрудник будет предлагать им заявки, задавать вопросы, а инженеров с подходящими компетенциями может быть несколько, при этом загрузка у всех разная и быстро меняется. Затем необходимо контролировать выполнение работ, напоминать и переспрашивать. Однако после тестовой недели мы разработали календарь загрузки инженеров, где они по понедельникам отмечали свободные дни, сессии, командировки и прочее. Ситуация стала более управляемой. Еще через пару недель стали очевидны преимущества нововведения: заявки распределялись быстрее, ничего не зависало, не путалось и не терялось. В общем, все довольно быстро адаптировались, и мы подогнали формат максимально удобным образом для всех сторон, обеспечив требуемый результат.
В результате получилась довольно развитая, самостоятельная первая линия поддержки с пулом серьезных задач. Ребята не просто регистрируют и передают обращения, а находят ресурсы, следят за действиями инженеров, ведут заявки, формируют отчетность и влияют на общее качество работы.
Третья практика: нанимаем технических сервисных менеджеров
Технический сервисный менеджер (ТСМ), вопреки названию, у нас не занимается глубокими техническими вопросами. Задача этого специалиста — сопровождение и выполнение сервисного договора, который мы заключаем с заказчиком. А технические вопросы заказчик решает напрямую с командой сервисной поддержки, состоящей из первой линии и команд инженеров по вычислительной инфраструктуре, которые обрабатывают все сервисные заявки.
Зато именно технический сервисный менеджер участвует в установочной встрече с клиентом. Он рассказывает об организационных моментах, проводит по всем подготовительным этапам, при необходимости готовит индивидуальные процессы под запрос заказчика, на протяжении всего срока действия сервисного контракта следит за качеством предоставления сервисной поддержки и осуществляет регулярный мониторинг сервисных инцидентов. Он же ведет эскалации, если таковые возникают. В общем, ТСМ становится единой точкой входа и ключевым контактным лицом для заказчика по всем вопросам, связанным с сервисной поддержкой.
Мы специально выделили роль ТСМ примерно два с половиной года назад. До этого все вопросы по договору поддержки ложились на плечи сервисного менеджера. Для него это была дополнительная и довольно серьезная административная нагрузка.
В 2022 году количество сервисных запросов стало расти, заказчики массово переходили к нам, поэтому вопрос сопровождения и реализации договоров стал особенно актуальным. Необходимо было разгрузить сервисных менеджеров, вывести их из операционной деятельности, чтобы они могли сфокусироваться на расширении бизнеса и новых контрактах.
Еще один важный аспект — заказчики, которые работали с вендорами, привыкли к выделенному техническому сервис-менеджеру, который сопровождал их контракт. Чтобы соответствовать их требованиям, мы активно наращивали штат. В настоящее время 80% ключевых заказчиков ведет выделенный ТСМ, и мы постоянно повышаем охват. Один ТСМ может работать с несколькими заказчиками в зависимости от сложности сервисного проекта, типа заказчика и списка требований.
Эффект от работы ТСМ мы увидели практически сразу — явное повышение удовлетворенности заказчиков, которое мы получили по обратной связи. При таргетированном опросе клиентов, которых вели технические сервисные менеджеры, подавляющее большинство отдельно отмечало ценность этой роли и считало ее нашим конкурентным преимуществом.
Кроме ведения своих назначенных клиентов, команда ТСМ управляет эскалациями всех заказчиков, находящихся у нас на поддержке. Это позволяет эффективнее и быстрее решать сложные и горячие заявки благодаря опыту работы с подобными инцидентами.
В плане дополнительной подготовки и обучения мы уделяем особое внимание soft skills, взаимодействию с заказчиком и развитию коммуникационных навыков. Также все ТСМ проходят технические тренинги, чтобы прокачать технические знания, лучше понимать коллег и заказчиков и говорить с ними на одном языке. Это как внутрикорпоративные, так и внешние мероприятия, на которых без лишнего погружения в технические детали можно получить общее понимание современных технологий и оборудования, с которыми мы работаем в нынешних реалиях на российском рынке — новые вендоры, новое оборудование и т. д.
Четвертая практика: пишем стандарты коммуникации с клиентами и глоссарий для инженеров
КРОК всегда делал акцент на обучении и «взращивании» квалифицированных кадров. И инженерная команда не исключение! Например, в июле у нас стартует Летняя ИТ-школа — это двухнедельный интенсив по погружению в ИТ-профессию для студентов старших курсов. По итогам таких интенсивов каждый год мы пополняем команду стажерами, которые только начинают свой карьерный путь, перенимая знания у более опытных коллег.
Чтобы процесс адаптации новеньких инженеров был более комфортным и понятным, мы написали саппорт-хэндбук. Это специальное руководство по тому, как взаимодействовать с заказчиком в рамках нашей культуры и общего видения работы. Однако мы стараемся, чтобы это была не просто методичка или формальная инструкция, а живая история с реальными примерами из практики.
Чтобы такого не случалось, мы и разработали хэндбук:)
Все началось с того, что мы общались с клиентами в HPSM через комментарии и письма. Затем появилась Jira и больше возможностей для коммуникации. Мы начали пересматривать свой подход к работе и анализировать, что инженеры пишут в заявках и как общаются. Стали собирать спорные моменты, замечать типичные повторяющиеся ошибки в группах. По мере накопления реального материала из комментариев начали формировать этот сборник.
Хэндбук состоит из нескольких разделов:
Первый раздел общий: о компании, клиентах, отношениях в командах и работе поддержки. Он помогает понять наши ценности, ожидания, видение оказания услуг поддержки, чтобы инженеры разделяли нашу клиентоориентированность.
Одна из «заповедей» из нашего хэндбука
Во втором разделе описаны проблемы клиентов и пути их решения для инженеров. Мы рассказываем о правилах общения с заказчиками и уровне оказания услуг. В специальных подразделах с примерами расписаны разные ситуации и подходы:
писать решение максимально подробно и простыми словами, так как не все заказчики являются техническими специалистами;
обращать внимание на повторяющиеся поломки и комплексно рассматривать проблемы;
своевременно и быстро давать обратную связь, не оставляя заявки в статусе «получен ответ заказчика»;
спокойно преодолевать сложные моменты коммуникации, искать персональный подход, опираясь на знания о заказчиках и накопленный опыт;
продумывать план действий, прикидывать ход решения заявки и согласовывать с заказчиком при необходимости;
собирать всю диагностическую информацию и решать вопросы с простоями.
Следующий раздел представлен в формате чата: как общаться с заказчиками, чтобы формулировать ответы понятно и правильно, находясь на одной волне (если клиент ведет диалог официально — отвечать тоже официально; клиент общается неформально — отвечаем примерно так же).
В завершение идет глоссарий — как называем и не называем те или иные запчасти, например, материнская плата и «мать» — табу. В работе используем только «системная плата». Есть довольно большой подраздел по оборудованию, значениям SLA, инцидентов и прочего, про Jira и другие системы все расписано простыми словами для легкого погружения инженеров и понимания структуры и работы сервиса.
И еще один пример того, как не надо общаться с заказчиком
На основании этого хэндбука мы уже внедрили быстрые ответы в Jira, чтобы инженеру не приходилось каждый раз придумывать формулировки. Мы внесли набор сообщений, которые чаще всего отправляются заказчику — это может быть запрос логов или информация об отправке запчасти, например. И они отправляются автоматически.
Сейчас мы хотим переработать весь сборник в формат полноценной книги для новых сотрудников и не только. Подробнее напишем о культуре взаимодействия в команде, работе в крупной компании. Доработаем разделы коммуникации с заказчиком, культуры технической поддержки и ведения заявки. Выделим нашу проактивную позицию в техподдержке: мы не просто выполняем договор, а стараемся предоставить больше. Например, если приходит заявка на неисправный диск, мы смотрим логи и видим, что также нужно заменить батарейку, чей срок годности подходит к концу.
Помимо изучения текстового материала, мы ввели практику воркшопов для новых инженеров. Ребят собирают на очную встречу, презентуют материал, рассказывают о коммуникациях, разбирают исторические и частые ошибки, объясняют правильные и неправильные подходы, уделяя особое внимание soft skills, внимательности и ответственности при выполнении задач.
Пятая практика: индекс NPS как показатель общей результативности
Вместе с отделом маркетинга мы проводим регулярные исследования удовлетворенности заказчиков нашим сервисом. Одной из ключевых метрик является NPS (Net Promoter Score), показывающая, как нас оценивают заказчики, насколько они доверяют компании и готовы ли рекомендовать нас другим. По сути, это один из главных индексов измерения клиентской лояльности.
Мы внедряем множество изменений, и для нас крайне важно понимать, как это влияет на заказчиков и идем ли мы верным путем. Возможно, мы считаем, что клиентам удобно, а на самом деле они думают иначе. Чтобы это проверить, мы с помощью открытых опросников собираем обратную связь. Это позволяет нам не только получать высокие оценки работы компании, но и критические замечания.
Примеры комментариев заказчиков о работе портала
Ежегодный масштабный сбор обратной связи — не единственный способ оценить реальное качество сервиса. Мы также обращаем внимание на информацию от заказчиков на транзакционном уровне, то есть при выполнении индивидуальных сервисных заявок. Анализируем процесс выполнения, пытаясь выявить момент возникновения недовольства. Кроме того, мы любим общаться с нашими заказчиками вживую :) Мы проводим специальные мероприятия для наших сервисных клиентов, где можно поговорить с руководителями направлений и поделиться своей обратной связью напрямую. Как правило, именно в таком формате живого диалога удается продуктивнее обсудить предложения по улучшению сервиса и лучше друг друга понять. А также для сбора обратной связи от клиентов мы создали отдельного чат-бота в Telegram.
Отчет, содержащий пожелания и критику текущих процессов и инструментов, мы передаем в департамент внутренней автоматизации. Менеджер по развитию службы сервиса перерабатывает этот материал и выделяет требования к доработкам, которые мы регистрируем и выполняем.
Заказчики видят изменения и понимают, что мы не просто опрашиваем их, а обрабатываем всю информацию и используем ее для развития сервисов. Следовательно — охотнее дают обратную связь. И, как вы можете видеть на графике ниже, по результатам нашего последнего опроса, наш индекс NPS по сервису вырос до рекордных 90%!
После внедренных изменений, согласно данным за 2022–2023 годы, мы наблюдали такую динамику
Точки роста и планы на будущее
Хочется отметить, что, несмотря на предварительный анализ и подготовку, внедрение подобных нововведений не проходит идеально. Мы внедряли эти практики постепенно, обсуждали с командой, собирали фидбэк и доработки, тестировали. И даже сейчас нельзя сказать, что процессы устоялись и приняли финальный вид.
По итогам предыдущих спринтов у нас уже есть пул доработок:
Добавить коэффициент «температуры» заявки, чтобы первая линия и технические сервис-менеджеры могли видеть наиболее приоритетные заявки для контроля, меньше тратить ресурсов и равномерно распределять нагрузку.
Автоматизировать больше внутренних процессов, особенно по проектам запчастей.
Внести множество изменений в бота, чтобы инженерам было удобнее взаимодействовать с заказчиками через Telegram со смартфона, так как мобильная версия Jira со всеми нашими кастомизациями пока не реализована.
Сделать дополнительные отчеты из Jira для анализа используемых запчастей: сколько каких запчастей мы поменяли у конкретного заказчика.
Добавить плагин для проверки правописания, чтобы автоматически снизить количество ошибок и опечаток в переписке при большом потоке работы.
Чтобы подытожить, хочется посоветовать сервисным компаниям, которые выстраивают подобные процессы, использовать как можно больше инструментов для сбора обратной связи. Индекс NPS раз в год — это очень важно, там много полезных вопросов. Но так же ценно получать обратную связь от клиентов в режиме реального времени и регулярно. Это могут быть оценки и возможность комментирования после оказанной услуги или коммуникация через выделенного сервис-менеджера. Такая прямая обратная связь и оперативная работа с ней предоставляет множество точек роста для сервиса.
Конкретный пример: заказчик сообщил, что неудобно прикладывать логи, потому что наш клиентский портал не пропускает определенные типы файлов. Мы незамедлительно передали это коллегам из департамента внутренней автоматизации. Они взяли задачу в работу, а заказчик оценил скорость решения этой проблемы.
Кроме того, важно, чтобы над выстраиванием и развитием процессов работали люди, которые действительно в этом заинтересованы. Настоящие специалисты, которые видят недостатки и готовы с ними работать. Для таких проектов важно собрать заряженную команду. У нас это получилось, и, возможно, это главный секрет успешного развития клиентского сервиса.
Почитать еще про слагаемые сервиса КРОК:
Фронтенд-апгрейд для Jira. Как и зачем мы модернизировали сервисный портал КРОК
Это база. Как прокачиваются сервисные инженеры КРОК
Горы ЗИП. Почему наш склад ломится от оборудования и причем здесь ушедшие вендоры
