Перейти до основного вмісту

Добрик показує практичні знання про підтримку Процеси підтримки · · 8 хв читання · Матеріал DobroDesk

Як спроєктувати запис на зустріч із передачею людині

Практичний підхід до поєднання запису із сайту, контексту клієнта та шляху до працівника, коли автоматичний сценарій не може завершити запит.

Як спроєктувати запис на зустріч із передачею людині

Запис на зустріч працює краще, коли є частиною шляху підтримки, а не формою, прикріпленою до бульбашки чату. Клієнту потрібен зрозумілий наступний крок, а команді — запит, контекст і результат в одній розмові.

Визначте межі запису до збору даних

Спочатку визначте межі процесу. Налаштована дія запису може зібрати потрібні команді поля та використати перевірене джерело доступності. DobroDesk не має створювати враження, що сам вигадує доступні години або що провайдер запису підключений у кожному робочому просторі.

Запитуйте лише відомості, які змінюють запис. Залежно від послуги це можуть бути ім'я, спосіб зв'язку, тип послуги та коротка причина звернення. Поясніть потребу в полі, а чутливі деталі залиште для розмови з працівником, якщо вони не потрібні для вибору часу.

Зберігайте час, часовий пояс і контекст разом

Показуйте дату й час у часовому поясі клієнта та робіть часовий пояс видимим до підтвердження. Зберігайте обрану послугу, час і контактні дані разом із розмовою, щоб працівнику не довелося просити клієнта починати спочатку.

Сценарій запису у віджеті сайту: клієнт обирає послугу та починає запит, перш ніж команда його опрацює.
Сценарій запису у віджеті сайту: клієнт обирає послугу та починає запит, перш ніж команда його опрацює.

Підтвердження — корисна контрольна точка, але не кінець підтримки. У розмові має залишитися результат запису або явна помилка, а клієнт повинен мати спосіб поставити уточнювальне питання. Команда бачить той самий контекст, якщо клієнт змінює запит.

Зробіть винятки окремим шляхом передачі

Передбачте передачу для випадків, які дія запису не може безпечно вирішити. Особливе прохання, відсутність зручного часу, помилка провайдера чи питання про оплату мають потрапити до відповідального працівника разом зі зібраним контекстом. Не відправляйте клієнта до порожньої форми або нового каналу без пояснення.

Перевіряйте весь шлях, а не лише успішний сценарій. Спробуйте звичайний запис, зміну часового поясу, недоступну дату, повторний запит і прохання поговорити з людиною. Перевірте, що бачить клієнт, що отримує скринька та яка наступна дія очевидна після кожного результату.

Вимірюйте завершення та роботу після нього

Вимірюйте завершені записи разом із якістю передачі. Дивіться на завершені записи, покинуті кроки, звернення без відповідального та причини, через які клієнтам знадобився працівник. Висока частка завершень може приховувати незрозуміле підтвердження або чергу, яка не справляється з винятками.

Крок перевірки у сценарії запису: перед підтвердженням або передачею видно обрану послугу, час і дані клієнта.
Крок перевірки у сценарії запису: перед підтвердженням або передачею видно обрану послугу, час і дані клієнта.

Тримайте автоматичну дію та шлях до людини в одній моделі підтримки. Перевіряйте доступність і тексти після зміни провайдера чи розкладу, оновлюйте публічні інструкції та залишайте контакт із командою легко помітним. Надійна розмова завершується автоматично, коли це доречно, і залишається корисною, коли це неможливо.

Перевірте віджет сайту до запуску

Перевірте вигляд віджета, вітальне повідомлення та передачу розмови до того, як ним скористаються клієнти.

Ще почитати

Суміжні матеріали для команд, які оцінюють процес підтримки.