Весной портал технической поддержки «ДоксВижн» экстренно переехал с Zendesk на платформу ITSM 365 — всего за 3 недели. Говорят, переезд хуже пожара. Однако весной полыхало у многих — многие ИТ-службы столкнулись с вызовом, когда требовалось быстро перевести привычные сервисы на новые платформы с сохранением бизнес-процессов и функций. В этой статье я хочу рассказать, как мы выбирали новый инструмент для реализации портала технической поддержки и быстро мигрировали.

Мы компания-вендор, разрабатываем Docsvision и оказываем техническую поддержку нашим партнёрам и клиентам. В марте мы поняли, что не сможем продлить наш аккаунт на Zendesk, на котором больше 10 лет работал наш портал техподдержки. Менеджеры Zendesk перестали нам отвечать, впереди маячил срок очередной оплаты (у нас была поквартальная оплата), доллар лихорадило. Впору паниковать, но это не наш путь.

Что бы ни случилось, мы считали, что сервис технической поддержки Docsvision не должен пострадать, наша мантра в то время и всегда «сервис должен быть непрерывным». Мы должны продолжать помогать нашим заказчикам, отвечать на их вопросы, выдерживать SLA на привычном высоком уровне и не создавать им дополнительных проблем.

Вообще, несмотря на долгие отношения с Zendesk, сервис нас не очень устраивал. Весьма ограниченная функциональность, высокая цена за агентские учётки, шаг в сторону — дополнительная оплата и всё такое. Осенью 2021 года мы приняли решение, что будем всё же искать что-то другое, и начали делать это в комфортном неспешном темпе. У нас был почти год до истечения контракта, мы всё успеем, думали мы. В планах переезд был в июле 2022. Поэтому, когда гром ударил, шока у нас не было, но пришлось ускориться с окончательным выбором, внедрением и запуском.

Поиск и выбор нового сервис-деска

Из всего разнообразия на рынке мы нашли 21 сервис-деск. Чтобы выбрать подходящий, определили критерии для выбора, на старте их было порядка 50, по ходу немного скорректировали. При подготовке статьи проверила — 43 критерия из 6 групп. Да, так много уже на первом этапе, у нас много требований, и было время проверить системы по всем ним. Может быть, кому-то будет полезен наш список.

Критерии оценки – первый этап

Технические характеристики:

1. Стабильность/надёжность/доступность. Нам нужен сервис надолго и работающий 24/7. Продукт должен быть давно на рынке, с хорошей репутацией.

2. Размещение (in-house, SaaS). Готовы были рассматривать разные варианты, но SaaS был предпочтительнее.

3. Территория хранения данных. Закон о персональных данных ужесточался, нам нужно было, чтобы данные хранились в пределах РФ.

4. Размер хранилища. В процессе работы у нас формируется очень много файлов (логи, скриншоты и проч.), нам нужно было, чтобы хранилище хотя бы в первый год работы не переполнилось (Zendesk, кстати, в своё время пришёл к нам за дополнительной платой за хранение наших данных, альтернативой было только удалить старые тикеты).

Стоимость владения:

1. Стоимость подписки в месяц.

2. Дополнительные платежи.

3. Условия покупки дополнительных учётных записей.

Удобство работы:

1. Красивый интерфейс по нашему вкусу.

2. Возможность тегирования заявок.

3. Удобный поиск.

4. Мобильное приложение.

5. Возможность создать заявку от имени клиента.

6. Способы создания заявки.

7. Удобство для пользователя.

Кастомизация:

1. Возможность кастомизации. Добавление своих типов заявок, дополнительных полей в заявки и другие объекты, отчётов и прочее.

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

3. API.

4. Брендирование.

Необходимые фичи:

1. Отчёты/Статистика.

2. Выгрузка отчётов в excel.

3. Настройка SLA.

4. Календарь рабочего времени.

5. Возможность разграничения прав на объекты.

6. Форум.

7. База знаний.

8. Возможность добавлять наблюдателей по заявкам.

9. Модерация при регистрации пользователей.

10. Личный кабинет пользователя/компании.

11. Срытые комментарии в заявке.

