Заявка в Service Desk: как оформить и классифицировать
Кратко
Заявка в service desk оформляется четырьмя обязательными полями: тема или описание проблемы, тип (инцидент или запрос на обслуживание), категория (услуга, к которой относится обращение) и приоритет. Правильная классификация решается не интуицией, а двумя вопросами: «было ли обещано, что так будет работать» (отличает инцидент от запроса) и «сколько пользователей и насколько сильно затронуто» (задаёт приоритет). Ошибка в этих двух пунктах на входе искажает все сроки и отчёты дальше по цепочке.
Актуально на 23 сентября 2026 года.
Что обязательно указать при оформлении
| Поле | Зачем нужно | Кто заполняет |
|---|---|---|
| Тема | Быстрый поиск и сортировка в списке заявок | Обратившийся |
| Описание | Достаточно данных, чтобы начать работу без уточняющего вопроса | Обратившийся |
| Тип | Инцидент или запрос на обслуживание — задаёт логику обработки | Обратившийся или служба при приёме |
| Категория (услуга) | К какой услуге или направлению относится заявка | Обратившийся из готового списка или служба |
| Приоритет | Порядок и срок обработки | Служба, по правилу, а не по просьбе |
Практика, которая экономит половину уточняющих вопросов: в описании сразу просить то, что понадобится для конкретной категории — для проблем со входом это логин и время последней успешной попытки, для вопроса по оплате — номер счёта. Общая форма «опишите проблему» без подсказок по категории собирает поток обращений, на две трети состоящий из «не работает», без единой детали. Список самих категорий стоит строить не с нуля — см. виды обращений клиентов: как классифицировать.
Инцидент или запрос: как отличить за секунды
Путаница этих двух типов — самая частая причина, по которой очередь работает плохо: срочный инцидент лежит вперемешку с плановым запросом, и непонятно, что делать раньше.
| Обращение | Тип | Почему |
|---|---|---|
| «Принтер на третьем этаже печатает с полосами третий день» | Инцидент | Раньше печатал чисто, теперь с браком |
| «Откройте доступ к папке отдела новому сотруднику» | Запрос | Ничего не ломалось, просят открыть доступ |
| «Письма клиентам уходят в спам со вчерашнего дня» | Инцидент | Раньше доходили, теперь нет |
| «Нужен второй монитор на рабочее место» | Запрос | Плановая просьба, ничего не переставало работать |
| «Как выгрузить отчёт по расходам за прошлый месяц» | Запрос | Консультация, а не поломка |
Правило одной фразой: было обещано и перестало работать — инцидент; не было обещано и человек просит, чтобы стало, — запрос. У инцидента цель — восстановить работу как можно быстрее, у запроса — выполнить правильно, спешка здесь скорее вредна. Смешение типов в одной очереди без пометки обычно даёт один и тот же результат: запросы обрабатываются как горящие, а настоящие инциденты теряются в общем потоке. Разбор граничных случаев (например, «никогда не работало») и того, что из этого деления меняется в настройке системы, — в статье Инцидент или запрос на обслуживание: в чём разница.
Как назначить приоритет: пример расчёта
Приоритет строится на пересечении влияния (скольких и насколько затронуло) и срочности (когда станет поздно), а не на слове «важно» от обратившегося.
Пример: служба получает 150 заявок в месяц, из них по факту распределение получилось таким:
| Приоритет | Признак влияния | Заявок в месяц | Доля | Срок первого ответа |
|---|---|---|---|---|
| Критичный | Сервис недоступен всем, нет обходного пути | 8 | 5,3% | 15 минут |
| Обычный | Часть функций или часть пользователей | 97 | 64,7% | 1 час |
| Низкий | Один пользователь, работа продолжается | 45 | 30% | 4 часа |
Если критичных набирается больше 10–15% потока, приоритет назначают слишком щедро — и это видно сразу по отчёту, без дополнительного расследования. Пятая колонка в таблице — самопроверка: рабочий диапазон для критичного приоритета обычно не превышает 5–10% всего потока.
Как проверить классификацию за 20 минут
- Возьмите 30 последних заявок и проверьте тип заново вручную, отдельно от того, что стоит в системе. Расхождение выше 10–15% — сигнал, что правило деления не объяснено команде или объяснено словами, а не примерами.
- Посчитайте долю заявок с приоритетом «критичный». Если она заметно выше 10% потока — приоритет обесценился.
- Проверьте, есть ли у заявок с типом «запрос» согласование, если оно требуется по регламенту, — запрос без обязательного согласования на выходе снимает часть смысла процесса.
- Найдите три заявки с описанием короче одного предложения: по ним обычно виден пробел в форме — не хватает подсказки для конкретной категории.
Частые ошибки
- Тип выбирает обратившийся без проверки службой. Человек не знает вашей классификации и выбирает по интуиции — половина инцидентов оказывается заведена как запросы и лежит без срочности.
- Приоритет назначают по просьбе клиента. Через месяц почти всё в очереди становится «срочным», и приоритет перестаёт на что-либо влиять.
- Общая форма без подсказок по категории. Собирает описания без деталей, необходимых для конкретной темы, и превращает первый ответ в уточняющий вопрос вместо решения.
- Согласование требуют и для инцидентов. Инцидент чинят, а не согласовывают — требование одобрения перед восстановлением работы дорого стоит в минутах простоя.
Частые вопросы
Чем заявка в service desk отличается от обычного тикета в helpdesk?
Формально это то же обращение, обработанное системой учёта заявок. Термин «service desk» чаще указывает на более широкий охват: помимо инцидентов система работает и с запросами на обслуживание, доступами и изменениями, а не только с поломками. Подробнее — в статье Что такое helpdesk-система и как она работает.
Как классифицировать заявку, если непонятно, инцидент это или запрос?
По безопасному умолчанию: если сомневаетесь, считайте инцидентом. Ошибиться в эту сторону дешевле — запрос, полежавший как инцидент, никому не вредит, а инцидент, полежавший как запрос, оставляет человека без работающей функции без должной срочности.
Кто должен назначать приоритет заявки — клиент или служба?
Категорию или тему обычно выбирает обратившийся — он знает свою ситуацию. Приоритет назначает служба по правилу (влияние и срочность), потому что только она видит картину по всем заявкам сразу и может сравнить одно обращение с другими.
Что делать, если заявок с приоритетом «критичный» становится слишком много?
Проверить признаки, по которым он назначается: они должны требовать полной недоступности сервиса для всех пользователей и отсутствия обходного пути, а не общего ощущения срочности. Размытые формулировки вроде «серьёзное влияние на бизнес» стоит заменить проверяемыми фактами.
Как это устроено в TehProf.kz Support
Заявка получает поля «Услуга» и «Приоритет» (Низкий / Обычный / Высокий / Срочный) уже на форме создания — как в клиентском портале, так и при заведении оператором из админ-панели; приоритет клиента можно ограничить в настройках, чтобы решение оставалось за службой. Список заявок и канбан-доска фильтруются по обоим полям одновременно, а бейдж в навигации сразу показывает число заявок в статусе «Новая», ожидающих первичной обработки и классификации. Если включён режим, при котором AI Ассистент разбирает входящее сообщение, он может сам подобрать тему, категорию и срочность заявки на основании текста обращения — этот способ доступен на тарифах Business и выше, на остальных тарифах заявка создаётся без автоматической классификации.
Связанные статьи
- Что такое helpdesk-система и как она работает
- Инцидент или запрос на обслуживание: в чём разница
- Как выбрать программу для техподдержки: 10 критериев
- Что такое service desk и чем он отличается от helpdesk
- Программы service desk: как выбрать
- Программы для системы заявок: как выбрать
Нужна поддержка, которая так и работает?
TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.