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