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. Genau das löst das Formmanagement von Dynamics 365. 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. 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. Was genau ist also ein Fall? Ein Fall ist ein Datensatz für ein Kundenanliegen, das eine Antwort oder Lösung erfordert. Dies kann ein beschädigtes Produkt, eine Abrechnungsfrage, ein Anmeldeproblem oder eine Hilfeanfrage für einen Dienst sein.

Hier ist der Punkt, ein Kunde kann mehrere Fälle gleichzeitig haben, gleichzeitig haben. 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. Das sind separate Probleme, daher speichert Dynamics 365 sie in getrennten Falldatensätzen, anstatt jede Konversation in einen verwirrenden Thread zu werfen. Wenn ein Mitarbeiter einen Fall erstellt, verknüpft er diesen direkt mit dem Kunden. Dieser Kunde kann ein Kontakt sein, also eine Einzelperson oder ein Konto, also das Unternehmen, für das die Person arbeitet. Wenn also Jamie von Northwind Trailers ein Problem meldet, kann der Fall auf Jamie und das Unternehmen verweisen, so dass jeder, der den Datensatz öffnet, sieht, wer Hilfe benötigt und zu welcher Organisation das Problem gehört. Der Fall benötigt auch eine klare Beschreibung des Problems, meist mit einem Titel wie Unser Drucker stoppt nach Software-Update oder Kunde wurde für Jahresplan doppelt belastet, was beim Durchsehen der offenen Fälle hilft, ohne jeden Datensatz einzeln zu öffnen.

Unter diesem Titel fügt der Mitarbeiter die Details hinzu. Was ist passiert? Wann ist begonnen? Was hat der Kunde bereits versucht? Welches Produkt ist betroffen? Und ob es sich um eine Frage, eine Anfrage oder einen Fehler handelt? Diese Details verwandeln eine vage Nachricht in Arbeit, die jemand übernehmen und lösen kann. Lassen Sie es uns weiter aufschlüsseln. Ein Fall kann ein Thema, ein Produkt, eine Priorität und ein Falltyp enthalten. Der Betreff ordnet das Problem einem Bereich wie Abrechnung oder technischem Support zu. Das Produkt identifiziert, was der Kunde nutzte. Die Priorität gibt dem Team vor, wie schnell es sich darum kümmern muss. Und der Falltyp bietet eine weitere Möglichkeit, die Arbeit nach dem Supportprozess zu sortieren. Keines dieser Felder löst das Problem des Kunden von allein, aber sie helfen dem Support-Team, die Arbeit klar zu überblicken, insbesondere wenn hunderte Anfragen von verschiedenen Kunden eingehen.

Ein Team, das sich mit einem schwerwiegenden Ausfall befasst, sollte nicht erst allgemeine Fragen durchsuchen müssen, um diesen zu finden. Ein Fall ist also nicht nur ein Formular, das man ausfüllt und dann vergisst. Er wird zum Arbeitsdatensatz für die gesamte Konversation. E-Mails können mit dem Fall verknüpft werden, Telefonate können dort erscheinen und ein Mitarbeiter kann nach einem Chatnotizen hinzufügen, eine Folgeaufgabe festlegen oder einen Termin erfassen. Jede Aktivität bleibt dem gleichen Kundenproblem zugeordnet, sodass die nächste Person die Geschichte nicht von Grund auf neu zusammensetzen muss. Stellen Sie sich vor, ein Mitarbeiter beginnt morgens mit der Arbeit und übergibt den Fall nach der Mittagspause an einen Produktspezialisten. Ohne einen Falldatensatz erhält der Spezialist vielleicht nur eine kurze Nachricht wie, oh, kannst du dir das mal ansehen? Was nicht ausreicht.

Mit dem Falldatensatz sieht er das ursprüngliche Problem, Kundendetails, was während des Anrufs geschah und was der erste Mitarbeiter bereits geprüft hat. Das bietet eine deutlich bessere Übergang. Dynamic Stadium 65 hält den Fall in einem klaren Status, wer mit dem Supportprozess durchläuft. Er bleibt aktiv, während das Team ermittelt und sobald das Team das Problem behoben oder die endgültige Antwort gegeben hat, wird er gelöst. Wenn die Anfrage nicht mehr bearbeitet werden muss, weil sie vielleicht irrtümlich einging oder der Kunde sie zurückgezogen hat, kann das Team sie stornieren. Aktiv, gelöst und storniert. Diese drei Zustände geben dem Team einen gemeinsamen Überblick über den Status jedes Problems, sodass niemand raten muss, ob ein Fall noch Aufmerksamkeit benötigt und Manager alte, abgeschlossene Arbeit nicht wie neue Kundenprobleme behandeln müssen. Ein Datensatz gibt Ihnen Kontrolle und die vollständige Kundenhistorie gibt dem Mitarbeiter Kontext.

