Перейти к основному содержимому

2.07. Техническая поддержка

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Разработчику Архитектору Инженеру

Понятие и задачи​

Техническая поддержка (техподдержка) — это комплекс мер, направленных на решение проблем пользователей, обеспечение бесперебойной работы IT-продуктов и улучшение взаимодействия с клиентами.

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

  1. Решение текущих проблем:
    • Диагностика - выявление причины проблемы. Например, пользователь сообщает о сбое в работе приложения, и техподдержка должна определить, вызван ли он ошибкой в программном коде, проблемами с оборудованием или действиями самого пользователя.
    • Устранение неполадок - предоставление инструкций для решения проблемы или выполнение действий со стороны специалистов. Это может включать перезагрузку системы, исправление настроек или обновление программного обеспечения.
    • Эскалация - передача сложных случаев высококвалифицированным специалистам или разработчикам, если проблема требует глубокого анализа.
  2. Обеспечение бесперебойной работы:
    • Профилактика - мониторинг систем для предотвращения возможных сбоев. Например, регулярная проверка серверов, обновление программного обеспечения и своевременная замена оборудования.
    • Резервное копирование - обеспечение восстановления данных в случае аварий или сбоев.
    • Масштабирование - помощь в адаптации систем под растущие потребности бизнеса, например, увеличение вычислительных мощностей или расширение функционала.
  3. Обучение и консультирование пользователей:
    • Инструкции - предоставление руководств по использованию продукта или услуги. Например, создание базы знаний с FAQ, видеоуроков или интерактивных справок.
    • Обучение - проведение вебинаров, тренингов или индивидуальных консультаций для клиентов, особенно если продукт требует особых навыков (например, CRM-системы или ERP-решения).
    • Поддержка внедрения - помощь в настройке и интеграции новых технологий в существующие процессы.
  4. Сбор обратной связи и улучшение продукта:
    • Анализ запросов - изучение типичных проблем, с которыми сталкиваются пользователи, чтобы выявить слабые места продукта.
    • Передача информации разработчикам - предоставление данных о багах, недостатках интерфейса или пожеланиях клиентов для дальнейшего улучшения продукта.
    • Оценка качества сервиса - сбор отзывов о работе техподдержки для повышения эффективности обслуживания.
  5. Формирование положительного клиентского опыта:
    • Коммуникация - поддержание четкого и профессионального диалога с клиентами, даже если проблема требует длительного времени для решения.
    • Честность - информирование клиентов о реальных сроках устранения проблемы и возможных ограничениях.
    • Персонализация - учет индивидуальных потребностей клиентов, особенно в B2B-сегменте, где требования могут сильно различаться.

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

Эти задачи реализуются в рамках более широкой системы управления ИТ-услугами (ITSM), которая стандартизирует процессы, повышает их предсказуемость и эффективность.

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

Чтобы получить быстрое и эффективное решение проблемы, важно соблюдать несколько рекомендаций при обращении:

  1. Опишите проблему максимально подробно. Укажите, что именно произошло. Например: «При попытке войти в систему появляется сообщение об ошибке «Неверный логин или пароль»». Опишите действия, которые привели к проблеме: «Я нажал кнопку входа после ввода данных». Если есть скриншоты или видео с демонстрацией проблемы, обязательно приложите их.
  2. Укажите контекст. Опишите условия использования продукта - какое устройство (модель, операционная система), браузер или версия программы вы используете. Уточните, когда проблема впервые возникла и как часто она повторяется.
  3. Будьте конкретны. Избегайте общих фраз, таких как «Всё сломалось» или «Не работает». Вместо этого укажите, какой именно функционал вызывает трудности. Пример правильного обращения: «При загрузке отчетов в Excel файл сохраняется пустым».
  4. Соблюдайте вежливость. Даже если проблема вызывает раздражение, важно сохранять профессиональный тон. Это помогает установить конструктивный диалог с техподдержкой.
  5. Используйте предоставленные инструменты. Если компания предлагает форму для отправки запросов, заполните её полностью, указав все необходимые данные. Приложите логи, коды ошибок или другие технические детали, если они доступны. Старайтесь использовать официальные каналы, даже если кажется, что обращение к людям напрямую решит вопрос быстрее.

Каналы техподдержки - это способы подачи обращений. Каждый канал технической поддержки имеет свои преимущества и ограничения. Компании обычно предлагают несколько вариантов, чтобы клиент мог выбрать наиболее удобный для себя способ связи.

  1. Телефонная поддержка - это быстрое решение простых вопросов и возможность получить мгновенные ответы, но может быть сложно дозвониться в часы пик. Не всегда удобно для сложных технических проблем, требующих демонстрации.
  2. Электронная почта подходит для детального описания проблемы. История переписки сохраняется для дальнейшего анализа. Ответ может занимать больше времени, и помощь не будет мгновенной, но зато проблему можно будет переслать быстрее, чем сотрудник будет переписывать всё с нуля после телефонного звонка.
  3. Онлайн-чат решает проблему электронной почты - это уже мгновенная связь с оператором. Есть возможность отправлять скриншоты или файлы в реальном времени. Но такой способ может быть недоступен в нерабочее время и требует стабильного интернет-соединения.
  4. Система тикетов - более структурированный процесс решения проблемы. Все обращения документируются, что позволяет отслеживать прогресс. Имеется возможность прикреплять файлы и дополнительную информацию. Но может потребовать времени на регистрацию и заполнение формы. Здесь ответ не всегда мгновенный, этот способ ближе к электронной почте.
  5. Социальные сети и мессенджеры в первую очередь представляют собой удобство для пользователей, которые предпочитают эти платформы, а также быстрое реагирование на публичные жалобы. Но имеется ограниченная возможность передачи технических данных, а публичный характер может создавать дискомфорт для клиента.
  6. База знаний и самообслуживание не является каналом, однако предоставляет решение, имеет круглосуточный доступ к информации и возможность быстро найти ответ на распространенные вопросы. Конечно, это не подходит для уникальных или сложных проблем и требует времени на поиск нужной информации, но всё же экономит время сотрудников техподдержки.

История техподдержки​

Проблема игнорирования важности техподдержки, перекладывания на ботов, 1-2 сотрудника на все вопросы, проблема смещения фокуса техподдержки в клиентных компаниях на «скрытие проблем» и «отфутболивание клиентов». Так в госкомпаниях, клиентообслуживающих конторах.

Хотя в ИТ-компаниях всё чётко - высокий уровень оплаты и соответственно квалификации, привлечение других компаний, которые профильно работают техобслуживанием и техподдержкой.

С переходом к цифровым сервисам потребовалось не просто реагировать на проблемы, а управлять ими системно. Так появились стандарты, такие как ITIL, положившие начало современной практике ITSM — управления ИТ-услугами как бизнес-процессами.

На заре массового распространения компьютеров и программного обеспечения (1960–1980-е годы) поддержка пользователей носила преимущественно ручной и реактивный характер. Основным каналом коммуникации был телефон, а процессы обработки запросов не регламентировались. Специалисты, отвечавшие за поддержку, зачастую совмещали эту деятельность с другими обязанностями — разработкой, администрированием или даже продажами.

Думаю, вы понимаете, почему так - потому что не было массовости и клиентоориентированности как таковой. Студенты сами разбирались, а программы поначалу были довольно примитивными.

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

