Как превратить поток заявок в управляемый процесс: строим Service Desk под разные задачи

Кайтен

Управляйте задачами, проектами и командой в одном месте

Попробовать бесплатно

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

Service Desk помогает не просто вести учет обращений, а превращать хаотичный поток запросов в прозрачный и контролируемый процесс.

Что такое Service Desk простыми словами 

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

Service Desk — это не только учет заявок. Это сочетание:

• Процесса обработки заявок. Какой путь проходит обращение от поступления до результата.
• Ролей и распределения заявок. Кто отвечает за обработку обращений, кто контролирует процесс работы.
• Правил и SLA. По каким критериям команда определяет сроки обработки, приоритет и исполнителя. 
• Источников заявок. Из каких каналов коммуникаций приходят обращения: почта, мессенджер, сайт, звонок и др.
• Системы управления заявками. Сервис, где отображается процесс обработки заявок и реальный статус каждого обращения. 

Есть три основных типа систем для обработки обращений:

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

Как понять, что компании необходим Service Desk 

Как правило, команды начинают использовать Service Desk не потому, что так нужно, а из-за нужды в упорядочении процесса обработки заявок.

«Симптомы», которые показывают необходимость внедрения Service Desk:

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

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

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

С этим и помогает Service Desk.

Задачи, которые решает Service Desk 

Показали в таблице, как Service Desk помогает навести порядок в обращениях, сроках и нагрузке команды.

Из чего состоит рабочий Service Desk 

Разберем основные элементы системы.

Каналы приема заявок 

Заявки обычно попадают в отдел из разных каналов:

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

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

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

Попробовать бесплатно

Чем больше источников, тем лучше — пользователь сможет найти удобный для себя способ связаться с исполнителями. 

Категории заявок 

Распределять заявки можно по разным произвольным категориям. Это могут быть:

• отделы, откуда приходят заявки;
• источники;
• доступы и обслуживание оборудования;
• документы и др.

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

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

Процесс обработки и статусы

Статусы показывают, на каком этапе находится заявка. Самый простой вариант процесса, который можно внедрить на старте:

Новая заявка → В работе → Ожидает информации → На согласовании → Решена → Закрыта

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

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

Роли

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

• Заявитель создает обращение и отслеживает его статус. Обычно он отправляет заявку через форму на сайте, портал, почту или мессенджер. При этом заявитель видит только свои обращения.
• Исполнитель обрабатывает заявки: берет их в работу, меняет статусы, уточняет детали у заявителя и решает задачу. В зависимости от роли в команде исполнитель может видеть весь входящий поток, если работает на первой линии, или только заявки своей категории, если отвечает за профильное направление.
• Руководитель видит все обращения, контролирует сроки и нагрузку команды, следит за аналитикой и качеством обработки заявок. Он может распределять задачи между исполнителями, менять правила работы с запросами и настраивать SLA.
• Администратор отвечает за технические настройки Service Desk: роли, доступы, источники заявок, автоматизации и поля в формах. Иногда эту роль берет на себя руководитель.

Приоритеты

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

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

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

SLA

SLA — это договоренность о том, как быстро команда должна реагировать на заявку и за какое время ее решать.

Для старта не нужно усложнять. Достаточно зафиксировать:

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

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

База знаний 

Без базы знаний команде нужно каждый раз «изобретать велосипед». С ней — исполнители всегда имеют под рукой понятную систематизированную инструкцию для решения обращений. 

Она нужна, чтобы:

• Не отвечать на одни и те же вопросы вручную. Можно выслать заказчику ссылку на нужный раздел с объяснениями;
• Снижать поток повторяющихся обращений. В базу можно добавить раздел с решением частных проблем и сделать его публичным, чтобы пользователи и сотрудники могли самостоятельно решать свои запросы, не нагружая команду;
• Помогать новым сотрудникам быстрее включаться в работу;
• Фиксировать решения, а не держать их «в голове» отдельных специалистов, которые могут уволиться и «забрать» с собой важную информацию. 

Аналитика

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

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

Ниже подробно объясняем, как построить Service Desk.

Как построить Service Desk: пошаговый план 

Шаг 1. Определите цель внедрения Service Desk

Внедрение Service Desk не может быть целью. Система должна решать конкретные проблемы и закрывать бизнес-цели.

Примеры целей:

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

Без сформулированной цели Service Desk превратится в еще один внедренный сервис, который добавит нагрузку команде, а не сделает процесс управляемым.  

Шаг 2. Опишите, какие заявки вы будете принимать, и составьте каталог услуг 

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

Примеры типов обращений:

• доступы;
• починка оборудования;
• справка;
• согласование договора;
• закупка;
• жалоба клиента и пр.

На основе видов заявок составьте каталог услуг. 

Важно: не пытайтесь сразу создать идеальную структуру каталога или типов запросов. Сначала выделите 10-15 самых частых типов обращений и посмотрите, какие из них можно объединить. В процессе работы каталог будет меняться — это нормально. Главное, адаптировать каталог и типы обращений, а не реальность к каталогу. 

Шаг 3. Настройте единый вход для заявок

