Всем привет!
Мы 1GT.IT – ИТ-подразделениe One Company, отвечающего за поддержку инфраструктуры партнёрских компаний.
В этой статье мы расскажем, как мы столкнулись с ростом внутренней поддержки и почему ни одна готовая helpdesk-система не решила наши задачи:
- Что начало тормозить поддержку по мере роста компании.
- Почему helpdesk-системы не помогли решить наши проблемы.
- И к каким выводам мы пришли.
Если вы управляете сервисной командой в ИТ и проходите этап масштабирования, этот опыт может быть вам знаком или полезен.
Как всё начиналось: поддержка в чатах
На старте у нас было менее 30 пользователей – сотрудники из партнерских компаний.
Для внутренней поддержки мы создали отдельные групповые чаты в мессенджерах – по одному на каждую компанию. Пользователи писали туда напрямую, и этого хватало.
В то время такое решение было рабочим: чатов и участников было немного, обращения не терялись.
Момент, когда чаты перестали справляться
Рост компании — это всегда проверка на прочность. Простые решения, которые идеально работали при 30 пользователях, начали давать сбой при 300+.
Боль №1. Потеря управляемости
Команда постоянно обновлялась: одни приходили, другие уходили. Но ушедшие оставались в чатах – и никто не успевал их оттуда удалять.
При этом обращения приходили в разное время и в самых разных форматах: то скриншот, то голосовое, то просто «не работает».
Найти конкретный запрос или понять, обработан он или нет, становилось всё труднее.
Боль №2: Массовые инциденты терялись в переписке
При массовых сбоях мы публиковали объявления в чатах, но они исчезали под потоком новых сообщений.
Пользователи продолжали писать по одной и той же проблеме, а поддержка отвечала точечно, не видя общей картины.
Боль №3: Жалобы без фактов
Количество жалоб на поддержку росло. При этом сама поддержка утверждала, что все отрабатывает.
Проверить как все было на самом деле было невозможно: не было ни логов, ни истории переписки, ни метрик.
Боль №4. Отсутствие аналитики
Мы не могли ответить даже на базовые вопросы:
- сколько обращений приходит;
- по каким темам;
- какая средняя скорость реакции;
- где возникают узкие места.
Боль №5. Обращения в личку
В чатах были видны личные номера сотрудников. Клиенты писали напрямую — в том числе в выходные.
При смене дежурств это приводило к типовой ситуации: обращение попадало «не туда», и казалось, что поддержка игнорирует запрос.
Мы пробовали вводить правила, использовать корпоративные каналы, вручную помечать обработанные обращения, но это лишь добавляло рутины и не решало главной проблемы:
чаты не масштабируются.
Пора было искать систему.
Поиск helpdesk-системы: три итерации разочарования
В начале поиска у нас не было подробного технического задания. Было только общее понимание:
система поддержки должна быть удобной в ежедневной работе не только для клиентов, но и для операторов.
Это понимание основывалось на нашем внутреннем девизе: «Всегда довольный клиент».
Итерация 1. Бесплатные решения
Мы начали с бесплатных систем и остановились на OTRS.
Уже на этапе тестирования выяснилось:
- для создания тикета пользователю нужно заполнять форму – это неудобно для клиентов;
- работа с мобильных устройств оказалась неудобной, особенно для операторов.
Так появились первые требования к системе:
- Обращение создается по одному сообщению, без форм.
- Оператор может полноценно работать с телефона.
Итерация 2. Поиск на рынке
Мы продолжили изучать рынок helpdesk-решений, но на этом этапе даже не дошли до тестирования — просто не нашли подходящих вариантов просто по нашим критериям.
Часть систем требовала серьёзной перестройки процессов, часть была перегружена функциональностью, не нужной в ежедневной работе поддержки.
Итерация 3. Последняя попытка
Мы дошли до презентации одного из сервисов. В рамках демонстрации мобильное приложение работало нестабильно, поэтому на тот момент мы решили не запускать пилот.
Важно отметить, что это было решение, принятое в конкретных условиях и временных рамках, исходя из наших требований к мобильной работе и скорости внедрения.
Главное открытие: проблема не в инструментах
Во всех рассмотренных решениях повторялась одна и та же картина:
Необходимо было подстраивать процесс под инструмент
Мы же хотели, чтобы переход из чатов в систему был максимально безболезненным и формат оставлся такими же привычным.
Мы поняли:
- Либо мы подстраиваем процессы под инструмент — и теряем клиентский опыт.
- Либо создаём инструмент под свои процессы — и сохраняем скорость и простоту работы.
Выбрали второе. Так мы начали разработку собственной helpdesk-системы.
Что мы поняли в процессе
Несколько выводов, которые могут быть полезны другим компаниям:
- структура в поддержке нужна даже на раннем этапе;
- требования важно формулировать до выбора системы;
- удобство оператора критично — неудобным инструментом просто не будут пользоваться.
Что было дальше
В итоге мы пошли по пути проектирования собственной helpdesk-системы, которой мы сейчас и пользуемся:
- с интерфейсом как у мессенджера без заполнения форм;
- с аналитикой и прозрачной историей обращений.
В следующих статьях мы планируем рассказать: как мы проектировали систему, какие ошибки допустили и какие результаты получили после внедрения.
Если у вас был похожий опыт, поделитесь с какими ограничениями helpdesk-систем вы сталкивались?