Die Kundengeschichte hinter dem Fall Ein Fall sagt Ihnen, was behoben werden muss. Der Kundendatensatz sagt Ihnen, was zu diesem Moment gefüttert. Wenn ein Mitarbeiter einen Fall in Dynamics 365 Customer Service öffnet, kann er über die letzte Nachricht hinausblicken. Er sieht das Gesamtbild wie frühere Fälle, vergangene E-Mails, die mit dem Kunden verknüpften Produkte und dessen Support-Historie. Kontext verändert das Gespräch. Warum ist Kontext wichtig? Stellen Sie sich vor, ein Kunde meldet einen Geräteausfall. Wenn der Agent nur die heutige Nachricht sieht, stellt er möglicherweise grundlegende Fragen. Und welches Modell das ist? Wann hat es angefangen? Haben Sie es neu gestartet? Aber der Kunde hat den Support diese Woche bereits zweimal kontaktiert. Der erste Mitarbeiter sandte Schritte zur Fehlerbehebung, der zweite organisierte ein Ersatzteil. Ein dritter Mitarbeiter, der diesen Verlauf sieht, wird den Kunden nicht bitten, von vorn anzufangen.

Stattdessen sagt er, ich sehe, dass Sie diese Schritte bereits versucht haben und das Ersatzteil das Problem nicht behoben hat. Lassen Sie es den nächsten Schritt versuchen. Das fühlt sich ganz anders an, als können Sie das Problem bitte noch einmal erklären? Dies wird oft als 63 Grad Kundensicht bezeichnen. Der Name klingt schick, ist aber simpel. Es bedeutet, dass der Agent den Kunden aus mehr als einem Blickwinkel sieht, nicht nur als isolierte Nachricht. Der Agent sieht die Person, das Unternehmen, frühere Supportanfragen, vergangene Gespräche und die damit verbundenen Produkte. Für ein Support-Team ersetzt das Raten durch einen klaren Ausgangspunkt. Nun erhält nicht jeder Kunde die gleiche Art von Support. Ein Kunde hat vielleicht eine Garantie erworben, sein Unternehmen bezahlt für eine bestimmte Anzahl an Supportstunden. Oder er hat einen Vertrag für eine bestimmte Anzahl von Fällen oder Premium-Support mit schnellerer Hilfe, mit schnellerer Hilfe.

Dynamics 365 verfolgt all dies durch Berechtigungen. Eine Berechtigung ist die Support-Vereinbarung des Kunden innerhalb des Systems. Betrachten Sie es als die Servicebedingungen, die an das Konto gebunden sind. Bevor ein Agent einem Techniker zusagt oder kostenpflichtige Arbeiten beginnt, prüft er, welcher Support gilt. Das vermeidet unangenehme Überraschungen. Zum Beispiel könnte ein Kunde noch Garantie auf ein defektes Produkt haben. Der Fall kann diesem Pfad folgen. Ein anderer Kunde hat möglicherweise alle Supportstunden aufgebaut. Der Agent sieht das, bevor er sich zu arbeiten außerhalb der Vereinbarung verpflichtet. Es hilft dem Support-Team auch, kundenfair zu behandeln. Der Agent muss nicht alte Verträge durchsuchen oder eine andere Abteilung fragen. Die Support-Bedingungen liegen bei den Kundeninformationen genau dort, wo der Agent sie finden kann. Dann gibt es noch die Wissensdatenbank.