В этот период доминировал реактивный подход, когда система активируется только после возникновения сбоя. Профилактика, документирование, передача знаний — элементы, которые сегодня считаются базовыми, практически не применялись.

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

Helpdesk — централизованное подразделение, предназначенное для приёма, регистрации, маршрутизации и первичного решения запросов пользователей. Его ключевая особенность — наличие единого канала входящих обращений (чаще всего телефон или электронная почта) и попытка систематизации процессов.

На этом этапе появились первые системы учёта обращений (ticketing systems) — программные решения для автоматизации жизненного цикла запроса: от создания до закрытия. Примеры ранних систем: Remedy Action Request System, TrackIt!, а позже — более доступные платформы вроде osTicket. Эти системы позволили фиксировать каждое обращение как тикет (incident ticket), назначать ответственных, контролировать сроки выполнения и собирать базовые метрики (время ответа, время решения, категоризация). Функционал, конечно, был ограничен - интеграций с другими системами почти не существовало, аналитика — минимальна, а процессы часто оставались «на бумаге», не соответствующей реальной практике.

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

Переломным моментом стала популяризация IT Infrastructure Library (ITIL) — набора рекомендаций по управлению ИТ-услугами, изначально разработанного британским правительством (CCTA), но получившего международное признание. ITIL представляет собой структурированную модель, описывающую процессы, роли, ответственности и лучшие практики в управлении ИТ-сервисами. В версии ITIL v2 (1999–2004) и особенно в ITIL v3 (2007) были детально описаны такие процессы, как:

  • Управление инцидентами (Incident Management),
  • Управление проблемами (Problem Management),
  • Управление изменениями (Change Management),
  • Управление конфигурациями (Configuration Management),
  • Управление уровнем услуг (Service Level Management).

Внедрение ITIL способствовало переходу от хаотичной поддержки к IT Service Management (ITSM) — системному подходу, при котором ИТ рассматриваются не как набор технологий, а как услуги, ориентированные на бизнес-потребности.

ITSM (IT Service Management) — это дисциплина, объединяющая людей, процессы и технологии для эффективного проектирования, доставки, управления и непрерывного улучшения ИТ-услуг. Цель ITSM — обеспечение согласованности, предсказуемости и ценности ИТ для бизнеса.

На этом этапе, в 2000-х, техническая поддержка становится частью широкой экосистемы управления сервисами, и появляются единые порталы самообслуживания, базы знаний, SLA и KPI, многоуровневые модели поддержки, а также интеграция с системами мониторинга и управления активами. Ну, и как это всегда бывает, со временем направление обросло методиками и инструментами. Развитие таких платформ, как ServiceNow, BMC Remedy, Jira Service Management, Atlassian и другие, сделало ITSM доступным не только для крупных компаний, но и для среднего бизнеса. Команды стали обширными, организованными, структурированными, как и управление ими.

С началом цифровой трансформации в 2010-х и ростом сложности распределённых систем (микросервисы, облачные платформы, SaaS) требования к технической поддержке радикально изменились. Сегодня ожидается не просто устранение сбоев, а их предотвращение, быстрая диагностика и минимальное влияние на пользователей. Широкое внедрение автоматизации позволило перенести рутинные задачи (например, сброс паролей, перезагрузку серверов, проверку логов) на скрипты и workflow-движки. Это снизило нагрузку на L1-поддержку и повысило скорость реакции. Более того, появились системы на основе искусственного интеллекта (AI) и машинного обучения — так называемые AIOps (Artificial Intelligence for IT Operations). Они анализируют огромные массивы данных в реальном времени, выявляют аномалии, коррелируют события из разных источников и предлагают гипотезы о причинах инцидентов. Это вообще было мечтой - чтобы распределять, диагностировать и категоризировать приходилось не человеку, а автоматизированной системе.

Так появились чат-боты, способные распознавать тип запроса и направлять его или частично решать, предиктивная аналитика для прогнозирования отказов оборудования, автоматическое создание тикетов на основе событий мониторинга (например, из Prometheus или Zabbix). В современных ИТ-компаниях граница между поддержкой и разработкой стирается. Подходы DevOps и SRE (Site Reliability Engineering) кардинально меняют роль технической поддержки.

DevOps подразумевает, что разработчики несут ответственность за работоспособность своих сервисов в продакшене. Они участвуют в дежурствах, реагируют на инциденты, используют ту же систему тикетов.

SRE, как концепция, введённая Google, рассматривает инженеров как «операторов кода». Они не просто исправляют ошибки, а устраняют их причины через автоматизацию, улучшение архитектуры и снижение операционной нагрузки (toil).

В этих условиях традиционная техподдержка трансформируется в инженерную службу, где акцент делается не на обработке запросов, а на устойчивости систем, проактивном мониторинге и непрерывном улучшении.

Несмотря на технологический прогресс, в ряде организаций техническая поддержка продолжает восприниматься как второстепенная функция, выполняемая силами одного-двух сотрудников или полностью возложенная на ботов и внешние шаблонные ответы. Ведь не каждая компания уровнем как Google, поэтому имеются общераспространённые проблемы:

  1. Недооценка важности поддержки — в некоторых компаниях (особенно в государственных структурах, бюджетных организациях и клиентах с низкой цифровой зрелостью) техподдержка сводится к «отфутболиванию» запросов: пользователю дают стандартный ответ, не вникая в суть проблемы.
  2. Отсутствие инвестиций в процессы — нет систем учёта, баз знаний, SLA; поддержка работает в режиме «пожаротушения».
  3. Скрытие проблем вместо их решения — цель становится не устранить инцидент, а закрыть тикет любой ценой. Это приводит к накоплению технического долга и повторяющимся сбоям.
  4. Низкий уровень квалификации и мотивации — в условиях низкой оплаты и отсутствия карьерных перспектив сотрудники не стремятся развиваться, а компетенции ограничиваются базовыми действиями.

В отличие от этого, в технологических компаниях (продуктовых, SaaS, аутсорсинговых провайдерах) техническая поддержка является стратегически важным элементом. Здесь высокие требования к качеству сервиса, внедрены SLA и системы мониторинга удовлетворённости (CSAT, NPS), поддержка интегрирована с разработкой и продуктом, используются профильные компании-аутсорсеры (например, для 24/7 L1-поддержки), предусмотрены пути роста: от оператора до инженера по надёжности.

Такой подход позволяет не только минимизировать простои, но и использовать данные поддержки для улучшения продуктов: например, через анализ частых запросов выявляются недочёты в интерфейсе или документации. Лично я считаю, что будущее технической поддержки — не в замене людей ботами, а в повышении её роли как центра обратной связи, проактивного управления рисками и драйвера непрерывного улучшения.

Обработка обращений​

Обработка обращений — это централизованный процесс приёма, учёта, анализа и разрешения запросов от пользователей, связанных с нарушением или ухудшением работы ИТ-услуг. Он является ядром операционной деятельности технической поддержки и напрямую входит в состав дисциплины управления инцидентами (Incident Management) в рамках методологии ITSM (IT Service Management).

Ключевая цель обработки обращений — восстановить нормальное функционирование сервиса в кратчайшие сроки при минимальном воздействии на бизнес-деятельность. Для достижения этой цели используется структурированный подход, основанный на управлении полным жизненным циклом обращения.

