Сообщение «не работает монитор» в общем чате ещё не стало заявкой. Его могут прочитать несколько человек, но никто не возьмёт ответственность. Сотрудник не знает, приняли ли просьбу, а руководитель не видит, где она остановилась.
Чтобы сообщение не потерялось, нужен минимальный управляемый маршрут: собрать обязательные сведения, зарегистрировать просьбу, назначить владельца, показывать правдивый статус и зафиксировать результат. Начать лучше с одного повторяющегося типа обращений, а не пытаться сразу перенести в бота все внутренние процессы.
Какую просьбу выбрать первой
Возьмите обращение, для которого команда уже понимает правила и круг ответственных. Подойдёт запрос о неисправном рабочем оборудовании: сотрудник описывает проблему, указывает рабочее место, при необходимости прикладывает фотографию, а внутренняя служба принимает задачу.
До автоматизации ответьте на пять вопросов:
- Кто вправе подать такую заявку?
- Какие сведения нужны, чтобы начать работу?
- Кто отвечает за назначение исполнителя?
- Какие состояния проходит заявка?
- По какому правилу работа считается завершённой?
Если ответы зависят от конкретного случая, сначала опишите эти развилки. Бот не устраняет неопределённость в процессе: он лишь применяет заданные правила и показывает, когда требуется решение человека.
Какие поля собирать и кому их показывать
Набор обязательных полей определяет владелец процесса. Не стоит требовать сведения «на всякий случай»: каждое поле должно помогать определить маршрут, выполнить работу или подтвердить результат.
| Поле | Зачем оно нужно | Что проверить |
|---|---|---|
| Тип просьбы | Выбрать маршрут и ответственную очередь | Список категорий понятен сотрудникам |
| Описание | Передать суть проблемы исполнителю | Текста достаточно для первого действия или уточнения |
| Место или идентификатор объекта | Понять, где возникла проблема и с чем работать | Формат соответствует конкретному процессу |
| Вложения | Передать фотографию или документ, если они нужны | Файл допустим и доступен только нужным ролям |
| Заявитель | Сообщать изменения и задавать вопросы | Сотрудник определён по разрешённым данным |
| Ответственный | Закрепить владельца следующего действия | Есть основной исполнитель, очередь или заместитель |
| Статус | Показать фактическое состояние | Название не создаёт ложного впечатления об успехе |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Пароли, коды доступа, API-ключи и другие секреты нельзя просить в заявке или приводить в подсказке как пример. Если для работы нужен доступ, его передают согласованным безопасным способом вне текста обращения.
Доступ к содержимому заявки зависит от роли. Заявитель может видеть свою просьбу и её статус, исполнитель — сведения, необходимые для работы, руководитель процесса — очередь и историю изменений. Точный состав ролей нужно закрепить до подключения рабочих данных. Бот не должен расширять доступ только потому, что сотрудник знает номер чужой заявки.
Как устроить маршрут и статусы
Для первого сценария достаточно короткой последовательности:
- Черновик. Бот собирает сведения, но заявка ещё не передана в работу.
- Зарегистрировано. Система сохранила запись и вернула идентификатор.
- Назначено. У заявки появился ответственный или определённая очередь.
- Уточнение или работа. Исполнитель запросил недостающие данные либо выполняет задачу.
- Результат предоставлен. Исполнитель описал выполненное действие или другой итог.
- Закрыто. Выполнено правило подтверждения, принятое для этого процесса.
Уточнение не равно отказу. Сотрудник должен увидеть, какого сведения не хватает и как его добавить. После ответа заявка продолжает прежний маршрут, а не создаётся заново.
Статус должен описывать факт. Если запись не сохранилась, нельзя отвечать «заявка принята». Если исполнитель не назначен, нельзя показывать «в работе». В такой ситуации система оставляет заявку в видимой очереди, сообщает о задержке владельцу процесса и показывает заявителю честное состояние.
Заранее решите, что происходит при отсутствии основного исполнителя. Это может быть общая очередь, назначенный заместитель или ручной выбор руководителя. Главное — не скрывать зависшую просьбу за нейтральным уведомлением.
Учебный пример: не работает монитор
Условная заявка, не реальный инцидент.
Сотрудник пишет боту: «Не работает монитор». По этому сообщению неизвестны рабочее место и характер неисправности. Бот спрашивает, где находится оборудование и что именно наблюдает сотрудник. После получения обязательных данных он пытается зарегистрировать запрос и сообщает фактический статус.
Бот не объявляет монитор исправленным, не придумывает срок ремонта и не предлагает сотруднику разбирать оборудование. Его задача на этом этапе — получить достаточные сведения, сохранить обращение и передать его по установленному маршруту.
| Ситуация | Действие системы |
|---|---|
| Не указано рабочее место | Запросить недостающее поле до регистрации или направить неполную заявку по заранее принятому правилу |
| Исполнитель не назначен | Оставить заявку в очереди ответственного и показать её фактический статус |
| Сотрудник повторил сообщение | Найти текущую заявку по согласованным признакам и связать повтор с ней |
| Исполнитель предоставил результат | Сохранить результат и запросить подтверждение, если оно предусмотрено процессом |
| Запись не сохранилась | Не сообщать об успешной регистрации; зафиксировать ошибку и дальнейшее действие |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для распознавания повтора одного совпадения текста может быть недостаточно. Правило может учитывать заявителя, тип просьбы, объект и наличие незакрытой заявки. Его проверяют на реальных обезличенных примерах: новый похожий запрос нельзя ошибочно присоединить к старому, а повторная отправка не должна создавать лишнюю запись.
Что показывать сотруднику
После отправки сотруднику нужны не технические подробности, а ответы на практические вопросы:
- зарегистрирована ли заявка и как её найти;
- кому она передана или в какой очереди находится;
- что требуется от заявителя сейчас;
- какой результат зафиксировал исполнитель;
- почему заявка ещё не закрыта.
Уведомление само по себе не завершает работу. Закрытие происходит по правилу процесса: после подтверждения заявителя, проверки ответственным или другого заранее установленного события. Если ответа заявителя нет, нужен отдельный порядок, а не скрытое автоматическое закрытие.
Комментарии, уточнения, назначения и смены статуса сохраняют в истории. Тогда руководитель может восстановить путь заявки, а сотруднику не приходится пересказывать прежнюю переписку новому исполнителю.
Когда нужен бот, интеграция или ИИ-агент
Бот — это интерфейс, через который сотрудник отправляет просьбу и узнаёт статус. Обычная интеграция переносит данные между чатом и рабочей системой по фиксированным правилам. Если категории, поля и маршрут заранее известны, такого решения часто достаточно.
ИИ-агент нужен не для самого факта регистрации, а для участков, где система выбирает следующий разрешённый шаг: разбирает свободное описание, решает, какое уточнение задать, или обращается к разным источникам в зависимости от запроса. Его полномочия всё равно ограничивают: агент не должен самовольно открывать чужие заявки, менять правила маршрута или объявлять работу выполненной.
Switch On AI может помочь спроектировать такой сценарий в рамках услуги разработки ИИ-агентов. На разборе стоит сначала проверить, нужен ли агентный выбор, или задачу надёжнее решат бот с известными полями и обычная интеграция. Прототип ключевого сценария помогает согласовать логику, но не считается полноценным внедрением и не подтверждает работу всех подключений.
Как принять результат
Приёмка должна охватывать не только правильно заполненную заявку. Проверьте весь маршрут на обычных и проблемных ситуациях.
| Проверка | Ожидаемое поведение |
|---|---|
| Не хватает обязательного поля | Бот называет конкретное поле и не выдумывает значение |
| Выбрана неверная категория | Заявку можно перенаправить без потери описания и истории |
| Нет доступного исполнителя | Просьба остаётся в видимой очереди, владелец процесса получает сигнал |
| Сообщение пришло повторно | Система применяет правило повтора и не создаёт лишнюю заявку |
| Пользователь запрашивает чужую заявку | Содержимое не раскрывается без требуемой роли |
| Рабочая система не сохранила запись | Пользователь не получает ложного подтверждения успеха |
| Результат предоставлен | Заявка закрывается только по установленному правилу |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для каждой проверки сохраните исходное сообщение, ожидаемое действие и фактический результат. Допуск формулируется через наблюдаемое поведение: заявку можно проследить, статус соответствует факту, сообщение не потеряно, дубль не создан, доступ не расширен.
Универсальный срок ответа для такого процесса задать нельзя. Очередь, роли, порядок подтверждения и допустимое время определяет конкретная внутренняя служба. Эти условия фиксируют в требованиях до разработки и затем проверяют на приёмке.
С чего начать обсуждение
Выберите один тип внутренних заявок и подготовьте несколько обезличенных примеров: обычное обращение, сообщение без обязательного поля, повтор и случай без доступного исполнителя. Также укажите систему, где должна храниться запись, роли пользователей и правило закрытия.
Расскажите Switch On AI о своём процессе. Вместе опишем поля, маршрут, ответственных и проверку результата до подключения команды и рабочих данных.
Вопросы по этой задаче
Кто назначает исполнителя внутренней заявки?
Это определяет владелец процесса. Исполнителя может выбрать фиксированное правило, ответственная очередь или руководитель. Если назначение не состоялось, заявка должна остаться видимой и получить правдивый статус.
Что делать, если сотрудник повторно отправил ту же просьбу?
Система применяет заранее согласованные признаки повтора и связывает сообщение с текущей заявкой, если это действительно тот же запрос. Новый похожий случай нельзя автоматически считать дублем только из-за совпадения текста.
Кто может видеть внутреннюю заявку?
Содержимое показывают только ролям, которым оно нужно для работы: заявителю, назначенному исполнителю и согласованным владельцам процесса. Знание номера заявки само по себе не должно давать доступ.
Когда внутреннюю заявку можно закрыть?
После выполнения установленного правила процесса: например, подтверждения заявителя или проверки ответственным. Отправленное уведомление и предоставленный результат сами по себе не всегда означают закрытие.