Support-Teams lösen dieselben Probleme immer wieder. Passwort-Resets. Einrichtungsanweisungen. Ein bekannter Fehler nach einem Update. Eine Abrechnungsfrage mit Standardantwort. Ein Wissensartikel speichert diese Antwort dann im Ort. Innerhalb des Service-Arbeitsbereichs kann ein Agent während der Arbeit dann am Fall nach Artikeln suchen. Ein Artikel kann eine einfache Erklärungsschritte, einen Screenshot oder die genauen Prüfungen enthalten, die das Team durchführen sollte. Anstatt dass jeder Agent seine eigene Version aus dem Gedächtnis schreibt, nutzen sie eine geteilte Antwort, die das Team überprüft hat. Das sorgt für konsistenten Support. Es hilft auch neueren Mitarbeitern. Sie brauchen keine jahrelange Erfahrung, um gängige Probleme gut zu lösen, da die bekannten Lösungen des Teams jederzeit verfügbar sind. Co-Pilot-Fallzusammenfassungen helfen bei einem weiteren häufigen Problemen Langefallhistorien.

Ein Fall kann im Laufe der Zeit viele E-Mails, Notizen und Aktualisierungen ansammeln. Alles zu lesen kostet Zeit, besonders nach einer Übergabe. Co-Pilot erstellt eine kurze Fallzusammenfassung, die Falltitel, Kunden, Betreff, Produkt, Priorität, Falltyp, Beschreibung und letzte Aktivitäten bündelt. Es ist eine kurze Zusammenfassung, bevor der Mitarbeiter beginnt. Der Mitarbeiter prüft den Datensatz zwar weiterhin und nutzt sein Urteilsvermögen, versteht die Situation aber schneller. Das hilft, wenn der Kunde wartet und der Fall bereits durch mehrere Hände gegangen ist. Sobald der Mitarbeiter den Kunden und das Problem versteht, muss der Fall die richtige Person erreichen. Von der Aufnahme bis zur richtigen Warteschlag. Ein Kunde kann auf viele Arten um Hilfe bitten. E-Mail, Telefonanruf, Chat, soziale Medien oder ein Self-Service-Portal. Der Kanal ändert sich, aber das Support-Team benötigt dennoch einen zentralen Ort zur Verwaltung der Anfrage.

Dynamics 365 kann Fälle aus diesen Unterhaltungen erstellen, wenn die Einrichtung Regeln zur Datensatzerstellung umfasst. Denken Sie an eine E-Mail, die an eine gemeinsame Support-Adresse eingeht. Anstatt sie in einem Posteingang liegen zu lassen, bis jemand bemerkt, wandelt eine Regel diese E-Mail in einen Fall um. Die Nachricht wird zum Arbeitsbeginn im Kundenservice. Das reduziert manuelles Kopieren. Dasselbe Prinzip gilt für andere verbundene Kanäle. Das Team wählt aus, welche Nachrichten einen neuen Fall erstellen und welche zu einem bestehenden gehören. Eine Antwort auf ein offenes Problem bleibt bei diesem Problem. Eine neue Frage erhält einen eigenen Fall. Dann benötigt der Fall einen Ort, an dem er verbleibt, bis jemand die Verantwortung. Dieser Ort ist oft eine Warteschlange. Eine Warteschlange ist ein gemeinsamer Arbeitsbereich für ein Team. Es ist nicht der Posteingang eines einzelnen Mitarbeiters und gehört nicht der Person, die die Anfrage gesehen hat.

Dadessen bietet sie dem gesamten Team einen Ort, an dem Aufgaben auf Bearbeitung warten. Denken Sie sich ein Unternehmen mit einem Abrechnungsteam, einem technischen Support und einem Rückgabeteam vor. Jedes Team hat seine eigene Warteschläge. Abrechnungsfragen gehen an die Abrechnung. Produktfehler an den technischen Support. Rückgabeanfragen an die Experten für den Rückgabeprozess. Das klingt einfach, weil es einfach ist. Durch eine klare Sortierung müssen Aufgaben nicht bind weitergereicht werden. Routing-Regeln helfen bei dieser Sortierung. Eine Routing-Regel prüft die Details eines Falls und sendet ihn an die richtige Warteschlange oder Person. Ein Fall zu einem bestimmten Produkt dient an das Produktteam. Ein Fall aus einer bestimmten Region geht an den lokalen Support. Ein schwerwiegendes Problem landet in einer dringenden Warteschlange. Eine allgemeine Frage wartet beim Standard.

