Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Управління знаннями в Dynamics 365: база знань для швидкої та узгодженої підтримки (ШІ-дубляж)

Transcript

Управління знаннями в Dynamics 365: база знань для швидкої та узгодженої підтримки (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
• 0:07
  Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живі сесії, реальні демонстрації та практичні знання від MVP та галузевих експертів з усього світу.
• 0:18
  Жодних загальних слайдів, жодних безкінічних модних слів.
• 0:22
  Ми вирішуємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви IT-фахівець, розробник або бізнес-лідер, для вас знайдуться підходящі сесії.
• 0:35
  Протягом 10 повних днів ви можете дослідити багато технологій та приєднатися до глобальної спільноти.
• 0:40
  Дивіться наживо та приносте практичні ідеї у свою організацію.
• 0:44
  Січень 2027 року, 10 днів, одна спільнота Microsoft. Реєстрація вже відкрита.
• 0:51
  Забронюйте своє місце сьогодні.
• 0:55
  CM365Con.net
• 0:57
  Приєднуйтесь зараз на M365Con.net і побачимось у січні.
• 1:05
  Клієнт ставить просте запитання, але агент має шукати відповідь у старих листах, спільних папках та чиїхось таблицях, поки клієнт чекає на лінії.
• 1:12
  Ось тут на допомогу приходить управління знаннями Dynamics 365.
• 1:15
  Уявіть, це як спільну картотеку для вашої команди підтримки.
• 1:18
  Затверджені відповіді знаходяться в одному місці, а не лише в головах людей.
• 1:21
  Це центральна бібліотека, де кожна стаття перевіряється та затверджується перед тим, як потрапити до команди.
• 1:26
  Я Мірко Петерс з M365, і це Microsoft Knowledge Nugget.
• 1:30
  Ви побачите, як статті «Пошук», «Доступ», «Зворотний зв'язок» та «Щоденна підтримка» працюють разом.
• 1:35
  Але спершу дозвольте показати вам реальну проблему, яку це вирішує.
• 1:38
  Вона масштабніша, ніж ви можете собі уявити.
• 1:40
  Чому командам потрібна спільна база знань?
• 1:43
  Уявіть, новий агент підтримки починає роботу в понеділок.
• 1:46
  Вже у вівторок, після всього двох днів, вони відповідають на питання про повернення, рахунки, доступ до акаунтів та правила, на вивчення яких у досвідченої команди пішли роки.
• 1:53
  Вони можуть попросити допомоги у колеги, але колега може бути зайнятий.
• 1:56
  І якщо вони все ж переривають, колега втрачає фокус на своїй власній роботі.
• 2:00
  Тож вони шукають у старих листах, але лист дворічної давни не може містити відповідь, яка вже неправильна через зміну політики.
• 2:05
  Так знання підтримки накопичуються без жодного планування.
• 2:08
  Це безладно і ненадійно.
• 2:10
  Хтось веде нотатки в документи, інший зберігає корисні повідомлення у папці поштової скриньки,
• 2:14
  хтось інший просто знає, бо вже вирішував таку саму проблему клієнта 50 разів раніше.
• 2:18
  Відповідь існує, але її пошук забирає дорогоцінний час.
• 2:21
  І цей час накопичується для всієї команди.
• 2:23
  Поки агент шукає, розчарування клієнта зростає.
• 2:26
  Клієнти помічають цю затримку негайно.
• 2:28
  Кожна секунда тиші здається вічністю.
• 2:30
  Вони чують, як хтось друкує, а потім, чи можу я перевести вас у режим очікування на хвилину.
• 2:34
  Або гірше, вони чують припущення, бо агент хоче допомогти, але не має перед очима перевіреної відповіді.
• 2:39
  Цього ніхто не хоче.
• 2:40
  Річ у тім, що сучасного клієнта не хвилює, як організована ваша внутрішня робота.
• 2:43
  Він просто хоче отримувати послідовну відповідь щоразу.
• 2:46
  Обслуговування клієнтів відбувається швидко, і люди очікують однакових відповідей, незалежно від того,
• 2:49
  телефонують вони, пишуть на пошту, вчат чи відвідують ваш сайт.
• 2:51
  Якщо один агент пояснює політику повернення товарів по одному, а інший по іншому,
• 2:55
  клієнт не бачить у цьому внутрішню проблему з базою знань.
• 2:58
  Він бачить компанію, яка не може дійти згоди сама з собою.
• 3:02
  Спільна база знань надає команді одне перевірене джерело інформації.
• 3:05
  Тож замість покладатися на пам'ять, агенти знаходять вказівки, які бізнес уже перевірив і затвердив.
• 3:09
  Це означає, що відповідь залишається незмінною, навіть якщо з клієнтом працюють різні люди.
• 3:13
  Це допомагає і досвідченим агентам.
• 3:15
  Замисліться.
• 3:16
  Якщо ви експерт із повернень, ви відповідаєте на одне й те саме запитання тричі на день.
• 3:20
  Це марнування вашого досвіду.
• 3:21
  Коли одне й те саме запитання виникає щодня, експерт може витрачати години, повторюючи одну відповідь.
• 3:25
  Маючи якісну статтю, він пише інструкцію один раз, оновлює її, коли щось змінюється,
• 3:28
  і дозволяє всій команді користуватися нею.
• 3:30
  Фокус зміщується з повторення відповідей на їх покращення.
• 3:33
  Ви також зможете чіткіше помічати закономірності.
• 3:35
  Якщо 10 клієнтів запитують, як змінити адресу доставки, це може означати, що інструкції на сайті незрозумілі.
• 3:40
  Якщо агенти постійно шукають правило виставлення рахунків і не можуть знайти, команда розуміє, що стаття відсутня.
• 3:44
  Повторювані запитання – це не просто шум.
• 3:47
  Вони показують, де клієнти та агенти стикаються з труднощами і дають вам практичний перелік тем, які потребують чітких інструкцій.
• 3:52
  База знань стає робочою пам'яттю компанії, зберігаючи корисний досвід, доступним, коли хтось іде у відпустку, змінює роботу, приєднується до команди чи просто забуває деталь під час напруженого дня.
• 4:01
  Це не означає, що кожна відповідь має ставати довгим документом.
• 4:05
  Насправді, довгі документи часто створюють ту саму проблему знову, бо люди все одно не можуть знайти в них потрібне речення чи крок.
• 4:11
  Якісні знання дають людям пряму відповідь, чіткі кроки та достатньо контексту для впевненого вирішення ситуації.
• 4:16
  Тож, управління знаннями в Dynamics 365 впроваджує цю спільну пам'ять у робоче середовище служби підтримки, де ваші спеціалісти виконують щоденну роботу.
• 4:24
  Це не окремий інструмент, який треба вивчати з нуля.
• 4:26
  Це інтегровано в інструменти, якими агенти вже користуються щодня.
• 4:29
  Що насправді являє собою управління знаннями в Dynamics 365?
• 4:33
  Отже, що насправді дає вам управління знаннями в Dynamics 365?
• 4:36
  Ось найпростіше визначення.
• 4:37
  Це надає вашій команді єдине місце для створення, впорядкування, перевірки, пошуку та вдосконалення довідкових статей безпосередньо під час роботи з клієнтами.
• 4:44
  Стаття – це цілеспрямований фрагмент інструкції.
• 4:46
  Вона може відповідати на запитання, наприклад, як мені змінити платіжну адресу.
• 4:49
  Або пояснювати, що агент має перевірити перед схваленням повернення коштів, включаючи посилання на політику та кроки для особливих випадків.
• 4:55
  Це не просто спільна папка з файлами Word та PDF.
• 4:58
  У папці можна зберігати інформацію, але часто потрібно знати назву файлу, перш ніж знайти відповідь.
• 5:03
  Управління знаннями в Dynamics 365 працює скоріше як довідкове бюро у вашому відділі обслуговування клієнтів.
• 5:09
  Кожна відповідь має заголовок, тему та мітки, які допомагають потрібній людині знайти її саме тоді, коли вона потрібна.
• 5:14
  Уявіть великий офісний будинок.
• 5:16
  Ваша команда підтримки працює за столами обслуговування клієнтів, обробляючи дзвінки, електронні листи та звернення.
• 5:21
  Десь поруч розташоване довідкове бюро з персоналом. За цим столом стоять чітко підписані папки з відповідями щодо оплати, доставки, доступу до облікового запису, налаштування продукту та правил компанії.
• 5:30
  Це довідкове бюро і є вашою базою знань. Статті всередині схожі на ті папки, але вони не всі написані однаково.
• 5:36
  Проста стаття може починатися з короткої відповіді для агента, а потім містити точний перелік кроків.
• 5:41
  Інша може включати посилання на політику знімок екрана того, що бачить клієнт, або пов'язану статтю для наступного ймовірного запитання.
• 5:47
  І мета не в тому, щоб написати підручник.
• 5:49
  Мета – допомогти людині правильно вирішити одну проблему клієнта, не змушуючи її читати п'ять сторінок, які лише частково стосуються поточного випадку.
• 5:56
  Це безпосередньо пов'язано з роботою, яку агенти вже виконують у Dynamics 365 Customer Service.
• 6:01
  Коли агент відкриває звернення клієнта, йому не потрібно залишати робочу область, відкривати інший сайт і починати окремий пошук серед старих документів.
• 6:08
  Вони можуть шукати знання, читаючи проблему клієнта, а потім відкрити інструкцію, що відповідає за питанню.
• 6:13
  Це дозволяє підтримувати хід розмови.
• 6:15
  Звернення повідомляє агенту, що сталося, а стаття бази знань допомагає вирішити, що робити далі.
• 6:19
  Об'єднайте ці дві речі, і людина, що допомагає клієнту, матиме контекст і схвалені інструкції в одному місці.
• 6:24
  Деякі знання призначені лише для внутрішнього використання в компанії.
• 6:27
  Наприклад, стаття може пояснювати внутрішні перевірки перед тим, як агент змінить дані облікового запису,
• 6:31
  або перераховувати кроки для передачі складного випадку іншій команді.
• 6:34
  Клієнти ніколи не повинні бачити такі інструкції.
• 6:36
  Інші статті можуть відповідати на запитання клієнтів безпосередньо через сайт самообслуговування.
• 6:40
  Клієнт може шукати інструкції щодо оновлення контактних даних, розуміння рахунку або скидання пароля,
• 6:45
  перш ніж звертатися до підтримки.
• 6:46
  Одна система знань – різна аудиторія.
• 6:48
  Це означає, що ваша команда може контролювати, які статті доступні агентам, а які – клієнтам.
• 6:53
  Публічна версія має містити зрозумілі клієнту пояснення та безпечні інструкції,
• 6:57
  тоді як внутрішнє, робочі кроки лише для персоналу.
• 6:59
  Багато хто вважає, що управління знаннями потрібне лише величезним кол-центрам із сотнями агентів.
• 7:03
  Але невеликі команди підтримки можуть отримати від цього не меншу вигоду.
• 7:06
  Якщо четверо людей відповідають на одні і ті самі запитання, їм все одно потрібні чіткі відповіді.
• 7:10
  Насправді, менша команда часто відчуває труднощі швидше,
• 7:12
  бо якщо хтось іде на тиждень, він забирає з собою багато практичних навичок.
• 7:16
  Dynamics 365 Knowledge Management забезпечує цим знанням дім,
• 7:20
  структуру та зручний спосіб використання під час роботи з клієнтами.
• 7:23
  Далі розглянемо шлях запитання від моменту виявлення нестачі інформації до того, як команда зможе на неї покладатися.
• 7:29
  Це і є життєвий цикл статті «Бази знань».
• 7:31
  Отже, стаття зазвичай починається з прогалини у знаннях.
• 7:34
  Можливо, агент отримує запитання про повернення товару, шукає в базі знань і не знаходить нічого вартого довіри.
• 7:39
  Або ж те саме запитання постійно з'являється у зверненнях, але кожен агент відповідає на нього по-своєму.
• 7:44
  Це саме той момент, щоб створити статтю.
• 7:46
  Почніть зі слів, які дійсно використовують клієнти, бо саме їх агенти вводитимуть у рядок пошуку.
• 7:50
  Якщо клієнти питають, чому я не бачу своє повернення коштів,
• 7:53
  то назва «Перевірка статусу повернення коштів клієнту» дає команді «Кращий старт, ніж щось розмити на кшталт фінансовий процес».
• 7:59
  Також робіть першу відповідь короткою.
• 8:01
  Агенту, який працює під тиском, потрібно швидко побачити суть, а деталі вивчати лише за потреби.
• 8:06
  Тому стаття може починатися з одного речення про те, коли має надійти повернення, а далі – перелік перевірок для агента.
• 8:12
  Далі викладайте кроки в тій послідовності, в якій вони потрібні.
• 8:15
  Що агент має перевірити найперше?
• 8:17
  Яке вікно йому слід відкрити?
• 8:19
  Яку інформацію необхідно уточнити у клієнта?
• 8:21
  Коли варто зупинитися і передати справу іншому відділу?
• 8:24
  Чіткі інструкції усувають здогадки.
• 8:26
  Якісна стаття також розділяє те, що може зробити клієнт, і те, що доступно лише співробітнику.
• 8:30
  Ви можете додати посилання на публічну сторінку допомоги для клієнта, поки внутрішня версія описує дії агента перед закриттям звернення.
• 8:37
  Зображення теж допомагають, особливо коли потрібно знайти кнопку або розпізнати повідомлення на екрані.
• 8:41
  Але не додавайте зображення лише для заповнення місця.
• 8:44
  Якщо зображення не допомагає користувачеві виконати крок, приберіть його.
• 8:46
  Екрани змінюються, і кожне зображення – це ще одна річ, яку власнику статті доводиться оновлювати.
• 8:51
  Коли чернетка містить правильну відповідь, її потрібно позначити тегами.
• 8:54
  Категорії вказують на загальні теми, як от оплата, доставка, облікові записи або налаштування продукту.
• 8:59
  Ключові слова допомагають охопити різні терміни, якими люди описують одну і ту саму проблему.
• 9:02
  Клієнт може сказати «поверніть гроші», тоді як працівник шукає відшкодування.
• 9:05
  Обидва запити мають вести до однієї і тієї самої статті.
• 9:08
  Мова також має значення.
• 9:09
  Якщо ваша команда підтримує клієнтів кількома мовами, кожна аудиторія повинна мати інструкції, які можна прочитати та використати без сумнівів.
• 9:15
  Ви також можете пов'язати супутні продукти та статті, щоб людина, розв'язавши одну проблему, могла швидко знайти наступну пораду, не починаючи все з нуля.
• 9:23
  Потім настає черга перевірки.
• 9:24
  Той, хто пише статтю, може добре розуміти проблему клієнта, але не обов'язково знати внутрішню політику компанії.
• 9:29
  Експерт із предметної області перевіряє правильність наданих порад.
• 9:32
  Власник статті вирішує, чи готовий контент до використання та хто зможе його прочитати.
• 9:37
  Цей етап захищає як команду, так і клієнта.
• 9:39
  Уявіть, що агент пише корисні кроки для зміни адреси, але пропускає перевірку особи, яку вимагає політика компанії.
• 9:45
  Стаття може здаватися зрозумілою та дружньою, проте вона може створити проблеми з безпекою, якщо люди виконуватимуть її дослівно.
• 9:51
  Схвалення виявляється до того, як стаття потрапить до сервісного центру.
• 9:54
  Після схвалення ви публікуєте статтю для відповідної аудиторії.
• 10:02
  Саме запитання клієнта може потребувати двох версій, оскільки персоналу потрібні внутрішні інструкції, а клієнтам – прості і безпечні дії, які вони можуть виконати самостійно.
• 10:09
  Але публікація – це ще не фініш.
• 10:11
  Продукти змінюються, правила компанії оновлюються, кнопки переміщуються, процеси оплати коригуються.
• 10:16
  Якщо ніхто не перевіряє статтю, вчорашня правильна відповідь може збити когось зі шляху наступного місяця.
• 10:20
  Ось чому статті потребують власника та дати перевірки.
• 10:23
  Сприймайте кожну статтю як паперовий файл на робочому столі сервісного центру.
• 10:26
  Спочатку вона отримує чітку мітку, щоб люди могли її знайти.
• 10:29
  Потім експерт ставить печатку «Перевірено».
• 10:31
  Вона потрапляє до поточної теки, на яку може покладатися персонал.
• 10:34
  Коли процес змінюється, ви не залишаєте старий файл на столі поруч із новим.
• 10:38
  Ви оновлюєте статтю, зберігаєте попередню версію та вилучаєте контент, який більше не потрібен у повсякденній роботі.
• 10:43
  Завдяки цьому люди не обиратимуть застарілу відповідь лише тому, що вона з'явилася першою.
• 10:47
  База знань стає кращою саме завдяки цьому циклу.
• 10:50
  Знайдіть відсутню відповідь, напишіть чітку інструкцію, перевірте, опублікуйте, а потім перегляньте, коли робочий процес зміниться.
• 10:56
  Але навіть добре написана стаття нікому не допоможе, якщо вона залишається прихованою, коли клієнту потрібна відповідь.
• 11:02
  Пошук знань під час допомоги клієнту.
• 11:04
  Отже, як це виглядає на практиці?
• 11:06
  Ось момент, коли система справді доводить свою цінність.
• 11:10
  Клієнт звертається до підтримки, бо не розуміє списання у своєму останньому рахунку.
• 11:14
  Він роздратований і хоче отримати відповідь негайно, а агент має відкриту справу в Dynamics 365.
• 11:20
  Справа надає агенту корисний контекст, обліковий запис клієнта, тип списання та слова, які клієнт використав для опису проблеми.
• 11:26
  З того самого робочого екрана агент може шукати в базі знань.
• 11:29
  Він може шукати за запитом дублювання списання або питання щодо рахунка.
• 11:32
  І пошукова система переглядає заголовки статей, вміст, категорії та мітки, щоб надати інструкції, які відповідають справі.
• 11:37
  Це значно зменшує необхідність перемикатися між вікнами.
• 11:39
  Без такої інтеграції агенту довелося б копіювати фразу зі справи, відкривати інший сайт, шукати у спільному диску і сподіватися, що відповідь ще актуальна.
• 11:46
  Але коли база знань підключена безпосередньо до обслуговування клієнтів, пошук починається саме там, де виконується робота.
• 11:51
  Втім, довгий список результатів не вирішує проблему.
• 11:54
  Агенту не потрібно 10 статей, де лише загально згадується виставлення рахунків.
• 11:58
  Потрібна одна актуальна стаття, що пояснює конкретне списання, необхідні перевірки, слова для розмови з клієнтом і коли передати справу далі.
• 12:04
  Один хороший результат кращий – закупу приблизно підходящих.
• 12:07
  Ось чому чіткі заголовки статей та корисні ключові слова мають таке велике значення.
• 12:11
  Стаття під назвою «Інформація про рахунки» дає дуже мало для роботи.
• 12:15
  Тоді як заголовок на кшталт «Як пояснити дублювання щомісячної підписки» одразу підказує агенту, чи знайшов він потрібну інструкцію.
• 12:23
  Категорії також звужують пошук.
• 12:25
  Категорії, як-от рахунки, доступ до облікового запису, доставка, повернення та налаштування продукту діють як загальні орієнтири.
• 12:31
  Коли агент переходить до потрібного розділу, заголовок статті та вступні рядки допомагають зрозуміти, чи підходить це до ситуації клієнта.
• 12:37
  Dynamics 365 також може пропонувати статті на основі того, що вказано у справі.
• 12:41
  Це звучить корисно, і так воно і є, але система не замінює людину, яка читає справу.
• 12:46
  Запропонована стаття може збігатися зі словом у повідомленні клієнта, але не стосуватися самої проблеми.
• 12:50
  Агент все одно має прочитати інструкцію, перевірити деталі облікового запису і вирішити, чи вона застосовна.
• 12:55
  Уявіть це як отримання кількох можливих варіантів відповіді під час вікторини.
• 12:58
  Варіанти звужують поле пошуку, але вам все одно потрібно обрати той, що відповідає питанню.
• 13:01
  Обслуговування клієнтів працює так само, особливо коли правила виставлення рахунків, історія облікового запису або особливі потреби клієнта змінюють наступний крок.
• 13:07
  Давайте зупинимося на цьому прикладі з рахунками.
• 13:09
  Оператор шукає тип списання і відкриває затверджену статтю про дублювання платежів.
• 13:13
  Перша частина підказує їм перевірити, чи має клієнт більше однієї активної підписки.
• 13:17
  Далі пояснюється, як підтвердити дати платежів і що сказати клієнту, якщо друге списання було здійснено з іншого облікового запису.
• 13:23
  Потім стаття дає чіткий наступний крок, якщо списання справді збігаються.
• 13:26
  Можливо, оператор може розпочати процес повернення коштів, або інший відділ має спершу перевірити платіжний запис.
• 13:31
  У будь-якому разі оператор не вигадує відповідь, поки клієнт чекає.
• 13:34
  Вони дотримуються затвердженого компанією процесу, пояснюють, що буде далі, і фіксують результат у справі.
• 13:39
  Клієнт отримує чіткішу відповідь, оператор відчуває менший тиск, а команда бачить, яка інструкція допомогла вирішити справу.
• 13:45
  База знань також допомагає до того, як клієнт звернеться до оператора.
• 13:49
  Сайт самообслуговування надає клієнтам можливість знайти прості відповіді, наприклад, як оновити контактні дані, знайти рахунок або відновити доступ до аккаунта.
• 13:56
  Коли інструкції вирішують проблему, клієнт може продовжувати роботу, не відкриваючи запит у підтримку.
• 14:01
  Це не означає, що кожне питання підходить для самообслуговування.
• 14:04
  Заблокований аккаунт із незвичною активністю, оскаржений платіж або клієнт, якому потрібна особиста допомога, все одно потребують реальної людини.
• 14:10
  Управління знаннями підтримує якісне обслуговування, але не перетворює роботу з клієнтами на список шаблонних відповідей.
• 14:15
  Люди все одно слухають і використовують власне судження.
• 14:18
  База знань дає їм надійну відправну точку саме тоді, коли вона потрібна клієнту.
• 14:21
  Але ця бібліотека залишається корисною лише тоді, коли хтось підтримує її вміст зрозумілим, безпечним і актуальним.
• 14:26
  Підтримка знань у стані точності, безпеки та актуальності.
• 14:29
  База знань може стати ненадійною напрочуд швидко.
• 14:32
  Хтось публікує корисну відповідь, через 6 місяців процес змінюється, а до статті ніхто не повертається.
• 14:37
  Старі кроки легко знайти, тому оператори продовжують їх виконувати, припускаючи, що опублікована інструкція все ще правильна.
• 14:43
  Ось чому кожна стаття потребує відповідального, хто знає, хто може перевірити факти, оновити вміст і вирішити, коли вона більше не потрібна.
• 14:50
  Власникові статті не обов'язково писати кожне слово самотужки.
• 14:53
  Оператор підтримки може помітити проблему, член продуктової команди може знати правило продукту, а фінансовий експерт може підтвердити етап виставлення рахунку.
• 14:59
  Все ж таки, одна людина повинна відповідати за фінальну статтю і дотримуватися графіка її перегляду.
• 15:04
  Без відповідального кожен припускає, що це виправить хтось інший.
• 15:06
  Затвердження забезпечує перевірку безпеки перед тим, як інструкція потрапить до операторів чи клієнтів.
• 15:11
  Чернитка може містити правильну загальну ідею, але пропускати крок, що захищає обліковий запис, відповідає політиці компанії або належно обробляє виняток.
• 15:18
  Це особливо важливо, коли стаття підказує, як змінити особисті дані, обговорити платежі або отримати доступ до облікового запису.
• 15:24
  Рецензент перевіряє формулювання, підтверджує процес і вирішує, чи готова стаття.
• 15:27
  Команда може бути впевнена, що затверджена стаття пройшла перевірку не лише однією людиною.
• 15:32
  Дозволи також мають значення.
• 15:33
  Не кожен має редагувати кожну статтю і не кожна стаття має бути доступною для кожного читача.
• 15:38
  Агенту можуть знадобитися внутрішні інструкції для перевірки рахунку клієнта, тоді як клієнту потрібні лише безпечні кроки, які він може виконати самостійно.
• 15:45
  Dynamics 365 дозволяє керувати цим доступом.
• 15:47
  Ви можете вирішувати, хто створює чернетки, хто їх затверджує, хто публікує і хто може бачити внутрішній контент.
• 15:53
  Це захищає приватні робочі кроки від публічних сторінок, надаючи агентам усе необхідне під час роботи зі зверненням.
• 15:57
  Крім того, потрібно прислухатися до людей, які користуються цими статтями.
• 16:00
  Агент може знайти статтю, але помітити, що крок 4 більше не збігається з екраном.
• 16:04
  Клієнт може прочитати статтю самообслуговування і все одно звернутися до підтримки, бо інструкції здаються незрозумілими.
• 16:09
  Хтось може виконати пошук тричі і нічого не знайти, що дало б відповідне запитання.
• 16:12
  Ці моменти є корисними сигналами.
• 16:14
  Зворотний зв'язок підказує власнику контенту, де інструкції працюють, де вони заплатують людей і де може знадобитися нова стаття.
• 16:19
  Невдалі результати пошуку також важливі.
• 16:21
  Якщо люди постійно шукають зміна адреси доставки, але стаття не з'являється, база знань вказує на очевидну прогалину.
• 16:27
  Повторні звернення можуть вказувати на ту саму прогалину.
• 16:29
  Коли одна і та сама проблема постійно надходить до сервісної команди, перевірте, чи існує стаття, чи можуть люди її знайти і чи справді ці кроки вирішують проблему.
• 16:36
  Відповідь може потребувати кращого формулювання, чіткішого заголовка або нового внутрішнього процесу.
• 16:41
  Пишіть просто.
• 16:42
  Використовуйте заголовки, що описують проблему клієнта.
• 16:44
  Одна стаття – одна тема.
• 16:51
  Обсяг – це не мета.
• 16:57
  Мета – корисні актуальні відповіді, а це потребує регулярних перевірок, чіткого розподілу відповідальності та відгуків від працівників.
• 17:03
  Давайте застосуємо все це до однієї клієнтської ситуації.
• 17:06
  Простий приклад від початку до кінця.
• 17:08
  Дозвольте провести вас через реальний сценарій.
• 17:10
  Клієнт телефонує, бо не може отримати доступ до свого онлайн-акаунта.
• 17:13
  Вони натискають на посилання для скидання пароля, але електронний лист не надходить.
• 17:17
  Вони пробують знову, знову нічого.
• 17:18
  Тепер вони справді роздратовані, адже їм потрібно зробити замовлення, а увійти в систему не вдається.
• 17:23
  Агент відкриває звернення в Dynamics 365 і шукає за запитом «Лист про скидання пароля не отримано».
• 17:29
  Одразу з'являється схвалена стаття, заголовок якої чітко відповідає на запит клієнта.
• 17:34
  Агент розуміє, що це саме та відповідь.
• 17:36
  Стаття починається з контрольного списку.
• 17:38
  Перевірте адресу електронної пошти в обліковому записі.
• 17:40
  Перевірте, чи не заблоковано обліковий запис тимчасово.
• 17:42
  Попросіть клієнта перевірити папку зі спамом.
• 17:44
  Вона навіть містить готові формулювання для кожного кроку, щоб агент пояснив усе, не розголошуючи приватних даних.
• 17:50
  Припустімо, «Лист про скидання пароля все ще не прийшов».
• 17:52
  Стаття чітко вказує, що робити далі, зокрема, коли передати звернення команді підтримки облікових записів.
• 17:57
  Жодних розмитих порад на кшталт спробуємо ще раз пізніше.
• 18:00
  Клієнту важливо знати, що буде далі і хто відповідає за вирішення проблеми.
• 18:03
  Агент виконує схвалені кроки, фіксує перевірене і додає статтю до звернення.
• 18:07
  Але під час розмови він помічає, що дечого не вистачає.
• 18:10
  Стаття радить клієнтам перевірити папку спаму.