Клієнт пише електронного листа про пошкоджене замовлення, наступного дня телефонує, потім відкриває чат, бо ніхто не знає, що сталося, і він щоразу повторює одну й ту саму історію, поки ваша служба підтримки шукає інформацію в пошті, нотатках та окремих інструментах. Саме це і вирішує система управління зверненнями Dynamics 365. Уявіть звернення як одну підписану папку в офісній будівлі, куди потрапляє кожна деталь проблеми клієнта, від першого запитання до остаточної відповіді. З вами Мірко Петерс з М365FM, і в цьому короткому огляді ви дізнаєтеся, як пов'язані між собою звернення, маршрутизація, терміни відповіді, довідкові статті та закриття справ. Що таке звернення? Коротко, у 20 словах. Отже, що саме таке звернення? Звернення – це один запис про одну проблему клієнта, яка потребує відповіді чи вирішення, наприклад, пошкоджений товар, запитання щодо рахунку, проблеми з входом або запит на допомогу з послугою.

Важливо розуміти, один клієнт може мати кілька звернень одночасно. Один клієнт може запитати про рахунок у понеділок, повідомити про несправність пристрою у вівторок і потребувати допомоги зі зміною адреси в п'ятницю. Це окремі проблеми, тому Dynamics 365 зберігає їх в окремих записах, а не звалює всі розмови в одну заплутану чергу. Коли агент створює звернення, він одразу пов'язує його з клієнтом. Цим клієнтом може бути контакт, тобто конкретна особа або організація, компанія, у якій вона працює. Тож, якщо Джеймі з Носвіндтрейдас повідомляє про проблему, звернення може стосуватися і Джеймі, і компанії, тому будь-хто, хто відкриє запис, побачить, кому потрібна допомога та до якої організації належить це питання. Звернення також потребує чіткого опису проблеми, зазвичай із заголовком на кшталт «Принтер зупинився після оновлення ПЕЗЕ» або «З клієнта зняли оплату двічі», що допомагає швидко переглядати список відкритих справ, не відкриваючи кожен запис.

Під заголовком «Агент» додає деталі. Що сталося, коли це почалося? Що клієнт уже спробував зробити? Якого продукту це стосується? І чи це запитання, запит чи технічна несправність? Ці деталі перетворюють розмите повідомлення на конкретну роботу, яку хтось може взяти на себе та вирішити. Розберімо це докладніше. Звернення може містити тему, продукт, пріоритет і тип запиту. Тема групує проблему за напрямком, як-от виставлення рахунків чи технічна підтримка, продукт визначає, що використовує клієнт, пріоритет підказує команді, як швидко звернути на це увагу, а тип звернення надає ще один спосіб сортування роботи згідно з процесом підтримки. Жодне з цих полів саме по собі не вирішує проблему клієнта, але вони допомагають команді підтримки чітко бачити обсяг роботи, особливо коли надходять сотні звернень від різних клієнтів. Команда, що працює з серйозним збоєм у сервісі, не повинна витрачати час на пошук серед загальних запитань.

Отже, звернення – це не просто форма, яку хтось заповнив і забув. Це робочий запис усієї комунікації з клієнтом. Електронні листи можна прив'язати до звернення, сюди ж потрапляють телефонні дзвінки, а агент може додати примітки після чату, створити завдання на виконання або записати зустріч. Кожна дія зберігається разом із проблемою клієнта, тому наступному спеціалісту не доведеться збирати історію з нуля. Уявіть, що агент починає роботу вранці, а після обіду передає звернення фахівцю з продукту. Без запису звернення спеціаліст може отримати лише коротке повідомлення на кшталт «Ой, можеш подивитися на це». Чого недостатньо? Завдяки запису звернення вони бачать початкову проблему, деталі про клієнта, хід розмови та те, що перший агент уже перевірив. Це значно полегшує передачу справ. Dynamics 365 підтримує чіткий статус звернення під час проходження через процес підтримки. Воно залишається активним, поки команда проводить розслідування, а коли проблему вирішено або надано фінальну відповідь, звернення закривається.

Якщо запит більше не потребує роботи, наприклад, через помилку або відмову клієнта, команда може його скасувати. Активне, вирішене та скасоване. Ці три стани забезпечують команді спільне бачення етапу роботи над кожною проблемою. Нікому не потрібно вгадувати, чи потребує звернення уваги, а менеджерам не доводиться приймати завершену роботу за нову проблему. Один запис забезпечує контроль, а повна історія клієнта надає агенту контекст. Історія клієнта, що стоїть за зверненням. Звернення вказує на те, що потрібно виправити. Запис про клієнта пояснює, що призвело до цієї ситуації. Коли агент відкриває звернення в Dynamics 365 Customer Service, він може зазирнути далі за останнє повідомлення. Він бачить ширшу картину, попередні звернення, минулі листи, продукти, пов'язані з клієнтом та історію його підтримки. Контекст змінює розмову. Чому контекст важливий? Уявіть, що клієнт повідомляє про вихід пристрою з ладу.