Einige Unternehmen verteilen Aufgaben basierend auf Fähigkeiten. Ein Kunde, der auf Französisch schreibt, benötigt beispielsweise einen Mitarbeiter der Französisch. Ein technisches Problem erfordert jemanden, der für ein bestimmtes Produkt geschult hat. Routing bringt den Fall näher zu der Person, die ihn lösen kann, anstatt jede Anfrage gleich zu behandeln. Automatisierung hilft, aber Menschen treffen weiterhin Entscheidungen. Ein Teamleiter könnte sich einen schwierigen Fall ansehen und ihn direkt einem erfahrenen Mitarbeiter zuweisen. Vielleicht kennt jemand den Kunden bereits persönlich. Vielleicht betrifft das Problem mehrere Produkte und erfordert Erfahrungen, die eine Regel nicht bewerten kann. Manuelle Zuweisung gibt dem Team Spielraum für diese menschliche Entscheidung. Die Zuständigkeit kann sich wehrnissweit setzen. Ein Mitarbeiter benötigt möglicherweise mehr Informationen und gibt den Fall zurück in eine Warteschlange.

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. Dynamics 365 hält die Arbeit im Fluss, anstatt sie bei jemandem feststecken zu lassen. Nun, manchmal erzeugt ein einziges Problem viele Fälle. Stellen Sie sich einen Softwareausfall vor, der Dutzende von Kunden betrifft. Jeder Kunde kontaktiert den Support separat, daher benötigt jeder Bericht seinen eigenen Fall. Aber alle Berichte beziehen sich auf ein größeres Problem. Ein übergeordneter Fall verfolgt dieses umfassendere Problem, während untergeordnete Fälle die einzelnen Kunden berichten darunter fest. Das bietet dem Support-Team zwei Ansichten gleichzeitig. Sie arbeiten an dem zugrunde liegenden Ausfall über den übergeordneten Fall, während jeder untergeordnete Fall den richtigen Kunden informiert hält. Wenn Sie die Lösung finden, müssen Sie nicht für jeden Anrufer denselben Ausfall von Grund auf untersuchen.

Doppelte Fälle erzeugen ein ähnliches Problem kleinerem Maßstab. Ein Kunde könnte wegen desselben Problems mailen und anrufen oder zwei Mitarbeiter könnten Fälle eröffnen, bevor sie den anderen bemerken. Anstatt den Aufwand aufzuteilen, kann das Team ähnliche Fälle zusammenführen. Ein Fall wird zum Hauptdatensatz und die Arbeit bleibt gebündelt. Niemand sollte dasselbe Problem zweimal lösen müssen. Einen Fall in die richtige Warteschlange und zur richtigen Person zu bringen, ist der Anfang. Und der Kunde erwartet eine Antwort innerhalb der versprochenen Zeit. Versprechen Einheiten mit SLAs und geführter Arbeit. Einen Fall zur richtigen Person zu bringen, ist nur die halbe Miete, da der Kunde auch Hilfe innerhalb der versprochenen Zeit erwartet. Und genau hier kommt eine Service-Level-Agreement, kurz SLA genannt, ins Spiel. 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.

Sei es für die erste Antwort oder die vollständige Lösung des Problems. Aber hier ist der entscheidende Punkt. Das sind nicht immer dieselben Fristen. 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. 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. Stellen Sie sich nun einen Kunden vor, dessen Dienst nicht mehr funktioniert. 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. 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.

Und verschiedene Kunden können unterschiedliche Zusagen erhalten. Ein Unternehmen mit Premium-Support erhält schnellere Antwortziele als ein Kunde mit einem Standardplan. Ein Auswahl mit hoher Priorität hat eine kürzere Frist als eine routinemäßige, wie geht das, Anfrage. Supportvereinbarung, Priorität und Volltyp bestimmen die geltenden Zeitregeln. Das hält die Zusagen fair und transparent. Ohne SLAs könnte ein Mitarbeiter das älteste Element in einer Liste bearbeiten, während ein zeitkritischer Fall unbemerkt seine Frist überschreitet. Mit SLAs zeigt der Bildschirm zum Fall Zeitindikatoren an, die dem Mitarbeiter sagen, welche Zusage zuerst Aufmerksamkeit erfordert. So sehen Sie, wie der Druck wächst. Ein Fall mit viel verbleibender Zeit muss bearbeitet werden, aber ein Fall, dessen Antwortfrist abläuft, erfordert sofortige Aufmerksamkeit. Teams können auch Warnungen oder Eskalationsschritte festlegen, wenn ein Ziel nahe ist oder bereits überschritten wurde, damit ein Vorgesetzter eingreifen kann, bevor der Kunde beim Team nachhacken muss.

