WEBVTT 00:00:00.000 --> 00:00:10.540 Ein Kunde schreibt eine E-Mail wegen einer defekten Bestellung, ruft am nächsten Tag an und startet dann einen Chat, weil niemand Bescheid weiß und er muss jedes Mal seine Geschichte wiederholen, während ihr Support-Team-Posteingänge, Notizen und verschiedene Tools durchsucht. 00:00:11.380 --> 00:00:13.780 Genau das löst das Formmanagement von Dynamics 365. 00:00:14.860 --> 00:00:21.840 Stellen Sie sich einen Fall wie einen beschrifteten Ordner in einem geschäftigen Bürogebäude vor, in dem jeder Teil eines Kundenproblems landet von der ersten Frage bis zur endgültigen Antwort. 00:00:21.840 --> 00:00:33.680 Sie sind Mirko Peters von M365FM und in diesem Wissenshäppchen sehen Sie, wie Fälle, Weiterleitungen, Antwortfristen, Supportartikel und Abschluss zusammenpassen, was ein Fall eigentlich ist, in 20 Wörtern erklärt. 00:00:34.340 --> 00:00:35.620 Was genau ist also ein Fall? 00:00:36.120 --> 00:00:39.580 Ein Fall ist ein Datensatz für ein Kundenanliegen, das eine Antwort oder Lösung erfordert. 00:00:39.780 --> 00:00:44.860 Dies kann ein beschädigtes Produkt, eine Abrechnungsfrage, ein Anmeldeproblem oder eine Hilfeanfrage für einen Dienst sein. 00:00:45.260 --> 00:00:48.800 Hier ist der Punkt, ein Kunde kann mehrere Fälle gleichzeitig haben, gleichzeitig haben. 00:00:48.800 --> 00:00:54.760 Ein Kunde könnte am Montag eine Rechnung anfragen, am Dienstag ein defektes Gerät melden und am Freitag Hilfe bei einer Adressänderung benötigen. 00:00:54.880 --> 00:01:01.460 Das sind separate Probleme, daher speichert Dynamics 365 sie in getrennten Falldatensätzen, anstatt jede Konversation in einen verwirrenden Thread zu werfen. 00:01:02.040 --> 00:01:04.640 Wenn ein Mitarbeiter einen Fall erstellt, verknüpft er diesen direkt mit dem Kunden. 00:01:05.320 --> 00:01:09.960 Dieser Kunde kann ein Kontakt sein, also eine Einzelperson oder ein Konto, also das Unternehmen, für das die Person arbeitet. 00:01:10.660 --> 00:01:14.520 Wenn also Jamie von Northwind Trailers ein Problem meldet, kann der Fall auf Jamie und das Unternehmen verweisen, 00:01:14.520 --> 00:01:19.380 so dass jeder, der den Datensatz öffnet, sieht, wer Hilfe benötigt und zu welcher Organisation das Problem gehört. 00:01:20.880 --> 00:01:24.660 Der Fall benötigt auch eine klare Beschreibung des Problems, meist mit einem Titel wie 00:01:24.660 --> 00:01:26.900 Unser Drucker stoppt nach Software-Update oder 00:01:26.900 --> 00:01:34.220 Kunde wurde für Jahresplan doppelt belastet, was beim Durchsehen der offenen Fälle hilft, ohne jeden Datensatz einzeln zu öffnen. 00:01:35.600 --> 00:01:37.420 Unter diesem Titel fügt der Mitarbeiter die Details hinzu. 00:01:37.420 --> 00:01:38.200 Was ist passiert? 00:01:38.480 --> 00:01:39.040 Wann ist begonnen? 00:01:39.380 --> 00:01:40.500 Was hat der Kunde bereits versucht? 00:01:40.940 --> 00:01:41.780 Welches Produkt ist betroffen? 00:01:42.240 --> 00:01:44.540 Und ob es sich um eine Frage, eine Anfrage oder einen Fehler handelt? 00:01:44.980 --> 00:01:48.220 Diese Details verwandeln eine vage Nachricht in Arbeit, die jemand übernehmen und lösen kann. 00:01:48.760 --> 00:01:50.020 Lassen Sie es uns weiter aufschlüsseln. 00:01:50.600 --> 00:01:53.400 Ein Fall kann ein Thema, ein Produkt, eine Priorität und ein Falltyp enthalten. 00:01:53.960 --> 00:01:57.280 Der Betreff ordnet das Problem einem Bereich wie Abrechnung oder technischem Support zu. 00:01:57.600 --> 00:01:59.480 Das Produkt identifiziert, was der Kunde nutzte. 00:02:00.000 --> 00:02:02.460 Die Priorität gibt dem Team vor, wie schnell es sich darum kümmern muss. 00:02:02.460 --> 00:02:06.020 Und der Falltyp bietet eine weitere Möglichkeit, die Arbeit nach dem Supportprozess zu sortieren. 00:02:06.020 --> 00:02:10.880 Keines dieser Felder löst das Problem des Kunden von allein, aber sie helfen dem Support-Team, 00:02:10.940 --> 00:02:15.120 die Arbeit klar zu überblicken, insbesondere wenn hunderte Anfragen von verschiedenen Kunden eingehen. 00:02:16.180 --> 00:02:18.340 Ein Team, das sich mit einem schwerwiegenden Ausfall befasst, 00:02:18.440 --> 00:02:20.940 sollte nicht erst allgemeine Fragen durchsuchen müssen, um diesen zu finden. 00:02:21.460 --> 00:02:24.320 Ein Fall ist also nicht nur ein Formular, das man ausfüllt und dann vergisst. 00:02:25.080 --> 00:02:27.080 Er wird zum Arbeitsdatensatz für die gesamte Konversation. 00:02:27.700 --> 00:02:30.380 E-Mails können mit dem Fall verknüpft werden, Telefonate können dort erscheinen 00:02:30.380 --> 00:02:34.900 und ein Mitarbeiter kann nach einem Chatnotizen hinzufügen, eine Folgeaufgabe festlegen oder einen Termin erfassen. 00:02:35.900 --> 00:02:37.900 Jede Aktivität bleibt dem gleichen Kundenproblem zugeordnet, 00:02:38.600 --> 00:02:41.600 sodass die nächste Person die Geschichte nicht von Grund auf neu zusammensetzen muss. 00:02:42.280 --> 00:02:44.220 Stellen Sie sich vor, ein Mitarbeiter beginnt morgens mit der Arbeit 00:02:44.220 --> 00:02:46.800 und übergibt den Fall nach der Mittagspause an einen Produktspezialisten. 00:02:47.500 --> 00:02:50.340 Ohne einen Falldatensatz erhält der Spezialist vielleicht nur eine kurze Nachricht wie, 00:02:50.420 --> 00:02:51.400 oh, kannst du dir das mal ansehen? 00:02:52.520 --> 00:02:53.380 Was nicht ausreicht. 00:02:54.400 --> 00:02:56.540 Mit dem Falldatensatz sieht er das ursprüngliche Problem, 00:02:56.700 --> 00:02:59.840 Kundendetails, was während des Anrufs geschah und was der erste Mitarbeiter bereits geprüft hat. 00:02:59.840 --> 00:03:01.840 Das bietet eine deutlich bessere Übergang. 00:03:02.640 --> 00:03:05.080 Dynamic Stadium 65 hält den Fall in einem klaren Status, 00:03:05.180 --> 00:03:06.560 wer mit dem Supportprozess durchläuft. 00:03:07.420 --> 00:03:09.040 Er bleibt aktiv, während das Team ermittelt 00:03:09.040 --> 00:03:12.080 und sobald das Team das Problem behoben oder die endgültige Antwort gegeben hat, 00:03:12.240 --> 00:03:12.680 wird er gelöst. 00:03:12.680 --> 00:03:15.440 Wenn die Anfrage nicht mehr bearbeitet werden muss, 00:03:15.640 --> 00:03:17.980 weil sie vielleicht irrtümlich einging oder der Kunde sie zurückgezogen hat, 00:03:18.140 --> 00:03:18.980 kann das Team sie stornieren. 00:03:19.760 --> 00:03:21.060 Aktiv, gelöst und storniert. 00:03:22.640 --> 00:03:26.780 Diese drei Zustände geben dem Team einen gemeinsamen Überblick über den Status jedes Problems, 00:03:26.900 --> 00:03:29.840 sodass niemand raten muss, ob ein Fall noch Aufmerksamkeit benötigt 00:03:29.840 --> 00:03:34.340 und Manager alte, abgeschlossene Arbeit nicht wie neue Kundenprobleme behandeln müssen. 00:03:35.760 --> 00:03:37.220 Ein Datensatz gibt Ihnen Kontrolle 00:03:37.220 --> 00:03:39.760 und die vollständige Kundenhistorie gibt dem Mitarbeiter Kontext. 00:03:39.760 --> 00:03:42.480 Die Kundengeschichte hinter dem Fall 00:03:42.480 --> 00:03:44.860 Ein Fall sagt Ihnen, was behoben werden muss. 00:03:45.240 --> 00:03:47.220 Der Kundendatensatz sagt Ihnen, was zu diesem Moment gefüttert. 00:03:47.740 --> 00:03:51.360 Wenn ein Mitarbeiter einen Fall in Dynamics 365 Customer Service öffnet, 00:03:51.500 --> 00:03:52.980 kann er über die letzte Nachricht hinausblicken. 00:03:53.560 --> 00:03:55.920 Er sieht das Gesamtbild wie frühere Fälle, vergangene E-Mails, 00:03:56.040 --> 00:03:58.640 die mit dem Kunden verknüpften Produkte und dessen Support-Historie. 00:03:59.480 --> 00:04:00.720 Kontext verändert das Gespräch. 00:04:01.620 --> 00:04:02.460 Warum ist Kontext wichtig? 00:04:03.040 --> 00:04:04.780 Stellen Sie sich vor, ein Kunde meldet einen Geräteausfall. 00:04:05.400 --> 00:04:06.920 Wenn der Agent nur die heutige Nachricht sieht, 00:04:07.020 --> 00:04:08.700 stellt er möglicherweise grundlegende Fragen. 00:04:08.700 --> 00:04:10.220 Und welches Modell das ist? 00:04:10.500 --> 00:04:11.020 Wann hat es angefangen? 00:04:11.320 --> 00:04:12.120 Haben Sie es neu gestartet? 00:04:12.760 --> 00:04:15.140 Aber der Kunde hat den Support diese Woche bereits zweimal kontaktiert. 00:04:15.580 --> 00:04:17.540 Der erste Mitarbeiter sandte Schritte zur Fehlerbehebung, 00:04:17.620 --> 00:04:18.820 der zweite organisierte ein Ersatzteil. 00:04:19.220 --> 00:04:20.840 Ein dritter Mitarbeiter, der diesen Verlauf sieht, 00:04:20.920 --> 00:04:22.420 wird den Kunden nicht bitten, von vorn anzufangen. 00:04:22.840 --> 00:04:23.500 Stattdessen sagt er, 00:04:23.760 --> 00:04:25.520 ich sehe, dass Sie diese Schritte bereits versucht haben 00:04:25.520 --> 00:04:26.980 und das Ersatzteil das Problem nicht behoben hat. 00:04:27.300 --> 00:04:28.220 Lassen Sie es den nächsten Schritt versuchen. 00:04:28.720 --> 00:04:29.840 Das fühlt sich ganz anders an, als 00:04:29.840 --> 00:04:31.420 können Sie das Problem bitte noch einmal erklären? 00:04:32.060 --> 00:04:34.300 Dies wird oft als 63 Grad Kundensicht bezeichnen. 00:04:35.200 --> 00:04:36.460 Der Name klingt schick, ist aber simpel. 00:04:36.460 --> 00:04:39.480 Es bedeutet, dass der Agent den Kunden aus mehr als einem Blickwinkel sieht, 00:04:39.580 --> 00:04:40.740 nicht nur als isolierte Nachricht. 00:04:41.660 --> 00:04:43.400 Der Agent sieht die Person, das Unternehmen, 00:04:43.560 --> 00:04:45.460 frühere Supportanfragen, vergangene Gespräche 00:04:45.460 --> 00:04:46.940 und die damit verbundenen Produkte. 00:04:47.660 --> 00:04:50.320 Für ein Support-Team ersetzt das Raten durch einen klaren Ausgangspunkt. 00:04:50.960 --> 00:04:53.000 Nun erhält nicht jeder Kunde die gleiche Art von Support. 00:04:53.480 --> 00:04:55.000 Ein Kunde hat vielleicht eine Garantie erworben, 00:04:55.280 --> 00:04:57.860 sein Unternehmen bezahlt für eine bestimmte Anzahl an Supportstunden. 00:04:58.200 --> 00:05:00.280 Oder er hat einen Vertrag für eine bestimmte Anzahl von Fällen 00:05:00.280 --> 00:05:02.200 oder Premium-Support mit schnellerer Hilfe, 00:05:02.520 --> 00:05:03.160 mit schnellerer Hilfe. 00:05:03.160 --> 00:05:06.000 Dynamics 365 verfolgt all dies durch Berechtigungen. 00:05:06.940 --> 00:05:10.040 Eine Berechtigung ist die Support-Vereinbarung des Kunden innerhalb des Systems. 00:05:10.840 --> 00:05:12.940 Betrachten Sie es als die Servicebedingungen, die an das Konto gebunden sind. 00:05:13.480 --> 00:05:16.600 Bevor ein Agent einem Techniker zusagt oder kostenpflichtige Arbeiten beginnt, 00:05:16.680 --> 00:05:18.100 prüft er, welcher Support gilt. 00:05:19.060 --> 00:05:20.460 Das vermeidet unangenehme Überraschungen. 00:05:20.680 --> 00:05:23.660 Zum Beispiel könnte ein Kunde noch Garantie auf ein defektes Produkt haben. 00:05:24.140 --> 00:05:25.220 Der Fall kann diesem Pfad folgen. 00:05:25.760 --> 00:05:27.920 Ein anderer Kunde hat möglicherweise alle Supportstunden aufgebaut. 00:05:27.920 --> 00:05:31.000 Der Agent sieht das, bevor er sich zu arbeiten außerhalb der Vereinbarung verpflichtet. 00:05:31.320 --> 00:05:33.360 Es hilft dem Support-Team auch, kundenfair zu behandeln. 00:05:33.800 --> 00:05:36.800 Der Agent muss nicht alte Verträge durchsuchen oder eine andere Abteilung fragen. 00:05:37.180 --> 00:05:40.400 Die Support-Bedingungen liegen bei den Kundeninformationen genau dort, wo der Agent sie finden kann. 00:05:40.740 --> 00:05:41.820 Dann gibt es noch die Wissensdatenbank. 00:05:42.240 --> 00:05:44.040 Support-Teams lösen dieselben Probleme immer wieder. 00:05:44.700 --> 00:05:45.380 Passwort-Resets. 00:05:46.140 --> 00:05:46.540 Einrichtungsanweisungen. 00:05:46.840 --> 00:05:48.020 Ein bekannter Fehler nach einem Update. 00:05:48.300 --> 00:05:49.620 Eine Abrechnungsfrage mit Standardantwort. 00:05:50.040 --> 00:05:51.840 Ein Wissensartikel speichert diese Antwort dann im Ort. 00:05:52.440 --> 00:05:55.880 Innerhalb des Service-Arbeitsbereichs kann ein Agent während der Arbeit dann am Fall nach Artikeln suchen. 00:05:55.880 --> 00:06:01.480 Ein Artikel kann eine einfache Erklärungsschritte, einen Screenshot oder die genauen Prüfungen enthalten, die das Team durchführen sollte. 00:06:02.060 --> 00:06:06.980 Anstatt dass jeder Agent seine eigene Version aus dem Gedächtnis schreibt, nutzen sie eine geteilte Antwort, die das Team überprüft hat. 00:06:07.420 --> 00:06:08.440 Das sorgt für konsistenten Support. 00:06:08.880 --> 00:06:10.000 Es hilft auch neueren Mitarbeitern. 00:06:10.520 --> 00:06:16.020 Sie brauchen keine jahrelange Erfahrung, um gängige Probleme gut zu lösen, da die bekannten Lösungen des Teams jederzeit verfügbar sind. 00:06:16.580 --> 00:06:19.760 Co-Pilot-Fallzusammenfassungen helfen bei einem weiteren häufigen Problemen Langefallhistorien. 00:06:20.200 --> 00:06:23.440 Ein Fall kann im Laufe der Zeit viele E-Mails, Notizen und Aktualisierungen ansammeln. 00:06:23.440 --> 00:06:25.620 Alles zu lesen kostet Zeit, besonders nach einer Übergabe. 00:06:26.140 --> 00:06:32.900 Co-Pilot erstellt eine kurze Fallzusammenfassung, die Falltitel, Kunden, Betreff, Produkt, Priorität, Falltyp, Beschreibung und letzte Aktivitäten bündelt. 00:06:33.800 --> 00:06:35.460 Es ist eine kurze Zusammenfassung, bevor der Mitarbeiter beginnt. 00:06:35.900 --> 00:06:39.940 Der Mitarbeiter prüft den Datensatz zwar weiterhin und nutzt sein Urteilsvermögen, versteht die Situation aber schneller. 00:06:40.640 --> 00:06:43.860 Das hilft, wenn der Kunde wartet und der Fall bereits durch mehrere Hände gegangen ist. 00:06:44.820 --> 00:06:48.460 Sobald der Mitarbeiter den Kunden und das Problem versteht, muss der Fall die richtige Person erreichen. 00:06:48.460 --> 00:06:52.210 Von der Aufnahme bis zur richtigen Warteschlag. 00:06:52.670 --> 00:06:54.410 Ein Kunde kann auf viele Arten um Hilfe bitten. 00:06:54.670 --> 00:06:57.470 E-Mail, Telefonanruf, Chat, soziale Medien oder ein Self-Service-Portal. 00:06:58.010 --> 00:07:01.430 Der Kanal ändert sich, aber das Support-Team benötigt dennoch einen zentralen Ort zur Verwaltung der Anfrage. 00:07:02.330 --> 00:07:07.330 Dynamics 365 kann Fälle aus diesen Unterhaltungen erstellen, wenn die Einrichtung Regeln zur Datensatzerstellung umfasst. 00:07:08.290 --> 00:07:10.810 Denken Sie an eine E-Mail, die an eine gemeinsame Support-Adresse eingeht. 00:07:11.230 --> 00:07:15.310 Anstatt sie in einem Posteingang liegen zu lassen, bis jemand bemerkt, wandelt eine Regel diese E-Mail in einen Fall um. 00:07:15.970 --> 00:07:17.950 Die Nachricht wird zum Arbeitsbeginn im Kundenservice. 00:07:18.710 --> 00:07:19.930 Das reduziert manuelles Kopieren. 00:07:20.570 --> 00:07:22.610 Dasselbe Prinzip gilt für andere verbundene Kanäle. 00:07:23.150 --> 00:07:26.850 Das Team wählt aus, welche Nachrichten einen neuen Fall erstellen und welche zu einem bestehenden gehören. 00:07:27.610 --> 00:07:29.650 Eine Antwort auf ein offenes Problem bleibt bei diesem Problem. 00:07:29.870 --> 00:07:31.110 Eine neue Frage erhält einen eigenen Fall. 00:07:31.410 --> 00:07:33.530 Dann benötigt der Fall einen Ort, an dem er verbleibt, bis jemand die Verantwortung. 00:07:33.830 --> 00:07:34.970 Dieser Ort ist oft eine Warteschlange. 00:07:35.270 --> 00:07:37.130 Eine Warteschlange ist ein gemeinsamer Arbeitsbereich für ein Team. 00:07:37.450 --> 00:07:41.090 Es ist nicht der Posteingang eines einzelnen Mitarbeiters und gehört nicht der Person, die die Anfrage gesehen hat. 00:07:41.490 --> 00:07:44.450 Dadessen bietet sie dem gesamten Team einen Ort, an dem Aufgaben auf Bearbeitung warten. 00:07:44.870 --> 00:07:48.430 Denken Sie sich ein Unternehmen mit einem Abrechnungsteam, einem technischen Support und einem Rückgabeteam vor. 00:07:48.970 --> 00:07:50.350 Jedes Team hat seine eigene Warteschläge. 00:07:50.690 --> 00:07:51.830 Abrechnungsfragen gehen an die Abrechnung. 00:07:52.270 --> 00:07:53.510 Produktfehler an den technischen Support. 00:07:54.710 --> 00:07:56.510 Rückgabeanfragen an die Experten für den Rückgabeprozess. 00:07:56.830 --> 00:07:57.950 Das klingt einfach, weil es einfach ist. 00:07:58.590 --> 00:08:01.410 Durch eine klare Sortierung müssen Aufgaben nicht bind weitergereicht werden. 00:08:01.690 --> 00:08:03.090 Routing-Regeln helfen bei dieser Sortierung. 00:08:03.570 --> 00:08:07.290 Eine Routing-Regel prüft die Details eines Falls und sendet ihn an die richtige Warteschlange oder Person. 00:08:07.910 --> 00:08:10.270 Ein Fall zu einem bestimmten Produkt dient an das Produktteam. 00:08:10.690 --> 00:08:12.750 Ein Fall aus einer bestimmten Region geht an den lokalen Support. 00:08:13.130 --> 00:08:15.210 Ein schwerwiegendes Problem landet in einer dringenden Warteschlange. 00:08:15.470 --> 00:08:16.950 Eine allgemeine Frage wartet beim Standard. 00:08:17.610 --> 00:08:19.490 Einige Unternehmen verteilen Aufgaben basierend auf Fähigkeiten. 00:08:19.850 --> 00:08:22.950 Ein Kunde, der auf Französisch schreibt, benötigt beispielsweise einen Mitarbeiter der Französisch. 00:08:23.190 --> 00:08:25.750 Ein technisches Problem erfordert jemanden, der für ein bestimmtes Produkt geschult hat. 00:08:26.150 --> 00:08:30.110 Routing bringt den Fall näher zu der Person, die ihn lösen kann, anstatt jede Anfrage gleich zu behandeln. 00:08:30.730 --> 00:08:32.670 Automatisierung hilft, aber Menschen treffen weiterhin Entscheidungen. 00:08:32.670 --> 00:08:36.330 Ein Teamleiter könnte sich einen schwierigen Fall ansehen und ihn direkt einem erfahrenen Mitarbeiter zuweisen. 00:08:36.730 --> 00:08:38.250 Vielleicht kennt jemand den Kunden bereits persönlich. 00:08:38.790 --> 00:08:42.070 Vielleicht betrifft das Problem mehrere Produkte und erfordert Erfahrungen, die eine Regel nicht bewerten kann. 00:08:42.630 --> 00:08:45.070 Manuelle Zuweisung gibt dem Team Spielraum für diese menschliche Entscheidung. 00:08:45.470 --> 00:08:46.830 Die Zuständigkeit kann sich wehrnissweit setzen. 00:08:47.230 --> 00:08:50.230 Ein Mitarbeiter benötigt möglicherweise mehr Informationen und gibt den Fall zurück in eine Warteschlange. 00:08:50.230 --> 00:08:56.510 Ein Team könnte feststellen, dass das Problem in eine andere Abteilung gehört oder eine dringende Anfrage erfordert eine Eskalation, wenn das reguläre Team sie nicht lösen kann. 00:08:57.510 --> 00:09:00.890 Dynamics 365 hält die Arbeit im Fluss, anstatt sie bei jemandem feststecken zu lassen. 00:09:01.710 --> 00:09:03.930 Nun, manchmal erzeugt ein einziges Problem viele Fälle. 00:09:04.730 --> 00:09:06.950 Stellen Sie sich einen Softwareausfall vor, der Dutzende von Kunden betrifft. 00:09:07.510 --> 00:09:10.710 Jeder Kunde kontaktiert den Support separat, daher benötigt jeder Bericht seinen eigenen Fall. 00:09:11.230 --> 00:09:13.210 Aber alle Berichte beziehen sich auf ein größeres Problem. 00:09:13.650 --> 00:09:18.450 Ein übergeordneter Fall verfolgt dieses umfassendere Problem, während untergeordnete Fälle die einzelnen Kunden berichten darunter fest. 00:09:18.450 --> 00:09:20.390 Das bietet dem Support-Team zwei Ansichten gleichzeitig. 00:09:20.810 --> 00:09:25.890 Sie arbeiten an dem zugrunde liegenden Ausfall über den übergeordneten Fall, während jeder untergeordnete Fall den richtigen Kunden informiert hält. 00:09:26.190 --> 00:09:29.630 Wenn Sie die Lösung finden, müssen Sie nicht für jeden Anrufer denselben Ausfall von Grund auf untersuchen. 00:09:30.110 --> 00:09:32.370 Doppelte Fälle erzeugen ein ähnliches Problem kleinerem Maßstab. 00:09:32.910 --> 00:09:37.910 Ein Kunde könnte wegen desselben Problems mailen und anrufen oder zwei Mitarbeiter könnten Fälle eröffnen, bevor sie den anderen bemerken. 00:09:38.550 --> 00:09:41.290 Anstatt den Aufwand aufzuteilen, kann das Team ähnliche Fälle zusammenführen. 00:09:42.130 --> 00:09:44.370 Ein Fall wird zum Hauptdatensatz und die Arbeit bleibt gebündelt. 00:09:45.090 --> 00:09:46.730 Niemand sollte dasselbe Problem zweimal lösen müssen. 00:09:46.730 --> 00:09:50.070 Einen Fall in die richtige Warteschlange und zur richtigen Person zu bringen, ist der Anfang. 00:09:50.390 --> 00:09:52.850 Und der Kunde erwartet eine Antwort innerhalb der versprochenen Zeit. 00:09:53.910 --> 00:09:55.970 Versprechen Einheiten mit SLAs und geführter Arbeit. 00:09:57.210 --> 00:10:01.350 Einen Fall zur richtigen Person zu bringen, ist nur die halbe Miete, da der Kunde auch Hilfe innerhalb der versprochenen Zeit erwartet. 00:10:02.210 --> 00:10:05.090 Und genau hier kommt eine Service-Level-Agreement, kurz SLA genannt, ins Spiel. 00:10:06.230 --> 00:10:11.010 Eine SLA verknüpft eine Uhr mit dem Fall, sodass das Team genau weiß, wie viel Zeit es hat, um ein Kundenversprechen zu erfüllen. 00:10:11.010 --> 00:10:13.570 Sei es für die erste Antwort oder die vollständige Lösung des Problems. 00:10:13.570 --> 00:10:15.330 Aber hier ist der entscheidende Punkt. 00:10:16.070 --> 00:10:17.210 Das sind nicht immer dieselben Fristen. 00:10:17.930 --> 00:10:23.990 Nehmen Sie einen Kunden, der eine Bestätigung innerhalb einer Stunde erwartet, auch wenn das technische Team zwei Arbeitstage benötigt, um die Lösung zu finden und zu testen. 00:10:24.810 --> 00:10:32.310 Dynamics 365 erfasst Ziele für die erste Antwort und die Lösung getrennt, damit das Team schnell handeln kann, ohne vorzugeben, dass jedes Problem sofort gelöst werden kann. 00:10:32.310 --> 00:10:35.270 Stellen Sie sich nun einen Kunden vor, dessen Dienst nicht mehr funktioniert. 00:10:35.810 --> 00:10:42.550 Er erwartet keine vollständige Reparatur in zehn Minuten, aber er erwartet, dass jemand bestätigt, dass das Problem bekannt ist, erklärt, wie es weitergeht und ihn auf dem Laufenden hält. 00:10:43.070 --> 00:10:48.470 Das Ziel für die erste Antwort erfasst diesen ersten Kontakt, während das Lösungsziel den gesamten Weg bis zur Antwort oder Behebung nachverfolgt. 00:10:48.890 --> 00:10:50.550 Und verschiedene Kunden können unterschiedliche Zusagen erhalten. 00:10:50.550 --> 00:10:54.890 Ein Unternehmen mit Premium-Support erhält schnellere Antwortziele als ein Kunde mit einem Standardplan. 00:10:55.670 --> 00:10:59.930 Ein Auswahl mit hoher Priorität hat eine kürzere Frist als eine routinemäßige, wie geht das, Anfrage. 00:11:01.330 --> 00:11:03.890 Supportvereinbarung, Priorität und Volltyp bestimmen die geltenden Zeitregeln. 00:11:04.230 --> 00:11:05.550 Das hält die Zusagen fair und transparent. 00:11:06.110 --> 00:11:11.470 Ohne SLAs könnte ein Mitarbeiter das älteste Element in einer Liste bearbeiten, während ein zeitkritischer Fall unbemerkt seine Frist überschreitet. 00:11:11.930 --> 00:11:16.990 Mit SLAs zeigt der Bildschirm zum Fall Zeitindikatoren an, die dem Mitarbeiter sagen, welche Zusage zuerst Aufmerksamkeit erfordert. 00:11:17.390 --> 00:11:18.390 So sehen Sie, wie der Druck wächst. 00:11:18.390 --> 00:11:23.810 Ein Fall mit viel verbleibender Zeit muss bearbeitet werden, aber ein Fall, dessen Antwortfrist abläuft, erfordert sofortige Aufmerksamkeit. 00:11:24.650 --> 00:11:28.690 Teams können auch Warnungen oder Eskalationsschritte festlegen, wenn ein Ziel nahe ist oder bereits überschritten wurde, 00:11:28.850 --> 00:11:31.350 damit ein Vorgesetzter eingreifen kann, bevor der Kunde beim Team nachhacken muss. 00:11:32.290 --> 00:11:35.850 Zeitvorgaben steuern die Dringlichkeit und Geschäftsprozessflüsse steuern die Arbeit selbst. 00:11:36.490 --> 00:11:39.510 Ein Geschäftsprozessfluss ist eine Reihe von Phasen, die innerhalb des Falls angezeigt werden. 00:11:39.930 --> 00:11:43.930 Er gibt einem Mitarbeiter einen klaren Weg vor, basierend darauf, wie das Unternehmen die Bearbeitung von Fällen wünscht. 00:11:44.390 --> 00:11:47.330 Die Phasen können von der Annahme über die Untersuchung bis zur Lösung reichen. 00:11:47.330 --> 00:11:49.390 Mit den richtigen Fragen und Prüfungen an jedem Punkt. 00:11:49.710 --> 00:11:52.110 Betrachten Sie es als eine Checkliste mit festem Platz im Prozess. 00:11:52.410 --> 00:11:56.190 Ein neuer Mitarbeiter muss nicht raten, welche Details wichtig sind, bevor er einen Fall an einen Spezialisten weiterleitet. 00:11:56.630 --> 00:12:00.990 Der Prozess kann nach Produkt, Problemtyp, Auswirkungen und anderen Informationen fragen, die das nächste Team benötigt. 00:12:01.550 --> 00:12:06.050 Ein erfahrener Mitarbeiter kann schneller arbeiten, aber der gemeinsame Pfad sorgt dafür, dass das Team in die gleiche Richtung arbeitet. 00:12:06.570 --> 00:12:07.190 Hier ist ein Szenario. 00:12:07.570 --> 00:12:09.230 Ein Dienstausfall mit hoher Priorität ein. 00:12:09.770 --> 00:12:12.710 Der Fall gelangt in die dringende Warteschlange und das SLI beginnt herunterzuzählen. 00:12:12.710 --> 00:12:18.950 Der Mitarbeiter bestätigt die Kundendaten, protokolliert die Auswirkungen und sendet die erste Antwort, bevor dieses Antwortziel abläuft. 00:12:19.850 --> 00:12:25.470 Als nächstes verschiebt der Prozessfluss den Fall in die Diagnose, wo das Team Fehlerdetails sammelt und nach zugehörigen Berichten sucht. 00:12:26.150 --> 00:12:30.470 Der Fall geht dann in die Lösungsphase über, sobald das Team die Ursache identifiziert und ein Kundenupdate vorbereitet hat. 00:12:30.470 --> 00:12:33.250 Dieser Ablauf verschafft auch Managern ein klareres Bild. 00:12:33.770 --> 00:12:37.970 Sie können sehen, wo der Fall während der Aufnahme, Diagnose oder der finalen Kundenantwort in Stocken gerät. 00:12:38.550 --> 00:12:42.810 Der Ablauf löst das Problem für das Team nicht, verhindert aber, dass grundlegende Schritte an einem stressigen Tag untergehen. 00:12:43.530 --> 00:12:47.590 Dynamics 365 kann auch steuern, welche Statusänderungen Agenten an verschiedenen Punkten wählen können. 00:12:48.370 --> 00:12:49.970 Dies nennt man Statusgrundübergänge. 00:12:50.050 --> 00:12:52.170 Das klingt technisch, ist aber ein einfaches Prinzip. 00:12:53.070 --> 00:12:54.570 Ein Fall sollte sinnvolle Schritte durchlaufen. 00:12:54.570 --> 00:13:02.070 Man möchte nicht, dass jemand einen Fall als gelöst markiert, während er noch auf eine interne Prüfung wartet oder direkt von neu auf storniert springt, ohne den Grund anzugeben. 00:13:02.870 --> 00:13:04.930 Die zulässigen Optionen können sich je nach Fall ändern. 00:13:05.490 --> 00:13:09.930 Ein Fall in Bearbeitung kann es einem Agenten beispielsweise ermöglichen, ihn auf Warten zu setzen, während er auf Kundendetails wartet. 00:13:10.530 --> 00:13:13.290 Nachdem der Kunde geantwortet hat, kann der Agent die Arbeit aktiv fortsetzen. 00:13:13.490 --> 00:13:15.970 Wenn das Problem behoben ist, kann der Fall auf gelöst gesetzt werden. 00:13:16.350 --> 00:13:17.470 Das sorgt für eine saubere Fallestuch. 00:13:17.790 --> 00:13:19.330 Eine Antwort allein schließt die Arbeit nicht ab. 00:13:19.730 --> 00:13:22.710 Das Team muss dokumentieren, wie das Problem endete und den Fall dann ordnungsgemäß schließen. 00:13:22.710 --> 00:13:28.790 Das Senden einer Antwort schließt einen Fall nicht automatisch. 00:13:29.170 --> 00:13:33.770 Das Team muss die Lösung dokumentieren, also festhalten, was das Problem behoben hat oder welche Antwort der Kunde erhalten hat. 00:13:34.310 --> 00:13:39.650 Das könnte ein versendetes Ersatzgerät, eine erstattete Doppelzahlung oder eine vom Kunden korrigierte Einstellung sein. 00:13:40.910 --> 00:13:44.810 Diese Notiz wird Teil der Kundenakte und gibt dem nächsten Agenten einen nützlichen Anhaltspunkt, 00:13:45.130 --> 00:13:48.010 falls der Kunde Monate später erneut mit einem ähnlichen Problem anruft. 00:13:48.670 --> 00:13:49.910 Manchmal funktioniert die erste Lösung nicht. 00:13:49.910 --> 00:13:52.910 Vielleicht befolgt der Kunde die Anweisungen und der Fehler tritt erneut auf. 00:13:53.430 --> 00:13:55.330 Vielleicht kommt ein Ersatzteil an, behebt den Fehler aber nicht. 00:13:55.990 --> 00:13:59.950 In dieser Situation kann das Team den Fall wieder öffnen oder zurück in die Warteschlange stellen, 00:14:00.070 --> 00:14:02.390 statt einen neuen Datensatz ohne Historie anzulegen. 00:14:03.230 --> 00:14:04.870 Der Fall wird dort fortgesetzt, wo das Team aufgehört hat? 00:14:05.270 --> 00:14:06.710 Das ist wichtig, wenn die Zuständigkeit wechselt. 00:14:06.870 --> 00:14:11.310 Ein neuer Agent kann sehen, was der vorherige versucht hat, was der Kunde bestätigt hat und was noch geprüft werden muss. 00:14:11.310 --> 00:14:16.050 Der Kunde muss nicht die ganze Geschichte von vorne erzählen, nur weil eine andere Person die Arbeit übernommen hat. 00:14:16.910 --> 00:14:20.970 Im Laufe der Zeit verraten all diese Fälle dem Support-Team auch, was über ein einzelnes Problem hinaus passiert. 00:14:21.730 --> 00:14:26.270 Manager können die Lösungszeit betrachten, die verfolgt, wie lange Fälle von der Eröffnung bis zum Abschluss dauern. 00:14:26.950 --> 00:14:29.570 Sie können die Phasenzeit analysieren, die zeigt, wo die Fälle ihre Zeit verbringen. 00:14:29.570 --> 00:14:35.630 Sie können auch die Erstlösungsrate beobachten, also wie oft die erste Person, die mit dem Kunden spricht, das Problem ohne Übergabe lösen kann. 00:14:36.470 --> 00:14:37.710 Die Arbeitsbelastung zählt Ihnen bei. 00:14:37.990 --> 00:14:40.650 Wenn sich Montagmorgens eine Warteschlange füllt, kann das Team dies sehen. 00:14:41.230 --> 00:14:45.530 Wenn technische Anfragen tagelang auf eine interne Prüfung warten, erscheint diese Verzögerung in den Falldaten. 00:14:46.110 --> 00:14:51.930 Wenn ein Team Fälle schnell schließt, Kunden sie aber ständig wieder öffnen, hat das Team Grund, die Qualität der ersten Lösungen genauer zu prüfen. 00:14:52.810 --> 00:14:54.370 Die Zahlen allein erklären nicht alles. 00:14:54.970 --> 00:14:56.970 Sie zeigen dem Team, welche Fragen es wert sind, gestellt zu werden. 00:14:57.350 --> 00:14:59.010 Warum nehmen die Anfragen zum Bestimmten? 00:14:59.010 --> 00:15:01.650 Warum dauert eine bestimmte Fallart länger als erwartet? 00:15:02.510 --> 00:15:06.390 Warum suchen Mitarbeiter wiederholt nach derselben Antwort, finden aber keinen nützlichen Wissensartikel? 00:15:07.250 --> 00:15:09.650 Muster machen aus täglicher Supportarbeit praktisches Lernen. 00:15:10.170 --> 00:15:12.330 Ein Anstieg ähnlicher Fälle kann auf einen Produktfehler hindeuten. 00:15:12.830 --> 00:15:14.790 Könnte zeigen, dass ein aktuelles Update die Kunden verwirrt hat. 00:15:15.230 --> 00:15:17.590 Könnte aufzeigen, dass eine Anleitung klarere Schritte benötigt. 00:15:18.190 --> 00:15:22.210 Anstatt jede Anfrage als unabhängig zu betrachten, kann das Team die gemeinsame Ursache erkennen und daran arbeiten. 00:15:22.610 --> 00:15:24.190 Dies kann das zukünftige Fallaufkommen reduzieren. 00:15:24.550 --> 00:15:25.890 Kundenfeedback gehört ebenfalls in dieses Bild. 00:15:25.890 --> 00:15:28.890 Ein geschlossener Fall mag zeigen, dass das Team das Antwortziel erreicht hat. 00:15:29.010 --> 00:15:32.730 Doch der Kunde kann dennoch frustriert sein, wenn er den Support dreimal kontaktieren musste, wenn musste. 00:15:33.470 --> 00:15:37.350 Die Betrachtung von Fallhistorie und Feedback gibt Managern einen umfassenderen Blick auf das Kundenerlebnis. 00:15:37.750 --> 00:15:39.670 Manche Kunden würden es vorziehen, gar keinen Fall zu erstellen. 00:15:40.150 --> 00:15:41.470 Hier kann ein Self-Service-Portal helfen. 00:15:41.950 --> 00:15:49.210 Über ein Portal können Kunden eine Anfrage erstellen, den Status prüfen, neue Informationen hinzufügen oder freigegebene Supportartikel lesen, ohne das Support-Team anzurufen. 00:15:49.210 --> 00:15:52.310 Bei einfachen Fragen kann das für alle Zeit sparen. 00:15:52.930 --> 00:15:56.590 Ein Kunde kann einen Lieferstatus prüfen oder eine Einrichtungsanleitung folgen, wenn man es ihm passt. 00:15:57.470 --> 00:16:02.390 Unterdessen können Mitarbeiter mehr Zeit für Probleme aufwenden, bei denen ein Mensch ermitteln, erklären oder eine Entscheidung treffen muss. 00:16:02.930 --> 00:16:07.650 Dynamics 365 Customer Service lässt sich zu den mitvertrauten Microsoft-Tools rund um den Fallprozess verbinden. 00:16:08.290 --> 00:16:09.950 Ein Mitarbeiter kann E-Mails über Outlook bearbeiten. 00:16:10.370 --> 00:16:12.290 Ein Team kann ein schwieriges Problem in Teams diskutieren. 00:16:12.870 --> 00:16:15.090 Dokumente und geteilte Informationen können in SharePoint gespeichert werden. 00:16:15.090 --> 00:16:23.170 Power BI kann Falldaten in Berichte und Dashboards verwandeln, während Power-Plattform-Tools zusätzliche Formulare, Warnungen oder automatisierte Schritte für die Prozesse des Teams unterstützen. 00:16:23.630 --> 00:16:24.750 Jedes Tool hat seine eigene Aufgabe. 00:16:25.170 --> 00:16:27.990 Der Fall bleibt der Ort, an dem das Support-Problem und seine Historie verbunden bleiben. 00:16:28.250 --> 00:16:32.550 Selbst wenn Leute andere Tools zur Kommunikation, zum Teilen von Dateien, von Dateien, von Dateien oder zur Überprüfung der Arbeit nutzen, 00:16:32.690 --> 00:16:35.190 beim Fallmanagement geht es nicht wirklich darum, eine Ticketmaske auszufüllen. 00:16:35.250 --> 00:16:39.890 Es geht darum, jedem Kunden anliegen einen klaren Weg, eine aufgezeichnete Antwort und ein Team zu geben, das aus dem Geschehen entlernen. 00:16:41.010 --> 00:16:41.310 Fazit. 00:16:41.990 --> 00:16:43.470 Halten Sie die gesamte Kundengeschichte zusammen. 00:16:43.470 --> 00:16:45.150 Hier ist also das eigentliche Fazit. 00:16:46.170 --> 00:16:51.490 Das Dynamics-Item 65 Case Management bündelt Problem, Bearbeitung, Zusagen und Ergebnisse in einem Datensatz. 00:16:52.250 --> 00:16:53.930 Kein Kontextverlust und keine mehrfache Führung mehr. 00:16:54.310 --> 00:16:55.670 Schauen Sie sich einen eigenen Support-Prozess an. 00:16:56.050 --> 00:16:57.850 Oh, wo verschwinden eigentlich die Kundeninformationen? 00:16:58.390 --> 00:17:00.270 Genau hier verändert die Zusammenführung alles. 00:17:00.750 --> 00:17:06.110 Abonnieren Sie auf Ihrer bevorzugten Podcast-Plattform für mehr Microsoft-Wissen von mir, Mirko Peters bei mtreff.fm, 00:17:06.570 --> 00:17:09.530 wo wir die Microsoft-Tools hinter der täglichen Arbeit verständlich erklären. 00:17:09.810 --> 00:17:10.510 Verständlich erklären.