WEBVTT 00:00:00.000 --> 00:00:11.080 Клієнт пише електронного листа про пошкоджене замовлення, наступного дня телефонує, потім відкриває чат, бо ніхто не знає, що сталося, і він щоразу повторює одну й ту саму історію, поки ваша служба підтримки шукає інформацію в пошті, нотатках та окремих інструментах. 00:00:11.240 --> 00:00:14.560 Саме це і вирішує система управління зверненнями Dynamics 365. 00:00:15.140 --> 00:00:22.240 Уявіть звернення як одну підписану папку в офісній будівлі, куди потрапляє кожна деталь проблеми клієнта, від першого запитання до остаточної відповіді. 00:00:22.240 --> 00:00:31.480 З вами Мірко Петерс з М365FM, і в цьому короткому огляді ви дізнаєтеся, як пов'язані між собою звернення, маршрутизація, терміни відповіді, довідкові статті та закриття справ. 00:00:31.660 --> 00:00:36.080 Що таке звернення? Коротко, у 20 словах. Отже, що саме таке звернення? 00:00:36.240 --> 00:00:45.220 Звернення – це один запис про одну проблему клієнта, яка потребує відповіді чи вирішення, наприклад, пошкоджений товар, запитання щодо рахунку, проблеми з входом або запит на допомогу з послугою. 00:00:45.220 --> 00:00:55.060 Важливо розуміти, один клієнт може мати кілька звернень одночасно. Один клієнт може запитати про рахунок у понеділок, повідомити про несправність пристрою у вівторок і потребувати допомоги зі зміною адреси в п'ятницю. 00:00:55.180 --> 00:01:01.600 Це окремі проблеми, тому Dynamics 365 зберігає їх в окремих записах, а не звалює всі розмови в одну заплутану чергу. 00:01:01.760 --> 00:01:05.140 Коли агент створює звернення, він одразу пов'язує його з клієнтом. 00:01:05.320 --> 00:01:10.560 Цим клієнтом може бути контакт, тобто конкретна особа або організація, компанія, у якій вона працює. 00:01:10.560 --> 00:01:20.520 Тож, якщо Джеймі з Носвіндтрейдас повідомляє про проблему, звернення може стосуватися і Джеймі, і компанії, тому будь-хто, хто відкриє запис, побачить, кому потрібна допомога та до якої організації належить це питання. 00:01:20.720 --> 00:01:34.860 Звернення також потребує чіткого опису проблеми, зазвичай із заголовком на кшталт «Принтер зупинився після оновлення ПЕЗЕ» або «З клієнта зняли оплату двічі», що допомагає швидко переглядати список відкритих справ, не відкриваючи кожен запис. 00:01:34.860 --> 00:01:44.900 Під заголовком «Агент» додає деталі. Що сталося, коли це почалося? Що клієнт уже спробував зробити? Якого продукту це стосується? І чи це запитання, запит чи технічна несправність? 00:01:45.040 --> 00:01:48.880 Ці деталі перетворюють розмите повідомлення на конкретну роботу, яку хтось може взяти на себе та вирішити. 00:01:48.880 --> 00:01:53.860 Розберімо це докладніше. Звернення може містити тему, продукт, пріоритет і тип запиту. 00:01:54.020 --> 00:02:06.960 Тема групує проблему за напрямком, як-от виставлення рахунків чи технічна підтримка, продукт визначає, що використовує клієнт, пріоритет підказує команді, як швидко звернути на це увагу, а тип звернення надає ще один спосіб сортування роботи згідно з процесом підтримки. 00:02:06.960 --> 00:02:15.900 Жодне з цих полів саме по собі не вирішує проблему клієнта, але вони допомагають команді підтримки чітко бачити обсяг роботи, особливо коли надходять сотні звернень від різних клієнтів. 00:02:16.020 --> 00:02:21.300 Команда, що працює з серйозним збоєм у сервісі, не повинна витрачати час на пошук серед загальних запитань. 00:02:21.440 --> 00:02:27.600 Отже, звернення – це не просто форма, яку хтось заповнив і забув. Це робочий запис усієї комунікації з клієнтом. 00:02:27.600 --> 00:02:35.800 Електронні листи можна прив'язати до звернення, сюди ж потрапляють телефонні дзвінки, а агент може додати примітки після чату, створити завдання на виконання або записати зустріч. 00:02:35.940 --> 00:02:41.960 Кожна дія зберігається разом із проблемою клієнта, тому наступному спеціалісту не доведеться збирати історію з нуля. 00:02:42.140 --> 00:02:47.080 Уявіть, що агент починає роботу вранці, а після обіду передає звернення фахівцю з продукту. 00:02:47.260 --> 00:02:52.640 Без запису звернення спеціаліст може отримати лише коротке повідомлення на кшталт «Ой, можеш подивитися на це». 00:02:52.640 --> 00:03:00.260 Чого недостатньо? Завдяки запису звернення вони бачать початкову проблему, деталі про клієнта, хід розмови та те, що перший агент уже перевірив. 00:03:00.380 --> 00:03:02.280 Це значно полегшує передачу справ. 00:03:02.480 --> 00:03:07.260 Dynamics 365 підтримує чіткий статус звернення під час проходження через процес підтримки. 00:03:07.460 --> 00:03:13.480 Воно залишається активним, поки команда проводить розслідування, а коли проблему вирішено або надано фінальну відповідь, звернення закривається. 00:03:13.480 --> 00:03:19.620 Якщо запит більше не потребує роботи, наприклад, через помилку або відмову клієнта, команда може його скасувати. 00:03:19.620 --> 00:03:21.760 Активне, вирішене та скасоване. 00:03:22.660 --> 00:03:27.560 Ці три стани забезпечують команді спільне бачення етапу роботи над кожною проблемою. 00:03:27.740 --> 00:03:34.760 Нікому не потрібно вгадувати, чи потребує звернення уваги, а менеджерам не доводиться приймати завершену роботу за нову проблему. 00:03:35.780 --> 00:03:40.260 Один запис забезпечує контроль, а повна історія клієнта надає агенту контекст. 00:03:40.460 --> 00:03:42.800 Історія клієнта, що стоїть за зверненням. 00:03:42.960 --> 00:03:45.140 Звернення вказує на те, що потрібно виправити. 00:03:45.340 --> 00:03:47.960 Запис про клієнта пояснює, що призвело до цієї ситуації. 00:03:47.960 --> 00:03:53.440 Коли агент відкриває звернення в Dynamics 365 Customer Service, він може зазирнути далі за останнє повідомлення. 00:03:53.580 --> 00:03:59.400 Він бачить ширшу картину, попередні звернення, минулі листи, продукти, пов'язані з клієнтом та історію його підтримки. 00:03:59.540 --> 00:04:01.120 Контекст змінює розмову. 00:04:01.260 --> 00:04:02.620 Чому контекст важливий? 00:04:02.760 --> 00:04:05.520 Уявіть, що клієнт повідомляє про вихід пристрою з ладу. 00:04:05.580 --> 00:04:09.200 Якщо агент бачить лише сьогоднішнє повідомлення, він може почати з базових запитань. 00:04:09.340 --> 00:04:10.140 Яка це модель? 00:04:10.280 --> 00:04:11.300 Коли це почалося? 00:04:11.460 --> 00:04:12.620 Ви перезапускали його. 00:04:12.620 --> 00:04:15.540 Але клієнт уже двічі звертався до служби підтримки цього тижня. 00:04:15.660 --> 00:04:19.240 Перший агент надіслав інструкції з усунення несправностей, другий організував заміну деталі. 00:04:19.360 --> 00:04:22.880 Третій агент, який бачить цю історію, не проситиме клієнта починати все спочатку. 00:04:23.040 --> 00:04:26.960 Натомість він скаже, я бачу, що ви вже спробували ці кроки і заміна деталі не допомогла. 00:04:27.140 --> 00:04:28.660 Давайте спробуємо щось інше. 00:04:28.820 --> 00:04:31.700 Це зовсім не те саме, що чи можете ви ще раз пояснити проблему. 00:04:31.880 --> 00:04:34.980 Це часто називають повним уявленням про клієнта 360 градусів. 00:04:34.980 --> 00:04:36.980 Назва звучить вишукано, але все просто. 00:04:37.160 --> 00:04:41.580 Це означає, що агент бачить клієнта з різних боків, а не лише через одне окреме повідомлення. 00:04:41.720 --> 00:04:47.240 Агент бачить людину, компанію, попередні запити до підтримки, минулі розмови та пов'язані з ними продукти. 00:04:47.420 --> 00:04:50.740 Для команди підтримки це замінює з догадки чіткою відправною точкою. 00:04:50.900 --> 00:04:53.840 Звісно, не кожен клієнт отримує однаковий рівень підтримки. 00:04:54.020 --> 00:04:58.700 Клієнт міг придбати гарантію, його компанія може оплачувати певну кількість годин підтримки 00:04:58.700 --> 00:05:02.980 або мати контракт на певну кількість звернень чи преміум підтримку зі швидшою допомогою. 00:05:03.140 --> 00:05:06.700 Dynamics 365 відстежує все це через право на обслуговування. 00:05:06.840 --> 00:05:10.320 Право на обслуговування – це угода про підтримку клієнта всередині системи. 00:05:10.460 --> 00:05:13.720 Сприймайте це як умови обслуговування, прив'язані до їхнього облікового запису. 00:05:13.820 --> 00:05:18.480 Перш ніж агент пообіцяє візит інженера або розпочне платну роботу, він перевіряє умови підтримки. 00:05:18.640 --> 00:05:20.680 Це допомагає уникнути незручних сюрпризів. 00:05:20.680 --> 00:05:23.860 Наприклад, клієнт може все ще мати гарантійне покриття на несправний продукт. 00:05:23.960 --> 00:05:25.820 Звернення може йти за відповідним сценарієм. 00:05:25.960 --> 00:05:28.380 Інший клієнт міг уже використати всі свої години підтримки. 00:05:28.540 --> 00:05:31.160 Агент бачить це перед тим, як взяти на себе роботу поза межами угоди. 00:05:31.260 --> 00:05:33.920 Це також допомагає команді підтримки ставитися до клієнтів справедливо. 00:05:34.100 --> 00:05:37.040 Агенту не потрібно шукати старі контракти чи звертатися до іншого відділу. 00:05:37.040 --> 00:05:40.780 Умови підтримки знаходяться поруч із інформацією про клієнта саме там, де агент може їх знайти. 00:05:40.920 --> 00:05:41.960 Далі – база знань. 00:05:41.960 --> 00:05:44.820 Команди підтримки вирішують одні й ті самі проблеми знову і знову. 00:05:44.960 --> 00:05:47.940 Скидання паролів, інструкції з налаштування, відома помилка після оновлення, 00:05:48.040 --> 00:05:49.880 питання щодо рахунків зі стандартною відповіддю. 00:05:50.040 --> 00:05:52.420 Стаття в базі знань зберігає цю відповідь в одному місці. 00:05:52.560 --> 00:05:56.380 У робочому просторі служби підтримки агент може шукати статті під час роботи над зверненням. 00:05:56.380 --> 00:06:01.940 Стаття може містити просте пояснення, покрокові інструкції, знімок екрана або перелік точних перевірок, які має виконати команда. 00:06:02.080 --> 00:06:06.900 Замість того, щоб кожен агент писав власну версію з пам'яті, вони використовують спільну відповідь, яку перевірила команда. 00:06:07.040 --> 00:06:08.880 Це забезпечує послідовність підтримки. 00:06:09.040 --> 00:06:10.740 Це також допомагає новим агентам. 00:06:10.940 --> 00:06:16.160 Їм не потрібно роками набувати досвіду для успішного вирішення типових проблем, оскільки перевірені командні рішення завжди під рукою. 00:06:16.160 --> 00:06:20.080 Короткі огляди звернень Co-Pilot допомагають розв'язати ще одну поширену проблему – довгу історію звернень. 00:06:20.220 --> 00:06:23.380 З часом у зверненні може накопичитися безліч електронних листів, нотаток та оновлень. 00:06:31.940 --> 00:06:36.040 Це швидкий брифінг перед тим, як агент розпочне роботу. 00:06:36.180 --> 00:06:40.580 Агент все одно перевіряє запис і використовує власне судження, але швидше входить у курс справи. 00:06:40.720 --> 00:06:44.540 Це допомагає, коли клієнт чекає, а звернення вже пройшло через кілька рук. 00:06:44.540 --> 00:06:49.300 Коли агент розуміє клієнта та проблему, звернення має потрапити до потрібної людини. 00:06:50.340 --> 00:06:52.240 Від отримання до правильної черги. 00:06:52.400 --> 00:06:57.980 Клієнт може звернутися по допомогу різними способами – електронною поштою, телефоном, чатом, у соцмережах чи через портал самообслуговування. 00:06:57.980 --> 00:07:02.080 Канал зв'язку змінюється, але службі підтримки потрібне єдине місце для керування запитами. 00:07:02.260 --> 00:07:07.820 Dynamics 365 може створювати звернення на основі цих розмов, якщо налаштовано правила створення записів. 00:07:07.960 --> 00:07:11.020 Уявіть електронний лист, що надходить на спільну адресу підтримки. 00:07:11.020 --> 00:07:15.460 Замість того, щоб лежати в поштовій скринці, поки його помітять, правило перетворює цей лист на звернення. 00:07:15.600 --> 00:07:18.420 Повідомлення стає початком роботи в системі обслуговування клієнтів. 00:07:18.560 --> 00:07:20.540 Це зменшує необхідність у ручному копіюванні. 00:07:20.540 --> 00:07:23.160 Такий самий принцип діє і для інших підключених каналів. 00:07:23.300 --> 00:07:27.040 Команда сама обирає, які повідомлення створюють нове звернення, а які доповнюють наявне. 00:07:27.200 --> 00:07:29.680 Відповідь на відкриту проблему залишається в межах цієї проблеми. 00:07:29.820 --> 00:07:31.480 Нове запитання отримує власне звернення. 00:07:31.640 --> 00:07:33.780 Потім зверненню потрібне місце, поки хтось не візьметься за нього. 00:07:33.780 --> 00:07:35.320 Таким місцем часто є черга. 00:07:35.480 --> 00:07:37.560 Черга – це спільний робочий простір для команди. 00:07:37.660 --> 00:07:41.400 Це невхідна скринька одного агента, і вона не належить тому, хто першим побачив запит. 00:07:41.400 --> 00:07:44.780 Натомість це місце, де вся команда бачить завдання, що чекають на увагу. 00:07:44.900 --> 00:07:48.660 Уявіть компанію з відділом розрахунків, технічною підтримкою та відділом повернень. 00:07:48.800 --> 00:07:50.540 У кожної команди є власна черга. 00:07:50.700 --> 00:07:56.400 Питання щодо рахунків йдуть до фінансового відділу, несправності, до техпідтримки, запити на повернення, до фахівців із повернень. 00:07:56.400 --> 00:07:58.500 Це звучить просто, тому що так воно і є. 00:07:58.620 --> 00:08:01.380 Чітке сортування рятує людей від хаотичної передачі завдань. 00:08:01.500 --> 00:08:03.740 Правила маршрутизації допомагають із цим сортуванням. 00:08:03.740 --> 00:08:07.700 Правило маршрутизації перевіряє деталі звернення та спрямовує його до потрібної черги або фахівця. 00:08:07.880 --> 00:08:10.440 Звернення щодо певного продукту йде до продуктової команди. 00:08:10.600 --> 00:08:13.060 Звернення з певного регіону спрямовується до місцевої підтримки. 00:08:13.280 --> 00:08:15.260 Серйозна проблема потрапляє до термінової черги. 00:08:15.440 --> 00:08:17.480 Загальне запитання очікує у стандартній черзі. 00:08:17.480 --> 00:08:19.960 Деякі організації розподіляють роботу на основі навичок. 00:08:20.080 --> 00:08:23.180 Наприклад, клієнту, який пише французькою, потрібен агент, що володіє цією мовою. 00:08:23.180 --> 00:08:26.200 Технічна проблема потребує фахівця, який пройшов навчання з певного продукту. 00:08:26.320 --> 00:08:30.320 Маршрутизація наближає справу до того, хто може її вирішити, замість однакового опрацювання всіх запитів. 00:08:30.520 --> 00:08:32.960 Автоматизація допомагає, але рішення все одно приймають люди. 00:08:33.100 --> 00:08:36.620 Керівник команди може переглянути складну справу і призначити її безпосередньо старшому агенту. 00:08:36.620 --> 00:08:38.660 Можливо, хтось уже знайомий із цим клієнтом. 00:08:38.820 --> 00:08:42.380 Можливо, проблема стосується кількох продуктів і потребує досвіду, який неможливо оцінити правилом. 00:08:42.380 --> 00:08:45.160 Ручне призначення дає команді простір для такого людського вибору. 00:08:45.280 --> 00:08:47.560 Відповідальний за справу може змінюватися під час її опрацювання. 00:08:47.720 --> 00:08:50.640 Агенту може знадобитися більше інформації, і він поверне справу в чергу. 00:08:50.780 --> 00:08:53.180 Команда може виявити, що питання належить до іншого відділу, 00:08:53.240 --> 00:08:56.900 або терміновий запит може потребувати ескалації, коли звичайна команда не може його вирішити. 00:08:57.060 --> 00:09:01.760 Dynamics 365 забезпечує рух роботи, замість того, щоб залишати її в того, хто зайшов у глухий кут. 00:09:01.840 --> 00:09:04.040 Іноді одна проблема створює багато справ. 00:09:04.040 --> 00:09:07.360 Уявіть збій у програмному забезпеченні, що впливає на десятки клієнтів. 00:09:07.460 --> 00:09:11.140 Кожен клієнт звертається до підтримки окремо, тому кожне повідомлення потребує власної справи. 00:09:11.220 --> 00:09:13.720 Але всі звіти пов'язані з однією ширшою проблемою. 00:09:13.880 --> 00:09:18.580 Батьківська справа відстежує цю загальну проблему, тоді як дочірні справи відстежують окремі звіти клієнтів під нею. 00:09:18.700 --> 00:09:20.980 Це дає команді підтримки два погляди одночасно. 00:09:21.140 --> 00:09:25.960 Вони працюють над основним збоєм через батьківську справу, тоді як кожна дочірня справа тримає відповідного клієнта в курсі. 00:09:25.960 --> 00:09:30.020 Коли вони знаходять рішення, їм не потрібно досліджувати той самий збій з нуля для кожного, хто телефонує. 00:09:30.180 --> 00:09:32.840 Дублювані справи створюють схожу проблему в меншому масштабі. 00:09:32.960 --> 00:09:38.220 Клієнт може написати і зателефонувати щодо однієї і тієї ж проблеми, або два агенти можуть відкрити справи, не помітивши іншу. 00:09:38.360 --> 00:09:41.660 Замість того, щоб розпорошувати зусилля, команда може об'єднати схожі справи. 00:09:41.780 --> 00:09:44.900 Одна справа стає головним записом, і робота залишається зосередженою в одному місці. 00:09:45.060 --> 00:09:47.480 Ніхто не повинен вирішувати одну і ту саму проблему двічі. 00:09:47.480 --> 00:09:53.440 Перенаправлення справи в потрібну чергу і до потрібної людини – це лише початок роботи, а клієнт очікує на відповідь у визначений термін. 00:09:53.580 --> 00:09:56.660 Виконання обіцянок за допомогою SLA та керованої роботи. 00:09:56.780 --> 00:10:01.900 Направити справу до потрібної людини – це лише половина справи, оскільки клієнт також очікує допомоги в межах обіцяного вами часу. 00:10:02.020 --> 00:10:06.080 І саме тут на допомогу приходить угода про рівень обслуговування, я буду називати її SLA. 00:10:06.080 --> 00:10:13.960 SLA додає таймер до справи, тому команда точно знає, скільки часу у них є, щоб виконати обіцянку перед клієнтом, будь-то перша відповідь чи повне вирішення проблеми. 00:10:14.040 --> 00:10:17.840 Але тут важливо врахувати нюанс. Це не завжди один і той самий дедлайн. 00:10:18.020 --> 00:10:24.580 Візьмемо клієнта, який очікує підтвердження протягом один години, навіть якщо технічній команді потрібно два робочі дні, щоб знайти та протестувати виправлення. 00:10:24.580 --> 00:10:32.840 Dynamics 365 окремо відстежує цільовий час першої відповіді та цільовий час вирішення, щоб команда могла діяти швидко, не вдаючи, що кожну проблему можна виправити миттєво. 00:10:32.980 --> 00:10:35.780 Тепер уявіть клієнта, у якого перестав працювати сервіс. 00:10:35.780 --> 00:10:42.860 Вони не очікують повного ремонту за 10 хвилин, але вони очікують, що хтось підтвердить, що проблема відома, пояснить, що буде далі і триматиме їх у курсі. 00:10:42.980 --> 00:10:48.580 Цільовий показник першої відповіді відстежує цей перший контакт, тоді як показник вирішення відстежує повний шлях до відповіді або виправлення. 00:10:54.580 --> 00:11:24.520 Звернення, яке має багатовільного часу, потребує роботи, але звернення, що наближається до дедлайну відповіді, потребує уваги негайно. 00:11:24.580 --> 00:11:31.960 Команди також можуть налаштувати сповіщення або кроки ескалації, коли ціль близька або вже минула, щоб керівник міг втрутитися до того, як клієнт почне вимагати реакції. 00:11:32.120 --> 00:11:36.060 Часові цілі керують терміновістю, а бізнес-процеси керують самою роботою. 00:11:36.240 --> 00:11:39.600 Бізнес-процес – це набір етапів, що відображаються всередині звернення. 00:11:39.780 --> 00:11:44.420 Він дає агенту чіткий шлях, якого слід дотримуватися відповідно до того, як організація хоче обробляти звернення. 00:11:44.420 --> 00:11:49.420 Етапи можуть переходити від отримання до розслідування та вирішення з правильними запитаннями та перевірками на кожному кроці. 00:11:49.600 --> 00:11:52.420 Уявіть це як контрольний список, що займає своє місце в процесі. 00:11:52.580 --> 00:11:56.620 Новому агенту не потрібно вгадувати, які деталі важливі перед передачею звернення фахівцю. 00:11:56.740 --> 00:12:01.360 Потік може запитати продукт, тип проблеми, вплив та іншу інформацію, необхідну наступній команді. 00:12:01.640 --> 00:12:06.320 Досвідченіший агент може працювати швидше, але спільний шлях все одно спрямовує команду в одному напрямку. 00:12:06.480 --> 00:12:07.220 Ось сценарій. 00:12:07.220 --> 00:12:09.800 Надходить повідомлення про збій високого пріоритету. 00:12:10.000 --> 00:12:13.660 Звернення потрапляє в термінову чергу, і його СЛА починає зворотний відлік. 00:12:13.780 --> 00:12:19.540 Агент підтверджує дані клієнта, фіксує вплив і надсилає першу відповідь до завершення терміну відповіді. 00:12:19.720 --> 00:12:25.680 Далі процес переводить звернення на етап діагностики, де команда збирає деталі помилок і перевіряє пов'язані звіти. 00:12:25.880 --> 00:12:30.720 Потім звернення переходить до вирішення, коли команда визначає причину та готує оновлення для клієнта. 00:12:30.720 --> 00:12:33.600 Ця послідовність також дає керівникам чіткішу картину. 00:12:37.220 --> 00:12:43.360 Це остаточної відповіді клієнту. Цей процес не розв'язує всі проблеми команди, але запобігає пропускам важливих етапів протягом завантаженого дня. 00:12:43.580 --> 00:12:48.320 Dynamics 365 також може контролювати, які зміни статусу доступні агентам на різних етапах. 00:12:48.460 --> 00:12:52.580 Це називається переходами за станом, що звучить технічно, але ідея досить проста. 00:12:52.800 --> 00:12:55.280 Звернення повинно проходити через логічні етапи. 00:12:55.280 --> 00:13:02.340 Ви ж не хочете, щоб хтось позначив звернення як вирішене, поки воно чекає на перевірку або одразу скасував нове звернення без пояснення причин. 00:13:02.340 --> 00:13:05.400 Доступні варіанти можуть змінюватися залежно від стану звернення. 00:13:05.580 --> 00:13:10.080 Наприклад, під час розслідування агент може призупинити звернення, очікуючи на деталі від клієнта. 00:13:10.260 --> 00:13:13.380 Після того, як клієнт відповість, агент може повернути його до активної роботи. 00:13:13.500 --> 00:13:16.180 Коли проблему виправлено, звернення можна перевести у статус «Вирішено». 00:13:16.180 --> 00:13:18.060 Це дозволяє вести чіткішу історію звернень. 00:13:18.060 --> 00:13:20.020 Сама лише відповідь не завершує роботу. 00:13:20.180 --> 00:13:23.540 Команда має зафіксувати результат і належним чином закрити звернення. 00:13:23.540 --> 00:13:26.180 Вирішення, навчання та краще обслуговування. 00:13:26.380 --> 00:13:29.040 Надсилання відповіді не закриває звернення автоматично. 00:13:29.220 --> 00:13:34.740 Команда має задокументувати вирішення, записати, що саме допомогло усунути проблему або яку остаточну відповідь отримав клієнт. 00:13:34.880 --> 00:13:40.460 Це може бути надсилання нового пристрою, повернення коштів за подвійний платіж або налаштування доступу користувачем. 00:13:40.460 --> 00:13:48.200 Ця примітка стає частиною історії клієнта, надаючи наступному агенту корисну інформацію, якщо клієнт знову звернеться з подібною проблемою через місяці. 00:13:48.200 --> 00:13:53.360 Інколи перше рішення не спрацьовує. Можливо, клієнт виконав інструкції, але помилка знову з'явилася. 00:13:53.540 --> 00:13:56.000 Можливо, заміна деталі не усунула несправність. 00:13:56.120 --> 00:14:02.400 У такій ситуації команда може знову відкрити звернення або повернути його в чергу на доопрацювання замість створення нового запису без історії. 00:14:02.400 --> 00:14:07.320 Робота зі зверненням продовжується з того місця, де зупинилися. Це важливо, коли змінюється відповідальний агент. 00:14:07.480 --> 00:14:11.760 Новий агент бачить, що робив попередній, що підтвердив клієнт і що ще потрібно перевірити. 00:14:11.760 --> 00:14:16.600 Клієнту не потрібно пояснювати всю історію спочатку лише тому, що за роботу взялася інша людина. 00:14:16.820 --> 00:14:21.540 З часом усі ці дані допомагають службі підтримки зрозуміти ширшу картину, а не лише окремі проблеми клієнтів. 00:14:21.680 --> 00:14:26.560 Керівники можуть аналізувати час до вирішення, показник того, скільки часу минає від відкриття до закриття звернення. 00:14:26.560 --> 00:14:30.120 Вони можуть відстежувати час на кожному етапі, щоб бачити, де затримується робота. 00:14:30.120 --> 00:14:36.240 Також можна контролювати вирішення при першому контакті, тобто як часто спеціаліст може розв'язати проблему без перенаправлення до інших колег. 00:14:36.460 --> 00:14:37.980 Навантаження теж має значення. 00:14:38.160 --> 00:14:41.380 Якщо черга переповнюється кожного понеділка вранці, команда це бачить. 00:14:41.520 --> 00:14:45.980 Якщо технічні запити днями чекають на внутрішню перевірку, ця затримка відображається в даних. 00:14:45.980 --> 00:14:52.420 Якщо одна команда закриває справи швидко, але клієнти постійно їх відкривають знову, у команди є привід перевірити якість цих перших рішень. 00:14:52.540 --> 00:14:54.580 Цифри самі по собі не пояснюють усього. 00:14:54.580 --> 00:14:57.280 Вони підказують команді, які питання варто поставити. 00:14:57.420 --> 00:14:59.740 Чому кількість запитів щодо певного продукту зростає? 00:14:59.860 --> 00:15:02.420 Чому певний тип справ триває довше, ніж очікувалося? 00:15:02.560 --> 00:15:06.900 Чому агенти постійно шукають одну і ту саму відповідь, але не знаходять корисної довідкової статті? 00:15:07.040 --> 00:15:09.760 Шаблони перетворюють щоденну підтримку на практичний досвід. 00:15:09.760 --> 00:15:12.480 Зростання схожих справ може вказувати на несправність продукту. 00:15:12.600 --> 00:15:15.360 Це може свідчити про те, що нещодавнє оновлення збило клієнтів з пантелику. 00:15:15.520 --> 00:15:18.140 Це може виявити, що інструкції потребують чіткіших кроків. 00:15:18.320 --> 00:15:22.260 Замість того, щоб сприймати кожен запит окремо, команда може помітити спільну причину та працювати з нею. 00:15:22.400 --> 00:15:24.360 Це може зменшити кількість запитів у майбутньому. 00:15:24.540 --> 00:15:27.000 Відгуки клієнтів також є важливою частиною цієї картини. 00:15:27.000 --> 00:15:33.020 Закрита справа може свідчити про виконання цілі, але клієнт може бути розчарованим, якщо йому довелося звертатися тричі. 00:15:33.140 --> 00:15:37.380 Аналіз історії справи та відгуків дає менеджерам повніше уявлення про досвід користувача. 00:15:37.380 --> 00:15:39.980 Деякі клієнти воліють взагалі не створювати запит. 00:15:40.120 --> 00:15:42.320 Ось тут допоможе портал самообслуговування. 00:15:42.500 --> 00:15:49.940 Через портал клієнти можуть створити запит, перевірити статус, додати інформацію або прочитати статті, не телефонуючи до служби підтримки. 00:15:49.940 --> 00:15:52.640 Для простих питань це економить час для всіх. 00:15:52.720 --> 00:15:57.200 Клієнт може перевірити статус доставки або прочитати інструкцію тоді, коли йому зручно. 00:15:57.380 --> 00:16:02.560 Тим часом агенти можуть приділяти більше часу проблемам, де потрібне дослідження, пояснення чи рішення людини. 00:16:02.560 --> 00:16:07.780 Dynamics 365 Customer Service також інтегрується зі звичними інструментами Microsoft для роботи з запитами. 00:16:07.940 --> 00:16:10.380 Агент може працювати з електронною поштою через Outlook. 00:16:10.560 --> 00:16:12.780 Команда може обговорити складну проблему в Teams. 00:16:13.000 --> 00:16:15.800 Документи та спільна інформація можуть зберігатися в SharePoint. 00:16:15.800 --> 00:16:23.320 Power BI перетворює дані на звіти та дашборди, а інструменти Power Platform підтримують форми, сповіщення чи автоматизацію процесів. 00:16:23.460 --> 00:16:25.260 Кожен інструмент має свою роль. 00:16:25.260 --> 00:16:32.340 Справа залишається місцем, де проблема та її історія пов'язані, навіть коли використовуються інші інструменти для спілкування чи обміну файлами. 00:16:32.480 --> 00:16:35.300 Управління справами – це не просто заповнення форми запиту. 00:16:35.300 --> 00:16:40.800 Це забезпечення кожної проблеми клієнта чітким шляхом, задокументованою відповіддю та командою, яка вчиться на досвіді. 00:16:40.900 --> 00:16:43.940 Висновок. Тримайте всю історію клієнта в одному місці. 00:16:44.100 --> 00:16:45.800 Отже, головний висновок такий. 00:16:45.940 --> 00:16:51.720 Керування зверненнями в Dynamics 365 зберігає проблему, роботу, обіцянки та результат в одному записі. 00:16:51.720 --> 00:16:54.120 Жодної втрати контексту чи повторних виправлень. 00:16:54.240 --> 00:16:56.000 Погляньте на власний процес підтримки. 00:16:56.180 --> 00:16:58.420 Ой, куди ж зникає інформація про клієнтів. 00:16:58.420 --> 00:17:01.060 Саме тут об'єднання всього в одне ціле змінює все. 00:17:01.180 --> 00:17:05.080 Підписуйтеся на своїй улюбленій подкаст-платформі, щоб отримувати більше знань про Microsoft від мене, 00:17:05.180 --> 00:17:10.680 Мірко Петерса, на m365.fm, де ми простою мовою пояснюємо інструменти Microsoft для повсякденної роботи.