Klient pisze e-mail w sprawie zepsutego zamówienia, potem dzwoni następnego dnia, a następnie otwiera czat, ponieważ nikt nie wie, co się stało i za każdym razem powtarza tę samą historię, podczas gdy Twój zespół wsparcia przeszukuje skrzynki odbiorcze, notatki i osobne narzędzia. To właśnie rozwiązuje zarządzanie zgłoszeniami w Dynamics 365. Pomyśl o zgłoszeniu jak o jednej opisanej teczce w ruchliwym biurowcu, do której trafia każdy element problemu klienta od pierwszego pytania aż po ostateczną odpowiedź. Jesteś Mirko Petersem z M365FM i w tej pigułce wiedzy zobaczysz, jak zgłoszenia, przydzielanie, terminy odpowiedzi, artykuły wsparcia i zamykanie spraw łączą się w całość. Czym właściwie jest zgłoszenie w 20 słowach? Czym więc dokładnie jest zgłoszenie? Zgłoszenie to jeden rekord dotyczący jednego problemu klienta, który wymaga odpowiedzi lub naprawy. Może to być uszkodzony produkt, pytanie o rozliczenie, problem z logowaniem lub prośba o pomoc w korzystaniu z usługi.

Oto kwestia. Jeden klient może mieć kilka zgłoszeń jednocześnie. Jeden klient może zapytać o fakturę w poniedziałek, zgłosić awarię urządzenia we wtorek i potrzebować pomocy przy zmianie adresu w piątek. To oddzielne problemy, więc Dynamics 365 przechowuje je w osobnych rekordach zgłoszeń, zamiast gromadzić każdą rozmowę w jednym mylącym wątku. Kiedy agent tworzy zgłoszenie, łączy je bezpośrednio z klientem. Tym klientem może być kontakt, czyli osoba fizyczna lub konto, czyli firma, dla której pracuje. Jeśli więc Jamies Norwind Traders zgłosi problem, zgłoszenie może wskazywać zarówno na Jamie'ego, jak i na firmę, dzięki czemu każdy otwierający rekord widzi, kto potrzebuje pomocy i do której organizacji należy sprawa. Zgłoszenie wymaga również prostego opisu problemu, zazwyczaj zaczynającego się od tytułu, takiego jak drukarka przestała działać po aktualizacji oprogramowania lub klient obciążony dwukrotnie za plan roczny, co pozwala szybko przejrzeć listę otwartych spraw bez otwierania każdego rekordu.

Pod tym tytułem agent dodaje szczegóły. Co się stało? Kiedy to się zaczęło? Co klient już wypróbował? Którego produktu dotyczy? Oraz czy jest to pytanie, prośba czy usterka? Te szczegóły zamieniają niejasną wiadomość w zadanie, które ktoś może przejąć i rozwiązać. Rozbijmy to na czynniki pierwsze. Zgłoszenie może zawierać temat produkt, priorytet i typ zgłoszenia. Temat grupuje zgłoszenie w obszar taki jak rozliczenia lub wsparcie techniczne. Jak produkt określa, z czego korzysta klient, priorytet informuje zespół, jak szybko należy się nim zająć, a typ sprawy daje zespołowi kolejny sposób sortowania pracy w oparciu o ich proces wsparcia. Żadne z tych pól nie rozwiązuje samo w sobie problemu klienta, ale pomagają zespołowi wsparcia wyraźnie widzieć pracę, zwłaszcza gdy napływają setki zgłoszeń od różnych klientów. Zespół zajmujący się poważną awarią usługi nie powinien musieć przeszukiwać ogólnych pytań, aby ją znaleźć.