Жизненный цикл обращения — это последовательность контролируемых этапов, через которые проходит каждый зарегистрированный запрос пользователя, начиная с момента его поступления и заканчивая финальным закрытием и, при необходимости, оценкой эффективности проведённых действий. Данный цикл обеспечивает прозрачность, прослеживаемость и управляемость процесса поддержки.

В рамках стандартизированных практик ITSM (в частности, ITIL) жизненный цикл инцидента традиционно включает следующие этапы:

  • Создание (Creation)
  • Классификация (Classification)
  • Приоритизация (Prioritization)
  • Назначение (Assignment)
  • Диагностика (Diagnosis)
  • Решение (Resolution)
  • Закрытие (Closure)
  • Оценка (Post-Incident Review / Evaluation)

Эта модель позволяет не только оперативно реагировать на инциденты, но и анализировать их причины, выявлять системные проблемы и предотвращать повторные сбои.

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

Регистрация → Классификация → Приоритезация → Назначение → Решение → Закрытие

image.png

Теперь рассмотрим каждый из них.

  1. Регистрация. Цель - фиксация обращения клиента и сбор базовой информации.

Действия:

  • Создание записи в системе (тикета).
  • Указание контактных данных клиента (имя, email, номер телефона).
  • Описание проблемы или запроса.
  • Прикрепление дополнительных материалов (скриншоты, файлы, логи).

Регистрация позволяет отслеживать историю взаимодействия с клиентом, избежать потери данных и обеспечить прозрачность процесса. К примеру, клиент сообщает о проблеме с входом в систему. Специалист регистрирует обращение, указывая дату, время и описание: «Ошибка 'Неверный логин или пароль' при попытке авторизации».

Цель этапа регистрации — формализованная фиксация обращения пользователя в единой системе учёта, обеспечение его прослеживаемости и сбор достаточного объёма информации для последующей обработки. Это первый и обязательный шаг жизненного цикла любого инцидента или запроса в рамках ITSM. Без корректной регистрации невозможно обеспечить контроль за выполнением, соблюдение SLA, анализ нагрузки или восстановление истории взаимодействия.

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

Идентификация пользователя: ФИО, идентификатор в системе (например, ID клиента или логин), должность, подразделение (для внутренних пользователей). Это позволяет проверить права доступа, уровень обслуживания (SLA) и историю предыдущих обращений.

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

Описание проблемы или запроса: чёткое, информативное изложение сути вопроса. Желательно в форме, близкой к шаблону: «что делал пользователь», «что произошло», «когда впервые возникло», «воспроизводится ли регулярно». Например: «При попытке входа в CRM-систему по ссылке https://crm.example.com появляется ошибка "403 Forbidden". Проблема возникла сегодня в 10:15. Повторяется на всех устройствах». На практике, конечно, они всегда нечёткие.

Система или сервис, к которому относится обращение: указание конкретного приложения, платформы, модуля или устройства. Это критично для правильной маршрутизации.

Дополнительные материалы: скриншоты, видео, файлы конфигурации, логи, HTTP-заголовки, коды ошибок. Особенно важны при диагностике технических сбоев.

Наверняка вы обращались в поддержку хоть раз. Указывали ли вы всё это? Разумеется, нет. Поэтому надо стараться, чтобы сбор был автоматизированным, и не вынуждал пользователя всё это заполнять.

В современных условиях пользователи могут обращаться через различные каналы, и система поддержки должна обеспечивать канально-независимую регистрацию.

При звонке специалист Helpdesk открывает тикет вручную, заполняя все поля на основе устной информации. Важно сразу уточнить контактные данные и суть проблемы до завершения разговора.

При электронной почте система автоматически создаёт тикет на основе входящего письма, присваивает уникальный ID и сохраняет переписку как часть истории. Ответы пользователя будут добавляться к тому же тикету, что обеспечивает непрерывность диалога.

В случае чат-поддержки (веб-чат, мессенджер, Slack-бот) сообщения автоматически ассоциируются с тикетом в реальном времени. Диалог становится частью карточки обращения, а после передачи в ручную обработку — продолжается в той же системе.

Через самообслуживание (self-service portal) пользователь сам заполняет форму, прикрепляет файлы и получает номер тикета — это снижает нагрузку на операторов и повышает точность данных.

На этапе регистрации также определяется дальнейшая стратегия взаимодействия:

  • Мгновенное решение (immediate resolution). Некоторые запросы могут быть закрыты сразу: например, консультация по функционалу, сброс пароля через автоматизированную форму, направление на документацию. Если проблема решена в ходе первого контакта, тикет всё равно регистрируется и закрывается с пометкой «решено» — это важно для аналитики и учёта нагрузки.
  • Передача на разбор (escalation or investigation). Более сложные случаи требуют времени: диагностики, взаимодействия с другими командами, анализа логов. В этом случае тикет создаётся с пониманием, что ответ будет дан позже. Канал связи (email, чат) служит не только средством получения запроса, но и каналом обратной доставки решения. Именно поэтому регистрация включает обязательное указание способа связи — чтобы знать, куда и как вернуться к пользователю.

Таким образом, регистрация исключает потерю обращений, обеспечивает единое информационное пространство и позволяет строить отчёты по нагрузке, типам инцидентов, эффективности поддержки.

  1. Классификация.

Цель этапа классификации — однозначное отнесение зарегистрированного обращения к одной или нескольким категориям на основе его содержания, характера проблемы и контекста. Это ключевой шаг для обеспечения корректной маршрутизации, эффективного распределения нагрузки между командами и последующего анализа инцидентов.

Действия:

  • Разделение обращений по типам (например, технические ошибки, вопросы по функционалу, запросы на обучение).
  • Использование заранее определенных меток или тегов (например, «Ошибка сервера», «Проблема с интерфейсом»).

Классификация помогает направлять запросы к правильным специалистам и ускоряет процесс решения. К примеру, запрос «Не работает кнопка отправки формы» классифицируется как «UI/UX-проблема».

Без точной классификации невозможно автоматизировать процессы, построить осмысленную аналитику или выявить системные слабые места в ИТ-инфраструктуре. Ошибочная или отсутствующая категоризация приводит к задержкам, передазначению тикетов и увеличению времени восстановления сервиса (MTTR).

Классификация осуществляется на основе заранее утверждённой таксономии — набора категорий, подкатегорий и тегов, унифицированных по всей службе поддержки. Эти метки должны быть:

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

В большинстве ITSM-систем классификация реализуется через комбинацию полей и тегов, позволяющих описать обращение с разных сторон.

Для комплексного описания обращения используется многомерная классификация — то есть каждый тикет может быть помечен по нескольким независимым осям:

По типу обращения

  • Инцидент (Incident) — любое событие, приводящее к нарушению или потенциальному нарушению нормального функционирования ИТ-услуги. Пример: «Сайт недоступен», «Приложение зависает при загрузке файла».
  • Запрос на обслуживание (Service Request / ЗНО) — запрос на предоставление стандартной услуги, не связанной с отказом. Пример: «Выдать доступ к папке», «Установить ПО», «Сменить пароль».
  • Вопрос / Консультация — запрос информации, не требующий изменения конфигурации или вмешательства в систему. Пример: «Как экспортировать отчёт?», «Есть ли мобильное приложение?»

