В прошлой статье «Как мы выбирали helpdesk-систему» мы рассказали, как рост компании сломал поддержку в чатах и почему популярные helpdesk-решения не подошли под наши процессы.
Мы пошли по пути проектирования собственной helpdesk-системы. Но как мы приняли такое решение? В этой статье мы хотим более детально осветить процесс принятия управленческого решения о создании собственной системы.
Сразу скажем: разработка собственной helpdesk-системы — почти всегда плохая идея. Это дорого, рискованно и редко окупается. В большинстве компаний правильный ответ на вопрос «делать своё или нет» — не делать.
В нашем случае решение оказалось другим. Не потому, что мы захотели «свой продукт», а потому что в конкретный момент времени, с конкретными ограничениями и процессами, альтернативы оказались ещё хуже.
В этой статье мы рассмотрим:
- какие варианты у нас были;
- по каким критериям принимали решение;
- какие риски осознанно приняли;
- и почему этот опыт нельзя механически повторять в другой компании.
Варианты, которые рассматривали
Когда мы подошли к моменту выбора, на столе оказалось несколько путей. Главная задача — закрыть реальные боли поддержки: отсутствие управляемости, аналитики и распределения нагрузки.
Вариант 1: Адаптация существующего helpdesk
Идея: взять готовое решение и подстроить под процессы.
Плюсы:
- нет затрат на разработку,
- можно отказаться от подписки сервиса в любой момент;
- уже есть готовый функционал.
Минусы:
- на тот момент большинство систем не поддерживали, мобильную работу операторов,
- требуется перестройки процессов и обучения сотрудников,
- интерфейс часто перегружен ненужными функциями,
- нет полного контроля над UX.
Вывод: адаптация не решала ключевых проблем с UX и скоростью отклика.
Вариант 2: Кастомизация готового продукта
Идея: купить систему и доработать под себя.
Плюсы:
- можно приблизить к нашим требованиям,
- использовать готовый бекенд.
Минусы:
- дорого,
- зависимость от вендора;
- сложно поддерживать обновления,
- доработка продукта все равно ограничена.
Вывод: риск перерасхода ресурсов и зависимость от вендора оставались высокими.
Вариант 3: Создание собственной системы
Идея: сделать продукт с нуля, с интерфейсом для пользователей и операторов.
Плюсы:
- полный контроль над UX,
- мобильность,
- прозрачная аналитика,
- адаптация под реальные процессы,
- возможность масштабирования и выхода на внешний рынок.
Минусы:
- высокая стоимость,
- высокая ответственность – поддержка и развитие продукта на нашей команде,
- риск инвестиции ресурсов в узкоспециализированный продукт.
Вывод: путь рискованный, но единственный, который позволял закрыть все критические требования и возможностью масштабирования на внешний рынок.
Почти все компании выбрали бы варианты 1 или 2 вариант. Мы пошли по третьему пути только после оценки ограничений всех альтернатив и понимания, что компромиссы неприемлемы.
Как мы принимали решение
Принятие решения — это не импульс, а система критериев, выработанных исходя из процессов и ограничений:
«Сможет ли готовое решение закрыть критические потребности без компромиссов?»
Если ответ был «нет» — тогда рассматривали вариант «своё».
Критические требования:
- Удобство для оператора
Оператор должен создавать, классифицировать и отвечать на обращения с телефона, без лишних шагов и обучения.
- Удобство для пользователя
Пользователь не должен учиться пользоваться сервисом. Интерфейс как в мессенджере, создание тикета в 1–2 шага.
- Мобильность и дежурства
Поддержка работает по сменам, часто вне офиса. Нужно, чтобы обращения не терялись.
- Контроль процессов и аналитика
Нужно видеть реальную статистику и узкие места для непрерывного улучшения клиентского сервиса.
- Стоимость и риски
Разработка = ресурсы, поддержка = время команды, обновления = новые затраты.
Решение делать своё возникло после жёсткой фильтрации альтернатив по этим критериям.
Риски, которые мы осознанно приняли
Любое решение о разработке сопровождается рисками. Мы выделили несколько ключевых:
- Перерасход ресурсов — разработка могла занять больше времени и денег.
Решение: определить рамки MVP, зафиксировать структуру бюджета, составить дорожную карту и выстроить регулярный процесс планирования.
- Поддержка и эксплуатация — все баги и обновления на нашей команде.
Решение: выделить отдельную команду, которая отвечает именно за развитие и стабильность продукта.
- Не взлетит у пользователей — они могут не привыкнуть к системе.
Решение: начать с MVP и тестовой группы, проверить гипотезы, собрать обратную связь. Затем подготовить понятный план внедрения и сопровождения пользователей.
- Потеря фокуса команды — разработка могла отвлечь от основной работы.
Решение: назначить отдельную команду для разработки проекта.
Риски были осознанные, а альтернативы не закрывали критические требования — мобильность, UX и прозрачность.
Почему этот опыт нельзя повторять
- Готовые helpdesk-системы подходят большинству компаний.
- Разработка требует ресурсов и зрелых процессов.
- Без уникальных ограничений она не оправдана.
Итог: этот кейс — не универсальный рецепт, а решение, продиктованное конкретным контекстом.
Что дальше
Следующий шаг: проверка гипотез на MVP и постепенное формирование полноценной системы.
В следующих публикациях разберём:
- как проектировался MVP;
- какие ошибки были допущены;
- какие управленческие эффекты появились после внедрения.