Vom Point of Sale zum Point of Experience

Wie Headless POS Customer Journeys orchestriert und warum das euer stärkster Wettbewerbsfaktor wird.

Eine Szene, die man oft sehen kann:

Eine Kundin steht vor dem Regal, hat die Jacke in der Hand, aber nicht die richtige Größe. Früher: „Tut mir leid, online vielleicht noch verfügbar“ und hoffentlich kommt sie später zurück. Heute läuft es anders: Verkäufer zückt Tablet, checkt Bestand, legt die Größe in den Warenkorb, bietet Lieferung für morgen an, Kundin bezahlt am Regal. Kein Kassenstau, keine Medienbrüche, kein „Kommen Sie später“.

Das ist für mich die Essenz dessen, was wir intern „vom POS zum POX, dem Point of Experience“ nennen. Headless ist dafür kein Selbstzweck. Es ist das Betriebssystem für Erlebnisse, die dort passieren, wo der Kaufimpuls gerade ist.

Was sich verschiebt: von Geräten zu Journeys

Wenn wir Headless richtig denken, verschieben wir unsere Aufmerksamkeit weg vom „Kassenmöbel“ hin zur Kundenreise. Damit meine ich nicht „Marketing-Funnel“, sondern das ganz Konkrete im Ladenalltag: Wer tut wann wo was und welche UI ist dafür die beste „Linse“?

• Assisted Selling: Das Tablet am Regal ist nicht „mobile Kasse“, es ist ein Beratungstool, das Zahlung kann.
• Self Service: Der Kiosk ist nicht „zweite Kasse“, sondern eine ruhige Spur für Standardkäufe in Peaks.
• Online-zu-Store: Webshop ist nicht „anderer Kanal“, sondern ein Einstiegspunkt in dieselbe Transaktion.
• Automat/Abholstation: Kein „Sonderfall“, sondern ein Touchpoint in derselben Journey, nur eben ohne Personal.

Headless macht das möglich, weil Transaktion und Regeln stabil im Kern bleiben und ihr vorn natürlich die passende UI aufsetzt. (Wer das hier gelesen hat, weiß: transaktionszentriert statt terminalzentriert.)

Drei Journeys (so, wie ich sie bei erfolgreichen Retailern sehe)

1) Beratung am Regal (Assisted Selling)

Die Beratung beginnt mit Auswahl & Größencheck. Der entscheidende Moment ist nicht der Gang zur Kasse, sondern der Fortschritt in der Beratung. Das Tablet ist die Linse auf die Transaktion: Artikel hinzufügen, Alternativen zeigen, Rabattregeln prüfen, sofort kassieren oder „morgen liefern“.

Warum es funktioniert:

• Momentum bleibt bei der Beratung, nicht in der Schlange.
• „Nicht da“ wird zu „kommt morgen“ und das ohne Medienbruch.
• Promotions greifen genau wie am Kiosk und im Web.

Team-Hinweis: Trainiert „Assist Mode“ wie Mitarbeitende clean übernehmen, wenn etwas klemmt (Altersprüfung, Zahlungsabbruch, ID-Check).

2) Self-Checkout mit Assist Mode (Peaks sauber brechen)

Self-Checkout ist keine Religion, sondern ein Staumanager. Gut gemacht reduziert er Wartezeiten und ohne, dass Service leidet. Entscheidend sind drei Dinge: klarer Flow, sichtbarer Assist Mode (Mitarbeiter können an jedem Punkt übernehmen) und gleiches Regelwerk wie am Regal und online.

Warum es funktioniert:

• Peaks werden planbar (Samstag, Events, Saisonstart).
• Personal wird dort eingesetzt, wo es Wert schafft: Beratung statt Abkassieren.
• Die Journey bleibt konsistent, weil ein Warenkorb ist ein Warenkorb.

Messung: „Assist-Quote“ (wie oft hilft Personal), Abbruchrate pro Schritt, Durchsatz pro Kiosk.

3) Web → Store → Automat (Click & Collect ohne Friktion)

Der Warenkorb entsteht online. In der Filiale will die Kundin ergänzen („noch die Mütze dazu“), nicht neu beginnen. Abschluss am Kiosk oder beim Mitarbeiter, Abholung 24/7 am Automaten? Alles okay, denn eine Transaktion, ein Beleg, ein Regelwerk.

Warum es funktioniert:

• Es fühlt sich „nahtlos“ an, weil es nahtlos ist.
• Retouren & Umtausch sind sauber und natürlich steuerlich korrekt und nachvollziehbar.
• Marketing muss Promo-Regeln nicht „zweimal denken“.

Designprinzipien für erlebnisstarke Journeys

Ich packe hier mal die Prinzipien rein, die bei Projekten den Unterschied machen:

