Как распределять заявки в Naumen Service Desk: базовые и кастомные способы
Одна из ключевых целей внедрения системы Service Desk — сделать так, чтобы техподдержка как можно быстрее выполняла заявки пользователей. Для этого нужно, чтобы обращения попадали четко по назначению — именно к тем специалистам, которые их решат. В Naumen Service Desk можно выбрать, по какому принципу будут распределяться заявки, и гибко настраивать их путь. Эти принципы подходят как для внутренней техподдержки, так и для работы с внешними клиентами.
Важно. Перед тем, как определить оптимальный алгоритм распределения, потребуется составить каталог услуг сервисного подразделения. Именно это служит отправной точкой в любой работе с заявками.
1. По услуге
Самый простой и очевидный принцип: заявка напрямую попадает в определенную сервисную службу, которая поддерживает нужную услугу. От пользователя до исполнителя всего шаг.
Подходит компаниям:
- локализованным по одному адресу — все заявители и специалисты поддержки находятся на одной территории;
- с внешними клиентами в рамках одного города;
- с простыми
бизнес-процессами , без сложной иерархии — например, за все, что связано сИТ-системами , оборудованием и оргтехникой, отвечает один отдел. Каждый его специалист способен решить любой вопрос в этой сфере.
Допустим, у сотрудника на рабочем ноутбуке не работает почта. Он оставляет заявку через
За сервисными службами закрепляется свой набор услуг, поэтому ИТ-система сама «понимает», куда отправить заявку
2. По правилу
Правило — это определенный алгоритм, по которому Naumen Service Desk распределяет заявки. Оно может включать и учитывать множество параметров. Эта гибкость позволяет настраивать
Местоположение — базовый параметр
Этот параметр по умолчанию заложен в коробочном решении Naumen Service Desk. Система определяет «адрес», из которого пришла заявка, и отправляет ее в сервисное подразделение нужного города.
Подходит компаниям:
- с филиалами, региональными офисами, представительствами в разных городах. В каждой точке свои сервисные подразделения;
- с внешними клиентами в разных географических точках, в каждой из которых есть собственные сервисные подразделения.
Допустим, у компании есть офисы в Москве и Хабаровске со своими командами поддержки. Это не только разная география, но и разные часовые пояса. Например, у сотрудника в хабаровском офисе нет доступа к локальному серверу. Он пишет запрос в техподдержку. Заявку получит именно то
При распределении заявок ИТ-система может учитывать не только местоположение, откуда поступило обращение, но и часовой пояс, по которому обслуживается пользователь
В случае с внешним клиентом — представим, что компания продает, сдает в аренду и обслуживает холодильное оборудование. Для клиентов из разных городов действуют региональные сервисные подразделения. Например, клиент отправляет заявку в поддержку, что на его оборудовании не работает терморегулятор. Она автоматически попадет в сервисную команду, закрепленную именно за его городом, и исполнителю, который отвечает за терморегуляторы.
Возможные параметры при кастомных сценариях
В правило можно включить любое число параметров, которые проложат заявке путь к нужному исполнителю: от одного до более сотни. Алгоритм может учитывать:
- вид техники, по которой регистрируется запрос. Например, ноутбук, принтер, сканер, гарнитура, если речь о предоставлении услуги сотрудникам компании. Или тип оборудования на обслуживании, если сервис предоставляется внешним клиентам;
- тип обращения. Например, инцидент — мешает рабочему процессу, нужно разобраться как можно скорее; запрос на обслуживание — не требует немедленного решения; консультация — активные действия здесь не нужны, пользователь запрашивает
какую-то дополнительную информацию; - тип заявителя. Например, можно выделить
VIP-группу , и запросы от ее участников будут выполняться в первую очередь.
Это лишь некоторые из востребованных параметров, по которым распределяются заявки. Правило может включать их все или только некоторые. Все зависит от
Подходит компаниям:
- с филиалами, региональными офисами, представительствами в разных городах. И в каждой точке свои сервисные подразделения;
- с крупным по численности сервисным подразделением, сотрудники которого различаются по специализациям и компетенциям;
- с внешними клиентами в разных географических точках, за каждой из которых закреплено свое сервисное подразделение;
- с каталогом услуг, который включает сложные и распределенные процессы.
Допустим, у директора офиса в Перми сломался принтер. Он обращается в техподдержку. По названным выше параметрам его заявка сразу попадет к специалисту по обслуживанию принтеров именно пермского сервисного подразделения. И специалист, учитывая
В случае с внешним клиентом — представим, что сервисная компания обслуживает банкоматы. В одном из них у клиента застряла банковская карта. Он звонит по номеру, указанному на банкомате и сообщает о проблеме. Это инцидент
Учет VIP-статуса пользователя при обработке обращений позволяет по-разному настраивать сценарии обслуживания для техподдержки
Роль — гибкий параметр
Этот параметр также можно использовать в правиле при кастомизации. В разных компаниях свои особенности внедрения Service Desk. Бывает, что в правиле нужно заложить более гибкую возможность назначать ответственного за заявку. Например, это не
Например, если роль ответственного прописана как «руководитель пользователя», то система отталкивается от должности заявителя. Если роль «владелец оборудования», то от типа оборудования в заявке. Если роль «территориальный менеджер», то система берет сведения из адреса пользователя.
Подходит компаниям со сложной иерархией и разделенной ответственностью за выполнение заявок как сотрудников, так и внешних клиентов.
Допустим, сотрудник пишет запрос в поддержку на новый рабочий ноутбук. По таким заявкам ответственный назначается по роли «руководитель пользователя». Обращение попадает к руководителю заявителя, он его верифицирует, добавляет необходимые сведения, например, прикладывает служебную записку, и затем передает на исполнение в нужное подразделение.
Кастомные настройки помогают учитывать специфические параметры, например, роль пользователя в ИТ-системе, что будет определять дальнейший маршрут заявки
В случае с внешним клиентом — представим, что аутсорсинговая компания обслуживает
3. По ответственности
Базовый подход, заложенный в Naumen Service Desk, подразумевает, что назначенный по заявке ответственный не меняется. Даже если для решения нужно задействовать других специалистов или подразделения.
Есть и другой подход, который можно реализовать в Naumen Service Desk с помощью настройки. Если заявка подразумевает участие нескольких отделов, то ответственность передается между ними по цепочке, в зависимости от того, кто в данный момент по ней работает.
Допустим, в
По базовому подходу Naumen Service Desk
Если в решение заявки вовлекаются разные подразделения, то можно настроить автоматическую цепочку передачи ответственности
4. На стороне исполнителя
Если в подразделение идет поток заявок, и они попадают в очередь, то появляется необходимость в дополнительном внутреннем распределении. Это можно делать вручную. Например, руководитель или другой ответственный сотрудник распределяет заявки по исполнителям, исходя из собственной оценки ситуации.
В Naumen Service Desk в рамках кастомного проекта можно реализовать автоматическое распределение новых заявок по самым разным принципам:
- по очереди;
- более свободному специалисту;
- специалисту, на котором заявки с меньшим весом: типом, приоритетом, трудоемкостью;
- другим параметрам, которые важны в конкретной компании.
Naumen Service Desk — гибкая система, в которой можно настроить распределение заявок в техподдержку по разным принципам и множеству параметров. Главное — понимать иерархию,