Спрогнозировать ход масштабирования — задача, достойная оракула, но зачастую проблемная для ИТ-команд. Даже когда процессы обновлены и настроены, команда укомплектована нужными спецами, а все причастные люди работают слажено — всё равно что-то может сломаться: не в «человеческом» плане, так в техническом.
Ранее мы рассказали, как в течение нескольких месяцев пошагово масштабировали техподдержку Сравни — меняли tone of voice, учили бота общаться по-человечески, специальным образом онбордили людей. Но всё это вряд ли бы нам пригодилось без технической возможности помогать клиентам — успешно закрывать обращения, которых в компании поступает полмиллиона в год.
Для покрытия всех потребностей нашей техподдержки требовался ещё один решительный шаг — переезд на новый хэлпдеск. Под катом рассказываем, чем нас не устраивала прошлая система, как выбирали замену, а главное — что помогло (и не очень) в ходе самого переезда. И заодно делимся чек-листом по процессу.
Привет, Хабр!
Я — Никита, лид автоматизации клиентской поддержки (Customer Care) в Сравни. Наша команда появилась в 2017 году и с тех пор работала на одном хэлпдеске. Всё это время мы мирились с его ограничениями: подстраивались под интерфейс и делали «костыли», чтобы получать нужную нам функциональность.
Среди проблемных моментов, связанных с прошлым хэлпдеском, выделю следующее:
Тегирование запросов. В недавней статье моя коллега @MariaLakshina подсветила одну из ключевых сложностей в работе клиентской поддержки Сравни — это мультипродуктовость: поддержка работает сразу со всеми продуктами, обрабатывая сотни тысяч тикетов в год.
Для анализа поступающих тикетов у нас была система тегирования запросов, но к концу 2023 года она сильно устарела и не отвечала нашим требованиям.
Мы запланировали масштабную кампанию по обновлению тегов — и сразу столкнулись с технической сложностью: текущий хэлпдеск ограничивал количество разделов иерархической системы, в то время как нам, с учётом мультипродуктовости, требовалось их весьма много. В итоге пришлось придумывать дополнительные поля тегов, что в итоге путало саппортов — вот и пример тех самых костылей.
Сбор статистики. Собирать статистику по работе поддержки тоже было сложно из-за недостаточного логирования действий внутри тикетов. Чтобы посчитать нужную метрику, аналитику приходилось придумывать, как из одной имеющейся метрики вычесть другую, да ещё и так, чтобы цифра в итоге была верной и точной.
Работоспособность хэлпдеска. Работал он очень медленно, поиск тикета в системе занимал 10 минут, а отчеты могли грузиться до часа. Раздражали и сбои: стабильно пару раз в неделю сервер хэлпдеска не выдерживал нагрузки.
Таких узких мест в системе было много: по сути мы попали в ситуацию, когда не хэлпдеск подстраивается под нашу работу, а мы под хэлпдеск.
Выбираем новый хэлпдеск
Мы решили поизучать рынок на предмет того, что сейчас предлагают подрядчики. Почему не стали делать собственное решение? Дело в количестве продуктов: создать инструмент, объединяющий такое количество информации, было бы слишком трудоёмко по предварительной оценке.
На этапе выбора решения мы обращали внимание на следующие критерии:
гибкие настройки статусов тикета — свобода в создании правил автоматизации и возможность доработок системы под наши нужды;
адекватная и быстрая поддержка;
возможность отследить изменение каждого поля тегирования и настроить тегирование, как нам будет удобно;
по возможности — цена тарифа не выше текущей.
В ходе ресерча выделили несколько сервисов, затем запрашивали демо. Обращали внимание не только на технические нюансы решений, но и на то, как менеджеры их презентуют, насколько подробно отвечают на наши вопросы; уточняли, готовы ли подрядчики дорабатывать решения под наши задачи. После отсева остался ровно один претендент — это HelpDeskEddy, который мы решили опробовать в рамках бесплатного тестового периода.
В ноябре 2024 я принялся самостоятельно изучать сервис, затем презентовал команде его возможности. Сошлись на том, что решение полностью покрывает наши потребности. Оставалось разобраться с самой трудоёмкой задачей — организовать и обеспечить наш переезд.
Переезжаем на новый хэлпдеск
Первое, чем мы озаботились после тестирования хэлпдеска — это согласование с коллегами его внедрения в наши процессы. Документацию о работе сервиса показали команде аналитиков, системным администраторам и коллегам из ИБ. Убедились, что блокеров к внедрению нет, и начали продумывать пошаговый план переезда.
Необходимые шаги фиксировали в формате чек-листа. К слову, если потенциальный подрядчик предоставляет вам чек-лист по подключению его продукта — это сильно облегчает процесс тестирования.
В течение декабря 2024 года я работал по нашему чек-листу: углублялся в работу сервиса, уточнял детали у нашего менеджера и формировал общую картину того, как наша поддержка будет выглядеть в новом хэлпдеске.
Начал с основного — переезда каналов связи. Определил, какие каналы можно перевезти без особых проблем и временных затрат (Telegram, VK, почты, интеграция с голосовым ботом), а какие каналы требуется тщательно подготовить к миграции (например, в случае с чатом в мобильном приложении нужно было подключить новую интеграцию к HDE, и затем плавно переключить).
Мой совет здесь: заранее выясните, как и за какое время вы сможете перевезти ваши каналы связи в новую систему. Благодаря тому, что я заранее выписал все каналы и узнал, как именно будет выглядеть переезд, в этом процессе мы споткнулись всего один раз (о нём расскажу чуть позже).
Один из каналов связи нашей поддержки — это чат в мобильном приложении. Изначально я думал, что его сложнее всего будет перевезти на новый хэлпдеск, но в кооперации с командой мобильного приложения мы без проблем закрыли задачу.
Я передал ребятам всю документацию для изучения; по итогу они предложили несколько вариантов подключения чата, один из которых нам подошел. Мы подключили чат и начали его тестировать.
Также важно разбивать процесс на итерации. В нашем случае было так: мы решили, что когда в новом хэлпдеске все будет готово, то тестово перевезём 5% трафика и донастроим что-то в моменте. А потом будем наращивать процент трафика в течение нескольких дней, пока сотрудники адаптируются к работе в новом хэлпдеске. Подход себя оправдал: на переезде 5% трафика мы поймали пару доработок и оперативно их закрыли, а постепенная миграция позволила коллегам работать без особого стресса.
Момент, который я не предусмотрел — смена подрядчика, который обеспечивал нам работу мессенджеров. Я думал, что это займет меньше времени, а в итоге всё задержалось из-за бюрократии. Пришлось немного подождать, но в целом это было некритично.
Параллельно с подключением каналов связи я занялся другими важными задачами. Например, переносом нашей системы тегирования тикетов. Автоматически перенести теги так, как нам требовалось, не получилось — пришлось долго прописывать их в системе вручную. Помимо этого я настраивал и другие элементы: фильтры заявок, правила, группы доступа, поля заявок, плагины и многое другое для удобной работы сотрудников.
В течение декабря мы столкнулись с дилеммой. С одной стороны, спешить с переездом не хотелось — слишком много рисков: что-то может вдруг отвалиться технически, у саппортов могут возникать вопросы по работе с новой системой. С другой стороны, не хотелось терять время на праздниках!
Пришли к компромиссу. До каникул я завершил настройку базовой функциональности хэлпдеска, мы предоставили тестовый доступ к нему старшим смены (они работают в сменном графике) и подключили им канал с низким трафиком. Таким образом в течение праздников коллеги смогли основательно протестировать систему.
По мотивам их обратной связи я внес необходимые доработки, и к концу января мы перевезли поддержку на новый хэлпдеск. В течение февраля ещё ожидали подрядчиков, чтобы подключить мессенджеры, а уже в марте всё работало так, как нужно: саппорты привыкли к пользованию хэлпдеском, все системы были налажены.
Что учитывать при переезде на новый хэлпдеск?
Последовательность действий, которые помогли в процессе лично мне, я собрал в небольшую памятку:
Собрать чек-лист по техническим моментам миграции. Можно попросить подрядчика составить что-то подобное, а возможно, специальный чек-лист у них уже есть. Если обе опции недоступны, есть смысл составить его самому: поэтапно пройтись по действующей системе и описать всё, что предстоит настроить; собрать требования команды и руководителя к новой системе.
Уведомить о переезде все причастные команды. Как минимум безопасников, сисадминов и аналитиков. Плюс задуматься об интеграциях. Когда я начал собирать список интеграций, необходимых в новой системе, набралось немало. А изменение интеграции — это время, зачастую — время другой команды. Поэтому важно заранее приходить к командам и чётко обозначать сроки: с уверенностью в завершении работ к планируемой работе.
Пообщаться с юристами. Переезд на новый хэлпдеск как минимум подразумевает заключение договора с новым партнером. Договор, в свою очередь, может предполагать некоторые ограничения в использовании системы — стоит заблаговременно обратиться к корпоративным юристам для выявления таких моментов. Подробнее о юридических тонкостях покупки нового ПО (и других распространенных в ИТ сценариев) на Хабре недавно рассказала наша коллега @Legaldrive.
Обеспечить условия для адаптации к новому хэлпдеску. В первую очередь сервис должен быть полезен и удобен вашим саппортам. Полезно будет подготовить разъясняющие видео, провести серию встреч с обучением. Например, на этапе тестирования системы я показал ее работу другим лидам и сориентировал их по функциональности, а для обучения саппортов записал пару видео с рассказом о том, как пользоваться хэлпдеском и о его специфике. Плюс важно внимательно собирать фидбек коллег, оперативно вносить доработку в систему с учётом их потребностей.
Действовать аккуратно. Как известно, сколько не готовься, всё равно что-то может пойти не так. Главное — иметь на такой случай запасной план. При переезде на новую систему мы не расторгали договор с прошлым хэлпдеском. И переезжали постепенно, чтобы убедиться в полном соответствии хэлпдеска нашим ожиданиям.
А ещё, как известно, всегда можно сделать лучше. Например, сейчас я понимаю: мы могли чуть больше погрузиться процесс подключения каналов и предусмотреть сильную задержку, связанную со сменой подрядчика; лучше приоритизировать задачи; могли сначала переработать некоторые процессы, а уже потом их перевезти.
Другое дело, что в итоге у нас всё разрешилось удачно — и вот что конкретно мы получили от нашего переезда.
Плюсы переезда на новый хэлпдеск
На основе фидбека саппортов и других команд, мы зафиксировали основные преимущества работы с новым хэлпдеском (подтверждены пятью месяцами активного пользования системой):
Работа саппортов стала комфортнее и быстрее. Стало удобнее работать внутри тикета, появилась возможность реже переключать внимание на другие рабочие системы.
Приведу пример. В прошлом хэлпдеске было неудобное разделение разных каналов связи: почтового и чата. Из-за этого саппортам приходилось переходить в другую вкладку, а лиду — следить, чтобы это не забывали делать. Сейчас всё в одном месте, обработка почты занимает меньше времени, а все почтовые тикеты — на виду. В целом время ответа клиентам существенно сократилось — в том числе потому, что при переезде, проводя инвентаризацию процессов, многие из них мы пересмотрели и улучшили. И очень этому рад!
Удобнее работать с новым хэлпдеском и аналитикам. Выгружая тестово данные из новой системы, они рассказали, что получают намного больше сырых данных по сравнению с прошлым хэлпдеском. И отслеживать их легче, чем раньше. Что это значит для нас? Больше сырых данных — это больше метрик, которые мы можем собирать и анализировать. И приятный бонус — большое количество логов внутри тикета. Раньше, чтобы понять причину того или иного поведения правил в тикете, нужно было сильно погружаться и «копать». Сейчас всё намного проще и нагляднее.
Лиды и руководство — тоже все в плюсе. Мы тратим меньше денег на новый хэлпдеск, получаем больше информации, сотрудникам удобнее работать, а новые необходимые нам функции часто реализуют менеджеры нового хэлпдеска.
На этом всё. Надеюсь, информация оказалась для вас полезной и вы сможете применить полученные знания на практике. Рад был поделиться опытом!