Sprawa to nie tylko formularz, który ktoś wypełnia i o nim zapomina. Staje się ona rekordem roboczym dla całej konwersacji. Do sprawy można dołączać wiadomości e-mail, mogą pojawiać się w niej połączenia telefoniczne, a agent może dodawać notatki po czacie, ustawiać zadania kontrolne lub rejestrować spotkania. Każda aktywność jest przypisana do tego samego problemu klienta, więc kolejna osoba nie musi odtwarzać historii od zera. Wyobraźmy sobie, że agent zaczyna pracę rano, a po lunchu przekazuje sprawę specjaliście do spraw produktu. Bez rekordu sprawy specjalista mógłby otrzymać tylko krótką wiadomość – hej, możesz na to zerknąć? Co jest niewystarczające? Dzięki rekordowi sprawy specjalista widzi pierwotny problem, dane klienta, przebieg rozmowy oraz to, co sprawdził już pierwszy agent. To zapewnia znacznie lepsze przekazanie sprawy. Dynamics 365 utrzymuje sprawę w jasnym stanie, podczas gdy przechodzi ona przez proces wsparcia.

Może ona pozostać aktywna podczas badania przez zespół, a gdy zespół naprawi problem lub udzieli ostatecznej odpowiedzi, zamyka ją. Jeśli zgłoszenie nie wymaga już pracy, np. wpłynęło przez pomyłkę lub klient się wycofał, zespół może je anulować. Aktywna, rozwiązana i anulowana. Te trzy stany zapewniają zespołowi wspólny wgląd w status każdego zgłoszenia, więc nikt nie musi zgadywać, czy sprawa nadal wymaga uwagi, a menedżerowie nie muszą traktować zakończonych prac jak nowych problemów klientów. Jeden rekord zapewnia kontrolę, a pełna historia klienta daje agentowi kontekst. Historia klienta kryjąca się za sprawą. Sprawa mówi Ci, co wymaga naprawy. Rekord klienta mówi Ci, co doprowadziło do tego momentu. Gdy agent otwiera sprawę w Dynamics 365 Customer Service, może spojrzeć dalej niż tylko na ostatnią wiadomość. Widzi szerszy obraz, wcześniejsze sprawy, dawne e-maile, produkty powiązane z klientem oraz historię jego wsparcia.

Kontekst zmienia rozmowę. Dlaczego kontekst ma znaczenie? Wyobraź sobie, że klient zgłasza awarię urządzenia. Jeśli agent widzi tylko dzisiejszą wiadomość, może zacząć od podstawowych pytań. Jaki to model? Kiedy to się zaczęło? Czy urządzenie zostało zrestartowane? Ale klient kontaktował się już ze wsparciem dwa razy w tym tygodniu. Pierwszy agent wysłał instrukcję naprawy, drugi zorganizował część zamienną. Trzeci agent, widząc tę historię, nie każe klientowi zaczynać od nowa. Zamiast tego powie, widzę, że próbował już Pan tych kroków, a część zamienna nie pomogła. Spróbujmy czegoś innego. To zupełnie co innego niż pytanie, czy może Pan ponownie opisać problem? Często nazywa się to widokiem 360 stopni na klienta. Nazwa brzmi wymyślnie, ale to proste. Oznacza to, że agent widzi klienta z wielu stron, a nie tylko przez pryzmat jednej wiadomości. Agent widzi osobę, firmę, wcześniejsze zgłoszenia, poprzednie rozmowy i powiązane z nimi produkty.

Dla zespołu wsparcia zastępuje to domysły jasnym punktem wyjścia. Nie każdy klient otrzymuje taki sam rodzaj wsparcia. Klient mógł wykupić gwarancję. Firma może płacić za określoną liczbę godzin wsparcia lub mieć kontrakt obejmujący daną liczbę zgłoszeń czy wsparcie premium z szybszą pomocą. Dynamics 365 śledzi to wszystko za pomocą uprawnień. Uprawnienie to zapisana w systemie umowa o wsparcie techniczne dla klienta. Można o tym myśleć jak o warunkach serwisowych przypisanych do konta. Zanim agent obieca wizytę inżyniera lub rozpocznie płatne prace, sprawdza, jakie wsparcie przysługuje klientowi. Pozwala to uniknąć nieprzyjemnych niespodzianek. Na przykład klient może nadal mieć gwarancję na wadliwy produkt. Zgłoszenie może być procesowe in zgodnie z tą ścieżką. Inny klient mógł wykorzystać już wszystkie swoje godziny wsparcia. Agent widzi to, zanim podejmie się pracy wykraczającej poza umowę.

