Обработка обращений: от приёма до закрытия и оценки

Приём обращения: почтовый ящик и API

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

Что проверяется на входе по API

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

Адрес почтового ящика, параметры подключения и значение токена задаются при развёртывании в вашем контуре.

Регистрация и первичная обработка

У обращения двенадцать статусов и двадцать пять объявленных переходов. Это значит, что путь «из статуса в статус» перечислен заранее: шага мимо модели в карточке нет, и вопрос «а можно ли отсюда сразу закрыть» решается не переговорами, а моделью.

Приём в работу и назначение исполнителя

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

Три линии поддержки и эскалация подрядчику

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

Пять шагов маршрута — по одному экрану на шаг

Возврат обращения и повторная маршрутизация

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

Отдельные жизненные циклы: обращения, инциденты, ЗНО, процессы, поставщики

Разные сущности не тянут по одному маршруту. В продукте объявлено семь статусных моделей, и у каждой свой набор статусов и переходов — а право на переход проверяется на своей модели, а не «на системе вообще».

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

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

Карточка обращения: описание, история изменений, чат

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

Состав вкладок, колонок и статусов — как в продукте: «Описание», «История изменений» и чат по обращению объявлены вкладками карточки, а порядок вкладок сотрудник меняет под себя. Номера, фамилии и даты — пример заполнения.

Решение, закрытие и оценка пользователем

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

Что это даёт ИТ-директору

Служба поддержки для ИТ-директора — это ещё один контур с учётными записями, правами и собственным способом отдавать данные наружу. Вот что в этом контуре определено заранее.

• Границы блока. Приём обращений, маршрут по линиям, эскалация подрядчику, карточка с журналом переходов и оценка. Реестры объектов, процессов и поставщиков ведутся здесь же и связываются с обращением на карточке.
• Предсказуемое поведение маршрута. Переходы объявлены заранее и не собираются на лету: девятнадцать статусов инцидента и двадцать пять переходов — это фиксированный контракт, по которому пишется интеграция и строится отчётность.
• Права на уровне перехода. Статусные модели зарегистрированы как самостоятельные охраняемые типы с действиями просмотр, изменение и выполнение действия / смена статуса. Право видеть карточку и право двигать её по маршруту выдаются отдельно.
• Журнал событий. Переходы пишутся в сквозной журнал с экраном просмотра на карточке; отдельно ведутся журнал безопасности и журнал работы пользователей.
• Два входа для смежных систем. Почтовый ящик службы и HTTP-запрос обращений по позиции каталога активов с проверкой токена.

Права доступа и аудит · Импорт и интеграции · Требования к контуру