Преобразовать разговор в тикет
Используйте тикет, когда работа должна продолжаться за пределами живого разговора или когда ей требуются явный тип, статус, ответственный или путь решения. Тикет дополняет хронологию разговора; он не должен дублироват...
Используйте тикет, когда работа должна продолжаться за пределами живого разговора или когда ей требуются явный тип, статус, ответственный или путь решения. Тикет дополняет хронологию разговора; он не должен дублировать каждое сообщение клиента или заменять необходимый ответ.
В этом руководстве объясняется, когда создавать тикет, как фиксировать пригодный для действий контекст, как основной тикет отображается в Inbox и как действия send-and-close или действия со статусом могут влиять и на тикет, и на состояние передачи.
Как это вписывается в Humind
Inbox - это операционная запись разговоров с клиентами. Он объединяет историю сообщений, контекст покупателя и товара, внутреннее взаимодействие, состояние передачи человеку, теги и тикеты. Ответы клиентов и внутренние заметки намеренно имеют разную видимость.
Последовательный командный процесс важнее любого отдельного фильтра. Договоритесь, когда брать разговор на себя, когда оставлять внутреннюю заметку, когда создавать тикет и когда возвращать разговор ИИ, чтобы зона ответственности оставалась понятной каждому оператору.
Перед началом
Доступ: Для работы из разговора требуется доступ к Inbox. Действия чтения или записи тикетов зависят от прав и конфигурации тикетинга в компании; настройки провайдера контролируются администраторами.
- Убедитесь, что тикетинг включен и что нужный тип тикета и нужные статусы существуют.
- Прочитайте разговор, внутренние заметки, теги и существующий основной тикет.
- Уточните, использует ли команда тикетинг Humind или протестированного внешнего провайдера.
Пошаговый рабочий процесс
Решите, нужен ли тикет
Создавайте тикет для работы, которой требуется отслеживаемое последующее действие, участие другой команды, структурированный жизненный цикл или решение после того, как покупатель уйдет. Оставляйте простой вопрос в разговоре, если оператор может ответить на него и завершить его сразу.
Сначала проверьте, существует ли уже основной тикет клиента. Несколько тикетов по одной проблеме создают неясность со статусом и ответственностью.
Создайте пригодный для действий контекст тикета
Используйте действие тикета в разговоре и выберите соответствующий тип или начальный статус, предлагаемый конфигурацией компании. Суммируйте запрос, подтвержденные факты, уже выполненную работу, ожидание клиента и следующее действие.
Ссылайтесь на контекст разговора или опирайтесь на него, а не копируйте ненужные персональные данные в произвольный текст. Используйте внутренние заметки для фиксации рассуждений, полезных для коллег, которым не место в поле тикета.
Поддерживайте статус и ответственность
Проверьте основной тикет в деталях разговора. Обновляйте свойства по мере изменения расследования и последовательно используйте категории статусов компании. Humind сопоставляет настроенные статусы с категориями, такими как категория resolved, для сценария отправки.
Тикет, оставленный открытым без владельца или следующего действия, не является надежной передачей. Используйте упоминания или процесс назначения в команде, когда действовать должен другой человек.
Отвечайте и закрывайте осознанно
Когда существует основной тикет, меню отправки ответа может показывать действие send-and-close. Это действие отправляет ответ клиенту, переводит тикет в настроенный статус категории resolved и возвращает разговор к ИИ. Другие действия в меню отправки могут обновлять состояние тикета.
Перед нажатием прочитайте текущую метку меню и статус. Закрытие тикета и возврат к ИИ - связанные, но разные результаты, которые происходят вместе в этом сценарии.
Проверьте результат для клиента и оператора
Подтвердите, что покупатель получил нужное сообщение, что тикет показывает правильное состояние, что ответственность за ветку указана верно и что внутренние заметки остаются приватными. Снова откройте или обновите тикет в соответствии с политикой, если поступит новая информация.
Для внешних провайдеров проверьте соответствующую запись у провайдера во время первоначального запуска. Не предполагайте, что переключатель учетных данных гарантирует сквозную синхронизацию тикетов.
Права доступа и важные оговорки
- Типы тикетов и названия статусов задаются конфигурацией компании; используйте текущие метки, показанные в рабочем пространстве.
- Send-and-close может изменить и состояние тикета, и состояние разговора одним действием.
- Поведение внешних Gorgias или Zendesk должно настраиваться и тестироваться отдельно.
- Тикет - это внутренняя операционная работа, и сам по себе он не уведомляет покупателя о ходе выполнения.
Проверьте результат
Используйте этот контрольный список, прежде чем считать работу завершенной:
- Тикет отражает реальную потребность в последующем действии и не дублирует существующий основной тикет.
- Сводка, тип, состояние, владелец и следующее действие понятны другому коллеге.
- Итоговый ответ клиенту, статус тикета и ответственность ИИ или человека соответствуют ожидаемому результату.
- Записи внешнего провайдера проверены, если этот провайдер является частью рабочего процесса.
Устранение неполадок
Действия с тикетом недоступны
Убедитесь, что тикетинг включен, что у компании есть типы тикетов и статусы и что у вашей роли есть необходимый доступ. Попросите администратора проверить конфигурацию провайдера и Inbox.
Send-and-close использовал неправильный статус
Проверьте, какой настроенный статус сопоставлен с категорией resolved. Исправьте состояние тикета и попросите администратора исправить конфигурацию статусов, прежде чем операторы снова будут использовать комбинированное действие.
Внешний провайдер не получил тикет
Проверьте выбранного провайдера, учетные данные администратора, контекст компании и собственную запись провайдера. Считайте интеграцию неподтвержденной, пока полный тест не завершится успешно.