WEBVTT 00:00:00.000 --> 00:00:11.120 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. 00:00:11.120 --> 00:00:22.320 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ź. 00:00:22.320 --> 00:00:31.480 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ść. 00:00:31.480 --> 00:00:35.980 Czym właściwie jest zgłoszenie w 20 słowach? Czym więc dokładnie jest zgłoszenie? 00:00:36.200 --> 00:00:45.280 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. 00:00:45.460 --> 00:00:48.720 Oto kwestia. Jeden klient może mieć kilka zgłoszeń jednocześnie. 00:00:48.720 --> 00:00:54.840 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. 00:00:54.960 --> 00:01:01.800 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. 00:01:01.980 --> 00:01:05.200 Kiedy agent tworzy zgłoszenie, łączy je bezpośrednio z klientem. 00:01:05.400 --> 00:01:10.360 Tym klientem może być kontakt, czyli osoba fizyczna lub konto, czyli firma, dla której pracuje. 00:01:10.360 --> 00:01:20.460 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. 00:01:20.680 --> 00:01:35.120 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. 00:01:35.120 --> 00:01:44.640 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? 00:01:44.780 --> 00:01:50.400 Te szczegóły zamieniają niejasną wiadomość w zadanie, które ktoś może przejąć i rozwiązać. Rozbijmy to na czynniki pierwsze. 00:01:50.680 --> 00:01:53.880 Zgłoszenie może zawierać temat produkt, priorytet i typ zgłoszenia. 00:01:54.100 --> 00:01:57.500 Temat grupuje zgłoszenie w obszar taki jak rozliczenia lub wsparcie techniczne. 00:01:57.500 --> 00:02:06.940 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. 00:02:07.220 --> 00:02:15.880 Ż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. 00:02:16.100 --> 00:02:21.280 Zespół zajmujący się poważną awarią usługi nie powinien musieć przeszukiwać ogólnych pytań, aby ją znaleźć. 00:02:21.280 --> 00:02:27.580 Sprawa to nie tylko formularz, który ktoś wypełnia i o nim zapomina. Staje się ona rekordem roboczym dla całej konwersacji. 00:02:27.800 --> 00:02:35.780 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. 00:02:35.960 --> 00:02:41.780 Każda aktywność jest przypisana do tego samego problemu klienta, więc kolejna osoba nie musi odtwarzać historii od zera. 00:02:42.040 --> 00:02:47.380 Wyobraźmy sobie, że agent zaczyna pracę rano, a po lunchu przekazuje sprawę specjaliście do spraw produktu. 00:02:47.380 --> 00:02:52.280 Bez rekordu sprawy specjalista mógłby otrzymać tylko krótką wiadomość – hej, możesz na to zerknąć? 00:02:52.440 --> 00:02:53.880 Co jest niewystarczające? 00:02:54.120 --> 00:03:00.100 Dzięki rekordowi sprawy specjalista widzi pierwotny problem, dane klienta, przebieg rozmowy oraz to, co sprawdził już pierwszy agent. 00:03:00.260 --> 00:03:02.380 To zapewnia znacznie lepsze przekazanie sprawy. 00:03:02.600 --> 00:03:07.320 Dynamics 365 utrzymuje sprawę w jasnym stanie, podczas gdy przechodzi ona przez proces wsparcia. 00:03:07.560 --> 00:03:13.360 Może ona pozostać aktywna podczas badania przez zespół, a gdy zespół naprawi problem lub udzieli ostatecznej odpowiedzi, zamyka ją. 00:03:13.360 --> 00:03:19.580 Jeśli zgłoszenie nie wymaga już pracy, np. wpłynęło przez pomyłkę lub klient się wycofał, zespół może je anulować. 00:03:19.780 --> 00:03:21.720 Aktywna, rozwiązana i anulowana. 00:03:22.460 --> 00:03:30.320 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, 00:03:30.460 --> 00:03:34.360 a menedżerowie nie muszą traktować zakończonych prac jak nowych problemów klientów. 00:03:35.920 --> 00:03:40.360 Jeden rekord zapewnia kontrolę, a pełna historia klienta daje agentowi kontekst. 00:03:40.360 --> 00:03:42.980 Historia klienta kryjąca się za sprawą. 00:03:43.200 --> 00:03:44.980 Sprawa mówi Ci, co wymaga naprawy. 00:03:45.180 --> 00:03:47.800 Rekord klienta mówi Ci, co doprowadziło do tego momentu. 00:03:47.980 --> 00:03:53.540 Gdy agent otwiera sprawę w Dynamics 365 Customer Service, może spojrzeć dalej niż tylko na ostatnią wiadomość. 00:03:53.760 --> 00:03:59.360 Widzi szerszy obraz, wcześniejsze sprawy, dawne e-maile, produkty powiązane z klientem oraz historię jego wsparcia. 00:03:59.600 --> 00:04:01.040 Kontekst zmienia rozmowę. 00:04:01.260 --> 00:04:02.580 Dlaczego kontekst ma znaczenie? 00:04:02.840 --> 00:04:05.380 Wyobraź sobie, że klient zgłasza awarię urządzenia. 00:04:05.380 --> 00:04:09.180 Jeśli agent widzi tylko dzisiejszą wiadomość, może zacząć od podstawowych pytań. 00:04:09.180 --> 00:04:12.820 Jaki to model? Kiedy to się zaczęło? Czy urządzenie zostało zrestartowane? 00:04:12.980 --> 00:04:15.720 Ale klient kontaktował się już ze wsparciem dwa razy w tym tygodniu. 00:04:15.860 --> 00:04:19.240 Pierwszy agent wysłał instrukcję naprawy, drugi zorganizował część zamienną. 00:04:19.480 --> 00:04:22.760 Trzeci agent, widząc tę historię, nie każe klientowi zaczynać od nowa. 00:04:22.980 --> 00:04:27.060 Zamiast tego powie, widzę, że próbował już Pan tych kroków, a część zamienna nie pomogła. 00:04:27.300 --> 00:04:28.520 Spróbujmy czegoś innego. 00:04:28.680 --> 00:04:31.760 To zupełnie co innego niż pytanie, czy może Pan ponownie opisać problem? 00:04:32.000 --> 00:04:34.900 Często nazywa się to widokiem 360 stopni na klienta. 00:04:34.900 --> 00:04:37.020 Nazwa brzmi wymyślnie, ale to proste. 00:04:37.160 --> 00:04:41.560 Oznacza to, że agent widzi klienta z wielu stron, a nie tylko przez pryzmat jednej wiadomości. 00:04:41.780 --> 00:04:47.220 Agent widzi osobę, firmę, wcześniejsze zgłoszenia, poprzednie rozmowy i powiązane z nimi produkty. 00:04:47.500 --> 00:04:50.800 Dla zespołu wsparcia zastępuje to domysły jasnym punktem wyjścia. 00:04:51.000 --> 00:04:53.580 Nie każdy klient otrzymuje taki sam rodzaj wsparcia. 00:04:53.780 --> 00:04:55.360 Klient mógł wykupić gwarancję. 00:04:55.520 --> 00:04:58.320 Firma może płacić za określoną liczbę godzin wsparcia 00:04:58.320 --> 00:05:03.060 lub mieć kontrakt obejmujący daną liczbę zgłoszeń czy wsparcie premium z szybszą pomocą. 00:05:03.300 --> 00:05:06.700 Dynamics 365 śledzi to wszystko za pomocą uprawnień. 00:05:06.860 --> 00:05:10.360 Uprawnienie to zapisana w systemie umowa o wsparcie techniczne dla klienta. 00:05:10.600 --> 00:05:13.480 Można o tym myśleć jak o warunkach serwisowych przypisanych do konta. 00:05:13.720 --> 00:05:16.480 Zanim agent obieca wizytę inżyniera lub rozpocznie płatne prace, 00:05:16.660 --> 00:05:18.560 sprawdza, jakie wsparcie przysługuje klientowi. 00:05:18.780 --> 00:05:20.760 Pozwala to uniknąć nieprzyjemnych niespodzianek. 00:05:20.760 --> 00:05:23.520 Na przykład klient może nadal mieć gwarancję na wadliwy produkt. 00:05:23.740 --> 00:05:25.780 Zgłoszenie może być procesowe in zgodnie z tą ścieżką. 00:05:25.780 --> 00:05:28.480 Inny klient mógł wykorzystać już wszystkie swoje godziny wsparcia. 00:05:28.680 --> 00:05:31.200 Agent widzi to, zanim podejmie się pracy wykraczającej poza umowę. 00:05:31.340 --> 00:05:33.920 Pomaga to również zespołowi sprawiedliwie traktować klientów. 00:05:34.080 --> 00:05:36.920 Agent nie musi przeszukiwać starych umów ani pytać innych działów. 00:05:37.080 --> 00:05:39.020 Warunki wsparcia znajdują się przy informacjach o kliencie, 00:05:39.120 --> 00:05:40.620 dokładnie tam, gdzie agent może je znaleźć. 00:05:40.720 --> 00:05:42.160 Kolejną kwestią jest baza wiedzy. 00:05:42.400 --> 00:05:44.740 Zespoły wsparcia rozwiązują te same problemy raz za razem. 00:05:44.960 --> 00:05:46.720 Resetowanie haseł, instrukcje konfiguracji, 00:05:46.720 --> 00:05:49.780 znany błąd po aktualizacji, pytanie o fakturę ze standardową odpowiedzią. 00:05:49.920 --> 00:05:52.560 Artykuł z bazy wiedzy przechowuje taką odpowiedź w jednym miejscu. 00:05:52.700 --> 00:05:56.420 W obszarze roboczym usługi agent może wyszukiwać artykuły podczas pracy nad zgłoszeniem. 00:05:56.640 --> 00:05:59.900 Artykuł może zawierać proste wyjaśnienie, instrukcje, zrzut ekranu 00:05:59.900 --> 00:06:01.920 lub dokładną listę kontrolną dla zespołu. 00:06:02.120 --> 00:06:04.000 Zamiast pisać własną wersję z pamięci, 00:06:04.160 --> 00:06:06.960 każdy agent korzysta ze zweryfikowanej odpowiedzi zespołowej. 00:06:07.200 --> 00:06:08.780 Dzięki temu wsparcie jest spójne. 00:06:08.960 --> 00:06:10.520 Pomaga to również nowym agentom. 00:06:10.520 --> 00:06:13.440 Nie potrzebują lat doświadczenia, aby dobrze radzić sobie z typowymi problemami, 00:06:13.520 --> 00:06:16.300 ponieważ sprawdzone rozwiązania zespołu są dostępne, gdy są potrzebne. 00:06:16.300 --> 00:06:20.060 Podsumowania spraw w Kopilocie pomagają w innym powszechnym problemie, długiej historii spraw. 00:06:20.300 --> 00:06:23.280 Sprawa może z czasem zgromadzić wiele e-maili, notatek i aktualizacji. 00:06:23.460 --> 00:06:26.320 Przeczytanie ich wszystkich zajmuje czas, zwłaszcza po przekazaniu sprawy. 00:06:26.440 --> 00:06:33.340 Kopilot tworzy krótkie podsumowanie sprawy, które gromadzi jej tytuł, klienta, temat, produkt, priorytet, typ, opis i ostatnią aktywność. 00:06:33.440 --> 00:06:35.960 To szybka odprawa przed rozpoczęciem pracy przez agenta. 00:06:35.960 --> 00:06:40.640 Agent nadal sprawdza rekord i używa własnego osądu, ale rozumie sytuację szybciej. 00:06:40.760 --> 00:06:44.340 Pomaga to, gdy klient czeka, a sprawa przeszła przez kilka osób. 00:06:44.340 --> 00:06:48.940 Gdy agent zrozumie klienta i problem, sprawa musi trafić do odpowiedniej osoby. 00:06:50.180 --> 00:06:52.440 Od przyjęcia zgłoszenia do właściwej kolejki. 00:06:52.620 --> 00:06:54.700 Klient może poprosić o pomoc na wiele sposobów. 00:06:54.820 --> 00:06:57.820 E-mail, telefon, czat, media społecznościowe, portal samoobsługowy. 00:06:58.020 --> 00:07:02.140 Kanał się zmienia, ale zespół wsparcia nadal potrzebuje jednego jasnego miejsca do zarządzania wnioskiem. 00:07:02.380 --> 00:07:07.920 Dynamics 365 może tworzyć sprawy z tych rozmów, jeśli konfiguracja obejmuje reguły tworzenia rekordów. 00:07:08.060 --> 00:07:11.000 Pomyśl o e-mailu docierającym na wspólny adres wsparcia. 00:07:11.000 --> 00:07:15.540 Zamiast zostawiać go w skrzynce, aż ktoś go zauważy, reguła zamienia ten e-mail w sprawę. 00:07:15.700 --> 00:07:18.500 Wiadomość staje się początkiem pracy wewnątrz obsługi klienta. 00:07:18.680 --> 00:07:20.400 Ogranicza to ręczne kopiowanie danych. 00:07:20.580 --> 00:07:23.060 Ta sama zasada dotyczy innych połączonych kanałów. 00:07:23.240 --> 00:07:27.000 Zespół wybiera, które wiadomości tworzą nową sprawę, a które należą do istniejącej. 00:07:27.160 --> 00:07:29.700 Odpowiedź na otwarty problem pozostaje przypisana do tego problemu. 00:07:29.860 --> 00:07:31.360 Nowe pytanie otrzymuje własną sprawę. 00:07:31.520 --> 00:07:33.780 Następnie sprawa potrzebuje miejsca, dopóki ktoś nie przejmie za nią odpowiedzialności. 00:07:33.940 --> 00:07:35.360 Tym miejscem jest często kolejka. 00:07:35.500 --> 00:07:37.520 Kolejka to wspólny zasobnik zadań dla zespołu. 00:07:37.520 --> 00:07:41.280 To nie jest skrzynka odbiorcza jednego agenta i nie należy do osoby, która zobaczyła zgłoszenie. 00:07:41.500 --> 00:07:44.780 Zamiast tego daje całemu zespołowi miejsce, gdzie widać pracę oczekującą na uwagę. 00:07:45.040 --> 00:07:48.740 Wyobraź sobie firmę z działem rozliczeń, zespołem wsparcia technicznego i działem zwrotów. 00:07:48.880 --> 00:07:50.440 Każdy zespół ma własną kolejkę. 00:07:50.620 --> 00:07:54.140 Pytania o rozliczenia trafiają do rozliczeń usterki produktów do wsparcia technicznego, 00:07:54.300 --> 00:07:56.460 wnioski o zwrot do osób znających proces zwrotów. 00:07:56.660 --> 00:07:58.560 Brzmi to prosto, ponieważ takie właśnie jest. 00:07:58.760 --> 00:08:01.560 Jasne sortowanie chroni ludzi przed bezmyślnym przekazywaniem zadań. 00:08:01.740 --> 00:08:03.640 Reguły routingu pomagają w takim sortowaniu. 00:08:03.640 --> 00:08:07.460 Reguła routingu sprawdza szczegóły sprawy i wysyła ją do właściwej kolejki lub osoby. 00:08:07.660 --> 00:08:10.520 Sprawa dotycząca konkretnego produktu trafia do zespołu produktowego. 00:08:10.780 --> 00:08:13.160 Sprawa z określonego regionu trafia do lokalnego wsparcia. 00:08:13.320 --> 00:08:15.180 Poważny problem trafia do kolejki pilnej. 00:08:15.360 --> 00:08:17.200 Ogólne pytanie czeka w standardowym zespole. 00:08:17.460 --> 00:08:19.900 Niektóre organizacje rozdzielają pracę na podstawie umiejętności. 00:08:20.120 --> 00:08:23.160 Na przykład klient piszący po francusku potrzebuje agenta, który mówi po francusku. 00:08:23.340 --> 00:08:26.160 Problem techniczny wymaga osoby przeszkolonej w zakresie konkretnego produktu. 00:08:26.360 --> 00:08:28.800 Dzięki kierowaniu zgłoszenia trafiają do osoby, która może je rozwiązać, 00:08:28.880 --> 00:08:30.300 zamiast traktować każde z nich jednakowo. 00:08:30.300 --> 00:08:32.960 Automatyzacja pomaga, ale to ludzie nadal podejmują decyzję. 00:08:33.100 --> 00:08:36.760 Kierownik zespołu może przyjrzeć się trudnej sprawie i przypisać ją bezpośrednio starszemu agentowi. 00:08:36.980 --> 00:08:38.520 Może ktoś już zna danego klienta. 00:08:38.720 --> 00:08:42.280 Być może problem dotyczy kilku produktów i wymaga doświadczenia, którego nie oceni żadna reguła. 00:08:42.480 --> 00:08:45.260 Ręczne przypisywanie daje zespołowi przestrzeń na taką ludzką decyzję. 00:08:45.480 --> 00:08:47.480 Właściciel sprawy może się zmieniać w trakcie jej trwania. 00:08:47.700 --> 00:08:50.580 Agent może potrzebować więcej informacji i zwrócić sprawę do kolejki. 00:08:50.820 --> 00:08:53.120 Zespół może odkryć, że sprawa należy do innego działu 00:08:53.120 --> 00:08:56.860 lub pilne zgłoszenie może wymagać eskalacji, gdy zwykły zespół nie może go rozwiązać. 00:08:56.860 --> 00:09:01.600 Dynamics 365 sprawia, że praca posuwa się do przodu zamiast utknąć u kogoś, kto nie może jej ruszyć. 00:09:01.820 --> 00:09:04.120 Czasami jeden problem powoduje powstanie wielu spraw. 00:09:04.360 --> 00:09:07.300 Wyobraźmy sobie awarię oprogramowania, która dotyka dziesiątki klientów. 00:09:07.480 --> 00:09:11.140 Każdy klient kontaktuje się z pomocą techniczną oddzielnie, więc każde zgłoszenie wymaga własnej sprawy. 00:09:11.300 --> 00:09:13.780 Wszystkie zgłoszenia łączą się jednak z jednym większym problemem. 00:09:13.980 --> 00:09:18.420 Sprawa nadrzędna śledzi szerszy problem, podczas gdy sprawy podrzędne śledzą indywidualne zgłoszenia klientów. 00:09:18.640 --> 00:09:21.040 Daje to zespołowi pomocy technicznej dwa widoki jednocześnie. 00:09:21.040 --> 00:09:26.080 Pracują nad podstawową awarią w ramach sprawy nadrzędnej, podczas gdy każda sprawa podrzędna informuje odpowiedniego klienta. 00:09:26.240 --> 00:09:29.940 Kiedy znajdą rozwiązanie, nie muszą badać tej samej awarii od nowa dla każdego dzwoniącego. 00:09:30.160 --> 00:09:32.780 Zduplikowane sprawy tworzą podobny problem na mniejszą skalę. 00:09:32.920 --> 00:09:38.380 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. 00:09:38.580 --> 00:09:41.620 Zamiast rozpraszać wysiłki, zespół może scalić podobne sprawy. 00:09:41.800 --> 00:09:44.900 Jedna sprawa staje się głównym rekordem, a praca pozostaje w jednym miejscu. 00:09:44.900 --> 00:09:47.560 Nikt nie powinien rozwiązywać tego samego problemu dwukrotnie. 00:09:47.740 --> 00:09:53.280 Dostarczenie sprawy do właściwej kolejki i osoby rozpoczyna pracę, a klient oczekuje odpowiedzi w obiecanym terminie. 00:09:53.520 --> 00:09:56.700 Dotrzymywanie obietnic dzięki umowom SLA i pracy sterowanej. 00:09:56.840 --> 00:10:02.080 Przekazanie sprawy właściwej osobie to tylko połowa sukcesu, ponieważ klient oczekuje również pomocy w obiecanym czasie. 00:10:02.300 --> 00:10:05.520 I tutaj wchodzi umowa o poziomie świadczenia usług, czyli SLA. 00:10:05.720 --> 00:10:10.720 SLA dołącza zegar do sprawy, dzięki czemu zespół dokładnie wie, ile czasu ma na spełnienie obietnicy złożonej klientowi, 00:10:10.820 --> 00:10:13.980 niezależnie od tego, czy chodzi o pierwszą odpowiedź, czy pełne rozwiązanie problemu. 00:10:13.980 --> 00:10:15.980 Ale tutaj istotna jest automatyzacja. 00:10:16.200 --> 00:10:17.700 Nie zawsze są to te same terminy. 00:10:17.940 --> 00:10:24.540 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. 00:10:24.780 --> 00:10:32.860 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. 00:10:33.060 --> 00:10:35.700 Wyobraźmy sobie klienta, któremu przestała działać usługa. 00:10:35.900 --> 00:10:42.940 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. 00:10:42.940 --> 00:10:48.700 Cel pierwszej odpowiedzi śledzi ten pierwszy kontakt, podczas gdy cel rozwiązania śledzi pełną drogę do uzyskania odpowiedzi lub naprawy. 00:10:48.880 --> 00:10:50.900 Różni klienci mogą mieć różne obietnice. 00:10:51.140 --> 00:10:55.720 Firma z pakietem wsparcia premium otrzymuje szybsze cele odpowiedzi niż klient korzystający z planu standardowego. 00:10:55.960 --> 00:11:00.120 Awaria o wysokim priorytecie ma krótszy termin niż rutynowe pytanie typu, jak to zrobić? 00:11:00.360 --> 00:11:03.980 Umowy wsparcia, priorytet i typ sprawy kształtują obowiązujące reguły czasowe. 00:11:04.240 --> 00:11:06.180 Dzięki temu obietnice są uczciwe i jasne. 00:11:06.180 --> 00:11:11.840 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. 00:11:12.060 --> 00:11:17.140 Dzięki SLA ekran sprawy pokazuje wskaźniki czasu, które informują agenta, która obietnica wymaga uwagi w pierwszej kolejności. 00:11:17.400 --> 00:11:18.880 Widać więc narastającą presję. 00:11:19.140 --> 00:11:24.420 Sprawa z dużą ilością pozostałego czasu wymaga pracy, ale sprawa zbliżająca się do terminu odpowiedzi wymaga natychmiastowej uwagi. 00:11:24.640 --> 00:11:31.840 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. 00:11:31.840 --> 00:11:36.240 Cele czasowe określają pilność, a przepływy procesów biznesowych prowadzą samą pracę. 00:11:36.380 --> 00:11:39.720 Przepływ procesu biznesowego to zestaw etapów widocznych wewnątrz sprawy. 00:11:39.920 --> 00:11:44.260 Daje on agentowi jasną ścieżkę do naśladowania w oparciu o to, jak organizacja chce obsługiwać sprawy. 00:11:44.420 --> 00:11:49.480 Etapy mogą prowadzić od przyjęcia zgłoszenia, przez dochodzenie, aż po rozwiązanie, z odpowiednimi pytaniami i kontrolami na każdym kroku. 00:11:49.640 --> 00:11:52.460 Pomyśl o tym jak o liście kontrolnej, która ma swoje miejsce w procesie. 00:11:52.640 --> 00:11:56.500 Nowy agent nie musi zgadywać, które szczegóły są istotne przed wysłaniem sprawy do specjalisty. 00:11:56.500 --> 00:12:01.300 Przepływ może wymagać podania produktu typu problemu, wpływu i innych informacji potrzebnych następnemu zespołowi. 00:12:01.520 --> 00:12:06.320 Bardziej doświadczony agent może poruszać się szybciej, ale wspólna ścieżka sprawia, że cały zespół pracuje w tym samym kierunku. 00:12:06.520 --> 00:12:07.380 Oto scenariusz. 00:12:07.540 --> 00:12:09.820 Pojawia się awaria usługi o wysokim priorytecie. 00:12:10.100 --> 00:12:13.520 Sprawa trafia do pilnej kolejki, a jej SLA zaczyna odliczać czas. 00:12:13.740 --> 00:12:19.440 Agent potwierdza dane klienta, rejestruje wpływ i wysyła pierwszą odpowiedź, zanim cel odpowiedzi wygaśnie. 00:12:19.700 --> 00:12:25.580 Następnie przepływ procesu przenosi sprawę do diagnozy, gdzie zespół zbiera szczegóły błędu i sprawdza powiązane raporty. 00:12:25.580 --> 00:12:30.840 Sprawa przechodzi następnie do etapu rozwiązania, gdy zespół zidentyfikuje przyczynę i przygotuje aktualizację dla klienta. 00:12:30.960 --> 00:12:33.700 Ta sekwencja daje również menedżerom lepszy wgląd w sytuację. 00:12:33.940 --> 00:12:38.460 Mogą oni zobaczyć, gdzie zgłoszenie zwalnia podczas przyjmowania diagnozy lub ostatecznej odpowiedzi dla klienta. 00:12:38.620 --> 00:12:43.240 Przepływ pracy nie rozwiązuje problemów zespołu, ale zapobiega pomijaniu podstawowych kroków w trakcie pracowitego dnia. 00:12:43.500 --> 00:12:48.260 Dynamics 365 może również kontrolować, jakie zmiany statusu agenci mogą wybierać w różnych momentach. 00:12:48.440 --> 00:12:52.580 Nazywa się to przejściami przyczyny statusu, co brzmi technicznie, ale sama koncepcja jest prosta. 00:12:52.760 --> 00:12:55.260 Zgłoszenie powinno przechodzić przez sensowne etapy. 00:12:55.580 --> 00:12:59.520 Chcesz, aby ktoś oznaczył zgłoszenie jako rozwiązane, gdy wciąż czeka ono na wymagane sprawdzenie wewnętrzne 00:12:59.520 --> 00:13:02.480 lub przechodził od nowego zgłoszenia prosto do anulowanego bez podania przyczyny. 00:13:02.640 --> 00:13:05.420 Dozwolone wybory mogą zmieniać się wraz ze zmianą stanu zgłoszenia. 00:13:05.640 --> 00:13:10.280 Na przykład zgłoszenie w trakcie badania może pozwolić agentowi na zawieszenie go w oczekiwaniu na szczegóły od klienta. 00:13:10.420 --> 00:13:13.120 Po odpowiedzi klienta agent może przywrócić je do aktywnej pracy. 00:13:13.380 --> 00:13:16.040 Gdy problem zostanie naprawiony, zgłoszenie może przejść do stanu rozwiązane. 00:13:16.180 --> 00:13:18.000 Tworzy to bardziej przejrzystą historię zgłoszenia. 00:13:18.000 --> 00:13:19.860 Sama odpowiedź nie kończy jeszcze pracy. 00:13:19.860 --> 00:13:23.880 Zespół musi odnotować, jak zakończył się problem, a następnie prawidłowo zamknąć zgłoszenie. 00:13:24.120 --> 00:13:26.140 Rozwiązanie, nauka i lepsza obsługa. 00:13:26.380 --> 00:13:28.940 Wysłanie odpowiedzi nie zamyka automatycznie zgłoszenia. 00:13:29.200 --> 00:13:34.580 Zespół musi odnotować rozwiązanie, co oznacza zapisanie, co naprawiło problem lub jaką ostateczną odpowiedź otrzymał klient. 00:13:34.820 --> 00:13:40.300 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. 00:13:40.300 --> 00:13:48.360 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. 00:13:48.520 --> 00:13:50.100 Czasami pierwsze rozwiązanie nie działa. 00:13:50.380 --> 00:13:53.160 Może klient postępuje zgodnie z instrukcjami, a błąd powraca. 00:13:53.420 --> 00:13:55.980 Może część zamienna dociera, ale nie rozwiązuje usterki. 00:13:56.160 --> 00:14:02.420 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. 00:14:02.620 --> 00:14:05.220 Zgłoszenie jest kontynuowane od miejsca, w którym zespół przerwał pracę. 00:14:05.220 --> 00:14:07.180 Ma to znaczenie przy zmianie właściciela zgłoszenia. 00:14:07.420 --> 00:14:11.780 Nowy agent może zobaczyć, co próbował zrobić poprzedni, co potwierdził klient i co jeszcze wymaga sprawdzenia. 00:14:11.980 --> 00:14:16.560 Klient nie musi wyjaśniać całej historii od początku tylko dlatego, że inną osobę przydzielono do pracy. 00:14:16.840 --> 00:14:21.560 Z czasem wszystkie te zgłoszenia mówią również zespołowi pomocy technicznej, co dzieje się poza pojedynczym problemem klienta. 00:14:21.760 --> 00:14:26.540 Menedżerowie mogą analizować czas do rozwiązania, który śledzi, jak długo trwają zgłoszenia od otwarcia do zamknięcia. 00:14:26.780 --> 00:14:29.980 Mogą sprawdzać czas etapu, który pokazuje, gdzie zgłoszenia spędzają najwięcej czasu. 00:14:29.980 --> 00:14:36.200 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. 00:14:36.360 --> 00:14:37.960 Obciążenie pracą również ma znaczenie. 00:14:38.200 --> 00:14:41.460 Jeśli jakaś kolejka zapełnia się w każdy poniedziałek rano, zespół może to zauważyć. 00:14:41.680 --> 00:14:46.060 Jeśli zgłoszenia techniczne czekają dniami na weryfikację wewnętrzną, to opóźnienie widać w danych. 00:14:46.300 --> 00:14:52.460 Jeśli zespół szybko zamyka zgłoszenia, ale klienci wciąż je otwierają ponownie, warto przyjrzeć się jakości pierwszych napraw. 00:14:52.700 --> 00:14:54.480 Same liczby nie wyjaśniają wszystkiego. 00:14:54.720 --> 00:14:57.200 Wskazują one zespołowi, jakie pytania warto zadać. 00:14:57.200 --> 00:14:59.760 Dlaczego rośnie liczba zgłoszeń dotyczących jednego produktu? 00:14:59.860 --> 00:15:02.340 Dlaczego dany typ zgłoszenia trwa dłużej niż oczekiwano? 00:15:02.520 --> 00:15:06.880 Dlaczego agenci ciągle szukają tej samej odpowiedzi, nie znajdując przydatnego artykułu z bazy wiedzy? 00:15:07.100 --> 00:15:09.760 Wzorce zmieniają codzienną pracę wsparcia w praktyczną naukę. 00:15:09.960 --> 00:15:12.500 Wzrost liczby podobnych zgłoszeń może wskazywać na wadę produktu. 00:15:12.720 --> 00:15:15.300 Może to pokazywać, że ostatnia aktualizacja zdezorientowała klientów. 00:15:15.520 --> 00:15:18.180 Może to ujawnić, że instrukcja obsługi wymaga jaśniejszych kroków. 00:15:18.400 --> 00:15:22.320 Zamiast traktować każde żądanie jako odrębne, zespół może dostrzec wspólną przyczynę i zająć się nią. 00:15:22.320 --> 00:15:24.260 To może ograniczyć przyszłą liczbę zgłoszeń. 00:15:24.400 --> 00:15:26.800 Informacje zwrotne od klientów również są częścią tego obrazu. 00:15:27.000 --> 00:15:29.580 Zamknięte zgłoszenie może świadczyć o osiągnięciu celu czasu reakcji, 00:15:29.700 --> 00:15:33.060 ale klient może być sfrustrowany, jeśli musiał kontaktować się ze wsparciem trzy razy. 00:15:33.240 --> 00:15:37.380 Analiza zarówno historii zgłoszeń, jak i opinii daje menedżerom pełniejszy obraz doświadczeń klientów. 00:15:37.560 --> 00:15:39.900 Niektórzy klienci wolą w ogóle unikać tworzenia zgłoszenia. 00:15:40.120 --> 00:15:42.420 W tym miejscu z pomocą przychodzi portal samoobsługowy. 00:15:42.600 --> 00:15:45.580 Poprzez portal klienci mogą tworzyć zgłoszenia, sprawdzać ich status, 00:15:45.740 --> 00:15:49.700 dodawać nowe informacje lub czytać zatwierdzone artykuły bez dzwonienia do zespołu wsparcia. 00:15:49.700 --> 00:15:52.700 W przypadku prostych pytań może to zaoszczędzić czas wszystkim. 00:15:52.900 --> 00:15:57.220 Klient może sprawdzić status dostawy lub przejrzeć poradnik konfiguracji, kiedy tylko mu to pasuje. 00:15:57.420 --> 00:16:00.700 W międzyczasie agenci mogą poświęcić więcej czasu na problemy wymagające analizy, 00:16:00.780 --> 00:16:02.600 wyjaśnienia lub podjęcia decyzji przez człowieka. 00:16:02.800 --> 00:16:06.560 Dynamics 365 Customer Service może również łączyć się ze znanymi narzędziami Microsoft 00:16:06.560 --> 00:16:07.900 w ramach procesu obsługi zgłoszeń. 00:16:08.060 --> 00:16:10.260 Agent może pracować z pocztą e-mail poprzez Outlook. 00:16:10.480 --> 00:16:12.760 Zespół może omawiać trudny problem w aplikacji Teams. 00:16:13.000 --> 00:16:15.660 Dokumenty i współdzielone informacje mogą znajdować się w SharePoint. 00:16:15.660 --> 00:16:19.060 PowerB może przekształcać dane o zgłoszeniach w raporty i pulpity nawigacyjne, 00:16:19.060 --> 00:16:23.360 a narzędzia Power Platform wspierać dodatkowe formularze, alerty lub zautomatyzowane kroki procesów zespołu. 00:16:23.480 --> 00:16:25.240 Każde narzędzie ma swoje własne zadanie. 00:16:25.480 --> 00:16:28.780 Zgłoszenie pozostaje miejscem, w którym problem wsparcia i jego historia pozostają połączone, 00:16:28.860 --> 00:16:32.360 nawet gdy ludzie korzystają z innych narzędzi do komunikacji, udostępniania plików czy przeglądu pracy. 00:16:32.580 --> 00:16:35.320 Zarządzanie zgłoszeniami nie polega tylko na wypełnianiu ekranu zgłoszenia. 00:16:35.560 --> 00:16:38.860 Chodzi o zapewnienie każdemu problemowi klienta jasnej ścieżki, zarejestrowanej odpowiedzi oraz zespołu, 00:16:38.940 --> 00:16:40.700 który potrafi wyciągać wnioski z tego, co się wydarzyło. 00:16:41.060 --> 00:16:41.560 Podsumowanie. 00:16:41.560 --> 00:16:44.180 Utrzymuj całą historię klienta w jednym miejscu. 00:16:44.300 --> 00:16:45.740 Oto najważniejszy wniosek. 00:16:45.900 --> 00:16:51.540 Zarządzanie sprawami w Dynamics 365 łączy zgłoszenie, pracę, obietnicę i rezultat w jednym rekordzie. 00:16:51.700 --> 00:16:54.220 Koniec z utraconym kontekstem i powtarzaniem tych samych napraw. 00:16:54.380 --> 00:16:56.060 Przyjrzyj się własnym procesom obsługi. 00:16:56.260 --> 00:16:58.260 Och, gdzie znikają informacje o kliencie? 00:16:58.480 --> 00:17:01.040 Właśnie tutaj scalenie wszystkiego w całość zmienia wszystko. 00:17:01.300 --> 00:17:03.440 Zasubskrybuj na swojej ulubionej platformie podcastowej, 00:17:03.560 --> 00:17:05.480 aby otrzymywać więcej wiedzy o rozwiązaniach Microsoft. 00:17:05.480 --> 00:17:07.880 Ode mnie Mirko Petersa z m365.fm, 00:17:07.980 --> 00:17:10.620 gdzie wyjaśniamy narzędzia Microsoft w codziennej pracy prostym językiem.