Was vorher fertig sein muss
Eine vorhandene Customer Journey für den zu blueprintenden Service mit klar abgegrenzten Phasen und Touchpoints.
Liste der beteiligten Rollen, Systeme und externen Provider mit jeweils einem Owner pro Rolle.
Was vor Start vorliegen muss
Großer Whiteboard- oder Miro-Board mit fünf Bahnen (Customer Actions, Frontstage, Backstage, Support Processes, Physical Evidence); Stickies in fünf Farben; Linealkarten für Linien (Interaction, Visibility, Internal Interaction); Zugang zu Prozessdiagrammen und Systemdokumentation.
Ein Facilitator mit Service-Design-Erfahrung; je ein Vertreter pro Frontstage-Rolle (Sales, Service, Support); je ein Owner pro Backstage-System; ein Notetaker; ein UX Lead für Visibility-Linie.
Customer Journey; Liste aller Touchpoints (digital, telefonisch, physisch); Systemlandschaft mit Ownership; bekannte Incidents oder Beschwerden der letzten 90 Tage; SLAs externer Provider.
4-6 h für einen Service-Slice, danach 1 h Pflege pro Quartal
Bahnen horizontal: oben Physical Evidence, dann Customer Actions, Line of Interaction, Frontstage, Line of Visibility, Backstage, Line of Internal Interaction, Support Processes. Vertikal in Journey-Phasen aufgeteilt.
Die eine Frage, die diese Methode beantwortet
An welchen unsichtbaren Backstage-Schritten entstehen Fail Points, die der Kunde an der Frontstage als Reibung erlebt?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Customer Actions | 45 min | Pro Journey-Phase die konkreten Aktionen des Kunden eintragen, Verb-orientiert und mit Touchpoint („öffnet App“, „ruft Hotline an“). Aus Journey übernehmen, nicht neu erfinden. | Wenn diese Bahn neu entsteht statt aus bestehender Journey kommt, fehlt Vorbedingung. Pause und Journey klären, sonst wird Blueprint Spekulation. |
2Phase 2: Frontstage | 45 min | Pro Customer Action die sichtbaren Mitarbeiter- oder System-Aktionen darunter. Mit Rolle und Tool. Physical Evidence (E-Mails, Belege, App-Screen) oberhalb der Actions. | Frontstage ist nur, was der Kunde direkt erlebt. Interne Validierungen gehören schon hinter die Visibility-Linie. |
3Phase 3: Backstage und Support | 60 min | Backstage-Aktionen und Support-Prozesse pro Frontstage-Schritt. Owner und System benennen. Verbindungen mit Pfeilen, Asynchrone Übergaben markieren. | Wer eine Backstage-Spur ohne Owner produziert, hat einen blinden Fleck. Lieber explizit „unbekannt, klären bis ...“ als Owner-Annahme. |
4Phase 4: Fail Points und Wartezeiten | 45 min | Mit roten Stickies Fail Points markieren (Übergaben, externe Calls, manuelle Schritte). Wartezeiten und SLA-Verstöße quantifizieren wo möglich. | Schwarze Fail Points ohne Häufigkeit oder Impact sind subjektiv. Mindestens eine Beobachtung oder Metrik pro Fail Point fordern. |
5Phase 5: Maßnahmen-Slice | 30-45 min | Drei bis fünf Fail Points priorisieren nach Häufigkeit × Schmerz. Pro Punkt eine konkrete Verbesserung mit Owner und Erfolgsmetrik definieren. | Wenn die Verbesserung „mehr Personal“ lautet, ist sie keine. Strukturhebel suchen: Automatisierung, Übergabe streichen, SLA neu verhandeln. |
Was am Ende rauskommt
Service Blueprint als Foto oder Miro-Board mit allen Bahnen und Linien plus begleitender Bericht mit identifizierten Fail Points, Häufigkeit, Owner und priorisiertem Maßnahmen-Slice.
Pro Service-Variante eigener Blueprint mit Versionsdatum. Änderungen am Service (neue Systeme, neue Touchpoints) erzeugen neue Version, alte mit Archive-Tag. Maßnahmen-Slice als verknüpftes Roadmap-Item.
Kompakte Arbeitsvorlage für Service Blueprinting mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Service Blueprinting Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Service Blueprint:
- Fail Points:
- Ownership Map:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Service Blueprint — Online-Schadenmeldung Kfz, Q2 2026
**Phase 1 (Schadenmeldung)**
- Customer Action: Kunde fotografiert Schaden, lädt in App hoch.
- Frontstage: App-Wizard mit 4 Schritten, Bestätigungs-E-Mail.
- Backstage: Bilderkennungs-Service (extern, Provider A, SLA 30 s), Schaden-DB.
- Support: Underwriting-Regelwerk.
- Fail Point F1 (rot): Provider A Timeout in 6% der Fälle, Kunde sieht Fehler ohne Hinweis.
**Phase 2 (Begutachtung)**
- Customer Action: Wartet auf Anruf.
- Frontstage: Sachbearbeiter ruft an, Termin mit Gutachter.
- Backstage: Gutachter-Disposition (manuell, Outlook), externer Gutachter.
- Fail Point F2 (rot): durchschnittlich 3,2 Tage Wartezeit bis Anruf, SLA wäre 1 Tag.
**Maßnahmen-Slice (bis 30.09.)**:
- F1: Fallback-Provider B integrieren, Owner @ben.
- F2: Disposition auf Tool umstellen mit Auto-Assignment, Owner @anna.
- Erfolgsmetrik F2: Mittlere Wartezeit unter 1,2 Tagen, gemessen über CRM.Symptome erkennen, gegensteuern
Pfeile zeigen auf Systeme oder Teams, niemand kann verbindlich für sie sprechen.
Owner-Liste vor Beginn vollständig. Wenn ein System keinen Owner hat, ist der Blueprint unvollständig. Lieber Lücke explizit markieren als raten.
Interne Prüfschritte werden als Frontstage eingetragen, weil ein Mitarbeiter sie sieht.
Linie streng am Kunden-Erleben. Was der Kunde nicht sieht, ist Backstage, auch wenn ein Mitarbeiter daran arbeitet.
Rote Stickies werden aus Bauchgefühl gesetzt, Häufigkeit unbekannt.
Pro Fail Point mindestens eine Beobachtung oder Metrik. Wenn keine Daten verfügbar, Spike zur Erhebung vor Maßnahme.
Blueprint umfasst Akquise, Lieferung, Service und Beendigung in einer Map, alles bleibt oberflächlich.
Pro Session ein Service-Slice (z. B. nur Schadenmeldung). Andere Phasen in eigenen Blueprints. Tiefe vor Breite.
Lösung jeder Reibung ist Aufstockung, keine strukturelle Änderung.
Pro Fail Point Strukturhebel zwingen: Übergabe streichen, Automatisierung, neue Reihenfolge, SLA. Mehr Personal nur als letzter Hebel mit ROI-Begründung.
Nach 6 Monaten stimmen die Systeme nicht mehr, neue Provider fehlen, Maßnahmen sind unprüfbar.
Quartalsweise Pflege fest einplanen. Bei Service-Änderung Blueprint-Update als Definition-of-Done der Änderung.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.