Якщо агент бачить лише сьогоднішнє повідомлення, він може почати з базових запитань. Яка це модель? Коли це почалося? Ви перезапускали його. Але клієнт уже двічі звертався до служби підтримки цього тижня. Перший агент надіслав інструкції з усунення несправностей, другий організував заміну деталі. Третій агент, який бачить цю історію, не проситиме клієнта починати все спочатку. Натомість він скаже, я бачу, що ви вже спробували ці кроки і заміна деталі не допомогла. Давайте спробуємо щось інше. Це зовсім не те саме, що чи можете ви ще раз пояснити проблему. Це часто називають повним уявленням про клієнта 360 градусів. Назва звучить вишукано, але все просто. Це означає, що агент бачить клієнта з різних боків, а не лише через одне окреме повідомлення. Агент бачить людину, компанію, попередні запити до підтримки, минулі розмови та пов'язані з ними продукти. Для команди підтримки це замінює з догадки чіткою відправною точкою.

Звісно, не кожен клієнт отримує однаковий рівень підтримки. Клієнт міг придбати гарантію, його компанія може оплачувати певну кількість годин підтримки або мати контракт на певну кількість звернень чи преміум підтримку зі швидшою допомогою. Dynamics 365 відстежує все це через право на обслуговування. Право на обслуговування – це угода про підтримку клієнта всередині системи. Сприймайте це як умови обслуговування, прив'язані до їхнього облікового запису. Перш ніж агент пообіцяє візит інженера або розпочне платну роботу, він перевіряє умови підтримки. Це допомагає уникнути незручних сюрпризів. Наприклад, клієнт може все ще мати гарантійне покриття на несправний продукт. Звернення може йти за відповідним сценарієм. Інший клієнт міг уже використати всі свої години підтримки. Агент бачить це перед тим, як взяти на себе роботу поза межами угоди. Це також допомагає команді підтримки ставитися до клієнтів справедливо.

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

Короткі огляди звернень Co-Pilot допомагають розв'язати ще одну поширену проблему – довгу історію звернень. З часом у зверненні може накопичитися безліч електронних листів, нотаток та оновлень.

Це швидкий брифінг перед тим, як агент розпочне роботу. Агент все одно перевіряє запис і використовує власне судження, але швидше входить у курс справи. Це допомагає, коли клієнт чекає, а звернення вже пройшло через кілька рук. Коли агент розуміє клієнта та проблему, звернення має потрапити до потрібної людини. Від отримання до правильної черги. Клієнт може звернутися по допомогу різними способами – електронною поштою, телефоном, чатом, у соцмережах чи через портал самообслуговування. Канал зв'язку змінюється, але службі підтримки потрібне єдине місце для керування запитами. Dynamics 365 може створювати звернення на основі цих розмов, якщо налаштовано правила створення записів. Уявіть електронний лист, що надходить на спільну адресу підтримки. Замість того, щоб лежати в поштовій скринці, поки його помітять, правило перетворює цей лист на звернення. Повідомлення стає початком роботи в системі обслуговування клієнтів.

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

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

Ручне призначення дає команді простір для такого людського вибору. Відповідальний за справу може змінюватися під час її опрацювання. Агенту може знадобитися більше інформації, і він поверне справу в чергу. Команда може виявити, що питання належить до іншого відділу, або терміновий запит може потребувати ескалації, коли звичайна команда не може його вирішити. Dynamics 365 забезпечує рух роботи, замість того, щоб залишати її в того, хто зайшов у глухий кут. Іноді одна проблема створює багато справ. Уявіть збій у програмному забезпеченні, що впливає на десятки клієнтів. Кожен клієнт звертається до підтримки окремо, тому кожне повідомлення потребує власної справи. Але всі звіти пов'язані з однією ширшою проблемою. Батьківська справа відстежує цю загальну проблему, тоді як дочірні справи відстежують окремі звіти клієнтів під нею. Це дає команді підтримки два погляди одночасно. Вони працюють над основним збоєм через батьківську справу, тоді як кожна дочірня справа тримає відповідного клієнта в курсі.

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