По области воздействия (техническая доменная зона):

  • Сервер — проблемы с физическими или виртуальными серверами, хостингом, ОС.
  • Сеть — сбои в маршрутизации, доступе к ресурсам, DNS, VPN, пропускной способности.
  • Программное обеспечение (ПО) — ошибки в работе приложений, баги интерфейса, логики.
  • Безопасность — подозрительная активность, блокировка аккаунта, запросы на аудит.
  • Клиентское устройство — проблемы на стороне пользователя: ПК, телефон, браузер, версия ОС.
  • Интеграция — сбои между системами, API-ошибки, форматы данных.

По источнику поступления:

  • Пользователь — обращение инициировано конечным пользователем (вручную).
  • Система мониторинга — автоматическое создание тикета на основе алерта (например, из Zabbix, Prometheus, Datadog).
  • Автоматизированная система — интеграция с CI/CD, SIEM, EDR и другими платформами, генерирующая события без участия человека.

Также бывает и по уровню специализации - Frontend, Backend, Базы данных, Аутентификация, Отчёты и др. — используется для глубокой маршрутизации внутри технических команд.

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

На этапе классификации это обращение будет помечено как:

  • Тип: Инцидент
  • Область: ПО → Веб-интерфейс
  • Подкатегория: UI/UX-проблема
  • Источник: Пользователь

Такая разметка позволяет системе автоматически направить тикет в команду фронтенд-разработчиков или L2-поддержки, отвечающей за клиентский слой.

На практике часть обращений изначально не может быть однозначно отнесена к категории — например, при недостатке информации или неоднозначной формулировке. Такие тикеты временно помещаются в состояние «Неклассифицировано» (Unclassified). Это не ошибка, а допустимая промежуточная стадия. Однако длительное нахождение в этой категории свидетельствует о проблемах с качеством первичного сбора данных, компетенцией регистратора и нехваткой категории в таксономии.

Рекомендуется устанавливать SLA на классификацию (например, в течение 15–30 минут после регистрации), чтобы минимизировать время простоя в «серой зоне».

Правильно выполненная классификация ускоряет маршрутизацию за счёт автоматических правил (routing rules), повышает точность распределения нагрузки, позволяет строить аналитику по доменам (например, «70% инцидентов за месяц — по безопасности»), выявляет «узкие места» в архитектуре или процессах, служит основой для обучения моделей AIOps и чат-ботов.

  1. Приоритизация.

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

Действия:

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

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

Этот этап является ключевым для соблюдения SLA (Service Level Agreement) — договорённостей о сроках реакции и решения, а также для управления ожиданиями клиентов и внутренних стейкхолдеров.

Перед тем как перейти к методике, необходимо чётко разграничить три часто путаемых, но принципиально разных понятия - влияние, критичность и приоритет.

Влияние (Impact), степень, в которой инцидент затрагивает бизнес-процессы, пользователей или сервисы. Оценивается по масштабу и глубине последствий. Пример: Полный простой CRM-системы влияет на всех менеджеров по продажам — высокое влияние. Ошибка в отображении аватара одного пользователя — низкое влияние.

Критичность (Urgency / Severity), скорость, с которой необходимо решить проблему. Определяется тем, насколько быстро её устранение предотвратит дальнейшие потери. Пример: Утечка данных требует немедленного вмешательства — высокая критичность. Незначительная опечатка в интерфейсе может быть исправлена в рамках планового релиза — низкая критичность.

Приоритет (Priority), результирующее значение, определяющее очерёдность обработки обращения. Формируется на основе комбинации влияния и критичности. Приоритет напрямую задаёт требования к SLA: срок первого ответа (First Response Time) и полного решения (Resolution Time).

Формула приоритизации: Приоритет=Влияние×Критичность.

Чем выше оба фактора, тем выше приоритет. Эта модель используется в большинстве ITSM-практик, включая ITIL.

Для стандартизации процесса применяются унифицированные шкалы. Наиболее распространённая — трёхуровневая:

  • низкий - единичный случай, некритичный функционал, и требуется решить в ближайшее время;
  • средний - группа пользователей, частичное нарушение функционала, желательно решить в течение дня;
  • высокий - все пользователи, критический сервис, остановка бизнес-процесса, и требуется решить немедленно.

ITSM определяет большее количество приоритетов - четыре.

  • P1 (Критический / Очень высокий). Сервис полностью недоступен, массовый сбой, угроза безопасности. Требует немедленного вмешательства. Пример: Падение основного сервера, блокировка всех учётных записей.
  • P2 (Высокий). Значительное нарушение работы, затрагивающее группу пользователей или ключевой функционал. Пример: Ошибка в расчёте зарплаты, сбой в отправке email-рассылок.
  • P3 (Средний). Локальная проблема, не блокирующая основную работу. Пример: Не отображается изображение в документе, зависание модуля при редком сценарии.
  • P4 (Низкий). Эстетические замечания, предложения по улучшению, консультации. Пример: «Можно ли изменить цвет кнопки?», «Где найти справку по экспорту?».

Уровень приоритета напрямую определяет SLA-метрики — согласованные сроки обслуживания, допустим 7 рабочих дней на P4 или 2 часа на P1. Эти значения могут варьироваться в зависимости от политики компании, типа сервиса и контрактных обязательств перед клиентами.

Рекомендуется проводить периодический пересмотр приоритетов, особенно при получении дополнительной информации или изменении обстановки.

Правильная приоритизация минимизирует простои критически важных сервисов, оптимизирует загрузку команд, обеспечивает прозрачность процесса для клиентов, позволяет контролировать выполнение SLA, формирует основу для отчётности и улучшения качества поддержки.

  1. Назначение.

Цель этапа назначения — передача зарегистрированного и классифицированного обращения в руки ответственного исполнителя или команды, обладающей необходимыми компетенциями для его решения. Этот этап завершает процесс маршрутизации и открывает фазу активной работы над инцидентом или запросом.

Действия:

  • Назначение задачи конкретному сотруднику на основе его компетенций (например, фронтенд-разработчику, системному администратору или консультанту).
  • Использование автоматизированных систем для распределения задач.

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

Назначение является критическим звеном в цепочке обработки: даже при идеальной регистрации и классификации задержка на этом этапе напрямую увеличивает время реакции (First Response Time) и общее время устранения проблемы (MTTR). Ошибочное или несвоевременное назначение приводит к «пинг-понгу» тикетов между специалистами, дублированию усилий и снижению доверия пользователей к службе поддержки.

Рабочая группа (Working Group, WG) — это функционально выделенная команда специалистов, отвечающих за определённую область ИТ-инфраструктуры, сервиса или бизнес-процесса. Рабочие группы формируются по принципу технической или предметной экспертизы.

Каждая рабочая группа имеет чётко определённую зону ответственности (Service Ownership), внутренние SLA на обработку тикетов, доступ к соответствующим системам и документации, возможность эскалации к более высоким уровням (L3/L4).

Для корректного понимания механизма назначения необходимо уточнить ключевые элементы, с которыми работает система: тикет, теги и история тикета.

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

Теги (Tags) — метки, присвоенные тикету на этапе классификации (например, api-error, authentication, high-priority). Используются для фильтрации, автоматизации и аналитики.

История тикета (Audit Trail) — хронологическая запись всех действий: изменений статуса, комментариев, переназначений, вложений. Обеспечивает прозрачность и аудируемость процесса.

Эти данные используются как при автоматическом, так и при ручном назначении.

