methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session4-6 h für einen Service-Slice, danach 1 h Pflege pro QuartalWorkshopService Blueprint

Session: Service Blueprinting

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Die App wählt

Methoden-Session mit 6-12. Der Plan nutzt die vorhandene Methodenlogik und das Run Sheet.

Run Sheet
  1. 1

    Phase 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. Hinweis: Wenn diese Bahn neu entsteht statt aus bestehender Journey kommt, fehlt Vorbedingung. Pause und Journey klären, sonst wird Blueprint Spekulation. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.

    FacilitatorService Blueprint
  2. 2

    Phase 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. Hinweis: Frontstage ist nur, was der Kunde direkt erlebt. Interne Validierungen gehören schon hinter die Visibility-Linie. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.

    FacilitatorFail Points
  3. 3

    Phase 3: Backstage und Support

    60 min

    Backstage-Aktionen und Support-Prozesse pro Frontstage-Schritt. Owner und System benennen. Verbindungen mit Pfeilen, Asynchrone Übergaben markieren. Hinweis: Wer eine Backstage-Spur ohne Owner produziert, hat einen blinden Fleck. Lieber explizit „unbekannt, klären bis ...“ als Owner-Annahme. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.

    FacilitatorOwnership Map
  4. 4

    Phase 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. Hinweis: Schwarze Fail Points ohne Häufigkeit oder Impact sind subjektiv. Mindestens eine Beobachtung oder Metrik pro Fail Point fordern. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.

    FacilitatorService Blueprint
  5. 5

    Phase 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. Hinweis: Wenn die Verbesserung „mehr Personal“ lautet, ist sie keine. Strukturhebel suchen: Automatisierung, Übergabe streichen, SLA neu verhandeln. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.

    OwnerFail Points
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerService Blueprint
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

# Session Brief: Service Blueprinting

## Ziel
Artefakt: Service Blueprint

## Arbeitsfrage
An welchen unsichtbaren Backstage-Schritten entstehen Fail Points, die der Kunde an der Frontstage als Reibung erlebt?

## Kontext
Customer Journey; Liste aller Touchpoints (digital, telefonisch, physisch); Systemlandschaft mit Ownership; bekannte Incidents oder Beschwerden der letzten 90 Tage; SLAs externer Provider.

## Setup
- Format: Methoden-Session
- Dauer: 4-6 h für einen Service-Slice, danach 1 h Pflege pro Quartal
- Modus: Workshop
- Teilnehmende: 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.
- Owner: Ein Facilitator mit Service-Design-Erfahrung
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Service Blueprint hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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.

## Vorbereitung
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.

## Agenda
1. Phase 1: Customer Actions (45 min)
   Owner: Facilitator
   Aktion: 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. Hinweis: Wenn diese Bahn neu entsteht statt aus bestehender Journey kommt, fehlt Vorbedingung. Pause und Journey klären, sonst wird Blueprint Spekulation. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Service Blueprint

2. Phase 2: Frontstage (45 min)
   Owner: Facilitator
   Aktion: Pro Customer Action die sichtbaren Mitarbeiter- oder System-Aktionen darunter. Mit Rolle und Tool. Physical Evidence (E-Mails, Belege, App-Screen) oberhalb der Actions. Hinweis: Frontstage ist nur, was der Kunde direkt erlebt. Interne Validierungen gehören schon hinter die Visibility-Linie. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Fail Points

3. Phase 3: Backstage und Support (60 min)
   Owner: Facilitator
   Aktion: Backstage-Aktionen und Support-Prozesse pro Frontstage-Schritt. Owner und System benennen. Verbindungen mit Pfeilen, Asynchrone Übergaben markieren. Hinweis: Wer eine Backstage-Spur ohne Owner produziert, hat einen blinden Fleck. Lieber explizit „unbekannt, klären bis ...“ als Owner-Annahme. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Ownership Map

4. Phase 4: Fail Points und Wartezeiten (45 min)
   Owner: Facilitator
   Aktion: Mit roten Stickies Fail Points markieren (Übergaben, externe Calls, manuelle Schritte). Wartezeiten und SLA-Verstöße quantifizieren wo möglich. Hinweis: Schwarze Fail Points ohne Häufigkeit oder Impact sind subjektiv. Mindestens eine Beobachtung oder Metrik pro Fail Point fordern. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Service Blueprint

5. Phase 5: Maßnahmen-Slice (30-45 min)
   Owner: Owner
   Aktion: Drei bis fünf Fail Points priorisieren nach Häufigkeit × Schmerz. Pro Punkt eine konkrete Verbesserung mit Owner und Erfolgsmetrik definieren. Hinweis: Wenn die Verbesserung „mehr Personal“ lautet, ist sie keine. Strukturhebel suchen: Automatisierung, Übergabe streichen, SLA neu verhandeln. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Fail Points

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Service Blueprint

## Abschluss
- Ergebnisartefakt aktualisieren: Service Blueprint
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

# Service Blueprint: Service Blueprinting

## Arbeitsfrage
An welchen unsichtbaren Backstage-Schritten entstehen Fail Points, die der Kunde an der Frontstage als Reibung erlebt?

## Kontext
Customer Journey; Liste aller Touchpoints (digital, telefonisch, physisch); Systemlandschaft mit Ownership; bekannte Incidents oder Beschwerden der letzten 90 Tage; SLAs externer Provider.

## Beteiligte
- Owner: Ein Facilitator mit Service-Design-Erfahrung
- Teilnehmende: 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.

## Input
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.

## Vorlage
# 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.

## Fertigstellungscheck
- Service Blueprint ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren
Vorlagenbasis

Service Blueprinting Arbeitsvorlage

# 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.
Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Service Blueprint.
  • 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.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.