Pomaga to również zespołowi sprawiedliwie traktować klientów. Agent nie musi przeszukiwać starych umów ani pytać innych działów. Warunki wsparcia znajdują się przy informacjach o kliencie, dokładnie tam, gdzie agent może je znaleźć. Kolejną kwestią jest baza wiedzy. Zespoły wsparcia rozwiązują te same problemy raz za razem. Resetowanie haseł, instrukcje konfiguracji, znany błąd po aktualizacji, pytanie o fakturę ze standardową odpowiedzią. Artykuł z bazy wiedzy przechowuje taką odpowiedź w jednym miejscu. W obszarze roboczym usługi agent może wyszukiwać artykuły podczas pracy nad zgłoszeniem. Artykuł może zawierać proste wyjaśnienie, instrukcje, zrzut ekranu lub dokładną listę kontrolną dla zespołu. Zamiast pisać własną wersję z pamięci, każdy agent korzysta ze zweryfikowanej odpowiedzi zespołowej. Dzięki temu wsparcie jest spójne. Pomaga to również nowym agentom. Nie potrzebują lat doświadczenia, aby dobrze radzić sobie z typowymi problemami, ponieważ sprawdzone rozwiązania zespołu są dostępne, gdy są potrzebne.

Podsumowania spraw w Kopilocie pomagają w innym powszechnym problemie, długiej historii spraw. Sprawa może z czasem zgromadzić wiele e-maili, notatek i aktualizacji. Przeczytanie ich wszystkich zajmuje czas, zwłaszcza po przekazaniu sprawy. Kopilot tworzy krótkie podsumowanie sprawy, które gromadzi jej tytuł, klienta, temat, produkt, priorytet, typ, opis i ostatnią aktywność. To szybka odprawa przed rozpoczęciem pracy przez agenta. Agent nadal sprawdza rekord i używa własnego osądu, ale rozumie sytuację szybciej. Pomaga to, gdy klient czeka, a sprawa przeszła przez kilka osób. Gdy agent zrozumie klienta i problem, sprawa musi trafić do odpowiedniej osoby. Od przyjęcia zgłoszenia do właściwej kolejki. Klient może poprosić o pomoc na wiele sposobów. E-mail, telefon, czat, media społecznościowe, portal samoobsługowy. Kanał się zmienia, ale zespół wsparcia nadal potrzebuje jednego jasnego miejsca do zarządzania wnioskiem.

Dynamics 365 może tworzyć sprawy z tych rozmów, jeśli konfiguracja obejmuje reguły tworzenia rekordów. Pomyśl o e-mailu docierającym na wspólny adres wsparcia. Zamiast zostawiać go w skrzynce, aż ktoś go zauważy, reguła zamienia ten e-mail w sprawę. Wiadomość staje się początkiem pracy wewnątrz obsługi klienta. Ogranicza to ręczne kopiowanie danych. Ta sama zasada dotyczy innych połączonych kanałów. Zespół wybiera, które wiadomości tworzą nową sprawę, a które należą do istniejącej. Odpowiedź na otwarty problem pozostaje przypisana do tego problemu. Nowe pytanie otrzymuje własną sprawę. Następnie sprawa potrzebuje miejsca, dopóki ktoś nie przejmie za nią odpowiedzialności. Tym miejscem jest często kolejka. Kolejka to wspólny zasobnik zadań dla zespołu. To nie jest skrzynka odbiorcza jednego agenta i nie należy do osoby, która zobaczyła zgłoszenie. Zamiast tego daje całemu zespołowi miejsce, gdzie widać pracę oczekującą na uwagę.

