Заявка в Service Desk: как оформить и классифицировать

Кратко

Заявка в service desk оформляется четырьмя обязательными полями: тема или описание проблемы, тип (инцидент или запрос на обслуживание), категория (услуга, к которой относится обращение) и приоритет. Правильная классификация решается не интуицией, а двумя вопросами: «было ли обещано, что так будет работать» (отличает инцидент от запроса) и «сколько пользователей и насколько сильно затронуто» (задаёт приоритет). Ошибка в этих двух пунктах на входе искажает все сроки и отчёты дальше по цепочке.

Актуально на 23 сентября 2026 года.

Что обязательно указать при оформлении

ПолеЗачем нужноКто заполняет
ТемаБыстрый поиск и сортировка в списке заявокОбратившийся
ОписаниеДостаточно данных, чтобы начать работу без уточняющего вопросаОбратившийся
ТипИнцидент или запрос на обслуживание — задаёт логику обработкиОбратившийся или служба при приёме
Категория (услуга)К какой услуге или направлению относится заявкаОбратившийся из готового списка или служба
ПриоритетПорядок и срок обработкиСлужба, по правилу, а не по просьбе

Практика, которая экономит половину уточняющих вопросов: в описании сразу просить то, что понадобится для конкретной категории — для проблем со входом это логин и время последней успешной попытки, для вопроса по оплате — номер счёта. Общая форма «опишите проблему» без подсказок по категории собирает поток обращений, на две трети состоящий из «не работает», без единой детали. Список самих категорий стоит строить не с нуля — см. виды обращений клиентов: как классифицировать.

Инцидент или запрос: как отличить за секунды

Путаница этих двух типов — самая частая причина, по которой очередь работает плохо: срочный инцидент лежит вперемешку с плановым запросом, и непонятно, что делать раньше.

ОбращениеТипПочему
«Принтер на третьем этаже печатает с полосами третий день»ИнцидентРаньше печатал чисто, теперь с браком
«Откройте доступ к папке отдела новому сотруднику»ЗапросНичего не ломалось, просят открыть доступ
«Письма клиентам уходят в спам со вчерашнего дня»ИнцидентРаньше доходили, теперь нет
«Нужен второй монитор на рабочее место»ЗапросПлановая просьба, ничего не переставало работать
«Как выгрузить отчёт по расходам за прошлый месяц»ЗапросКонсультация, а не поломка

Правило одной фразой: было обещано и перестало работать — инцидент; не было обещано и человек просит, чтобы стало, — запрос. У инцидента цель — восстановить работу как можно быстрее, у запроса — выполнить правильно, спешка здесь скорее вредна. Смешение типов в одной очереди без пометки обычно даёт один и тот же результат: запросы обрабатываются как горящие, а настоящие инциденты теряются в общем потоке. Разбор граничных случаев (например, «никогда не работало») и того, что из этого деления меняется в настройке системы, — в статье Инцидент или запрос на обслуживание: в чём разница.

Как назначить приоритет: пример расчёта

Приоритет строится на пересечении влияния (скольких и насколько затронуло) и срочности (когда станет поздно), а не на слове «важно» от обратившегося.

Пример: служба получает 150 заявок в месяц, из них по факту распределение получилось таким:

ПриоритетПризнак влиянияЗаявок в месяцДоляСрок первого ответа
КритичныйСервис недоступен всем, нет обходного пути85,3%15 минут
ОбычныйЧасть функций или часть пользователей9764,7%1 час
НизкийОдин пользователь, работа продолжается4530%4 часа

Если критичных набирается больше 10–15% потока, приоритет назначают слишком щедро — и это видно сразу по отчёту, без дополнительного расследования. Пятая колонка в таблице — самопроверка: рабочий диапазон для критичного приоритета обычно не превышает 5–10% всего потока.

Как проверить классификацию за 20 минут

  • Возьмите 30 последних заявок и проверьте тип заново вручную, отдельно от того, что стоит в системе. Расхождение выше 10–15% — сигнал, что правило деления не объяснено команде или объяснено словами, а не примерами.
  • Посчитайте долю заявок с приоритетом «критичный». Если она заметно выше 10% потока — приоритет обесценился.
  • Проверьте, есть ли у заявок с типом «запрос» согласование, если оно требуется по регламенту, — запрос без обязательного согласования на выходе снимает часть смысла процесса.
  • Найдите три заявки с описанием короче одного предложения: по ним обычно виден пробел в форме — не хватает подсказки для конкретной категории.

Частые ошибки

  • Тип выбирает обратившийся без проверки службой. Человек не знает вашей классификации и выбирает по интуиции — половина инцидентов оказывается заведена как запросы и лежит без срочности.
  • Приоритет назначают по просьбе клиента. Через месяц почти всё в очереди становится «срочным», и приоритет перестаёт на что-либо влиять.
  • Общая форма без подсказок по категории. Собирает описания без деталей, необходимых для конкретной темы, и превращает первый ответ в уточняющий вопрос вместо решения.
  • Согласование требуют и для инцидентов. Инцидент чинят, а не согласовывают — требование одобрения перед восстановлением работы дорого стоит в минутах простоя.

Частые вопросы

Чем заявка в service desk отличается от обычного тикета в helpdesk?

Формально это то же обращение, обработанное системой учёта заявок. Термин «service desk» чаще указывает на более широкий охват: помимо инцидентов система работает и с запросами на обслуживание, доступами и изменениями, а не только с поломками. Подробнее — в статье Что такое helpdesk-система и как она работает.

Как классифицировать заявку, если непонятно, инцидент это или запрос?

По безопасному умолчанию: если сомневаетесь, считайте инцидентом. Ошибиться в эту сторону дешевле — запрос, полежавший как инцидент, никому не вредит, а инцидент, полежавший как запрос, оставляет человека без работающей функции без должной срочности.

Кто должен назначать приоритет заявки — клиент или служба?

Категорию или тему обычно выбирает обратившийся — он знает свою ситуацию. Приоритет назначает служба по правилу (влияние и срочность), потому что только она видит картину по всем заявкам сразу и может сравнить одно обращение с другими.

Что делать, если заявок с приоритетом «критичный» становится слишком много?

Проверить признаки, по которым он назначается: они должны требовать полной недоступности сервиса для всех пользователей и отсутствия обходного пути, а не общего ощущения срочности. Размытые формулировки вроде «серьёзное влияние на бизнес» стоит заменить проверяемыми фактами.

Как это устроено в TehProf.kz Support

Заявка получает поля «Услуга» и «Приоритет» (Низкий / Обычный / Высокий / Срочный) уже на форме создания — как в клиентском портале, так и при заведении оператором из админ-панели; приоритет клиента можно ограничить в настройках, чтобы решение оставалось за службой. Список заявок и канбан-доска фильтруются по обоим полям одновременно, а бейдж в навигации сразу показывает число заявок в статусе «Новая», ожидающих первичной обработки и классификации. Если включён режим, при котором AI Ассистент разбирает входящее сообщение, он может сам подобрать тему, категорию и срочность заявки на основании текста обращения — этот способ доступен на тарифах Business и выше, на остальных тарифах заявка создаётся без автоматической классификации.

Связанные статьи

Нужна поддержка, которая так и работает?

TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.