• Kontinuität statt Neustart: Warenkorb & Identität wandern mit (QR, Link, Token), heißt kein Reset pro Gerät.
• Latenzbudget: UI-Aktionen müssen in <300 ms reagieren, sonst bricht der Flow. WebSockets schlagen eindeutig Polling.
• Klare Exit-Rampen: An jedem Punkt braucht es „Assist“-Pfad für Mitarbeiter.
• Progressive Disclosure: Nur die Infos zeigen, die jetzt helfen (Details on demand).
• Fehlertoleranz: Offline-Fall ist kein „Fehler“, sondern Zwischenzustand (lokal persistieren, später synchronisieren).
• Idempotenz: Aktionen dürfen beim Wiederholen keinen Schaden anrichten (Doppeltap, Funkloch, Browser-Back).
• Ein Regelwerk: Promotions & Steuern nie ins UI hart einbauen, denn der Core entscheidet und die UI visualisiert.

KPIs: Woran ihr echten Fortschritt erkennt

Ich bin allergisch gegen „wir haben das Gefühl, es ist besser“. Headless gibt euch die Chance, Wirkung zu messen, weil alle Touchpoints auf einem Kern laufen:

• Abbruchquote je Schritt (Auswahl → Warenkorb → Zahlung)
• Durchsatz & Queue-Time (Self-Checkout, Peak-Fenster)
• Assist-Quote (wie oft hilft Personal und niedrig ist nicht immer gut!)
• Time-to-Release (UI-Änderung „Ticket zu Live“)
• Promo-Compliance (Abweichungen „0“ über Kanäle)
• After-Sales (Retourenzeit, Kulanzfälle, Kosten pro Return)
• NPS an Touchpoints (kurze, kontextnahe Befragung)

Pro-Tipp: Metriken vor dem Pilot definieren. Dann gibt’s hinterher kein „Äpfel mit Birnen“ (oder so).

Team & Rollen: Wer schafft die Experience wirklich?

Wenn ihr vom Gerät zur Journey wechselt, verändert sich auch die Zusammenarbeit:

• Store Ops bringt Realität auf die Roadmap (was passiert wirklich an Station XY?).
• Product/UX gestaltet Flows & Micro-Interactions (und verantwortet die KPI-Wirkung.)
• Engineering hält den Kern stabil (Transaktion, Regeln) und baut UI-Templates, die schnell variieren.
• Compliance spart Diskussionen, weil sie im Core prüft und nicht UI für UI.
• Training liefert Micro-Learnings für Assist-Szenarien („Was tun bei Altersprüfung am Kiosk?“).

Kleine, crossfunktionale Teams sind hier Gold wert.

Governance ohne Spaßbremse

Offen heißt nicht chaotisch. Drei Leitplanken reichen oft, um schnell und robust zu sein:

1. Design-System: Komponenten, Zustände, Fehlertexte, Begriffe: einmal sauber, überall konsistent.
2. API-Verträge als Produkt: Versionen, Deprecation, Beispielpayloads, Fehlercodes (bitte immer dokumentiert.)
3. Change-Playbook: Wer schaltet was wann wie frei? Rollback? Prüfpfade für Promo/Steuer/Beleg?

Security gehört dazu: TLS, Gerätehärtung, Secrets-Handling, Rollen/Rechte und vor allem keine fachliche Logik im UI. Der Core trägt Verantwortung, die UI macht’s erlebbar.

Ein Pilot, der Wirkung zeigt (und skaliert)

Wenn ihr starten wollt, nehmt einen Use Case, der Kundenerlebnis + KPIs bewegt:

• Assisted Selling im Modeformat (Regal → Zahlung → Lieferung) oder
• Self-Checkout in Peaks (klare Assist-Rollen, Promo-Gleichheit)

Schritte: Journey definieren, Regeln & Steuern in den Core, UI-Template wählen, Metriken setzen, 2–3 Filialen, Ring-Rollout (5 % → 30 % → 100 %). Und: Mischbetrieb ist okay. KORONA POS (klassisch) oder Express laufen parallel, das heißt, ihr migriert immer im eigenen Tempo.

Wo KORONA POS Next konkret hilft und das ohne Architekturfriedhof

Habe ich schon oft erwähnt, daher hier mal kurz:
KORONA POS Next ist der verlässliche Motor im Hintergrund, bedeutet Transaktion, Regeln, Belege, Zahlarten, Compliance. Vorn drauf setzt ihr die Linse, die zur Journey passt: Web, Tablet, Kiosk, App, klassische Kasse, Automat.
In Echtzeit sprechen UI und Core über WebSockets, offline sorgt SQLite für Resilienz. Backoffice via KORONA Studio, angebunden an KORONA Cloud und die bestehenden Drittsysteme (ERP, FiBu, WaWi, CRM). Lizenziert wird pro aktivem UI (fair, planbar, peak-fähig).

Fazit

„Headless“ ist kein Feature. Es ist die Freiheit, Experiences zu entwerfen und zwar dort, wo der Wert entsteht: beim Kunden, im Moment, am richtigen Touchpoint. Wenn ihr den POS als Fähigkeit begreift, nicht als Möbelstück, werden Journeys einfacher, Teams schneller und Messbarkeit endlich ehrlich.

Meine Kollegen Christian und Martin zeigen euch gern, wie so eine Journey bei euch aussieht, vom Regal-Tablet über den Kiosk bis zum Web-Checkout. Mit echten Flows, echten KPIs, echtem Impact.

Ich danke euch für eure Aufmerksamkeit, Thomas