Учёт заявок в IT-отделе — это порядок, при котором каждое обращение сотрудника регистрируется в одной системе, получает номер, исполнителя, статус и срок. Пока заявки живут в почте, мессенджерах и коридорных разговорах, невозможно ни гарантировать выполнение, ни показать реальную нагрузку отдела.
Признаки, что почты и чата уже мало
- сотрудник спрашивает «что с моей заявкой?», и никто не может ответить сразу;
- одну проблему чинят двое, а другую — никто;
- при отпуске администратора его переписка недоступна коллегам;
- руководитель просит обосновать найм, а данных о загрузке нет;
- повторяющиеся проблемы каждый раз решаются заново.
Если узнаёте два-три пункта, пора вводить единую очередь.
Что должно быть в заявке
Минимальный набор полей, без которого учёт не работает:
| Поле | Зачем |
|---|---|
| Номер | Однозначная ссылка в разговоре и переписке |
| Заявитель | Кому отвечать и чьё это рабочее место |
| Тема и описание | Что случилось, своими словами |
| Категория | Маршрутизация и статистика по типам проблем |
| Приоритет | Порядок выполнения и сроки |
| Исполнитель | Персональная ответственность |
| Статус | Понятное состояние в любой момент |
| История | Комментарии, вложения, изменения |
Статусы: чем меньше, тем лучше
Для начала хватит пяти: «Новая», «В работе», «Ожидание», «Решена», «Закрыта». Каждый лишний статус — это правило, которое кто-то должен помнить. Важно договориться, что означает «Решена»: исполнитель считает задачу выполненной, а сотрудник может подтвердить или вернуть заявку.
Список и доска
Одни и те же заявки удобно смотреть по-разному. Список с фильтрами подходит для разбора очереди: новые, просроченные, без исполнителя. Канбан-доска показывает поток: сколько обращений на каждом этапе и где они скапливаются.
План перехода
Неделя 1. Подготовка. Составьте список категорий по реальным обращениям за последний месяц — обычно хватает 8–12. Определите исполнителей и того, кто распределяет новые заявки.
Неделя 2. Пилот. Подключите один отдел или этаж. Проверьте, что сотрудники находят форму и получают уведомления, а инженеры ведут переписку в заявке, а не в личных сообщениях.
Недели 3–4. Запуск. Объявите дату, после которой обращения принимаются только через систему. Оставьте привычный канал как вход: письмо на адрес поддержки или сообщение боту должно превращаться в заявку автоматически. Как подключить мессенджер, описано на странице Service Desk с Telegram-ботом.
Через месяц. Разбор. Посмотрите статистику: какие категории самые частые, где заявки ждут дольше всего. Это основа для базы знаний и для первых сроков SLA.
Что делать с заявками «мимо системы»
Просьбы в коридоре и личные сообщения не исчезнут в первый день. Рабочее правило: инженер сам регистрирует такое обращение от имени сотрудника и отвечает уже в заявке. Через две-три недели сотрудники привыкают, что так быстрее. Запрещать и отказывать — хуже: люди начинают обходить систему.
Типовые ошибки
- Слишком подробная форма. Десять обязательных полей — и сотрудник возвращается в чат.
- Нет ответственного за очередь. Новые заявки висят, пока кто-нибудь не возьмёт.
- Учёт ради учёта. Если отчёты никто не смотрит, дисциплина быстро падает.
- Переписка вне заявки. Решение остаётся в личных сообщениях и не попадает в историю.
Что дальше
Когда обращения стабильно регистрируются, появляется основа для следующих шагов: сроков реакции и решения, базы знаний по частым вопросам и связи заявок с оборудованием. Как очередь, фильтры и карточка заявки устроены в продукте, показано на странице учёт IT-заявок в SC Desk, а общий обзор — на странице SC Desk.
Нужна система для IT-поддержки?
Посмотрите SC Desk: заявки, SLA, база знаний и IT-активы. Сравните возможности и обсудите внедрение.