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