Кейс: миграция клиентского сервиса с Freshdesk на ELMA365 с интеграцией Jira

Мы внедряем ELMA365 и чаще всего нас зовут туда, где сервис уже «как-то работает», но бизнес из него вырос.

Это как раз такой случай. У клиента был действующий клиентский сервис на Freshdesk — не тестовый, не пилот, а система, через которую годами проходила реальная работа с клиентами и подрядчиками. Просто в какой‑то момент стало понятно: дальше так масштабироваться нельзя.

Расскажу, как мы аккуратно переехали на ELMA365, ничего не потеряли по истории и заодно радикально упростили работу с сервис‑провайдерами через Jira.

Сервис, который стал слишком большим для своей системы

Freshdesk у клиента использовался несколько лет. За это время там накопилось всё:

• тысячи обращений с перепиской;
• сотни компаний и тысячи клиентов;
• сотни активных тикетов одновременно в работе;
• часть задач уходила внешним сервис‑провайдерам через Jira.

И вот тут начались «болезни роста».

Чтобы изменить процесс - приходилось изобретать костыли. Передача обращения провайдеру - вручную. Статусы в одной системе обновились, в другой - нет. Комментарии живут в двух местах. Люди тратят время не на решение проблемы клиента, а на синхронизацию между инструментами.

Бизнесу уже был нужен не просто helpdesk, а управляемая процессная система, которая станет основой для развития сервиса.

Почему вообще решили переезжать

Переход — это всегда риск. Особенно когда речь про клиентский сервис, который работает каждый день.

Но в данном случае плюсы перевесили:

• нужна была гибкость в логике процессов, ролей, маршрутов;
• требовалось нормально выстроить работу с несколькими линиями поддержки;
• хотелось убрать ручную работу при взаимодействии с подрядчиками;
• и главное — получить систему, которую можно дорабатывать под бизнес, а не подстраиваться под ограничения коробки.

ELMA365 здесь выбрали как платформу, на которой можно строить сервис как процессную модель, а не как набор тикетов.

Самое чувствительное — миграция данных

Самый нервный вопрос в таких проектах всегда один: «А история точно не потеряется?»

Нужно было перенести из Freshdesk:

• исторические обращения с комментариями;
• карточки компаний и клиентов;
• активные тикеты со статусами и ответственными.

Причём это не архив ради галочки - это рабочая история, к которой регулярно возвращаются.

Был отдельно спроектирован сценарий миграции, чтобы:

• сохранить связи между обращениями, клиентами и компаниями;
• корректно перенести переписку;
• не «сломать» статусы и ответственных по активным обращениям;
• и главное - не останавливать работу поддержки на время перехода.

В итоге ELMA365 стала новой единой точкой, где доступна вся история клиентского сервиса, а не только данные «с сегодняшнего дня».

Новый контур клиентского сервиса в ELMA365

Отдельно важный момент - у клиента использовался внешний портал для пользователей, через который они работали со своими обращениями. При переходе было принципиально не просто «поднять новый интерфейс», а сохранить для клиентов привычную логику и сохранить историю взаимодействия.

Мы перенесли обращения таким образом, что внешние пользователи в новом портале ELMA365 получили доступ к своей истории: старым тикетам, переписке и контексту прошлых обращений. Для них переход не выглядел как «обнуление» сервиса - вся предыдущая работа осталась доступной.

Дополнительно на портале настроили более удобный контроль за обращениями:

• уведомления при получении новых комментариев по обращению;
• наглядную визуализацию статусов и активности по тикетам прямо в интерфейсе портала.

Пользователям больше не нужно постоянно заходить в каждое обращение и проверять, «не ответили ли там». Система сама сигнализирует о важных изменениях, а текущее состояние обращений видно сразу.

После переноса данных мы развернули уже полноценную модель сервиса внутри ELMA365:

• единый реестр обращений и инцидентов;
• статусы, приоритеты, категории;
• роли операторов, ответственных и руководителей;
• контроль сроков и SLA;
• внутренняя и внешняя переписка прямо в карточке обращения.

Для сотрудников это стало единым рабочим окном. Для руководителей — прозрачной картиной по срокам, загрузке и узким местам.

Интеграция с Jira

Отдельная история - работа с сервис‑провайдерами через Jira. Раньше это выглядело так: сотрудник вручную создаёт задачу, переносит данные для связи с инцидентом Jira, что позволяет обмениваться комментариями, но переменные, ответственные и статусы живут своей жизнью параллельно в двух системах.

Мы сделали интеграцию, при которой:

• задача в Jira создаётся автоматически при передаче обращения провайдеру;
• комментарии ходят в обе стороны;
• статусы синхронизируются между ELMA365 и Jira;
• сотрудникам не нужно ничего дублировать вручную.

Если раньше передача обращения занимала вплоть до часа (с учётом ручных действий и перепроверок), то теперь это буквально несколько секунд системной работы.

Это сильно снизило нагрузку и почти убрало человеческий фактор на этом этапе.

Внутренняя логика тоже стала взрослее

Помимо интеграции, внутри ELMA365 настроили более гибкую механику обработки обращений:

• многоуровневую смену ответственных;
• автоматические эскалации при нарушении сроков;
• маршрутизацию между линиями поддержки;
• более прозрачное распределение нагрузки.

Сервис перестал держаться на «ручном контроле» конкретных людей и стал работать как управляемый процесс.

Что это дало бизнесу

В сухом остатке:

• вся история клиентского сервиса переехала без потерь;
• появился единый контур работы в ELMA365 вместо разрозненных инструментов;
• передача обращения провайдеру сократилась с более чем часа до нескольких секунд;
• статусы и комментарии между системами синхронизированы;
• стало меньше ручной рутины и «операционного шума»;
• прозрачнее стала ответственность и логика эскалаций.

По сути, клиент получил не просто новый helpdesk, а процессную платформу, на которой можно дальше развивать сервис.

Если у вас похожая история - старая система уже не тянет, а потерять данные и остановить сервис нельзя - такие переходы вполне реально делать аккуратно и безболезненно.