Time Tracking в поддержке: учёт времени, биллинг и анализ загрузки

Зачем учитывать время

Время — самый дорогой ресурс в техподдержке. Час оператора стоит 500-2000 ₽ (зависит от уровня и региона). Без учёта времени:

• MSP не может выставлять корректные счета клиентам (or теряет деньги, или раздражает завышенными счетами);
• Руководитель не видит куда уходит рабочий день — кажется «все заняты», но что именно делают?
• Невозможно обосновать расширение штата (нет данных «у нас 20 операторов отрабатывают 4500 часов в месяц на 6000 заявок»);
• Сложно понять реальную стоимость обслуживания каждого клиента/типа заявок.

Сценарий MSP: биллинг по часам

Managed Service Provider обслуживает 10-50 клиентов на договорной основе. Типовые модели:

• Pre-paid hours — клиент покупает 20 часов поддержки в месяц, остатки переходят на след. месяц;
• Pay-as-you-go — выставляется по факту (например, 2000 ₽/час);
• Tiered — базовый тариф (10ч) + надбавка за каждый сверхлимитный час;
• Retainer + project hours — фиксированная плата + отдельные часы на крупные изменения.

В каждой модели нужен точный учёт минут по каждой заявке с привязкой к клиенту. ServiceDesk должен:

• Иметь Play/Stop таймер на заявке;
• Хранить time-entries с минутами, заметкой, исполнителем;
• Группировать по клиенту/договору;
• Экспортировать в Excel/PDF для счетов.

Без таких возможностей MSP вручную ведёт Excel — это 5-10% рабочего времени биллинг-менеджера и постоянные споры с клиентами «вы посчитали неверно».

Внутренняя поддержка: анализ нагрузки

Для in-house ИТ-отдела биллинг не нужен — но Time Tracking всё равно полезен:

• Реальная нагрузка в часах vs формальное «20 заявок в день» (одна заявка может занять 5 минут, другая — 5 часов);
• Самые дорогие категории — где уходит больше всего времени? Может стоит автоматизировать?
• Стоимость поддержки конкретного клиента/отдела — кросс-чарджинг внутри компании;
• Аналитика для бюджета — обосновать почему ИТ-отделу нужен ещё один оператор.

Ручной vs автоматический учёт

Ручной (Play/Stop кнопка)

Оператор открывает заявку, жмёт «Старт», работает, жмёт «Стоп» → сохраняется time-entry. Плюсы: точность, оператор сам контролирует. Минусы: забывают остановить, время инфлирует.

Решение от «забыл остановить»: sticky-banner «Таймер запущен на тикете #42 — 0:23:45» виден на всех страницах системы. Оператор уйдёт на другую заявку — увидит таймер, остановит. В TIQQET этот баннер реализован.

Автоматический (через webvisor-подобный мониторинг)

Система автоматически фиксирует «оператор открыл тикет на N минут». Плюсы: без действий оператора. Минусы: оператор может держать вкладку открытой и пить чай — учитывается как работа. Не подходит для биллинга.

Ручной с подтверждением

В конце дня оператор видит «сегодня вы открывали 25 тикетов, на 8 включали таймер, на 17 — нет. Заполните оставшиеся?» — выскакивает форма быстрого ввода минут на каждый. Компромисс между точностью и удобством.

Подводные камни

• Сопротивление команды — операторы видят в трекере «как меня контролируют». Снимается прозрачным объяснением «для оценки нагрузки и обоснования штата», а не «для урезания зарплаты».
• Двойной учёт — оператор работает над двумя заявками параллельно (отвечает в одной пока ждёт ответа в другой). Что делать? Либо разрешить одновременно несколько таймеров, либо учитывать только основной. Чёткое правило важнее «идеальной» точности.
• Микро-таймеры — оператор открыл заявку на 30 секунд (просто посмотреть), система записала «1 минуту». Накопительно это даёт +20-30% к реальному времени.
• Голосовые звонки — типичный недоучёт. Оператор позвонил клиенту, разговор 15 мин, в системе — ни одной записи. Решение: ручная запись после звонка или интеграция с телефонией.
• Юр. аспекты — для MSP важно чтобы клиент видел time-entries в детализации счёта. Без этого споры неизбежны.

В TIQQET Time Tracking реализован как ручной таймер с заметкой + sticky-banner от забывания + интеграция с биллинг-экспортом.