Как мы свою helpdesk-систему пилили

Еще четыре года назад команда техподдержки студии Plarium Krasnodar пользовалась сторонней тикет-системой, в чем было много минусов. Сегодня у нас появилась не просто своя система, а хелп-деск, подстроенный под нужды компании. Как это произошло — читайте в статье.



С чем же таким мы столкнулись, что задумались о разработке собственной тикет-системы? Основные проблемы:

1. Наша команда получала по 1–1,5 тысячи обращений от пользователей каждый день.
2. Отсутствовала удобная для ведения статистика. Все приходилось отмечать в различных документах вручную.
3. Самая главная трудность: большая часть обращений требовала проверки состояния аккаунта игрока, к чему на тот момент не было непосредственного доступа — мы работали только с текстами самих обращений и электронными адресами.
4. Создавал сложности и интерфейс. Чужие решения чаще всего неудобны, потому что не заточены под конкретную игру и регламенты работы техподдержки конкретной компании.
5. С учетом всего перечисленного оплачивать стороннюю систему было не очень выгодно.

И мы принимаем эпохальное решение — пилить собственную тикет-систему! А что? Силы есть, идей полно, энтузиазма — хоть отбавляй. Но на тот момент не было соответствующих процессов: мы, команда поддержки, еще ни разу ничего не заказывали у команды разработки внутреннего инструментария и плотно с ней не взаимодействовали.

С чего ж начать? Мы выписали в два столбца наши ожидания от инструмента (что-то в стиле «хотим получать сообщения и отвечать на них») и претензии к текущему варианту («вот тут окошко неудобное, сделайте удобнее»), назвали это техническим заданием и передали разработчикам. Дальнейший процесс занял примерно 3 месяца. Этапа тестирования не было, все ошибки находили разработчики или сама поддержка уже при использовании инструмента.

Как можно догадаться, этот блин вышел комом. Мы попробовали его и подумали, что недостатки покупного сервиса не такие уж и серьезные. И тут команда коммерческого хелп-деска предложила интеграцию, при которой она получала бы из игры информацию о пользователе и передавала ее в тикетах нашей поддержке (это решило бы основную проблему). Однако некоторые условия интеграции противоречили требованиям безопасности, принятым в компании. Итак, какие у нас были варианты:

1. Сделать небезопасную интеграцию с коммерческим хелп-деском.
2. Пользоваться его урезанным функционалом.
3. Вернуться к разработке инструмента.

Мы пошли по последнему пути. Исправили все, что не работало после первой итерации, и подключили тикет-систему к играм. У нее был базовый функционал: мы принимали заявки и отвечали на них, отправляя сообщения на почту. Но что самое главное, у нас наконец появилась возможность видеть в тикет-системе идентификатор игрока, ссылающийся на другой наш внутренний инструмент с остальной информацией об аккаунте.

В команду, которая обеспечивала процесс разработки, изначально вошли product owner, PM и dev-команда. Мы сами рисовали дизайн, разработчики редактировали и, насколько это было возможно, тестировали продукт. Затем присоединились UX/UI-дизайнеры и QA. В итоге получился следующий процесс: заказчик пишет, чего он хочет, UX/UI говорит, как это лучше сделать, разработчики реализуют, QA проверяет, а PM контролирует всю цепочку и сроки.



Введя тикет-систему с минимальным функционалом, мы начали ее улучшать и подгонять под нужды и цели компании. Всего до сегодняшнего дня было реализовано больше 200 фич, ниже перечислены основные.

