Digitalisierung des Service-Diagnoseflusses

Die Digitalisierung des Kundenservices innerhalb des vorgegebenen Zeitrahmens zur Vereinheitlichung von App Artisans und Back Office zur Verwaltung des Flusses von Anfragen für Wiederinterventionen nach einem Ausfall oder Vorfall bei der Installation

Die Bearbeitung des Kundenservices basierte auf zahlreichen und heterogenen Dokumenten, wenig geführten Prozessen und unregelmäßigen Wiederinterventionen. Als Product Designer habe ich die Schlüsselprozesse strukturiert, frühzeitig Wireframes erstellt und dann ein detailliertes Design bis zum finalen Prototypen für die Implementierung ausgearbeitet. In 1,5 PI haben wir App Artisans und Back Office auf einen klaren und „standardisierten“ Fluss ausgerichtet, der von den Handwerkern verstanden wird und die Kundenbeziehung entlastet. What’s the point: Der Kundenservice wird steuerbar, vorhersehbar und weniger kostenintensiv in der Unterstützung.

Hauptbildschirme für den funktionalen Verlauf der Kundenserviceverwaltung in der App Artisans

Kontext

Das Projekt zielt auf die Digitalisierung der Kundenserviceprozesse durch zwei komplementäre Produkte ab: eine App Artisans, die im Feld verwendet wird, und ein Back Office, das von der Kundenbeziehung / den Operationsteams betrieben wird. Der Kern des Kundenservices war stark auf „Dokumente“ (Berichte, Fotos, Angebote, Berichte) ausgerichtet, mit einer Heterogenität, die das Lesen und die Entscheidungsfindung erschwerte. Parallel dazu häuften sich die Kundenservicefälle, und es traten neue Dokumenttypen auf, wie Angebote, die den Betrag der für eine Reparatur verwendeten Objekte aufschlüsselten.

Der Rahmen war auch hinsichtlich der Planung sehr eng: Das Ziel war, eine erste funktionale Version in einem PI und halb zu liefern, was ein hohes Maß an Pragmatismus erforderte. Schließlich war ein Schlüsselpunkt des Projekts, digitalisieren, ohne die Gewohnheiten der Handwerker zu stören. Mit anderen Worten: ein klares und vertrautes Erlebnis anstreben und zu „innovative“ Muster vermeiden, die das Risiko von Missverständnissen oder Ablehnungen erhöht hätten.

Problem und Objectives

Das Hauptproblem resultierte aus einem hohen Volumen an Dokumenten, die zu bewerten waren, wobei Entscheidungen langsam und mehrdeutig werden konnten, wenn die Status und Verantwortlichkeiten nicht ausreichend klar waren. Ein weiterer Punkt der Reibung betraf die Wiederintervention: Der Prozess war nicht immer reibungslos, was zu Fehlern, Verzögerungen und manchmal zu „ad hoc“-Neuterminierungen führte. Schließlich wurde das Auftreten neuer Dokumenttypen (wie Angebote zu den verwendeten Teilen/Objekten) nicht zufriedenstellend in den bestehenden Fluss integriert, was das Risiko von Umgehungen oder Doppelungen schuf.

Das Ziel des Projekts war es daher, die App und das Back Office um einen klaren Fluss zu vereinen, mit verständlichen und expliziten Entscheidungsregeln, und die Wiederintervention einfach umsetzbar zu machen, in ein oder zwei Schritten aus den Kundenservicestatus. All dies sollte es ermöglichen, diese neuen Dokumente zu integrieren, ohne ein „zweites System“ parallel zu schaffen und über die Zeit hinweg konsistent zu bleiben.

Rolle und strategischer Umfang

In diesem Projekt habe ich die Rolle eines Product Designers end-to-end übernommen, von frühen Wireframes bis hin zu einem detaillierten Design der Prozesse und schließlich einem finalen Prototypen, der bereit für die Implementierung war. Mein Umfang umfasste insbesondere die Definition der Stati, Übergänge und Regeln im Zusammenhang mit Dokumenten, Status und Wiederinterventionen sowie die Synchronisation zwischen dem App-Erlebnis und dem Back Office, um die Konsistenz der Bildschirme und Verantwortlichkeiten zu gewährleisten.

Das Projekt zielte nicht auf eine vollständige Neugestaltung der Produktinformation ab; der Aufwand war bewusst auf die kritischen Kundenserviceprozesse konzentriert, mit einem ständigen Augenmerk auf Umsetzbarkeit und Lieferung innerhalb des vorgegebenen Zeitrahmens.

Ansatz

Ich habe zunächst das Thema durch die Kartographierung des bestehenden Kundenserviceflusses strukturiert, indem ich die Dokumente, Akteure, Stati aufgeschlüsselt und die Bereiche der Mehrdeutigkeit sowie die Schleifen der Wiederintervention identifiziert habe. Diese Phase hat es ermöglicht zu klären, wo die blockierenden Entscheidungen lagen und was klarer gemacht werden musste.

Anschließend habe ich Wireframes erstellt, um einfache „Glückspfade“ vorzuschlagen und zu überprüfen, dass die minimalen Schritte sowohl für die Handwerker als auch für das Back Office sinnvoll waren. Von dort aus habe ich die Prozesse in Form von Wireflows detailliert, indem ich die Stati, Übergänge, Voraussetzungen und erwarteten Ausgaben beschrieben habe, während ich die tatsächlich wesentlichen Ausnahmen umschrieb.