Автоназначение — механизм, при котором ITSM-система автоматически направляет тикет в нужную рабочую группу или конкретному исполнителю на основе заранее заданных правил. Правила автоназначения могут быть основаны на категории, тегах, истории, нагрузке или графику дежурств. Автоназначение позволяет сократить время на ручную сортировку, минимизировать ошибки маршрутизации, обеспечить соблюдение SLA на первое назначение, масштабировать поддержку без пропорционального роста координирующего персонала.

Несмотря на развитие автоматизации, ручное назначение остаётся необходимым в ряде случаев при сложных или смешанных инцидентах, затрагивающих несколько областей, при отсутствии однозначной классификации, при необходимости координации между командами, в организациях с низкой зрелостью ITSM-процессов.

Часто ручное назначение выполняет координатор поддержки (аналог Service Desk Analyst или Team Lead), который анализирует содержание тикета, учитывает текущую нагрузку в командах, проверяет наличие свободных специалистов с нужной экспертизой, при необходимости создаёт мультидисциплинарные задачи или временные рабочие группы.

Также используется распределение по очереди (round-robin) или по графику дежурств, особенно в круглосуточных службах. Например, каждый день ответственность за входящие тикеты переходит к следующему инженеру в списке — это обеспечивает равномерную нагрузку. В современных условиях некоторые тикеты требуют участия нескольких специалистов. В таких случаях возможно назначение основного исполнителя (Primary Assignee), отвечающего за прогресс и коммуникацию, добавление соисполнителей (CC, Watchers, Participants), создание связанных задач в других системах (например, Jira для разработки, Confluence для документации). Это особенно актуально при работе с инцидентами, затрагивающими несколько уровней стека (фронтенд, бэкенд, база данных, сеть).

Эффективное назначение сокращает время до первого контакта с ответственным, снижает количество переназначений (reassignments), повышает качество решения за счёт вовлечения профильных специалистов, упрощает отчётность и оценку нагрузки по командам, способствует соблюдению SLA и удовлетворённости клиентов.

  1. Решение.

Цель этапа решения — устранить причину или следствие инцидента и восстановить нормальное функционирование ИТ-услуги в рамках согласованного уровня качества. Это ключевой операционный этап жизненного цикла обращения, на котором реализуется техническая экспертиза, координация действий и контроль результатов.

Действия:

  • Диагностика причины проблемы.
  • Выполнение необходимых действий (например, исправление кода, перезапуск сервера, предоставление инструкций клиенту).
  • Тестирование решения для проверки его корректности.

Этот этап напрямую влияет на удовлетворенность клиента и качество сервиса. После анализа логов выясняется, что проблема вызвана сбоем в базе данных. Специалист восстанавливает подключение и проверяет работу системы.

Решение не ограничивается простым «починить и закрыть». Оно включает диагностику, выполнение корректирующих действий, проверку их эффективности и, при необходимости, информирование пользователя. От качества этого этапа напрямую зависит удовлетворённость клиента (CSAT), время простоя сервиса (downtime) и уровень доверия к ИТ-службе.

Перед тем как применять исправления, необходимо понять источник сбоя. Диагностика может включать анализ логов (application logs, system logs, audit trails), проверку метрик производительности (CPU, memory, latency, error rates), воспроизведение сценария у пользователя, использование отладочных инструментов (debuggers, packet analyzers, profilers), консультации с другими специалистами или командами. Цель — определить, является ли проблема единичной (например, ошибка конфигурации) или системной (например, дефект архитектуры или недостаток масштабируемости).

На основе диагностики применяется одно или несколько решений, зависящих от характера инцидента:

  • Операционные действия: перезапуск сервиса, переключение на резервный узел, очистка кэша, восстановление из резервной копии.
  • Изменение конфигурации: правка параметров сервера, обновление политик доступа, настройка таймаутов.
  • Исправление кода: если проблема вызвана багом, разрабатывается и внедряется патч (hotfix).
  • Консультация пользователя: предоставление пошаговой инструкции, изменение поведения со стороны клиента (например, обновление браузера).
  • Обходное решение (workaround): временное исправление, позволяющее восстановить работоспособность до выпуска постоянного фикса.

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

Тестирование может выполняться автоматически (через smoke-тесты, health-checks), вручную (инженер проходит сценарий), с участием пользователя («Проверьте, пожалуйста, доступ сейчас»).

На этапе решения важно поддерживать прозрачность, информировать пользователя о ходе работ («Мы выявили проблему, работаем над исправлением»), не обещать сроки, если они не гарантированы, по завершении — кратко объяснить, что было сделано. Это снижает уровень тревожности и формирует доверие к службе поддержки.

Только после подтверждения работоспособности можно переходить к закрытию тикета.

  1. Закрытие.

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

Действия:

  • Уведомление клиента о решении проблемы.
  • Запрос обратной связи (например, через оценку качества обслуживания).
  • Архивирование данных о запросе для анализа и статистики.

Закрытие обращения завершает цикл взаимодействия и позволяет оценить эффективность работы техподдержки. К примеру, клиент получает письмо: «Проблема с входом в систему устранена. Спасибо, что сообщили о ней!».

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

В идеальном процессе закрытие происходит только после подтверждения от клиента, что проблема действительно решена. Это может быть прямой ответ: «Да, всё работает», автоматическое подтверждение по истечении времени без повторного обращения (в случае SLA), оценка через опрос. Отсутствие подтверждения — основание для отложенного закрытия или перевода тикета в статус «Ожидание ответа клиента».

После решения система может автоматически отправить пользователю запрос на оценку по шкале CSAT (Customer Satisfaction Score): например, «Оцените качество поддержки по шкале от 1 до 5», через NPS (Net Promoter Score): «Насколько вероятно, что вы порекомендуете нашу службу поддержки коллеге?», с возможностью оставить комментарий. Эти данные используются для анализа эффективности работы поддержки, выявления слабых мест и повышения качества сервиса.

При закрытии тикета фиксируется причина инцидента (если установлена), применённое решение, затраченное время, использованные ресурсы, ссылки на связанные задачи (например, патч в Jira, обновление документации). Данные сохраняются в системе учёта и становятся доступными для анализа повторяющихся инцидентов, аудита, обучения новых сотрудников, подготовки отчётности перед руководством. Если решение представляет типовой случай, оно может быть оформлено как статья в базе знаний. Это позволяет снизить нагрузку на поддержку за счёт самообслуживания, ускорить решение аналогичных обращений в будущем.

В некоторых системах реализуется автоматическое закрытие тикетов через заданный интервал (например, 72 часа) после последнего сообщения от пользователя. Это допустимо только при соблюдении условий, допустим, что нет активных возражений. Автоматизация помогает избежать скопления «висячих» тикетов, но требует чётких правил и мониторинга.

Как разбирают проблемы?

  1. Автоматическое создание тикета. Как только пользователь обращается в поддержку — по телефону, через чат, email или внутреннюю форму — система фиксирует обращение и создаёт тикет (обращение/инцидент).

Система присваивает уникальный номер тикету для отслеживания, заполняются обязательные поля - контактные данные клиента, описание проблемы, категория обращения, приоритет, дата и время обращения. К примеру, пользователь пишет в чат: «Не могу войти в CRM». Система автоматически регистрирует запрос как тикет #CRM-2047 с категорией «Авторизация», приоритетом «Средний» и отправляет на L1-специалиста.

  1. Анализ похожих обращений. После создания тикета система проводит поиск аналогичных случаев в своей базе знаний (Knowledge Base) или в истории обращений. Это нужно, чтобы ускорить решение, если такая проблема уже встречалась, чтобы избежать дублирования работы и предложить клиенту самостоятельное решение через FAQ или статью. Так можно выявить повторяющиеся ошибки, которые могут быть багами или недостатками в обучении пользователей.