Wyobraź sobie firmę z działem rozliczeń, zespołem wsparcia technicznego i działem zwrotów. Każdy zespół ma własną kolejkę. Pytania o rozliczenia trafiają do rozliczeń usterki produktów do wsparcia technicznego, wnioski o zwrot do osób znających proces zwrotów. Brzmi to prosto, ponieważ takie właśnie jest. Jasne sortowanie chroni ludzi przed bezmyślnym przekazywaniem zadań. Reguły routingu pomagają w takim sortowaniu. Reguła routingu sprawdza szczegóły sprawy i wysyła ją do właściwej kolejki lub osoby. Sprawa dotycząca konkretnego produktu trafia do zespołu produktowego. Sprawa z określonego regionu trafia do lokalnego wsparcia. Poważny problem trafia do kolejki pilnej. Ogólne pytanie czeka w standardowym zespole. Niektóre organizacje rozdzielają pracę na podstawie umiejętności. Na przykład klient piszący po francusku potrzebuje agenta, który mówi po francusku. Problem techniczny wymaga osoby przeszkolonej w zakresie konkretnego produktu.

Dzięki kierowaniu zgłoszenia trafiają do osoby, która może je rozwiązać, zamiast traktować każde z nich jednakowo. Automatyzacja pomaga, ale to ludzie nadal podejmują decyzję. Kierownik zespołu może przyjrzeć się trudnej sprawie i przypisać ją bezpośrednio starszemu agentowi. Może ktoś już zna danego klienta. Być może problem dotyczy kilku produktów i wymaga doświadczenia, którego nie oceni żadna reguła. Ręczne przypisywanie daje zespołowi przestrzeń na taką ludzką decyzję. Właściciel sprawy może się zmieniać w trakcie jej trwania. Agent może potrzebować więcej informacji i zwrócić sprawę do kolejki. Zespół może odkryć, że sprawa należy do innego działu lub pilne zgłoszenie może wymagać eskalacji, gdy zwykły zespół nie może go rozwiązać. Dynamics 365 sprawia, że praca posuwa się do przodu zamiast utknąć u kogoś, kto nie może jej ruszyć. Czasami jeden problem powoduje powstanie wielu spraw.

Wyobraźmy sobie awarię oprogramowania, która dotyka dziesiątki klientów. Każdy klient kontaktuje się z pomocą techniczną oddzielnie, więc każde zgłoszenie wymaga własnej sprawy. Wszystkie zgłoszenia łączą się jednak z jednym większym problemem. Sprawa nadrzędna śledzi szerszy problem, podczas gdy sprawy podrzędne śledzą indywidualne zgłoszenia klientów. Daje to zespołowi pomocy technicznej dwa widoki jednocześnie. Pracują nad podstawową awarią w ramach sprawy nadrzędnej, podczas gdy każda sprawa podrzędna informuje odpowiedniego klienta. Kiedy znajdą rozwiązanie, nie muszą badać tej samej awarii od nowa dla każdego dzwoniącego. Zduplikowane sprawy tworzą podobny problem na mniejszą skalę. Klient może wysłać e-mail i zadzwonić w tej samej sprawie, lub dwóch agentów może otworzyć sprawy, zanim zauważą, że zrobił to ktoś inny. Zamiast rozpraszać wysiłki, zespół może scalić podobne sprawy. Jedna sprawa staje się głównym rekordem, a praca pozostaje w jednym miejscu.

Nikt nie powinien rozwiązywać tego samego problemu dwukrotnie. Dostarczenie sprawy do właściwej kolejki i osoby rozpoczyna pracę, a klient oczekuje odpowiedzi w obiecanym terminie. Dotrzymywanie obietnic dzięki umowom SLA i pracy sterowanej. Przekazanie sprawy właściwej osobie to tylko połowa sukcesu, ponieważ klient oczekuje również pomocy w obiecanym czasie. I tutaj wchodzi umowa o poziomie świadczenia usług, czyli SLA. SLA dołącza zegar do sprawy, dzięki czemu zespół dokładnie wie, ile czasu ma na spełnienie obietnicy złożonej klientowi, niezależnie od tego, czy chodzi o pierwszą odpowiedź, czy pełne rozwiązanie problemu. Ale tutaj istotna jest automatyzacja. Nie zawsze są to te same terminy. Weźmy klienta, który oczekuje potwierdzenia w ciągu 1 godziny, nawet jeśli zespół techniczny potrzebuje dwóch dni roboczych na znalezienie i przetestowanie poprawki. Dynamics 365 śledzi oddzielnie cel pierwszej odpowiedzi i cel rozwiązania, dzięki czemu zespół może działać szybko, nie udając, że każdy problem da się naprawić natychmiast.