Schließlich habe ich alles in einem finalen Prototypen zusammengeführt, mit den Schlüsselinteraktionen, einem klaren mikroskopischen Entscheidungs-Text und einer visuellen Ausrichtung zwischen App und Back Office, die als direkte Grundlage für die Implementierung dienen sollte. Die Aufteilung folgte einer Sequenzierungslogik, die mit der Planung kompatibel war: zuerst die kritischen Dokumente, dann die Wiederintervention, dann die Integration der neuen Dokumente.

Schlüsselentscheidungen

Mehrere strukturierende Entscheidungen leiteten das Design. Zunächst ermöglichte die Standardisierung der Dokumentenstatus (zu liefern, zu validieren, genehmigt, abgelehnt) eine größere Klarheit, auf Kosten einer geringeren Flexibilität bei einigen seltenen Fällen. Anschließend bevorzugte ich einen Einstiegspunkt pro Kundenserviceintervention mit einer Form von “Anforderungen”-Dokumentation: Die Idee war, Orientierung zu bieten, ohne zu überladen, auch wenn dies die totale Freiheit bei der Reihenfolge der Aktionen einschränkte, um Fehler zu minimieren.

Die Wiederintervention wurde von dem Kundenservicestatus aus mit einer Vorbefüllung zugänglich gemacht, um die Ausführungsgeschwindigkeit zu fördern, indem eine sehr detaillierte Anpassung der Anspruchsgrundlagen akzeptiert wurde. Für das „Verwendete Teile Angebot“ wurde die Entscheidung getroffen, es als ein Dokument des Typs „Angebot“ zu integrieren (anstatt einen separaten Fluss zu erstellen), um die Kohärenz des Systems zu wahren, während spezifische Bedürfnisse über eigene Felder kompensiert wurden.

Schließlich verbesserte die Wiederverwendung gemeinsamer Komponenten zwischen App und Back Office (Listen, Zeitlinien, Viewer) die Wartbarkeit und die Geschwindigkeit, auch wenn dies die Annahme eines weniger „maßgeschneiderten“ Ergebnisses bedeutete. In Bezug auf den Stil wurde eine pragmatische mikroskopische Kopie, die auf Aktionen ausgerichtet ist, gegenüber einem zu administrativen internen Jargon zugunsten der Teams in der Kundenbeziehung bevorzugt.

Lösung und Auswirkungen

Vorher litt der Verlauf unter einem Mangel an Nachvollziehbarkeit und Klarheit: Dokumente waren schwer zu bewerten, Wiederinterventionen wurden durch Umgehungen ausgelöst, und neue Dokumente wurden zu allgemein verwaltet. Danach wird die Intervention zu einer lesbaren Einheit, mit einer klaren dokumentarischen Checklist und expliziten Status, schnellen Aktionen (Wiederintervention anfordern, validieren/ablehnen, Ergänzungen anfordern), einer spezifischen Integration des „Verwendeten Teile Angebots“ und einer einheitlichen Zeitlinie, um Dokumente, Entscheidungen und Wiederinterventionen zu verknüpfen.

In Bezug auf die Auswirkungen, auch ohne quantifizierbare Metriken waren die erwarteten Signale klar: ein besseres Verständnis des Verlaufs durch die Handwerker ohne schwere Schulungen, weniger Hin- und Her und ein entlasteter Kundenservice dank schnelleren Entscheidungen und besserer Sichtbarkeit der Schritte.

Learnings, Artefakte, fehlende Elemente und Fortsetzung

Das Projekt bestätigt, dass die Benennung und Begrenzung der Stati Entscheidungen sofort klarer macht und die UI vereinfacht. Es zeigt auch, dass die Nähe zu den Gewohnheiten im Feld ein Hebel für die Akzeptanz sein kann und dass detaillierte Wireflows den Produkt-/Geschäfts-/Tech-Abgleich beschleunigen. Schließlich ist der iterative Mehrwert des Produkts eine Disziplin, die es ermöglicht, einen engen Zeitplan einzuhalten, ohne die Kohärenz zu opfern.

Fehlende Elemente betreffen hauptsächlich Nachberichte nach der Lieferung, eine Messung der vermiedenen Wiederinterventionen, die durchschnittliche Zeit für dokumentarische Entscheidungen und vergleichende Beispiele vor/nach. Ein realistischer Erhebungsplan wäre eine In-App-Umfrage nach zwei Wochen, eine Extraktion und Kategorisierung von Kundenservice-Tickets über vier Wochen, eine Überprüfung einer Stichprobe von Interventionen vor/nach mit Zeitlinie, eine Rückblick-Sitzung mit Handwerkern und Back Office-Mitarbeitern und vergleichende Erfassungen von Schlüsselscreens. Dies wurde aus Zeitgründen nicht umgesetzt.

Globales Wireflow des finalen Prototyps:

Kundenserviceverwaltung aus dem Back-Office:

Metriken

Um die tatsächlichen Auswirkungen des digitalen Kundenserviceverlaufs zu bewerten, haben wir einen Satz von Metriken definiert, die auf Adoption, Ausführungsqualität und operative Belastung ausgerichtet sind. Das Ziel war nicht nur die „Digitalisierung“, sondern sicherzustellen, dass der neue Fluss die Reibungen im Feld reduzierte, die Abschlüsse sicherstellte und die Kundenbeziehung entlastete. Diese Indikatoren wurden als umsetzbare Signale ab der V1 gedacht, auch in Abwesenheit perfekt konsolidierter historischer Metriken.