Современные системы используют NLP (Natural Language Processing), чтобы находить похожие обращения даже при разных формулировках.

  1. Направление специалисту. Если аналогов нет или проблема требует более детального анализа, тикет направляется на нужный уровень поддержки.
  1. Глубокая диагностика. Здесь проводится детальный анализ проблемы- изучают логи системы, проверяют конфигурации, воспроизводят проблему на тестовой среде, проверяют взаимодействие с другими системами, анализируют метрики производительности, работают с командой DevOps или QA. Цель - понять, является ли проблема однократной ошибкой пользователя, багом, проблемой интеграции или ошибкой настройки - всё это важно, чтобы определить причину.
  1. Определение причины. Обычно она идёт после диагностики.

В чём может быть ошибка?

  • Ошибка пользователя (например, неправильная настройка прав)
  • Ошибка в коде (баг)
  • Сбой в инфраструктуре (падение сервера, DDoS)
  • Проблема совместимости (например, старый браузер)
  • Недостаток документации или обучения

Для фиксации часто используется методология Root Cause Analysis (RCA) — анализ корневых причин. Если выяснилось, что проблема связана с ошибкой в коде или необходимостью доработки функционала — тикет направляется в команду разработки.

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

Особенности техподдержки​

Базы решений и типовые запросы​

База решений (Knowledge Base, KB) — это централизованный, структурированный репозиторий информации, содержащий документированные решения по типовым инцидентам, инструкции по использованию сервисов, ответы на часто задаваемые вопросы (FAQ), рекомендации по устранению неполадок и другую техническую или пользовательскую документацию.

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

База знаний является неотъемлемой частью дисциплины управления знаниями (Knowledge Management) в рамках IT Service Management (ITSM). Согласно ITIL 4, эффективное управление знаниями предполагает создание, хранение, распространение, актуализацию информации, необходимой для поддержки ИТ-услуг.

Knowledge Base выступает ключевым инструментом реализации этой стратегии. Она обеспечивает преемственность опыта между сотрудниками, снижение зависимости от отдельных специалистов, прозрачность процессов поддержки, основу для обучения новых сотрудников.

Статьи должны быть написаны понятным языком (с учётом аудитории), структурированы (заголовок, проблема, причина, решение, скриншоты), помечены тегами и категориями, датированы и подписаны автором, регулярно проверены на актуальность.

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

Если проблема возникла дважды — она будет возникать и дальше. Значит, её решение должно быть задокументировано.

Каждое успешное решение может быть трансформировано в статью KB — для долгосрочного хранения и доступа, в шаблон ответа (response template) — чтобы операторы быстро отправляли типовые решения, в автоматизированный workflow — например, кнопка «Сбросить пароль» в портале.

База знаний — живой ресурс. Устаревшие статьи вреднее, чем их отсутствие. Поэтому необходимо регулярно проводить аудит содержимого (раз в 6–12 месяцев), удалять или архивировать устаревшие инструкции, обновлять статьи при изменениях в ПО, политике или инфраструктуре, назначать владельцев статей (content owners) — ответственных за актуальность.

Каковы преимущества использования базы решений?

ПреимуществоОписание
СамообслуживаниеПользователи могут найти ответы самостоятельно, без обращения в поддержку. Это снижает нагрузку на специалистов и ускоряет процесс.
Единообразие информацииВсе сотрудники используют один источник информации, что исключает разногласия в ответах и гарантирует точность.
Скорость решенияТиповые проблемы решаются быстрее — специалисты просто направляют пользователя к готовому решению или используют шаблоны ответов.
Анализ данныхАналитика популярных статей и частых запросов позволяет выявлять слабые места в продукте и улучшать его.
МасштабируемостьБаза знаний легко масштабируется — новые статьи добавляются по мере появления новых вопросов.

К примеру, пользователь не может войти в систему. Вместо того чтобы ждать ответ от поддержки, он заходит в раздел «Авторизация» базы знаний и находит статью «Как восстановить доступ к аккаунту».

Обычно база знаний состоит из следующих компонентов:

ЭлементНазначение
Разделы / категорииИнформация организована по темам (например, «Вход в систему», «Оплата», «Интеграции»)
Статьи / FAQПодробные ответы на конкретные вопросы
Поисковая системаПозволяет быстро находить нужную информацию
Чат-боты и виджетыИнтегрируются с базой знаний для автоматического предложения решений
Метаданные и тегиОблегчают поиск и фильтрацию информации
Версии и обновленияСтатьи регулярно обновляются, чтобы соответствовать актуальным версиям продукта

Нужно собирать наиболее частые обращения, проводить интервью с сотрудниками поддержки, изучать логи и метрики, разделять информацию по темам и уровням сложности - главное - собрать как можно больше информации.

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

А собственно, что такое типовые запросы?

Типовые запросы — это повторяющиеся обращения, которые можно описать и подготовить заранее. Давайте рассмотрим примеры таких типовых запросов.

КатегорияПример запросаВозможное решение
АвторизацияНе могу войти в аккаунтВосстановление пароля через email
ФормыФорма не отправляетсяПроверка интернет-соединения, заполнения обязательных полей
ОбновленияКак установить последнюю версию приложения?Ссылка на центр загрузок или автообновление
ОплатаНе прошла оплатаПроверка реквизитов, повтор попытки, связь с банком
ИнтеграцииКак подключить CRM к почте?Пошаговая инструкция + API-ключи
ПроизводительностьСистема стала медленно работатьОчистка кэша, проверка подключения, обратиться в L2

Управление обращениями​

Инцидент — это любое незапланированное событие, которое приводит к полному или частичному нарушению нормальной работы ИТ-услуги или угрожает её стабильности. Основная цель при работе с инцидентом — как можно быстрее восстановить работоспособность сервиса, минимизировав влияние на бизнес.

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

ITIL 4 определяет инцидент как любое событие, которое вызывает или может вызвать прерывание предоставления услуги или снижение её качества.

Примеры инцидентов:

КатегорияПример
СерверыПадение сайта, недоступность API
АвторизацияПользователь не может войти в систему
Базы данныхОшибка чтения/записи, потеря данных
СетьПроблемы с подключением, DDoS-атаки
ПриложенияКраш программы, ошибка выполнения команды

Существует процесс управления инцидентами (Incident Management), цель которого как раз таки эффективное и своевременное реагирование на инцидент с быстрым восстановлением работоспособности системы. Это процесс, направленный на быструю идентификацию, регистрацию, диагностику, временное или окончательное решение, закрытие инцидента. Цель — не найти корень проблемы, а восстановить сервис. Глубокий анализ первопричины выносится за рамки Incident Management и передаётся в Problem Management.

Запрос на обслуживание (Service Request) — запланированное обращение, связанное с предоставлением стандартной ИТ-услуги, изменением конфигурации или использованием существующих возможностей системы. В отличие от инцидента, он не связан с отказом или сбоем и выполняется в рамках заранее определённых процедур.

Такие запросы предсказуемы, стандартизированы и часто автоматизированы. Они регулируются процессом Request Fulfilment, который обеспечивает их выполнение в установленные сроки и с соблюдением политик безопасности и доступа.

Примеры запросов на обслуживание:

