Ein Verkaufstag setzt jedes Glied der Kette unter Stress.
Die landesweiten Verkaufsveranstaltungen von Ralph Lauren verhalten sich weniger wie ein normaler Einzelhandelstag als vielmehr wie ein Ticketverkaufsstart. Die Kunden warten auf die Öffnung des Reservierungsfensters, dann stürmen Tausende in derselben Minute das Formular. Standard-Eventwerkzeuge drosseln die Rate, brechen ab oder berechnen Gebühren pro Ticket, die bei diesem Volumen nicht tragbar sind: keines davon wurde für einen markengeführten Verkaufsstart konzipiert, der parallel über mehrere Standorte läuft.
Am Tag selbst kehrt sich die Herausforderung um. Die Türen öffnen sich. Die Schlange wächst. Jede Sekunde, die ein Mitarbeiter mit einer Papierliste oder einem langsamen Check-in-Bildschirm verbringt, wird zu einer realen Warteschlange. Wir brauchten sofortige Einlasskontrollen, eine parallele Abwicklung von Laufkundschaft, damit die Schlange der Vorgebuchten nie ins Stocken gerät, und eine einzige verlässliche Datenquelle, die die Zentrale in Echtzeit über alle Standorte hinweg beobachten konnte.
“Die Türen öffnen sich. Die Schlange bewegt sich.”
Der Anspruch, dem wir uns selbst verpflichtet haben.
Konzipieren Sie für die schlimmste Minute des Tages. Die übrigen 23 Stunden ergeben sich von selbst.
Wir sind vom Lastprofil ausgegangen, nicht von der Funktionsliste. Wir haben die Ankunftskurve des Reservierungsfensters abgebildet, die Durchsatzkurve an den Türen eine Stunde später modelliert und dann rückwärts auf die Architektur geschlossen, die beide Oberflächen benötigten.
- Lese- und Schreibvorgänge trennen. Zwischengespeicherte Lesepfade fangen den Aktualisierungssturm des “Ist das Fenster offen?” ab; Reservierungen werden in die Schreibschicht eingereiht, sodass die Datenbank nie zum Engpass wird.
- Drei Oberflächen, ein Schema. Kunden-Web, Personal-Scan-App und Veranstaltungs-Kiosk lesen und schreiben alle denselben Reservierungsdatensatz. Keine Abgleichläufe, keine Exporte am Tagesende.
- QR per E-Mail, nicht per App. Keine Installation auf Kundenseite. Die Reservierungsbestätigungs-E-Mail trägt den QR-Code. Funktioniert auf jedem Telefon, in jedem Browser, bei jedem Kunden, auch bei denen, die ihre E-Mail erst am Veranstaltungsort abrufen.
- Der Kiosk als Überdruckventil. Laufkundschaft und Fälle mit verlorener E-Mail werden an einen Tablet-Kiosk am Eingang geleitet. Die Haupttür bleibt rein zum Scannen. Die Schlange der Vorgebuchten muss nie einen Registrierungsschritt aufnehmen.
Fünf Komponenten, ein System für den Event-Tag.
Jede Oberfläche übernimmt ihre eigene Aufgabe und kommt den anderen nicht in die Quere. Der Kunde sieht nie das Admin. Das Admin muss nie scannen. Der Kiosk blockiert nie den Scanner. Entkoppelt von Grund auf.
Mobile-first, Antwort in unter einer Sekunde auch bei Lastspitzen. Auswahl von Standort und Zeitfenster, Kontaktdaten, sofortige Bestätigung.
Serverseitig generiert, in die Bestätigungs-E-Mail eingebettet, innerhalb von Sekunden zugestellt. Keine App-Installation. Funktioniert auf jedem Telefon.
Öffnen, scannen, gültig / verwendet in unter einer Sekunde sehen. Offline-tolerant: synchronisiert sich erneut, sobald die Verbindung zurückkehrt.
Tablet am Eingang. Laufkundschaft registriert sich, das Ticket wird erzeugt und gescannt, alles parallel zur Schlange an der Haupttür.
Reservierungen, Check-ins, Nichterscheinen und Kiosk-Laufkundschaft in Echtzeit. Standortleiter sehen ihren eigenen Standort; die Zentrale sieht das gesamte Netzwerk.
In Produktion an mehreren landesweiten Verkaufsstandorten.
An Veranstaltungstagen öffnet das Reservierungsfenster ohne Drosselung. Die Tickets treffen innerhalb von Sekunden in den Postfächern ein. Das Personal bringt die Kunden in Scangeschwindigkeit durch die Tür. Laufkundschaft fließt parallel durch den Kiosk. Die Schlange der Vorgebuchten steht nie hinter einem Registrierungsschritt: genau dieses kleine betriebliche Detail entscheidet, ob der Raum effizient oder chaotisch wirkt.
Dasselbe Architekturmuster lässt sich natürlich auf andere Einzelhandelsverkäufe, Ausstellungen und Ladenveranstaltungen mit hohem Volumen übertragen. Die Komponenten sind unabhängig wiederverwendbar: Eine Marke kann nur den QR-Ticket-Ablauf übernehmen, nur den Personal-Scanner oder den gesamten Stack für ein einzelnes Veranstaltungswochenende aufsetzen.
- Backend
- PHP, MySQL, Redis cache, queued writes
- Kunden-Web
- Responsive Web: keine App-Installation erforderlich
- Personal-App
- iOS (Swift), Android, offline-tolerant
- Kiosk
- Für Tablets optimierte Web-App für den Veranstaltungseingang
- Infrastruktur
- Über CDN ausgelieferte Ressourcen, warteschlangengestützte Schreibvorgänge, auf Lastspitzen getestet
- Umsetzung
- Mehrsprachiges Team erfahrener Entwickler · von JTS betreut
Steht eine Veranstaltung mit hohem Andrang bevor?
Ein 30-minütiges Gespräch deckt Eignung, Umfang und das mögliche Aussehen der Architektur für Ihre Standortanzahl und Ihr Trafficprofil ab.
