QueueSync

01

Vom konkreten Problem zum Produkt

02

Ein gemeinsamer Echtzeit-Workflow

QueueSync trennt den Ablauf in Check-in, Mitarbeitendenansicht und Wartestatus. Neue Einträge, Statusänderungen und Aufrufe stehen den beteiligten Clients unmittelbar zur Verfügung.

1. 01

   Check-in

   Mitarbeitende erfassen Wartende direkt. Bei öffentlich erreichbaren Instanzen ist alternativ ein Self-Check-in per QR-Code möglich.

2. 02

   Mitarbeitendenansicht

   Die aktuelle Warteschlange, offene Vorgänge und Aufrufe werden auf gemeinsam genutzten oder persönlichen Geräten koordiniert.

3. 03

   Wartestatus

   Wartende verfolgen Ticketnummer, Position und Aufruf auf dem eigenen Smartphone.

Alle drei Perspektiven arbeiten mit demselben aktuellen Zustand.

03

Unterschiedliche Einsatzbereiche

Das Daten- und Statusmodell bildet einen allgemeinen Warteprozess ab. Die folgenden Einsatzbereiche sind Beispiele, keine feste Produktgrenze.

1. Walk-ins & Besucherströme

   Gäste und Besucher organisieren, ohne einen klassischen Ticketautomaten vorauszusetzen.

2. Hospitality & Einlass

   Wartende koordinieren und Aufrufe zentral auslösen.

3. Freizeit & Attraktionen

   Kapazitätsbegrenzte Angebote über eine virtuelle Warteschlange organisieren.

4. Events & Servicebereiche

   Temporäre oder dauerhafte Warteprozesse strukturiert abbilden.

QueueSync bildet den Ablauf ab – nicht eine bestimmte Branche.

04

Hosted oder lokale Appliance

QueueSync wurde nicht nur als Webanwendung, sondern als betreibbares Produkt konzipiert. Abhängig vom Einsatz läuft eine gehostete Instanz oder eine lokale QueueSync Appliance direkt am Standort.

1. Hosted

   Eine dedizierte Instanz pro Standort macht Check-in und Wartestatus bei Bedarf öffentlich erreichbar.

   • Standort-isolierte Daten und Konfiguration
   • Reproduzierbarer Betrieb mit Docker Compose
   • Self-Check-in und Statusansicht per Smartphone

2. QueueSync Appliance

   Die Anwendung läuft im lokalen Netzwerk des Standorts und hält Betriebsdaten direkt vor Ort.

   • Lokale Datenhaltung und Standort-Isolation
   • Automatisierte Backups und definierter Restore-Ablauf
   • Reproduzierbare Einrichtung, Geräteschutz und einfacher Austausch

Beide Betriebsarten entstehen aus derselben Produktbasis.

05

Für den Betrieb gebaut

Neben dem Kern-Workflow habe ich Funktionen umgesetzt, die bei gemeinsam genutzten Geräten und im täglichen Betrieb relevant werden.

1. Geräteschutz

   Bediengeräte per PIN autorisieren und einzeln oder gesammelt wieder sperren.

2. Admin & Statistik

   Einstellungen, Öffnungszeiten, Tagesstatistik, Event-Log und verbundene Clients zentral verwalten.

3. Team-Nachrichten

   Kurze Hinweise zwischen operativen Ansichten austauschen.

4. Ankündigungen

   Geplante Gruppen und Hinweise vorab für Mitarbeitende sichtbar machen.

5. Tagesabschluss

   Backups, Tagesstatistik und Log-Rotation automatisiert durchführen.

6. Self-Check-in

   Wartende tragen sich per QR-Code ein und verfolgen ihren eigenen Status.

06

Technische Leitplanken

Die Architektur hält Bedienoberflächen, Anwendungslogik und Betrieb voneinander getrennt, ohne den lokalen Einsatz unnötig komplex zu machen.

• 01Echtzeitsynchronisierung mehrerer Clients über Server-Sent Events statt Polling
• 02Trennung von React-Frontend, FastAPI-API und SQLAlchemy-Datenmodell
• 03Containerisierter und reproduzierbarer Betrieb mit Docker Compose
• 04Hosted- und Appliance-Deployment aus derselben Produktbasis
• 05Eigenständige Instanz und Datenhaltung je Standort
• 06Automatisierte SQLite-Backups, Tagesabschluss und Log-Rotation
• 07Responsive Self-Service-Oberflächen und kurze Wege auf gemeinsam genutzten Geräten
• 08Getrennte Geräte- und Admin-Authentifizierung mit widerrufbaren Gerätetokens