Zeitvorgaben steuern die Dringlichkeit und Geschäftsprozessflüsse steuern die Arbeit selbst. Ein Geschäftsprozessfluss ist eine Reihe von Phasen, die innerhalb des Falls angezeigt werden. Er gibt einem Mitarbeiter einen klaren Weg vor, basierend darauf, wie das Unternehmen die Bearbeitung von Fällen wünscht. Die Phasen können von der Annahme über die Untersuchung bis zur Lösung reichen. Mit den richtigen Fragen und Prüfungen an jedem Punkt. Betrachten Sie es als eine Checkliste mit festem Platz im Prozess. Ein neuer Mitarbeiter muss nicht raten, welche Details wichtig sind, bevor er einen Fall an einen Spezialisten weiterleitet. Der Prozess kann nach Produkt, Problemtyp, Auswirkungen und anderen Informationen fragen, die das nächste Team benötigt. Ein erfahrener Mitarbeiter kann schneller arbeiten, aber der gemeinsame Pfad sorgt dafür, dass das Team in die gleiche Richtung arbeitet. Hier ist ein Szenario.

Ein Dienstausfall mit hoher Priorität ein. Der Fall gelangt in die dringende Warteschlange und das SLI beginnt herunterzuzählen. Der Mitarbeiter bestätigt die Kundendaten, protokolliert die Auswirkungen und sendet die erste Antwort, bevor dieses Antwortziel abläuft. Als nächstes verschiebt der Prozessfluss den Fall in die Diagnose, wo das Team Fehlerdetails sammelt und nach zugehörigen Berichten sucht. Der Fall geht dann in die Lösungsphase über, sobald das Team die Ursache identifiziert und ein Kundenupdate vorbereitet hat. Dieser Ablauf verschafft auch Managern ein klareres Bild. Sie können sehen, wo der Fall während der Aufnahme, Diagnose oder der finalen Kundenantwort in Stocken gerät. Der Ablauf löst das Problem für das Team nicht, verhindert aber, dass grundlegende Schritte an einem stressigen Tag untergehen. Dynamics 365 kann auch steuern, welche Statusänderungen Agenten an verschiedenen Punkten wählen können.

Dies nennt man Statusgrundübergänge. Das klingt technisch, ist aber ein einfaches Prinzip. Ein Fall sollte sinnvolle Schritte durchlaufen. 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. Die zulässigen Optionen können sich je nach Fall ändern. Ein Fall in Bearbeitung kann es einem Agenten beispielsweise ermöglichen, ihn auf Warten zu setzen, während er auf Kundendetails wartet. Nachdem der Kunde geantwortet hat, kann der Agent die Arbeit aktiv fortsetzen. Wenn das Problem behoben ist, kann der Fall auf gelöst gesetzt werden. Das sorgt für eine saubere Fallestuch. Eine Antwort allein schließt die Arbeit nicht ab. Das Team muss dokumentieren, wie das Problem endete und den Fall dann ordnungsgemäß schließen. Das Senden einer Antwort schließt einen Fall nicht automatisch.

Das Team muss die Lösung dokumentieren, also festhalten, was das Problem behoben hat oder welche Antwort der Kunde erhalten hat. Das könnte ein versendetes Ersatzgerät, eine erstattete Doppelzahlung oder eine vom Kunden korrigierte Einstellung sein. Diese Notiz wird Teil der Kundenakte und gibt dem nächsten Agenten einen nützlichen Anhaltspunkt, falls der Kunde Monate später erneut mit einem ähnlichen Problem anruft. Manchmal funktioniert die erste Lösung nicht. Vielleicht befolgt der Kunde die Anweisungen und der Fehler tritt erneut auf. Vielleicht kommt ein Ersatzteil an, behebt den Fehler aber nicht. In dieser Situation kann das Team den Fall wieder öffnen oder zurück in die Warteschlange stellen, statt einen neuen Datensatz ohne Historie anzulegen. Der Fall wird dort fortgesetzt, wo das Team aufgehört hat? Das ist wichtig, wenn die Zuständigkeit wechselt. Ein neuer Agent kann sehen, was der vorherige versucht hat, was der Kunde bestätigt hat und was noch geprüft werden muss.

