Whoosh — лидер российского кикшеринга — работал в трёх тикет-системах одновременно и хотел свести поддержку в один гибкий контур. За месяц активной интеграции компания перенесла поддержку в коробочную версию HelpDeskEddy, за неделю адаптировала операторов и построила поверх системы собственный слой плагинов, маршрутизации и аналитики.
тикет-системы свели в один контур
на интеграцию коробочной версии
на переход команды поддержки
присутствия компании
О компании
Whoosh — сервис поминутной аренды электросамокатов и электровелосипедов, лидер рынка кикшеринга в России. Кроме России компания работает в Казахстане, Беларуси и в Латинской Америке — Бразилии, Чили, Мексике и Колумбии.
Мы продукт, который является частью транспортной сети города. Ежедневная проблема номер один — добраться из точки А в точку Б: от дома до работы, от метро до работы, от метро до автобуса.
Продукт делится на две части, и обе генерируют обращения. Хардверная — самокаты и велосипеды в городе: состояние техники до, во время и после поездки. Софтверная — мобильное приложение, через которое пользователь стартует и завершает поездку, привязывает карту, покупает пакеты минут и подписки. Отсюда и основной пул вопросов: что-то пошло не так в поездке или что-то пошло не так в приложении.
В HelpDeskEddy работает подразделение поддержки пользователей Whoosh. Внутри него несколько команд: поддержка внешнего клиента и отдельная линия для внутреннего клиента — операционных команд, которые обслуживают флот в городах.
Точка А: три системы и потолок гибкости
Резкой аварийной ситуации не было — была накопленная усталость от инструментов. Исторически поддержка Whoosh жила только в мобильном приложении, и омниканальность была не нужна. По мере роста бизнеса каналов стало больше, а старое решение их не тянуло: одна система закрывала почту и ботов для внутренних процессов, вторая — чаты, отдельно стояла телефония.
Решение для чатов не поддерживало нужные интеграции, а работа с почтой была ограниченной. Маршрутизация, интерфейс и логика сбора аналитики упирались в то, что предлагал вендор из коробки, а любая доработка означала отдельные часы разработки. Внутренние процессы — онбординг, выдача доступов, контроль качества — приходилось вести вручную. Плюс три подписки вместо одной.
Решение двигаться назрело примерно за два года до перехода. Но кикшеринг не может мигрировать в любой момент: с мая по ноябрь идёт сезон и пиковые нагрузки на сервис и поддержку. Окно для переезда узкое, зимнее — первое компания пропустила и переехала в следующее.
Что искали
Один контур
Свести три тикет-системы и телефонию в одно рабочее пространство.
Омниканальность
Подключать новые каналы по мере роста, включая Telegram-ботов.
Своя кастомизация
Настраивать систему силами команды — без счёта за часы разработки вендора.
Своя маршрутизация
Не зависеть от набора параметров, который предлагает вендор.
Аналитика в свой BI
Метрики по линиям, группам и операторам с выгрузкой во внутренний BI.
Автоматизация процессов
Онбординг сотрудников, выдача доступов, контроль качества.
Коробка в своём контуре
Развернуть on-premise с учётом собственного интеграционного слоя между приложением и интерфейсом оператора.
Почему HelpDeskEddy
Перед переходом команда провела полноценное исследование: собрала сравнительную таблицу, где по пунктам оценивала функционал решений и преимущества, важные именно поддержке Whoosh.
Ключевой сдвиг в требованиях: если двумя годами ранее компания искала систему со встроенной автоматизацией, то к моменту выбора стало понятно, что всю автоматизацию Whoosh будет вести сам. Значит, оболочку нужно выбирать по двум параметрам — омниканальность и кастомизация. HelpDeskEddy в компании смотрели ещё за три с половиной года до перехода, но тогда продукт показался сырым; повторный интерес возник после отраслевой конференции.
Мы посмотрели ещё раз и прикинули. При плюс-минус том же наборе фичей у вас хорошая кастомизация — и экономика решения нас устроила.
Вторым весомым аргументом стал сам процесс сотрудничества: скорость согласований, готовность идти навстречу и качество поддержки вендора. Решение принимали коллегиально: кандидатуру предложила поддержка, финальное слово было за разработкой, девопсами и продуктом — слишком много подразделений вовлечено в такую миграцию.
Как переезжали
Демонстрацию системы провели для команды поддержки, но настоящая проверка началась с тестового стенда в облаке, к которому Whoosh сразу подключил собственный чат-сервис.
Доступы к облаку, свой стенд, подключение собственного чат-сервиса.
Старт интеграции сразу после каникул.
Интеграция готова на стенде, разворачивается коробочная версия.
Запуск прода.
Перевод операторов поддержки в новую систему.
Доработка Quality of Life-плагинов под конкретные линии.
Заняла интеграция HelpDeskEddy с внутренней инфраструктурой Whoosh. Компания не использует стандартные методы интеграции — у неё собственный слой между мобильным приложением и интерфейсом оператора, который команда дорабатывала под HDE сама. Возможности интеграции по API
Отдельный блок работы — адаптация людей. Переход команды поддержки на новый инструмент занял неделю: операторы разобрались со всем, что было заложено в систему. Ещё пара недель ушла на привыкание, после чего процесс вышел на рабочий режим.
Что команда построила поверх системы
Whoosh — тот случай, когда клиент использует HelpDeskEddy как платформу, а не как готовую коробку.
Мне кажется, вообще ничего из того, что в системе было изначально настроено, мы не используем. У нас всё закастомилось.
Руководитель отдела автоматизации написал под задачи поддержки несколько собственных плагинов.
Маршрутизация
Самый крупный плагин. Управляет очередями входящих и позволяет в критичные моменты подключать к разбору другие линии.
Статистика по сменам
Показывает, что и в каком объёме приходит на смену, — данные для тимлидов в реальном времени.
История переписки в чате
Подгружает переписку из других тикетов прямо в окно чата в карточке заявки.
Маршрутизация под свои сценарии
Whoosh собирает по пользователю много дополнительных полей, а отдельный слой автоматизации эти поля прокидывает. На основе этого заявка из автоматизированного сценария сразу уходит на нужного оператора, минуя общий маршрут. Работает профилирование пользователей и несколько типов приоритизации.
В большинстве тикет-систем ты либо вообще не можешь настраивать маршрутизацию сам, либо настраиваешь постольку-поскольку: вендор предлагает набор параметров, они тебе не подходят, ты просишь поменять — тебе заряжают ценник или говорят, что так нельзя. Здесь мы не чувствовали себя завязанными на то, что нам предложили в инструменте, — смогли сделать два шага вперёд.
Дашборд для тимлидов
Через фильтры на главной собрали живую панель для тимлидов и мидл-менеджеров: сколько обращений приходит на каждую линию, на конкретный навык, на кросс-команду. Раньше для этого нужно было грузить отчёт — теперь картина всегда перед глазами, и по ней видно, где линии не хватает людей.
Гибкие роли
Whoosh завёл собственные роли под процессы, которых раньше не хватало. Например, для контроля качества: сотрудник видит все тикеты и имеет к ним доступ, но не получает супервайзерских настроек. Подробнее о настройке типов, статусов и прав — в разделе управление заявками.
Точка Б: что изменилось
Было
— три тикет-системы и отдельная телефония
— маршрутизация в рамках того, что даёт вендор
— первая линия и общая очередь без разбивки
— передача задач в сторонний сервис через промежуточное решение
— доработки — за отдельные часы разработки
Стало
— один контур для внешней и внутренней поддержки
— маршрутизация на собственных плагинах и правилах
— метрики по линиям, группам и каждому оператору
— передача заявки кнопкой внутри системы, с аналитикой
— кастомизация силами своей команды
Сквозные процессы перестали разбегаться
Раньше оператор первой линии оценивал критичность проблемы и заводил задачу в стороннюю систему, прямого доступа к которой у него не было, — процесс держался на промежуточном решении, которое принимало заявки и передавало их дальше. Сейчас этого звена нет: оператор нажимает кнопку передачи внутри одной системы, тикет уходит нужной команде, а по передаче остаётся аналитика. Пользователь получает решение быстрее, а руководитель видит, сколько времени заняла каждая передача.
Операционная часть поддержки оцифрована почти на 100%
До перехода не существовало показателей выработки по линиям — были только первая линия и общая очередь. Дополнительные поля к тикетам, которые команда заводит и регулирует самостоятельно, позволили соединить данные из базы с действиями оператора и построить развёрнутую аналитику в собственном BI.
Сейчас мы видим, сколько тикетов было на боте, сколько на первой линии, с каким CSAT тикет закрылся, в какой промежуток, по какому правилу, с каким типом пользователя. Скорость по каждому оператору, CSAT по каждому оператору. Мы сейчас видим всё, что раньше не видели.
Главный результат — не в отдельной метрике, а в том, что поддержка при сезонных пиковых нагрузках и работе в семи странах стала управляемой и измеримой.
Что особенно нравится в системе
Очень круто, что есть возможность глубинных настроек. И круто, что вы выкатываете свои примеры плагинов, которые позволяют дополнять или в принципе менять функционал.
Команда выделила инструменты, на которых держится вся кастомная логика.
Плагины
Возможность дописать любой функционал под свои процессы и менять поведение интерфейса.
Диспетчер и правила
Автоматизация маршрутизации, на которой держится вся логика распределения заявок.
Дополнительные поля
Основа аналитики: команда заводит и регулирует поля самостоятельно.
Конструктор отчётов
Базовые отчёты на период без аналитиков и лицензий на BI-инструменты.
Гибкие роли
Свои роли под процессы, которых нет в стандартном наборе, — например, для контроля качества.
Настройка дизайна
Интерфейс подстраивается под то, как команде удобно работать.
Я пользовался конструктором отчётов до того, как мы вытянули аналитику в собственный BI, чтобы строить базовые отчёты на период. Очень удобная штука — особенно для поддержек, у которых нет ни аналитиков, ни лицензий на какие-нибудь BI-инструменты.
Отношение к клиенту
Чувствовалось, что продукт изначально делается людьми, которые из саппорта вышли, для саппортов. Мы сразу запустили общий чат, внутри которого можно было обсуждать вопросы чуть ли не 24/7. И самое главное — вот эта магия обычно заканчивается через две недели после интеграции и оплаты счёта, появляется «пишите на support@». У нас с вами этого не произошло. Если есть серьёзная проблема, мы понимаем, что нас поддержат. Вы довольно лояльны, и мы это очень ценим.
Итог и планы
Whoosh пришёл в HelpDeskEddy не за готовым решением, а за платформой, которую можно перестроить под себя. За месяц активной интеграции компания перенесла поддержку из трёх разрозненных систем в единый контур на коробочной версии, за неделю адаптировала операторов и за пару месяцев дописала поверх системы собственный слой плагинов, маршрутизации и аналитики.
Вся поддержка пользователей уже работает в HelpDeskEddy, в этом же сезоне в тот же контур завели поддержку внутренних клиентов — операционных команд, обслуживающих флот в городах. Дальнейшее развитие компания планирует после закрытия сезона: наращивать собственные плагины и автоматизацию. Другие внедрения — в разделе кейсы.