12. Подписи для инженеров техподдержки при ответах.

13. Шаблоны ответов (макросы).

14. Обратная связь после решения инцидента. Возможность оценить ход решения заявки.

15. Механизмы импорта заявок (из Zendesk).

16. Приостановка доступа пользователю.

17. Отсутствие лимитов (или разумные лимиты) по количеству компаний и пользователей.

18. Работа со списками пользователей/организаций.

Другое:

1. Самообслуживание (что есть для самостоятельного обслуживания).

2. Трёхсторонняя работа (вендор-интегратор-пользователь).

3. Автоматическая маршрутизация заявок.

4. Отметка о недоступности инженера техподдержки. Инженер уходит в отпуск, становится недоступным, присутствует какая-то логика в обработке его заявок, которые возвращаются от пользователей.

5. Песочница. Для тестирования кастомизаций.

6. Геймификация.

7. ИИ.

Критерии писались на основе нашего опыта работы с Zendesk, то, что нам обязательно нужно, или то, чего не было, но оооочень хотелось. Часть систем «отвалились» ещё на уровне изучения информации в открытых источниках, большая часть. Где-то мы запрашивали демо, общались с менеджерами.

В шорт-лист попали 4 системы, которые отвечали большинству требований (Usedesk, Okdesk, ITSM365 и Intradesk, который тут же и сошёл с дистанции). Для окончательного выбора каждый сервис мы дополнительно оценили по 35 критериям в части функциональности и выбрали новый сервис-деск. Дополнительные критерии не так интересны публике, они больше заточены именно на наш формат работы, процессы и привычки. Мы заказали или продлили себе демостенды с системами и принялись рассматривать их со всех сторон: настраивали SLA, как нам нужно (наши правила нетривиальны, да ещё и местами индивидуальные), крутили автоматизацию, разбирались с настройками отчётов, смотрели особенности работы (вроде доступов к файлам заявок по прямой ссылке).

Миграция на новый портал

Впереди была миграция на новый портал. Это было для нас нечто новое. До этого мигрировали мы между какими-то внутренними системами, где можно не обращать внимания на костыли, недоделки. Здесь у нас не было шанса на ошибку. План был такой:

1. Уведомить пользователей, что нас ждёт переезд.

2. Наполнить каталог услуг.

3. Настроить все нужные типы заявок, необходимые и достаточные.

4. Настроить SLA.

5. Наполнить базу знаний необходимыми для старта статьями, в т.ч. описанием работы на новом портале.

6. Провести обучение сотрудников, которые будут работать с системой.

7. Зарегистрировать активных пользователей и отправить им данные для входа на новый портал. Мы взяли активных за последние пару лет.

8. Провели вебинар для партнёров, как работать с новым порталом.

9. Закрыли приём новых заявок на Zendesk, повесили объявление, где создавать заявки для тех, кто всё пропустил.

10. Всё, что могли, быстро дорешали на Zendesk, потенциально долгоиграющие заявки перенесли в новую систему.

11. Выгрузили все заявки (за 10 с лишним лет, страшно подумать) из Zendesk.

12. Выгрузили статьи из базы знаний.

13. Выполнение доработок не первой необходимости.

14. Загрузили все старые заявки в качестве архивных на новый портал. Правда, спустя несколько месяцев.

После переезда не прошло и месяца, как Zendesk после однократного уведомления просто удалил наш аккаунт (сразу на следующий день после уведомления).

Почему миграция прошла легко?

• Мы детально продумали план переезда.

• Совершили переезд в максимально короткие сроки, буквально в пятницу закончили работу на Zendesk, в понедельник начали на ITSM 365.

• Мы не заставляли пользователей самостоятельно регистрироваться, создавать новые заявки и прочее. Пользователям нужно было только заменить ссылку для входа, ну, и, может, пароль изменить на привычный. Формат логина мы оставили такой, к которому все привыкли. Зашёл на новый портал — продолжил работать со своими заявками.

Вместо заключения

Надеемся, что вам будет полезен наш опыт. Если в новом году вас ждёт что-то глобальное и, может, даже пугающее, то помните – дорогу осилит идущий. И не забывайте о пункте назначения.