КатегорияПример
Управление доступомДобавление нового пользователя, изменение прав
НастройкаИзменение параметров системы, конфигурация интеграций
ОбучениеЗапрос на проведение обучения сотрудников
ДокументацияПолучение справочных материалов, отчетов
АктуализацияОбновление программного обеспечения, смена тарифа

Управление запросами (Request Fulfilment) является процессом, целью которого выступает выполнение запроса в срок и в соответствии с установленными стандартами. Часто реализуется через каталог услуг (Service Catalog), может обрабатываться автоматически (например, self-service portal), имеет фиксированный workflow и SLA, но обычно менее жёсткие, чем для инцидентов.

Если пользователь пишет: «Я не могу отправить документ», это инцидент — нужно срочно разобраться. А если он пишет: «Как добавить нового пользователя?», это запрос на обслуживание — можно дать инструкцию или направить в KB. Причём, это даже можно квалифицировать как консультацию, что будет ещё проще.

Хотя в ITIL консультации не выделены как отдельный тип, на практике они составляют значительную долю обращений. Консультация — это запрос информации, не требующий изменения состояния системы или вмешательства в инфраструктуру.

Примеры: «Как экспортировать отчёт?», «Есть ли мобильное приложение?», «Где находится настройка уведомлений?». Бывают системы, где консультаций просто нет, и пользователи хорошо знают предметную часть и ориентируются в системе.

На моем же опыте было сложнее, 90% проблем были консультациями, так как на юзеров накидывали море информации. Консультации можно рассматривать как подтип запроса на обслуживание или как самостоятельную категорию в гибридных моделях. Их особенность — минимальная операционная нагрузка: решение чаще всего сводится к ссылке на документацию или базу знаний.

Правильная классификация позволяет, например, направить первый запрос в L2-поддержку с приоритетом P1, а второй — автоматически обработать через портал самообслуживания.

Также можно рассказать о проблемах.

Важно понимать, что инцидент ≠ проблема. Инцидент — это симптом, а проблема — это скрытая, потенциальная или реальная корневая причина одного или нескольких инцидентов.

Процесс управления проблемами (Problem Management) направлен не на срочное восстановление, а на долгосрочное устранение источников сбоев. К примеру, 50 пользователей не могут войти в систему, и анализ показывает, что ошибка повторяется при каждом обновлении конфигурации. Корневая причина (RCA — Root Cause Analysis): после обновления шаблона конфигурации в CI/CD pipeline некорректно применяются настройки LDAP-синхронизации.

Значит, инциденты и проблемы связаны. Выделяют следующие виды связей:

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

Координатор проблемы (Problem Manager) — специалист, отвечающий за идентификацию потенциальных проблем, организацию расследования (investigation), проведение RCA, контроль внедрения постоянных решений.

Современные системы управления ИТ-услугами (например, ServiceNow, Jira Service Desk, Zendesk) позволяют автоматически определять тип обращения, назначать приоритет, перенаправлять в нужный отдел, предлагать готовые решения из базы знаний и отслеживать выполнение по SLA (Service Level Agreement). AI и NLP помогают классифицировать обращения уже на этапе создания тикета, что значительно ускоряет дальнейшую обработку.

Линии (уровни) техподдержки​

Техническая поддержка обычно организуется по уровням, чтобы эффективно распределять задачи между специалистами. Это линии техподдержки. На первой линии обычно простые специалисты, и требований к их квалификации меньше - задача тут стоит именно «отбросить» лишнее и направить к другим специалистам для решения более сложных задач. К сожалению, пользователи не знают о таком делении, и рассчитывают на быструю поддержку «здесь и сразу», и необходимость перенаправления будет вызывать у них ярость, после которой последуют гневные оскорбления и впечатление «тупой техподдержки». Но такова доля сервиса.

На моей практике тоже была трёхуровневая система технической поддержки, но вопросы задавались настолько сложные и даже юридические, что первой линии приходилось перенаправлять почти все вопросы, потому что они требовали размышлений и решения сложных задач.

Уровни поддержки (L1–L3):

УровеньОписаниеОтветственность
L1 (Helpdesk)Первый контакт с пользователем. Обычно решают простые задачи.Отвечают на вопросы, помогают с входом, проверяют стандартные решения.
L2 (Technical Support)Специалисты с глубокими техническими знаниями.Диагностируют сложные проблемы, работают с логами, настройками, API.
L3 (Engineering / Development)Инженеры и разработчики уровня эксперта.Решают фундаментальные проблемы, баги, доработки кода.

Например, если L1 не может решить проблему с доступом, она передаёт тикет L2. Если L2 выясняет, что проблема в баге в интерфейсе, тикет уходит на доработку в L3. Можно распределить так, что L1 - простые вопросы, L2 - сложные вопросы, а L3 - разработчики системы.

Оценка обслуживания​

Техподдержка — это не только решение проблем, но и взаимодействие с пользователем. От того, как быстро специалист ответил, насколько чётко объяснил решение и был ли он вежлив, зависит доверие к продукту, лояльность клиента, вероятность повторного обращения или даже продажи в будущем.

После закрытия тикета клиентам часто предлагается оценить качество обслуживания . Обычно задают вопросы по следующим критериям:

КритерийОписание
Скорость ответаНасколько быстро специалист отреагировал на запрос? Был ли ответ оперативным?
Качество решенияПроблема была полностью решена? Полученное решение было понятным и точным?
Профессионализм специалистаСпециалист показал знание продукта, умел слушать, давал полезные рекомендации?
Вежливость и коммуникацияОбщение было дружелюбным, корректным, без жаргона?

Эти параметры могут быть представлены как в числовом виде (например, шкала от 1 до 5), так и в формате «Да/Нет» или открытого текстового ответа.

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

Отзыв (Review) — это формализованная и часто публичная форма обратной связи, размещаемая на сайтах, в магазинах приложений, социальных сетях или платформах вроде Trustpilot. В отличие от внутреннего feedback, отзыв влияет на репутацию компании.

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

  • опросы после закрытия тикета - автоматические формы с вопросами о качестве обслуживания;
  • шкала оценки (NPS, Net Promoter Score), от -100 до +100, где пользователь оценивает вероятность рекомендации компании другим;
  • открытые опросники и анкеты для детальной информации (хотя такие вещи имеют низкий уровень заполнения);
  • интервью и фокус-группы (для глубокого анализа потребностей клиентов);
  • анализ соцсетей и форумов (слежение за отзывами в интернете);
  • чат-боты и голосовые системы (интерактивные инструменты сбора информации).

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

МетрикаОписание
MTTR (Mean Time to Resolution)Среднее время устранения инцидента
First Response TimeВремя первого ответа
Ticket VolumeКоличество обращений за период
SLA ComplianceПроцент обращений, решённых в рамках SLA
Customer Satisfaction (CSAT)Удовлетворённость клиента решением
Resolution without EscalationПроцент обращений, решённых без перехода на L2/L3

Количественные показатели позволяют измерять эффективность поддержки объективно, отслеживать динамику и принимать управленческие решения. Ниже — основные KPI, используемые в ITSM.

  1. MTTR (Mean Time to Resolution) — это среднее время от момента регистрации инцидента до его полного закрытия, включая диагностику, решение и подтверждение. Измеряется в минутах, часах или рабочих днях, позволяет оценить общую эффективность процесса и чувствителен к выбросам (например, одному долгому инциденту).