Обычно настройка состоит из нескольких действий:

1. Создайте пространство, куда будут поступать все заявки.
2. Создайте сервисы по направлениям обращений. Сервис помогает разделить потоки заявок по смыслу. Например, можно создать отдельные сервисы для IT, HR, АХО, закупок или клиентской поддержки.

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

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

5.Настройте место назначения карточки — куда именно она будет попадать после регистрации. Укажите правила маршрутизации в зависимости от категорий заявок. 

6.Выберите поля, которые должен заполнить заявитель перед отправкой запроса. 

Важно объяснить команде новые правила работы с заявками

Если раньше сотрудники писали исполнителям напрямую, переход на Service Desk может выглядеть как лишний шаг. Поэтому важно объяснить, зачем теперь нужно оформлять запрос через систему: так заявка не потеряется, у нее появятся срок, ответственный и история переписки. 

Шаг 4. Определите жизненный цикл заявки

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

Пример жизненного цикла заявки:

1. Создана — заявитель оформил обращение, заявка попала в систему.
2. Заявка принята — первая линия зафиксировала обращение, проверила, что для работы достаточно данных.
3. Назначена — у заявки появился конкретный исполнитель.
4. В работе — исполнитель решает задачу.
5. Ожидает информации — исполнитель запросил данные у заявителя или ждет информацию от смежного отдела.
6. На согласовании — заявка ушла согласующему (при необходимости).
7. Решена — исполнитель закрыл задачу со своей стороны.
8. Закрыта — заявитель подтвердил решение или истек срок ожидания подтверждения.

После этого перенесите статусы в систему. Например, в Kaiten их можно отобразить на канбан-доске. Для этого создайте для каждого этапа отдельную колонку. После запуска Service Desk руководитель сможет видеть, где находится каждый запрос и на каких этапах застревают заявки.

Шаг 5. Назначьте роли и зоны ответственности

Если не закрепить роли, Service Desk быстро превратится в склад заявок: обращения будут попадать в систему, но команда не поймет, кто за что отвечает.

Для старта можно использовать базовое распределение:

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

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

Шаг 6. Настройте приоритеты и SLA

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

Как настроить приоритеты:

• Добавьте в форму заявки поле «Приоритет».
• Настройте обязательное заполнение поля, чтобы заявки не попадали в работу без приоритета.
• Добавьте визуальные метки для приоритетов: например, высокий, средний, низкий.
• При необходимости настройте автоматизацию. Например, если заявка критичная, система назначает ответственного и отправляет уведомление в Telegram.

Как настроить SLA:

• Зайдите в раздел SLA в меню «Службы поддержки».

• Задайте сроки первой реакции и решения для разных типов заявок.

• Укажите, когда SLA должен запускаться: при создании карточки, переходе в нужную колонку или назначении исполнителя.
• Привяжите SLA к рабочему календарю, если команда обрабатывает обращения только в рабочие часы.
• Добавьте уведомления о приближении дедлайна и просроченных заявках.

Более подробная информация о настройке SLA в Кайтене — в базе знаний.

Шаг 7. Подготовьте шаблонные ответы

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

Для начала подготовьте шаблоны для самых частых ситуаций:

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

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

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

Шаг 8. Соберите базу знаний

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

В базе знаний можно хранить:

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

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

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

Шаг 9. Запустите пилот

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

Для пилота подойдет процесс, который легко проверить и доработать:

• заявки на доступы;
• хозяйственные заявки;
• HR-запросы;
• клиентские обращения после покупки.

После пилота исправьте настройки и только затем масштабируйте Service Desk на другие команды и типы обращений. Так вы не перенесете ошибки тестового процесса на всю компанию. 

Шаг 10. Соберите обратную связь и развивайте процесс

После запуска регулярно проверяйте, как работает процесс: смотрите аналитику и собирайте обратную связь у исполнителей и заявителей.

Полезные вопросы участникам процесса:

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

После анализа обновите формы, категории, SLA, шаблоны, базу знаний и правила распределения заявок. Так Service Desk будет подстраиваться под реальную работу команды, а не фиксировать процесс, который быстро устаревает.

Как адаптировать Service Desk под разные задачи 

Есть миф, что Service Desk могут применять только IT-команды, но на самом деле систему можно адаптировать под разные задачи:

Если в отделе есть регулярный поток запросов, его можно и нужно выстраивать — независимо от сферы работы департамента. 

Service Desk: что это и как внедрить. Кратко

Service Desk — это не просто система учета заявок. Это способ сделать сервисные процессы в компании управляемыми.

Ключевые вещи:

• начинать нужно не с инструмента, а с целей, категорий заявок, цикла жизни обращений и правил их обработки;
• Service Desk помогает не только быстрее закрывать обращения, но и видеть повторяющиеся проблемы и узкие места. В этом ему помогает встроенная аналитика;
• для разных отделов сценарии будут отличаться, но базовая логика одна: единый вход, категории, статусы, ответственные, сроки, база знаний и аналитика;
• протестировать работу в системе можно на небольшом отделе или процессе, чтобы исправить узкие места;
• управляемость появляется там, где есть прозрачность и данные.

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