ШІ для підтримки клієнтів: актуальні відповіді

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

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

Почніть із запису про зміни, а не з переписування відповіді

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

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

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

Відстежте змінену відповідь у всіх її джерелах

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

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

• Відповіді у відкритому розділі поширених запитань: перевірте основну відповідь і пов’язані запитання, у яких згадується той самий процес.
• Внутрішня база знань: оновіть інструкції щодо винятків і ескалації, а також стандартну відповідь.
• Сторінки вебсайту: перевірте довідкові матеріали та інші сторінки, де повторюється стара інструкція.
• Шаблони відповідей: замініть збережені формулювання, які ваша команда все ще може надсилати вручну.
• Історичні розмови: визначте старі приклади, які потребують додаткової перевірки, якщо вони використовуються для підготовки нового чернеткового варіанта.

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

Відокремлюйте загальнодоступні відповіді від внутрішніх інструкцій щодо опрацювання

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

Це розрізнення має значення в Deskhero, оскільки набір знань, доступний для перевірених чернеток, відрізняється від набору знань, який використовується для автоматичних відповідей. Чернетки відповідей Deskhero спираються на знання робочого простору, зокрема на вміст розділу поширених запитань, внутрішню базу знань, проскановані сторінки вебсайту та попередні тікети. Користувачі перевіряють і надсилають ці чернетки. Чат-бот і автоматичні відповіді електронною поштою, які вмикаються за бажанням, відповідають лише на основі схвалених загальнодоступних відповідей у розділі поширених запитань; увімкнути їх можна після схвалення 100 відповідей у цьому розділі. Запитання, що виходять за межі цих знань, передаються людині.

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

Перепишіть відповідь, не приховуючи виняток

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

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

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

Перевірте невеликий набір запитань перед випуском

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

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

Використовуйте тестове середовище або інший підтримуваний метод перевірки, який не надсилає експериментальні відповіді клієнтам. Перевірте кожен фактично використовуваний шлях відповіді. Правильна перевірена чернетка не доводить, що окремий шлях автоматичної відповіді використовує ті самі джерела.

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

Чітко зафіксуйте рішення щодо випуску

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

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

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

Завершіть оновлення перевіркою реальних розмов

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

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

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