Wyobraźmy sobie klienta, któremu przestała działać usługa. Nie oczekuje on pełnej naprawy w 10 minut, ale spodziewa się, że ktoś potwierdzi przyjęcie zgłoszenia, wyjaśni dalsze kroki i będzie go informować o postępach. Cel pierwszej odpowiedzi śledzi ten pierwszy kontakt, podczas gdy cel rozwiązania śledzi pełną drogę do uzyskania odpowiedzi lub naprawy. Różni klienci mogą mieć różne obietnice. Firma z pakietem wsparcia premium otrzymuje szybsze cele odpowiedzi niż klient korzystający z planu standardowego. Awaria o wysokim priorytecie ma krótszy termin niż rutynowe pytanie typu, jak to zrobić? Umowy wsparcia, priorytet i typ sprawy kształtują obowiązujące reguły czasowe. Dzięki temu obietnice są uczciwe i jasne. Bez umów SLA agent mógłby pracować nad najstarszymi elementami z listy, podczas gdy sprawa wymagająca szybkiej reakcji po cichu przekracza swój termin. Dzięki SLA ekran sprawy pokazuje wskaźniki czasu, które informują agenta, która obietnica wymaga uwagi w pierwszej kolejności.

Widać więc narastającą presję. Sprawa z dużą ilością pozostałego czasu wymaga pracy, ale sprawa zbliżająca się do terminu odpowiedzi wymaga natychmiastowej uwagi. Zespoły mogą również ustawić alerty lub kroki eskalacji, gdy cel jest bliski lub już minął, aby przełożony mógł wkroczyć, zanim klient zacznie upominać się o rozwiązanie. Cele czasowe określają pilność, a przepływy procesów biznesowych prowadzą samą pracę. Przepływ procesu biznesowego to zestaw etapów widocznych wewnątrz sprawy. Daje on agentowi jasną ścieżkę do naśladowania w oparciu o to, jak organizacja chce obsługiwać sprawy. Etapy mogą prowadzić od przyjęcia zgłoszenia, przez dochodzenie, aż po rozwiązanie, z odpowiednimi pytaniami i kontrolami na każdym kroku. Pomyśl o tym jak o liście kontrolnej, która ma swoje miejsce w procesie. Nowy agent nie musi zgadywać, które szczegóły są istotne przed wysłaniem sprawy do specjalisty.

Przepływ może wymagać podania produktu typu problemu, wpływu i innych informacji potrzebnych następnemu zespołowi. Bardziej doświadczony agent może poruszać się szybciej, ale wspólna ścieżka sprawia, że cały zespół pracuje w tym samym kierunku. Oto scenariusz. Pojawia się awaria usługi o wysokim priorytecie. Sprawa trafia do pilnej kolejki, a jej SLA zaczyna odliczać czas. Agent potwierdza dane klienta, rejestruje wpływ i wysyła pierwszą odpowiedź, zanim cel odpowiedzi wygaśnie. Następnie przepływ procesu przenosi sprawę do diagnozy, gdzie zespół zbiera szczegóły błędu i sprawdza powiązane raporty. Sprawa przechodzi następnie do etapu rozwiązania, gdy zespół zidentyfikuje przyczynę i przygotuje aktualizację dla klienta. Ta sekwencja daje również menedżerom lepszy wgląd w sytuację. Mogą oni zobaczyć, gdzie zgłoszenie zwalnia podczas przyjmowania diagnozy lub ostatecznej odpowiedzi dla klienta.

