Система учёта заявок: что это, зачем нужна и как внедрить без ошибок
1 апреля 2026
обновлено: 2 апреля 2026
Понедельник, 9:00. Руководитель техподдержки открывает рабочую почту — и видит 23 новых письма. Не работает принтер на третьем этаже, сотрудник забыл пароль от CRM, новому человеку нужен доступ к корпоративному порталу. В мессенджере ещё 15 сообщений с похожими проблемами. Часть обращений дублируется в разных каналах, часть уже потерялась в переписке. На вопрос «Когда решите?» приходится отвечать наугад.
Чтобы такие ситуации не превращались в норму, существует Service Desk — система, которая превращает беспорядочный поток обращений в управляемый и прозрачный процесс.
SimpleOne провела исследование, опросив более 280 ИТ-директоров и руководителей службы поддержки в 2025 году, и на основании результатов смогла создать фактуру для этого материала
Что такое Service Desk и зачем нужна программа учета заявок
Service Desk — это программа для централизованного приема, обработки, маршрутизации и контроля заявок. Единое окно, через которое проходят все обращения сотрудников и клиентов: от «сломался принтер» до «нужно подключить нового контрагента к ERP».
Концепция Service Desk оформилась в ИТ-сфере в конце 1980-х, когда компании начали выделять специализированные службы технической поддержки. С появлением методологии ITIL (IT Infrastructure Library) подход эволюционировал из «горячей линии» в комплексную систему управления ИТ-услугами.
Сегодня Service Desk давно вышел за границы ИТ-отдела. В HR его применяют для обработки запросов сотрудников, в бухгалтерии — для внутренних финансовых заявок, в АХО — для хозяйственных вопросов. По данным SimpleOne, 95% компаний, которые ищут систему управления заявками, называют управление тикетами обязательной функцией, 85% — SLA из коробки, 80% — портал самообслуживания.
Современный Service Desk — это не отдельный хелпдеск, а часть ESM-экосистемы (Enterprise Service Management). Она объединяет ITSM, HR-сервисы, АХО и другие подразделения в единую систему обработки обращений.
Виды обращений: какие заявки обрабатывает Service Desk
Современная система обработки заявок работает с несколькими категориями обращений. Понять их различия важно ещё до внедрения — это позволяет правильно настроить маршрутизацию и SLA.
| Тип обращения | Описание | Примеры |
|---|---|---|
| Инцидент | Сбой или нарушение работы сервиса, который мешает работать прямо сейчас | Не работает VPN, не загружается почта, сломался принтер |
| Запрос на обслуживание | Стандартная типовая заявка — организация доступа к услугам или рабочему месту | Предоставление доступа к системе, выдача оборудования, установка ПО |
| Изменение | Плановая модификация ИТ-инфраструктуры или бизнес-процесса | Обновление ПО, миграция сервера, изменение прав доступа |
| Проблема | Корневая причина повторяющихся инцидентов | Ежемесячные сбои одного и того же принтера в филиале |
| Пользовательский вопрос | Справочное обращение, не требующее технического вмешательства | Как подключить Wi-Fi, как настроить подпись в почте |
Разграничение типов заявок решает сразу несколько задач. Инцидент и изменение обрабатываются по разным регламентам: первый требует немедленной реакции, второй — предварительного согласования. Без чёткой классификации специалисты тратят время на выяснение, что именно нужно сделать, вместо того чтобы делать это.
Помимо типа, заявки делятся по приоритету и источнику. По источнику обращения поступают из ИТ-отдела, HR, АХО, бухгалтерии, юридического отдела. По приоритету — от критичных (время решения 1–2 часа) до низких (5–7 дней). Правильно настроенная система учёта заявок присваивает приоритет автоматически — на основе правил и ключевых слов.
Типичные проблемы при ручном управлении заявками
По данным анализа запросов от компаний, ищущих систему управления заявками, 40% называют главной болью недостаток автоматизации, 34% — слабую отчётность и аналитику, 25% — отсутствие омниканальности. Ниже — конкретные сценарии, которые стоят за этими цифрами.
1. Заявки теряются в переписке
Обращение приходит в личный чат специалиста, который ушёл в отпуск. Или тонет в общем потоке писем. Пользователь ждёт ответа, специалист не знает о заявке, руководитель не видит проблемы — до тех пор, пока ситуация не обострится.
2. Нет приоритизации
Все обращения обрабатываются в порядке поступления или по принципу «кто громче попросил». Действительно срочные задачи решаются последними. Специалисты тратят время на несрочные запросы — и нарушают договорённости по SLA там, где это критично.
3. Дублирование работы
Пользователь не знает, дошла ли заявка, и отправляет её повторно: по почте, в мессенджере, по телефону. Несколько специалистов параллельно разбираются в одной проблеме, не зная друг о друге. Рабочее время уходит на координацию, а не на решение.
4. Руководитель не видит полную картину
Сколько заявок в работе? Какие на грани срыва? Кто перегружен? Ответить на эти вопросы можно только собрав данные вручную — и к моменту, когда цифры готовы, они уже устарели.
5. История теряется
Информация о прошлых обращениях хранится в личной переписке или не хранится вообще. Одни и те же проблемы решаются заново, корневые причины повторяющихся инцидентов не выявляются.
6. Масштабирование невозможно
При росте компании до 100–300 сотрудников ручная система обработки заявок перестаёт справляться. Скорость реакции падает, недовольство персонала растёт, контроль над процессами теряется — и нанять ещё одного специалиста уже не помогает.
Преимущества автоматизации через Service Desk
Рассмотрим, как правильно настроенная система учёта заявок меняет работу с обращениями — по каждому из болезненных сценариев выше.
1. Ничего не теряется
Все заявки автоматически регистрируются в системе независимо от канала поступления — почта, портал, мессенджер, телефония. Каждому обращению присваивается уникальный номер. Вся история переписки и действий хранится в одном месте. Процент потерянных обращений снижается с 15–20% до нуля.
2. Автоматическая маршрутизация и приоритизация
Система автоматически определяет тип заявки, категорию и приоритет — на основе правил и ключевых слов — и назначает ответственного исполнителя по компетенциям и текущей загрузке. В зрелых решениях можно создать тысячи правил автоназначения, импортировать их или настроить через скрипты на JavaScript. Параллельно встроенный контроль SLA автоматически отслеживает сроки, подсвечивает заявки, которые приближаются к дедлайну, и запускает эскалацию. Соблюдение SLA в среднем улучшается с 65–70% до 90–95%.
3. Портал самообслуживания
Пользователи находят ответы на типовые вопросы самостоятельно — через каталог услуг, базу знаний и FAQ. Количество обращений по стандартным вопросам снижается на 25–30%. ИИ-помощник на портале дополнительно классифицирует запрос и при необходимости автоматически создаёт заявку нужной категории — это нулевая линия поддержки, которая работает без участия специалиста.
4. Прозрачность и аналитика
Руководитель в реальном времени видит загрузку каждого специалиста, статус каждой заявки, которые приближаются к дедлайну. Аналитика показывает закономерности: если за неделю десять сотрудников пожаловались на медленную работу одной системы — это сигнал для ИТ-отдела разобраться с причиной, а не просто отвечать на каждый тикет по отдельности.
5. Экономия времени
Автоматизация регистрации, маршрутизации, уведомлений и отчётности позволяет специалистам тратить до 40% меньше времени на рутину — и больше на решение сложных задач.
6. Омниканальность
Заявки из почты, портала, мессенджеров и телефонии попадают в единую систему и обрабатываются по общим правилам. Пользователю не нужно думать, в какой канал писать — он получит ответ в любом случае.
SimpleOne ITSM — система учёта заявок для ИТ и всего бизнеса
SimpleOne ITSM — российская платформа для автоматизации работы с заявками, построенная на принципах ITIL 4 и адаптированная под специфику российского бизнеса.
В основе — гибкая платформа с No-Code, Low-Code и Pro-code-инструментами: типовые процессы настраиваются без программистов, сложные сценарии дорабатываются через JavaScript. Это означает, что компания не зависит от вендора при изменении процессов.
Для ИТ-отдела SimpleOne ITSM закрывает полный цикл: приём и обработка заявок, управление SLA, CMDB, база знаний, портал самообслуживания, управление изменениями. Всё необходимое для зрелой ИТ-поддержки — в одном продукте, без покупки отдельных модулей.
При этом платформа не ограничивается ИТ. Когда процессы в ИТ-отделе выстроены, к той же системе подключаются HR, АХО, бухгалтерия, юридический отдел — и начинают работать по тем же принципам: единый каталог услуг, SLA, маршрутизация и аналитика. Компания получает одну платформу для всех внутренних сервисов вместо набора разрозненных инструментов.
Ключевые возможности
1. Многоканальный приём обращений
Пользователи создают заявки через электронную почту, веб-портал самообслуживания, мобильное приложение, мессенджеры (Telegram), телефонию и чат-бота. Все обращения попадают в единую систему и обрабатываются по общим правилам.
2. Управление SLA
Встроенный механизм контроля соглашений об уровне обслуживания реализован на уровне LCAP-платформы как отдельный микросервис: индикаторы считаются с высокой скоростью и работают для ITSM, HR, АХО и других приложений одновременно. Поддерживается ретроспективный пересчёт при изменении приоритетов и визуальная индикация оставшегося рабочего времени.
3. Портал самообслуживания включён в лицензию и не требует отдельной оплаты
В отличие от ряда рыночных решений, где портал лицензируется дополнительно. На портале работает ИИ-ассистент: нейросеть ищет ответ в базе знаний и известных ошибках, классифицирует запрос и при необходимости автоматически создаёт заявку нужной категории.
4. Гибкая настройка процессов без программирования
Жизненный цикл заявки, правила эскалации и уведомлений, обязательные поля, согласования, автоматические действия при смене статуса можно настроить через No-/Low-code. При необходимости — глубокая кастомизация через JavaScript.
5. Управление конфигурациями (CMDB)
Единая база оборудования, программного обеспечения, лицензий, сетевых устройств, связей между элементами и истории изменений.
6. Интеграции
Active Directory / LDAP, почтовые системы (Exchange, Gmail, Яндекс Почта), телефония, Telegram, системы мониторинга (Zabbix, Nagios), 1С, SAP, REST API для подключения любых других систем.
Кейс: ГК Альфа-Лизинг
До внедрения платформы четыре подразделения компании работали через систему управления задачами, остальные — через звонки, почту и устные договорённости. После перехода на единую ESM-платформу:
- 9 служб (от бухгалтерии до информационной безопасности) подключены к единой системе;
- на 40–50% сократилось время на управление рутинными задачами;
- 90% запросов поступает через единый канал;
- 7 месяцев — окупаемость внедрения (вместо 5 лет по первоначальному плану);
- более 90% сотрудников удовлетворены качеством внутренних услуг.
«Без наличия системы создания ценности нельзя говорить о высоком уровне зрелости процессов ИТ — они должны опережать внутренние процессы, чтобы компания шла вперед к цифровой трансформации»Артём Косолапов ИТ-директор ГК Альфа-Лизинг.
Как выбрать Service Desk программу для заявок
Выбор системы учёта заявок — решение, которое повлияет на работу компании на годы вперёд. Ниже — чек-лист из восьми вопросов вендору, основанный на реальных критериях выбора 178 компаний из нашей выборки.
| Критерий | Вопрос вендору | На что обратить внимание |
|---|---|---|
| Цена / TCO | Какова полная стоимость владения за 3 года? | Учитывайте лицензии, внедрение, доработки, обучение, техподдержку. Скрытые расходы часто превышают стоимость лицензий |
| Функциональность из коробки | Что работает сразу, без доработок? | SLA, маршрутизация, портал самообслуживания — must have. Уточните, входит ли портал в лицензию |
| Гибкость / кастомизация | Можно ли настроить процессы без программистов? | No-Code для быстрой настройки, Low-Code и Pro-code — для глубоких доработок. Уточните наличие маркетплейса готовых решений |
| Интеграции / API | Есть ли готовые коннекторы к вашим системам? | Active Directory, почта, 1С, ERP, мессенджеры. Наличие открытого REST API — обязательное условие для роста |
| Удобство UI/UX | Можно ли посмотреть демо с реальными данными? | Попросите провести пилот с реальными пользователями из вашей команды — 2–4 часа практики лучше любой презентации |
| Российское ПО | Включён ли продукт в реестр отечественного ПО? | Для госсектора и компаний с требованиями по импортозамещению это обязательное условие. Уточните соответствие 152-ФЗ |
| Скорость внедрения | Каков реалистичный срок запуска базовой версии? | 66% компаний хотят внедриться за 1–3 месяца. Спрашивайте о типовых проектах, а не о минимальном возможном сроке |
| Качество поддержки | Как организована техподдержка после запуска? | Русскоязычная поддержка, выделенный менеджер, SLA на поддержку — уточните все условия до подписания договора |
По данным аналитики SimpleOne, 79% компаний называют цену и TCO главным критерием, 75% — функциональность из коробки, 60% — гибкость настройки. Важно не выбирать только по одному параметру: дешёвое решение с плохой кастомизацией обернётся дорогостоящими доработками, а перегруженная функциональностью система — долгим внедрением и низкой адопцией.
Для российских компаний в 2026 году дополнительный фильтр — реестр отечественного ПО и соответствие 152-ФЗ. 40% компаний, ищущих систему управления заявками, называют импортозамещение одним из ключевых факторов выбора.
Этапы внедрения Service Desk: от аудита до запуска
По данным SimpleOne, реалистичный срок полного внедрения Service Desk — 2–3 месяца. 66% компаний, ищущих систему, хотят уложиться именно в этот срок. При этом 49% приходят без технического задания — это нормально: хорошее внедрение начинается с аудита, а не с ТЗ.
Этап 1. Аудит и подготовка (2–3 недели)
Прежде чем что-то автоматизировать, нужно понять, как устроены процессы сейчас. Как поступают заявки, кто и как их обрабатывает, сколько времени занимает обработка, какие есть узкие места. Для этого проводятся интервью с ключевыми сотрудниками и анкетирование пользователей.
На этом же этапе формируется проектная команда: куратор от руководства, администратор системы, представители сервисных служб и пользователей. Без вовлечённости бизнеса внедрение превращается в ИТ-проект, который потом приходится «продавать» внутри компании заново.
Этап 2. Проектирование процессов (2–4 недели)
Команда описывает целевое состояние: для каждого типа заявок — жизненный цикл (статусы), ответственные на каждом этапе, условия перехода между статусами, правила эскалации. Параллельно разрабатывается каталог услуг: ИТ-услуги, HR-услуги, АХО — с указанием SLA для каждого типа.
Важный принцип: для первого этапа лучше автоматизировать меньше, но сделать это хорошо. Управление изменениями и CMDB на старте — не обязательны. 72% компаний планируют масштабирование в рамках ESM позднее — это нормальная траектория.
Этап 3. Настройка системы (2–3 недели)
Развёртывание, базовая конфигурация: организационная структура, загрузка пользователей через AD/LDAP, права доступа, каналы приёма заявок. Затем — настройка процессов: типы заявок, жизненные циклы, маршрутизация, SLA, уведомления. Настройка портала самообслуживания с каталогом услуг и первыми статьями базы знаний.
На этом этапе имеет смысл привлечь вендора или партнёра: профессиональная настройка экономит недели времени и снижает риск технических ошибок, которые потом сложно исправить.
Этап 4. Тестирование и пилот (1–2 недели)
Проектная команда проверяет все сценарии: создание заявок через разные каналы, обработка разных типов обращений, уведомления, SLA, отчёты. Затем запускается пилот на 1–2 отделах (20–30 человек), собирается обратная связь, исправляются проблемы. Параллельно готовятся инструкции и проводится обучение команды поддержки (2–4 часа).
Этап 5. Запуск и стабилизация (1–3 месяца)
За неделю до запуска — информационная кампания: рассылка сотрудникам, объяснение, что изменится и зачем. Рекомендуется «мягкий старт»: первые две недели заявки принимаются и по-старому, и через новую систему — это снижает стресс для пользователей и даёт время на адаптацию.
После запуска — регулярный мониторинг: процент соблюдения SLA, среднее время решения, удовлетворённость пользователей, доля заявок, закрытых через базу знаний. Первый месяц встречи проектной команды — еженедельно, затем — ежемесячно.
Этап 6. Масштабирование в ESM
После стабилизации ИТ-процессов большинство компаний начинают подключать другие подразделения: HR, АХО, бухгалтерию, юридический отдел. Это и есть переход к ESM — единой платформе для управления всеми внутренними услугами компании. Кейс лизинговой компании выше — наглядный пример такой траектории.
«Масштабирование на HR, АХО, бухгалтерию — это не отдельный проект, это следующий шаг той же логики. Когда ИТ-отдел уже работает по SLA и каталогу услуг, соседнему подразделению гораздо проще присоединиться к той же системе, чем строить что-то своё. Постепенно вся компания начинает говорить на одном языке»Андрей Вишняков Директор по бизнес-продуктам компании SimpleOne, ITIL Expert, SL, MP
Типичные ошибки при внедрении
- Автоматизация без формализации процессов — если процессы не описаны, система просто зафиксирует существующий беспорядок. Сначала нужно разобраться, кто за что отвечает, какие SLA реалистичны — только потом переносить это в платформу.
- Избыточная сложность на старте — попытка настроить все возможности сразу перегружает команду и замедляет запуск. Начинать с базового приёма, регистрации и распределения заявок — оптимальная стратегия.
- Отсутствие обучения и поддержки после запуска — Service Desk требует постоянного внимания: регулярный анализ метрик, сбор обратной связи, обновление базы знаний, оптимизация процессов на основе данных.
Резюме
Service Desk — это программа для централизованной обработки, учёта и контроля всех обращений в компании. Правильно внедрённая система обеспечивает автоматическую регистрацию и маршрутизацию заявок, контроль SLA, прозрачность для пользователей и руководства, аналитику для оптимизации процессов.
Экономический эффект измерим: до 40% экономии времени специалистов, рост соблюдения SLA с 65–70% до 90–95%, снижение количества повторных обращений на 25–30%, окупаемость внедрения — 6–12 месяцев. Лучшие примеры показывают ещё более быстрые результаты.
Успех внедрения зависит от трёх вещей: понимания и формализации процессов до начала настройки, вовлечённости команды, правильного выбора системы под реальные задачи бизнеса — а не под самый длинный список функций в презентации вендора.
