Еще четыре года назад команда техподдержки студии Plarium Krasnodar пользовалась сторонней тикет-системой, в чем было много минусов. Сегодня у нас появилась не просто своя система, а хелп-деск, подстроенный под нужды компании. Как это произошло — читайте в статье.
![](https://habrastorage.org/webt/yb/qj/vr/ybqjvrmcn0p-t_6sob5oth_c7te.jpeg)
С чем же таким мы столкнулись, что задумались о разработке собственной тикет-системы? Основные проблемы:
И мы принимаем эпохальное решение — пилить собственную тикет-систему! А что? Силы есть, идей полно, энтузиазма — хоть отбавляй. Но на тот момент не было соответствующих процессов: мы, команда поддержки, еще ни разу ничего не заказывали у команды разработки внутреннего инструментария и плотно с ней не взаимодействовали.
С чего ж начать? Мы выписали в два столбца наши ожидания от инструмента (что-то в стиле «хотим получать сообщения и отвечать на них») и претензии к текущему варианту («вот тут окошко неудобное, сделайте удобнее»), назвали это техническим заданием и передали разработчикам. Дальнейший процесс занял примерно 3 месяца. Этапа тестирования не было, все ошибки находили разработчики или сама поддержка уже при использовании инструмента.
Как можно догадаться, этот блин вышел комом. Мы попробовали его и подумали, что недостатки покупного сервиса не такие уж и серьезные. И тут команда коммерческого хелп-деска предложила интеграцию, при которой она получала бы из игры информацию о пользователе и передавала ее в тикетах нашей поддержке (это решило бы основную проблему). Однако некоторые условия интеграции противоречили требованиям безопасности, принятым в компании. Итак, какие у нас были варианты:
Мы пошли по последнему пути. Исправили все, что не работало после первой итерации, и подключили тикет-систему к играм. У нее был базовый функционал: мы принимали заявки и отвечали на них, отправляя сообщения на почту. Но что самое главное, у нас наконец появилась возможность видеть в тикет-системе идентификатор игрока, ссылающийся на другой наш внутренний инструмент с остальной информацией об аккаунте.
В команду, которая обеспечивала процесс разработки, изначально вошли product owner, PM и dev-команда. Мы сами рисовали дизайн, разработчики редактировали и, насколько это было возможно, тестировали продукт. Затем присоединились UX/UI-дизайнеры и QA. В итоге получился следующий процесс: заказчик пишет, чего он хочет, UX/UI говорит, как это лучше сделать, разработчики реализуют, QA проверяет, а PM контролирует всю цепочку и сроки.
![](https://habrastorage.org/webt/nb/zl/ie/nbzliemhgmdvmdixj0wq5qyfm_8.jpeg)
Введя тикет-систему с минимальным функционалом, мы начали ее улучшать и подгонять под нужды и цели компании. Всего до сегодняшнего дня было реализовано больше 200 фич, ниже перечислены основные.
Какой у нас был стек технологий:
![](https://habrastorage.org/webt/jq/dm/wf/jqdmwffzjjaoaii06fms_o_wc9m.jpeg)
Общий вид Support Ticket System
Подведем итоги.
Ввязываться в это дело или нет — решать вам. А мы не жалеем, что ввязались. Было страшно. И страшно интересно было тоже.
![](https://habrastorage.org/webt/yb/qj/vr/ybqjvrmcn0p-t_6sob5oth_c7te.jpeg)
С чем же таким мы столкнулись, что задумались о разработке собственной тикет-системы? Основные проблемы:
- Наша команда получала по 1–1,5 тысячи обращений от пользователей каждый день.
- Отсутствовала удобная для ведения статистика. Все приходилось отмечать в различных документах вручную.
- Самая главная трудность: большая часть обращений требовала проверки состояния аккаунта игрока, к чему на тот момент не было непосредственного доступа — мы работали только с текстами самих обращений и электронными адресами.
- Создавал сложности и интерфейс. Чужие решения чаще всего неудобны, потому что не заточены под конкретную игру и регламенты работы техподдержки конкретной компании.
- С учетом всего перечисленного оплачивать стороннюю систему было не очень выгодно.
И мы принимаем эпохальное решение — пилить собственную тикет-систему! А что? Силы есть, идей полно, энтузиазма — хоть отбавляй. Но на тот момент не было соответствующих процессов: мы, команда поддержки, еще ни разу ничего не заказывали у команды разработки внутреннего инструментария и плотно с ней не взаимодействовали.
С чего ж начать? Мы выписали в два столбца наши ожидания от инструмента (что-то в стиле «хотим получать сообщения и отвечать на них») и претензии к текущему варианту («вот тут окошко неудобное, сделайте удобнее»), назвали это техническим заданием и передали разработчикам. Дальнейший процесс занял примерно 3 месяца. Этапа тестирования не было, все ошибки находили разработчики или сама поддержка уже при использовании инструмента.
Как можно догадаться, этот блин вышел комом. Мы попробовали его и подумали, что недостатки покупного сервиса не такие уж и серьезные. И тут команда коммерческого хелп-деска предложила интеграцию, при которой она получала бы из игры информацию о пользователе и передавала ее в тикетах нашей поддержке (это решило бы основную проблему). Однако некоторые условия интеграции противоречили требованиям безопасности, принятым в компании. Итак, какие у нас были варианты:
- Сделать небезопасную интеграцию с коммерческим хелп-деском.
- Пользоваться его урезанным функционалом.
- Вернуться к разработке инструмента.
Мы пошли по последнему пути. Исправили все, что не работало после первой итерации, и подключили тикет-систему к играм. У нее был базовый функционал: мы принимали заявки и отвечали на них, отправляя сообщения на почту. Но что самое главное, у нас наконец появилась возможность видеть в тикет-системе идентификатор игрока, ссылающийся на другой наш внутренний инструмент с остальной информацией об аккаунте.
В команду, которая обеспечивала процесс разработки, изначально вошли product owner, PM и dev-команда. Мы сами рисовали дизайн, разработчики редактировали и, насколько это было возможно, тестировали продукт. Затем присоединились UX/UI-дизайнеры и QA. В итоге получился следующий процесс: заказчик пишет, чего он хочет, UX/UI говорит, как это лучше сделать, разработчики реализуют, QA проверяет, а PM контролирует всю цепочку и сроки.
![](https://habrastorage.org/webt/nb/zl/ie/nbzliemhgmdvmdixj0wq5qyfm_8.jpeg)
Введя тикет-систему с минимальным функционалом, мы начали ее улучшать и подгонять под нужды и цели компании. Всего до сегодняшнего дня было реализовано больше 200 фич, ниже перечислены основные.
- Сбор статистики по интересующим показателям. Исходя из целей и задач техподдержки, а также KPI для измерения эффективности работы, удалось определить, какая именно нам нужна статистика. Получилось 7 форм отчетов более чем по 50 показателям.
- Интерфейс обучения — чтобы новички могли безопасно (через апрув руководителя) работать с реальными обращениями пользователей.
- Программа автоматического ответа на обращение в зависимости от его содержания и темы.
- Жизненный цикл тикета с автоматическими переходами из одного статуса в другой по времени или событиям.
- HTML-верстка писем с красивым оформлением в стилистике проектов.
- Перенос самой важной информации об игроке прямо в тикет-систему. До этого специалисты поддержки могли видеть в ней только идентификатор-гиперссылку на другую программу с данными.
- Фильтрация и сортировка обращений.
- Участие игрока в оценке качества работы оператора. Мы сделали цикл отправки писем, сбор статистики и ее анализ.
- Функционал распределения доступов к элементам тикет-системы для разных операторов.
- Кабинет команды, которая оценивает качество работы операторов.
- Специальные технические статусы и состояния тикетов (не только классические new, waiting, answered, resolve и close, но и inprogress, pending). Они помогают операторам создавать добавочные фильтры; обозначают обращения, требующие дополнительной проверки и/или ожидающие ответа от других отделов; прерывают жизненный цикл тикета на время ожидания (не дают ему автоматически закрыться).
- Функция общения с игроком по инициативе техподдержки.
- Встроенная переписка с техподдержкой прямо в игре.
- Сервис, автоматически определяющий тему обращения по его тексту.
- Программируемые флоу — установленные решения, в том числе оповещение ответственных сотрудников, на случай того или иного события в тикет-системе.
Какой у нас был стек технологий:
- написанное на C# приложение .NET Web API в качестве бэкенда;
- клиент на Angular;
- MongoDB в качестве базы данных и ElasticSearch для полнотекстового поиска;
- Mailgun для рассылки сообщений на почту игрокам.
![](https://habrastorage.org/webt/jq/dm/wf/jqdmwffzjjaoaii06fms_o_wc9m.jpeg)
Общий вид Support Ticket System
Подведем итоги.
Плюсы от разработки собственной тикет-системы
- Заточенность хелп-деска под вашу компанию в решении задач, упрощении флоу и отслеживании показателей.
- Углубление знаний о функционировании тикет-системы и о работе команды техподдержки, сидящей через стенку от вас.
- Независимость от обновлений стороннего хелп-деска. Всегда неприятно, когда из-за мешающего изменения приходится перестраивать процессы.
- Безопасность, которую дает отказ от использования сторонних решений в своих проектах.
- Заточенность интерфейса под ваши потребности.
- Быстрое внедрение уникальных фич. Например, ни в одном стороннем хелп-деске до сих пор нет удовлетворительной системы обучения новичков или пространства для команды, которая оценивает качество работы операторов.
- Возможности интеграции. Ваш продукт вырастает до экосистемы, объединяя в себе разные программы в одну цепочку, что оптимизирует работу сотрудников и дает более высокое качество.
- Новое направление работы, развитие сотрудников, бесценный опыт.
- Мотивация для всех причастных. Специалисты поддержки чувствуют, как их «хотелки» реализуются, а команды разработчиков, QA и UX/UI-дизайнеров видят, как их проект растет и какую пользу он приносит операторам.
Минусы
- В начале развития проекта затраты на разработку и поддержку системы превышают стоимость готового решения. Насколько — зависит от объема поступающих сообщений, величины команды поддержки и набора необходимых функций. Однако такой проект окупается. Если 40 операторов отправляют по 50–70 тысяч ответов в месяц, затраты на свою систему и на покупной сервис сравняются через 3–5 лет (в зависимости от стоимости этого сервиса). Если учесть эффект от плюсов собственной тикет-системы, ее гибкости, от функциональных элементов, оптимизирующих работу сотрудников, то окупаемость наступает года за два. После завершения разработки нужно платить только за хостинг, и это меньше, чем за сторонний хелп-деск.
- Придется пройти долгий и трудный путь. Мы несколько раз меняли процесс разработки, ругались и мирились, делали и переделывали. За эти 3,5 года было исправлено больше 1 500 багов.
- Понадобятся структурные изменения. Необходима команда, которая работает на обеспечение внутренних процессов. Нужно разделять тех, кто производит продукт компании, и тех, кто делает back office tools. Привлечь основных разработчиков к созданию такого инструмента вряд ли получится.
Ввязываться в это дело или нет — решать вам. А мы не жалеем, что ввязались. Было страшно. И страшно интересно было тоже.
RationalBot
Как может быть рентабельной «домашняя» разработка достаточно типовой системы для 40 человек?
Передоложим, что команда в среднем была 4 человека, 3,5 года. Только ФОТ минимум 20 млн. Общие расходы на разработку за это время минимум 30 млн.
Jira service desk (для примера) 1,5 млн лицензия + 0,75 млн в год поддержка на 50 пользователей. Workflow кастомизируется, статусов можно хоть 15 сделать. Если чего-то не хватает — можно дополнительные плагины купить или заказать. Для интеграции есть API.
Окупаемость 25-35 лет, а не 3-5. И это при условии, что на поддержку своей системы не будет расходов в будущем. Но я так понимаю, что команда продолжает проедать 10 млн в год.
С моей точки зрения, из 4-х вариантов: покупка готового, кастомизация готового, заказная разработка и собственная разработка выбрали самый затратный и самый рискованный.
Plarium Автор
Здравствуйте. В статье мы объяснили, почему собственное решение для нас лучше, чем готовое. По стоимости и окупаемости у нас другие расчеты.
RationalBot
Вы же свои расчеты не привели…
Если Вы платили за helpdesk по 10 тыс. руб. в месяц на человека, то это сомнительный повод писать свое решение.
Про то, что количество инженеров поддержки удалось сократить в полтора раза, Вы тоже не написали.