Przepływ pracy nie rozwiązuje problemów zespołu, ale zapobiega pomijaniu podstawowych kroków w trakcie pracowitego dnia. Dynamics 365 może również kontrolować, jakie zmiany statusu agenci mogą wybierać w różnych momentach. Nazywa się to przejściami przyczyny statusu, co brzmi technicznie, ale sama koncepcja jest prosta. Zgłoszenie powinno przechodzić przez sensowne etapy. Chcesz, aby ktoś oznaczył zgłoszenie jako rozwiązane, gdy wciąż czeka ono na wymagane sprawdzenie wewnętrzne lub przechodził od nowego zgłoszenia prosto do anulowanego bez podania przyczyny. Dozwolone wybory mogą zmieniać się wraz ze zmianą stanu zgłoszenia. Na przykład zgłoszenie w trakcie badania może pozwolić agentowi na zawieszenie go w oczekiwaniu na szczegóły od klienta. Po odpowiedzi klienta agent może przywrócić je do aktywnej pracy. Gdy problem zostanie naprawiony, zgłoszenie może przejść do stanu rozwiązane. Tworzy to bardziej przejrzystą historię zgłoszenia.

Sama odpowiedź nie kończy jeszcze pracy. Zespół musi odnotować, jak zakończył się problem, a następnie prawidłowo zamknąć zgłoszenie. Rozwiązanie, nauka i lepsza obsługa. Wysłanie odpowiedzi nie zamyka automatycznie zgłoszenia. Zespół musi odnotować rozwiązanie, co oznacza zapisanie, co naprawiło problem lub jaką ostateczną odpowiedź otrzymał klient. Może to być wysłanie urządzenia zastępczego, zwrot podwójnej płatności lub aktualizacja ustawień, które blokowały dostęp. Ta notatka staje się częścią rekordu klienta i daje kolejnemu agentowi użyteczny punkt wyjścia, jeśli ten sam klient skontaktuje się ponownie z pomocą techniczną po miesiącach z podobnym problemem. Czasami pierwsze rozwiązanie nie działa. Może klient postępuje zgodnie z instrukcjami, a błąd powraca. Może część zamienna dociera, ale nie rozwiązuje usterki. W takiej sytuacji zespół może ponownie otworzyć zgłoszenie lub umieścić je z powrotem w kolejce do dalszej pracy, zamiast tworzyć zupełnie nowy rekord bez żadnej historii.

Zgłoszenie jest kontynuowane od miejsca, w którym zespół przerwał pracę. Ma to znaczenie przy zmianie właściciela zgłoszenia. Nowy agent może zobaczyć, co próbował zrobić poprzedni, co potwierdził klient i co jeszcze wymaga sprawdzenia. Klient nie musi wyjaśniać całej historii od początku tylko dlatego, że inną osobę przydzielono do pracy. Z czasem wszystkie te zgłoszenia mówią również zespołowi pomocy technicznej, co dzieje się poza pojedynczym problemem klienta. Menedżerowie mogą analizować czas do rozwiązania, który śledzi, jak długo trwają zgłoszenia od otwarcia do zamknięcia. Mogą sprawdzać czas etapu, który pokazuje, gdzie zgłoszenia spędzają najwięcej czasu. Mogą również monitorować wskaźnik rozwiązywania przy pierwszym kontakcie, czyli jak często pierwsza osoba rozmawiająca z klientem jest w stanie rozwiązać problem bez przekazywania go dalej. Obciążenie pracą również ma znaczenie.