SLA додає таймер до справи, тому команда точно знає, скільки часу у них є, щоб виконати обіцянку перед клієнтом, будь-то перша відповідь чи повне вирішення проблеми. Але тут важливо врахувати нюанс. Це не завжди один і той самий дедлайн. Візьмемо клієнта, який очікує підтвердження протягом один години, навіть якщо технічній команді потрібно два робочі дні, щоб знайти та протестувати виправлення. Dynamics 365 окремо відстежує цільовий час першої відповіді та цільовий час вирішення, щоб команда могла діяти швидко, не вдаючи, що кожну проблему можна виправити миттєво. Тепер уявіть клієнта, у якого перестав працювати сервіс. Вони не очікують повного ремонту за 10 хвилин, але вони очікують, що хтось підтвердить, що проблема відома, пояснить, що буде далі і триматиме їх у курсі. Цільовий показник першої відповіді відстежує цей перший контакт, тоді як показник вирішення відстежує повний шлях до відповіді або виправлення.

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

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

Це остаточної відповіді клієнту. Цей процес не розв'язує всі проблеми команди, але запобігає пропускам важливих етапів протягом завантаженого дня. Dynamics 365 також може контролювати, які зміни статусу доступні агентам на різних етапах. Це називається переходами за станом, що звучить технічно, але ідея досить проста. Звернення повинно проходити через логічні етапи. Ви ж не хочете, щоб хтось позначив звернення як вирішене, поки воно чекає на перевірку або одразу скасував нове звернення без пояснення причин. Доступні варіанти можуть змінюватися залежно від стану звернення. Наприклад, під час розслідування агент може призупинити звернення, очікуючи на деталі від клієнта. Після того, як клієнт відповість, агент може повернути його до активної роботи. Коли проблему виправлено, звернення можна перевести у статус «Вирішено». Це дозволяє вести чіткішу історію звернень. Сама лише відповідь не завершує роботу.

Команда має зафіксувати результат і належним чином закрити звернення. Вирішення, навчання та краще обслуговування. Надсилання відповіді не закриває звернення автоматично. Команда має задокументувати вирішення, записати, що саме допомогло усунути проблему або яку остаточну відповідь отримав клієнт. Це може бути надсилання нового пристрою, повернення коштів за подвійний платіж або налаштування доступу користувачем. Ця примітка стає частиною історії клієнта, надаючи наступному агенту корисну інформацію, якщо клієнт знову звернеться з подібною проблемою через місяці. Інколи перше рішення не спрацьовує. Можливо, клієнт виконав інструкції, але помилка знову з'явилася. Можливо, заміна деталі не усунула несправність. У такій ситуації команда може знову відкрити звернення або повернути його в чергу на доопрацювання замість створення нового запису без історії. Робота зі зверненням продовжується з того місця, де зупинилися. Це важливо, коли змінюється відповідальний агент.

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

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

Деякі клієнти воліють взагалі не створювати запит. Ось тут допоможе портал самообслуговування. Через портал клієнти можуть створити запит, перевірити статус, додати інформацію або прочитати статті, не телефонуючи до служби підтримки. Для простих питань це економить час для всіх. Клієнт може перевірити статус доставки або прочитати інструкцію тоді, коли йому зручно. Тим часом агенти можуть приділяти більше часу проблемам, де потрібне дослідження, пояснення чи рішення людини. Dynamics 365 Customer Service також інтегрується зі звичними інструментами Microsoft для роботи з запитами. Агент може працювати з електронною поштою через Outlook. Команда може обговорити складну проблему в Teams. Документи та спільна інформація можуть зберігатися в SharePoint. Power BI перетворює дані на звіти та дашборди, а інструменти Power Platform підтримують форми, сповіщення чи автоматизацію процесів. Кожен інструмент має свою роль.

Справа залишається місцем, де проблема та її історія пов'язані, навіть коли використовуються інші інструменти для спілкування чи обміну файлами. Управління справами – це не просто заповнення форми запиту. Це забезпечення кожної проблеми клієнта чітким шляхом, задокументованою відповіддю та командою, яка вчиться на досвіді. Висновок. Тримайте всю історію клієнта в одному місці. Отже, головний висновок такий. Керування зверненнями в Dynamics 365 зберігає проблему, роботу, обіцянки та результат в одному записі. Жодної втрати контексту чи повторних виправлень. Погляньте на власний процес підтримки. Ой, куди ж зникає інформація про клієнтів. Саме тут об'єднання всього в одне ціле змінює все. Підписуйтеся на своїй улюбленій подкаст-платформі, щоб отримувати більше знань про Microsoft від мене, Мірко Петерса, на m365.fm, де ми простою мовою пояснюємо інструменти Microsoft для повсякденної роботи.