1. Сбор статистики по интересующим показателям. Исходя из целей и задач техподдержки, а также KPI для измерения эффективности работы, удалось определить, какая именно нам нужна статистика. Получилось 7 форм отчетов более чем по 50 показателям.
2. Интерфейс обучения — чтобы новички могли безопасно (через апрув руководителя) работать с реальными обращениями пользователей.
3. Программа автоматического ответа на обращение в зависимости от его содержания и темы.
4. Жизненный цикл тикета с автоматическими переходами из одного статуса в другой по времени или событиям.
5. HTML-верстка писем с красивым оформлением в стилистике проектов.
6. Перенос самой важной информации об игроке прямо в тикет-систему. До этого специалисты поддержки могли видеть в ней только идентификатор-гиперссылку на другую программу с данными.
7. Фильтрация и сортировка обращений.
8. Участие игрока в оценке качества работы оператора. Мы сделали цикл отправки писем, сбор статистики и ее анализ.
9. Функционал распределения доступов к элементам тикет-системы для разных операторов.
10. Кабинет команды, которая оценивает качество работы операторов.
11. Специальные технические статусы и состояния тикетов (не только классические new, waiting, answered, resolve и close, но и inprogress, pending). Они помогают операторам создавать добавочные фильтры; обозначают обращения, требующие дополнительной проверки и/или ожидающие ответа от других отделов; прерывают жизненный цикл тикета на время ожидания (не дают ему автоматически закрыться).
12. Функция общения с игроком по инициативе техподдержки.
13. Встроенная переписка с техподдержкой прямо в игре.
14. Сервис, автоматически определяющий тему обращения по его тексту.
15. Программируемые флоу — установленные решения, в том числе оповещение ответственных сотрудников, на случай того или иного события в тикет-системе.

Какой у нас был стек технологий:

• написанное на C# приложение .NET Web API в качестве бэкенда;
• клиент на Angular;
• MongoDB в качестве базы данных и ElasticSearch для полнотекстового поиска;
• Mailgun для рассылки сообщений на почту игрокам.

Общий вид Support Ticket System

Подведем итоги.

Плюсы от разработки собственной тикет-системы

1. Заточенность хелп-деска под вашу компанию в решении задач, упрощении флоу и отслеживании показателей.
2. Углубление знаний о функционировании тикет-системы и о работе команды техподдержки, сидящей через стенку от вас.
3. Независимость от обновлений стороннего хелп-деска. Всегда неприятно, когда из-за мешающего изменения приходится перестраивать процессы.
4. Безопасность, которую дает отказ от использования сторонних решений в своих проектах.
5. Заточенность интерфейса под ваши потребности.
6. Быстрое внедрение уникальных фич. Например, ни в одном стороннем хелп-деске до сих пор нет удовлетворительной системы обучения новичков или пространства для команды, которая оценивает качество работы операторов.
7. Возможности интеграции. Ваш продукт вырастает до экосистемы, объединяя в себе разные программы в одну цепочку, что оптимизирует работу сотрудников и дает более высокое качество.
8. Новое направление работы, развитие сотрудников, бесценный опыт.
9. Мотивация для всех причастных. Специалисты поддержки чувствуют, как их «хотелки» реализуются, а команды разработчиков, QA и UX/UI-дизайнеров видят, как их проект растет и какую пользу он приносит операторам.

Минусы

1. В начале развития проекта затраты на разработку и поддержку системы превышают стоимость готового решения. Насколько — зависит от объема поступающих сообщений, величины команды поддержки и набора необходимых функций. Однако такой проект окупается. Если 40 операторов отправляют по 50–70 тысяч ответов в месяц, затраты на свою систему и на покупной сервис сравняются через 3–5 лет (в зависимости от стоимости этого сервиса). Если учесть эффект от плюсов собственной тикет-системы, ее гибкости, от функциональных элементов, оптимизирующих работу сотрудников, то окупаемость наступает года за два. После завершения разработки нужно платить только за хостинг, и это меньше, чем за сторонний хелп-деск.
2. Придется пройти долгий и трудный путь. Мы несколько раз меняли процесс разработки, ругались и мирились, делали и переделывали. За эти 3,5 года было исправлено больше 1 500 багов.
3. Понадобятся структурные изменения. Необходима команда, которая работает на обеспечение внутренних процессов. Нужно разделять тех, кто производит продукт компании, и тех, кто делает back office tools. Привлечь основных разработчиков к созданию такого инструмента вряд ли получится.

Ввязываться в это дело или нет — решать вам. А мы не жалеем, что ввязались. Было страшно. И страшно интересно было тоже.