MTTR не должен быть целью сам по себе. Снижение времени ценой качества (например, через workarounds) может ухудшить надёжность сервиса.

  1. FRT (First Response Time) — интервал между созданием тикета и первым контактом со стороны поддержки (ответ, комментарий, звонок). Критически важен для восприятия скорости реакции, для инцидентов высокого приоритета. Часто регламентируется SLA (например, FRT ≤ 15 минут для P1).

Высокий FRT вызывает тревожность у пользователей, даже если проблема будет решена быстро.

  1. SLA Compliance — процент обращений, закрытых в рамках установленных SLA. SLA (Service Level Agreement) — соглашение о допустимых сроках реакции и решения для каждого уровня приоритета.

Этот показатель отражает предсказуемость и надёжность поддержки. Низкий compliance сигнализирует о перегрузке, плохой маршрутизации или недооценке приоритетов.

  1. CSAT (Customer Satisfaction Score) — средняя оценка удовлетворённости пользователей после решения обращения. Обычно измеряется по шкале от 1 до 5.

Вопросы могут касаться скорости реакции, качества решения, профессионализма специалиста, вежливости и коммуникации. CSAT показывает, насколько хорошо поддержка соответствует ожиданиям пользователя. Однако он чувствителен к эмоциональному состоянию: даже при качественном решении пользователь может поставить низкую оценку, если был расстроен изначально.

  1. NPS (Net Promoter Score) - готовность рекомендовать, измеряет лояльность пользователей через один вопрос: «Насколько вероятно, что вы порекомендуете нашу службу поддержки коллеге или другу?».

Респонденты делятся на три группы:

  • Детракторы (0–6): недовольны, могут распространять негатив,
  • Пассивные (7–8): удовлетворены, но не лояльны,
  • Промоутеры (9–10): активные сторонники.

Результат — число от –100 до +100.

NPS > 50 — высокий уровень лояльности.

В отличие от CSAT, NPS измеряет долгосрочное доверие, а не реакцию на одно событие.

  1. Resolution without Escalation — доля обращений, полностью решённых на уровне L1 (Helpdesk), без передачи L2 или L3. Эффективность первой линии, можно сказать.

Высокий RwE говорит о хорошей подготовке L1-специалистов, наличии базы знаний, эффективной автоматизации. Низкий RwE может указывать на недостаток компетенций, сложность сервисов, отсутствие документации.

Эскалация (Escalation) — передача тикета на более высокий уровень поддержки (L2 → L3) или другому владельцу (например, разработчику). Бывает она функциональной (по экспертной области) и иерархической, при превышении SLA или необходимости принятия решений.

Эскалация — нормальный процесс, но частая передача сигналит о проблемах в первичной поддержке.

Лучшие практики предполагают сочетание количественных метрик (KPI, SLA) и качественного анализа (feedback, интервью). Только такой подход даёт полную картину: не только что произошло, но и почему пользователь остался доволен — или нет. В зрелых ИТ-организациях эти данные ежемесячно анализируются на совещаниях по улучшению сервисов, становясь основой для изменений в продукте, процессах и обучении персонала.

ITSM​

ITSM (IT Service Management) — это системный подход к проектированию, доставке, эксплуатации и непрерывному улучшению ИТ-услуг как бизнес-ориентированных процессов. В отличие от традиционной технической поддержки, где акцент делается на реактивном устранении сбоев, ITSM рассматривает ИТ как поставщика ценности для бизнеса, а не просто как набор технологий. Этот подход позволяет перейти от хаотичного «пожаротушения» к регламентированной, прозрачной и подотчётной деятельности, где каждое действие обосновано, документировано и подлежит анализу.

ITSM можно встретить в крупных корпорациях (банки, телекомы, производство), в продуктовых IT-компаниях (SaaS, платформы), в государственных структурах с высокими требованиями к надёжности, в аутсорсинговых провайдерах, предлагающих managed services.

ITSM охватывает широкий спектр процессов, объединённых общей целью — обеспечение качества ИТ-услуг. Ниже — ключевые области и их содержание.

  1. Предоставление услуг.

Управление каталогом услуг (Service Catalog Management) - центральный реестр всех доступных ИТ-услуг с описанием, условиями предоставления и ответственными сторонами. Примеры: «Выдача доступа к CRM», «Установка ПО», «Обучение новым сотрудникам». Каталог доступен пользователям через портал самообслуживания.

Управление уровнем услуг (Service Level Management, SLM) - процесс, обеспечивающий соответствие ИТ-услуг ожиданиям бизнеса. Включает определение требований, заключение соглашений, мониторинг выполнения, анализ и пересмотр.

Базовый инструмент — SLA (Service Level Agreement).

  1. Разрешение инцидентов.

Управление инцидентами (Incident Management) - восстановить нормальную работу сервиса в кратчайшие сроки. Включает регистрацию, классификацию, приоритезацию, назначение, решение, закрытие.

Управление проблемами (Problem Management) - выявить и устранить корневую причину (RCA) одного или нескольких инцидентов, чтобы предотвратить их повторение.

Управление событиями (Event Management) - мониторинг состояния ИТ-инфраструктуры и автоматическое реагирование на изменения (например, алерты при превышении нагрузки).

  1. Контроль изменений.

Управление изменениями (Change Management) - структурированный процесс внесения изменений в ИТ-среду (обновление ПО, конфигурации, оборудования). Цель — минимизировать риски, связанные с изменениями.

Ключевой элемент — CAB (Change Advisory Board) — совещательный орган, оценивающий риски и одобряющий изменения.

Регламентные работы - это плановые операции, необходимые для поддержания стабильности - обновление ПО и ОС, резервное копирование, проверка безопасности (аудит, сканирование уязвимостей), тестирование отказоустойчивости.

Выполняются в рамках Change Management и документируются.

Управление конфигурациями (Configuration Management) - ведение точной и актуальной информации обо всех компонентах ИТ-инфраструктуры. CI (Configuration Item) — объект управления, любой элемент, который необходимо управлять для предоставления услуги: сервер, сеть, ПО, пользователь, лицензия, документ, виртуальная машина.

CMDB (Configuration Management Database) - единая база данных, хранящая информацию о CIs и их взаимосвязях, позволяет понимать, что на что влияет, и оценивать последствия изменений.

  1. Учет ресурсов.

Управление активами (Asset Management) - учёт физических и программных активов на протяжении всего жизненного цикла: от приобретения до списания.

Управление лицензиями ПО (License Management) - контроль использования лицензий, предотвращение нарушений и штрафов, оптимизация затрат.

Как работает ITSM в системе? (на примере ServiceNow, Jira Service Desk)

  1. Пользователь создаёт тикет через портал, email, чат или API.
  2. Система автоматически определяет:
    • тип обращения (инцидент / запрос на обслуживание),
    • категорию и теги,
    • приоритет (на основе влияния × критичности),
    • SLA (сроки ответа и решения).
  3. Тикет автоматически назначается в нужную рабочую группу (WG) на основе правил маршрутизации.
  4. Процесс обработки:
    • диагностика,
    • согласования (если требуется CAB),
    • решение,
    • подтверждение у пользователя.
  5. После закрытия — автоматический опрос (CSAT/NPS).
  6. Данные попадают в аналитику:
    • какие инциденты повторяются?
    • где задержки в обработке?
    • какова удовлетворённость по направлениям?
    • какие услуги требуют доработки?