Der Kunde muss nicht die ganze Geschichte von vorne erzählen, nur weil eine andere Person die Arbeit übernommen hat. Im Laufe der Zeit verraten all diese Fälle dem Support-Team auch, was über ein einzelnes Problem hinaus passiert. Manager können die Lösungszeit betrachten, die verfolgt, wie lange Fälle von der Eröffnung bis zum Abschluss dauern. Sie können die Phasenzeit analysieren, die zeigt, wo die Fälle ihre Zeit verbringen. 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. Die Arbeitsbelastung zählt Ihnen bei. Wenn sich Montagmorgens eine Warteschlange füllt, kann das Team dies sehen. Wenn technische Anfragen tagelang auf eine interne Prüfung warten, erscheint diese Verzögerung in den Falldaten. 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.

Die Zahlen allein erklären nicht alles. Sie zeigen dem Team, welche Fragen es wert sind, gestellt zu werden. Warum nehmen die Anfragen zum Bestimmten? Warum dauert eine bestimmte Fallart länger als erwartet? Warum suchen Mitarbeiter wiederholt nach derselben Antwort, finden aber keinen nützlichen Wissensartikel? Muster machen aus täglicher Supportarbeit praktisches Lernen. Ein Anstieg ähnlicher Fälle kann auf einen Produktfehler hindeuten. Könnte zeigen, dass ein aktuelles Update die Kunden verwirrt hat. Könnte aufzeigen, dass eine Anleitung klarere Schritte benötigt. Anstatt jede Anfrage als unabhängig zu betrachten, kann das Team die gemeinsame Ursache erkennen und daran arbeiten. Dies kann das zukünftige Fallaufkommen reduzieren. Kundenfeedback gehört ebenfalls in dieses Bild. Ein geschlossener Fall mag zeigen, dass das Team das Antwortziel erreicht hat. Doch der Kunde kann dennoch frustriert sein, wenn er den Support dreimal kontaktieren musste, wenn musste.

Die Betrachtung von Fallhistorie und Feedback gibt Managern einen umfassenderen Blick auf das Kundenerlebnis. Manche Kunden würden es vorziehen, gar keinen Fall zu erstellen. Hier kann ein Self-Service-Portal helfen. Ü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. Bei einfachen Fragen kann das für alle Zeit sparen. Ein Kunde kann einen Lieferstatus prüfen oder eine Einrichtungsanleitung folgen, wenn man es ihm passt. Unterdessen können Mitarbeiter mehr Zeit für Probleme aufwenden, bei denen ein Mensch ermitteln, erklären oder eine Entscheidung treffen muss. Dynamics 365 Customer Service lässt sich zu den mitvertrauten Microsoft-Tools rund um den Fallprozess verbinden. Ein Mitarbeiter kann E-Mails über Outlook bearbeiten. Ein Team kann ein schwieriges Problem in Teams diskutieren.

Dokumente und geteilte Informationen können in SharePoint gespeichert werden. 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. Jedes Tool hat seine eigene Aufgabe. Der Fall bleibt der Ort, an dem das Support-Problem und seine Historie verbunden bleiben. Selbst wenn Leute andere Tools zur Kommunikation, zum Teilen von Dateien, von Dateien, von Dateien oder zur Überprüfung der Arbeit nutzen, beim Fallmanagement geht es nicht wirklich darum, eine Ticketmaske auszufüllen. Es geht darum, jedem Kunden anliegen einen klaren Weg, eine aufgezeichnete Antwort und ein Team zu geben, das aus dem Geschehen entlernen. Fazit. Halten Sie die gesamte Kundengeschichte zusammen. Hier ist also das eigentliche Fazit. Das Dynamics-Item 65 Case Management bündelt Problem, Bearbeitung, Zusagen und Ergebnisse in einem Datensatz.

Kein Kontextverlust und keine mehrfache Führung mehr. Schauen Sie sich einen eigenen Support-Prozess an. Oh, wo verschwinden eigentlich die Kundeninformationen? Genau hier verändert die Zusammenführung alles. Abonnieren Sie auf Ihrer bevorzugten Podcast-Plattform für mehr Microsoft-Wissen von mir, Mirko Peters bei mtreff.fm, wo wir die Microsoft-Tools hinter der täglichen Arbeit verständlich erklären. Verständlich erklären.