Jeśli jakaś kolejka zapełnia się w każdy poniedziałek rano, zespół może to zauważyć. Jeśli zgłoszenia techniczne czekają dniami na weryfikację wewnętrzną, to opóźnienie widać w danych. Jeśli zespół szybko zamyka zgłoszenia, ale klienci wciąż je otwierają ponownie, warto przyjrzeć się jakości pierwszych napraw. Same liczby nie wyjaśniają wszystkiego. Wskazują one zespołowi, jakie pytania warto zadać. Dlaczego rośnie liczba zgłoszeń dotyczących jednego produktu? Dlaczego dany typ zgłoszenia trwa dłużej niż oczekiwano? Dlaczego agenci ciągle szukają tej samej odpowiedzi, nie znajdując przydatnego artykułu z bazy wiedzy? Wzorce zmieniają codzienną pracę wsparcia w praktyczną naukę. Wzrost liczby podobnych zgłoszeń może wskazywać na wadę produktu. Może to pokazywać, że ostatnia aktualizacja zdezorientowała klientów. Może to ujawnić, że instrukcja obsługi wymaga jaśniejszych kroków. Zamiast traktować każde żądanie jako odrębne, zespół może dostrzec wspólną przyczynę i zająć się nią.

To może ograniczyć przyszłą liczbę zgłoszeń. Informacje zwrotne od klientów również są częścią tego obrazu. Zamknięte zgłoszenie może świadczyć o osiągnięciu celu czasu reakcji, ale klient może być sfrustrowany, jeśli musiał kontaktować się ze wsparciem trzy razy. Analiza zarówno historii zgłoszeń, jak i opinii daje menedżerom pełniejszy obraz doświadczeń klientów. Niektórzy klienci wolą w ogóle unikać tworzenia zgłoszenia. W tym miejscu z pomocą przychodzi portal samoobsługowy. Poprzez portal klienci mogą tworzyć zgłoszenia, sprawdzać ich status, dodawać nowe informacje lub czytać zatwierdzone artykuły bez dzwonienia do zespołu wsparcia. W przypadku prostych pytań może to zaoszczędzić czas wszystkim. Klient może sprawdzić status dostawy lub przejrzeć poradnik konfiguracji, kiedy tylko mu to pasuje. W międzyczasie agenci mogą poświęcić więcej czasu na problemy wymagające analizy, wyjaśnienia lub podjęcia decyzji przez człowieka.

Dynamics 365 Customer Service może również łączyć się ze znanymi narzędziami Microsoft w ramach procesu obsługi zgłoszeń. Agent może pracować z pocztą e-mail poprzez Outlook. Zespół może omawiać trudny problem w aplikacji Teams. Dokumenty i współdzielone informacje mogą znajdować się w SharePoint. PowerB może przekształcać dane o zgłoszeniach w raporty i pulpity nawigacyjne, a narzędzia Power Platform wspierać dodatkowe formularze, alerty lub zautomatyzowane kroki procesów zespołu. Każde narzędzie ma swoje własne zadanie. Zgłoszenie pozostaje miejscem, w którym problem wsparcia i jego historia pozostają połączone, nawet gdy ludzie korzystają z innych narzędzi do komunikacji, udostępniania plików czy przeglądu pracy. Zarządzanie zgłoszeniami nie polega tylko na wypełnianiu ekranu zgłoszenia. Chodzi o zapewnienie każdemu problemowi klienta jasnej ścieżki, zarejestrowanej odpowiedzi oraz zespołu, który potrafi wyciągać wnioski z tego, co się wydarzyło.

Podsumowanie. Utrzymuj całą historię klienta w jednym miejscu. Oto najważniejszy wniosek. Zarządzanie sprawami w Dynamics 365 łączy zgłoszenie, pracę, obietnicę i rezultat w jednym rekordzie. Koniec z utraconym kontekstem i powtarzaniem tych samych napraw. Przyjrzyj się własnym procesom obsługi. Och, gdzie znikają informacje o kliencie? Właśnie tutaj scalenie wszystkiego w całość zmienia wszystko. Zasubskrybuj na swojej ulubionej platformie podcastowej, aby otrzymywać więcej wiedzy o rozwiązaniach Microsoft. Ode mnie Mirko Petersa z m365.fm, gdzie wyjaśniamy narzędzia Microsoft w codziennej pracy prostym językiem.