SNAP ist eine Self-Photo-Studio-Kette in sechs indonesischen Städten. Die alte Website war eine statische Broschüre — Buchungen liefen über WhatsApp-DMs, jede Filiale führte ein eigenes Notizbuch, und etwa jede zwölfte Sitzung endete in einem Konflikt an der Tür. Wir haben den Kundenprozess als PWA neu gebaut und ein zentrales Admin-Dashboard ausgeliefert, das alle sechs Filialen auf einmal zeigt.
Eine Mobile-First-PWA auf Kundenseite, eine Desktop-SPA auf der Admin-Seite, eine API und eine Datenbank darunter. Sechs Module tragen die gesamte Kette — vom Stadtauswahl-Bildschirm, den ein Kunde auf Instagram sieht, bis zur täglichen Abrechnung, die der Filialleiter am Abend bestätigt.
Sechs Städte, zwölf Filialen, zwei physische Studiotypen. Der Kundenprozess überspringt den Filialschritt automatisch in Städten mit nur einem Studio und wählt das passende Kapazitätsmodell basierend auf dem Standort.
Box-Studios laufen über eine Hintergrund×Zeit-Matrix — jeder Raum bucht unabhängig. Roll-up-Studios nutzen einen gemeinsamen Zeitplan mit einer rein ästhetischen Hintergrundauswahl. Dieselbe UI-Hülle, zwei unterschiedliche Kapazitätsregeln darunter.
Kunde scannt einen dynamischen QRIS-Code, der Händler-Callback gibt den Slot frei, der Kunde sieht ein Häkchen. Kein Mitarbeiter, der Mobile-Banking überwacht. Keine manuelle „Ist es schon bezahlt?"-Nachricht.
Ein Dashboard für den Inhaber. Heutige Buchungen über sechs Filialen, Umsatz vs. gestern, Ausgaben nach Kategorie, Belegung nach Raum. Von jeder Kachel direkt in die Rohdaten.
Filialleiter sehen nur ihre Filiale — heutiger Kalender, Walk-in-Slot-Schalter, Ausgabenerfassung, Tagesabschluss-Kassenstand. Rollenbasiert, standardmäßig gesperrt.
Buchung bestätigt → WhatsApp-Vorlage mit Slot, Filialadresse und Kalenderlink geht raus. Erinnerung zwei Stunden vorher. Der DM-Thread ist nicht mehr der Ort, wo Buchungen leben — aber noch immer der Ort, wo Kunden Rückmeldung erwarten.
Jede Filiale hatte eine eigene Admin-Nummer. Kunden schrieben „morgen 15 Uhr Kemang?" und jemand antwortete, wenn er wach war. Zwei Mitarbeiter bestätigten denselben Slot manchmal an zwei verschiedene Kunden, weil der Posteingang die einzige Quelle der Wahrheit war.
An vollen Wochenenden endete ungefähr jede zwölfte Sitzung in einem Konflikt an der Tür — eine Partei wurde abgewiesen, erstattet und wurde auf Instagram laut.
Kunde wählt Stadt, Filiale, Datum, Uhrzeit und Hintergrund — jeder Schritt schreibt eine Reservierung in eine echte Zeile. Zwei Telefone tippen denselben Slot in derselben Sekunde: eines gewinnt, das andere sieht „gerade vergeben" und bekommt den nächsten freien 30-Minuten-Block angeboten.
Die Bestätigung geht danach per WhatsApp raus, damit Kunden dort Rückmeldung bekommen, wo sie es erwarten. Die DM ist jetzt der Beleg — nicht die Buchung.
Die Hälfte der Filialen sind Box-Studios — jeder Hintergrund steht in einem eigenen Raum, also bedeuten zwei Hintergründe zwei parallele Sitzungen. Die andere Hälfte sind Roll-down-Studios — mehrere Hintergründe in einem Raum, aber nur eine Sitzung gleichzeitig möglich.
Die alte Website behandelte sie identisch. Kunden buchten vier Hintergründe zur selben Zeit in einer Roll-down-Filiale und stellten vor Ort fest, dass das nicht möglich war.
Jede Filiale ist in der Datenbank als multi oder single markiert. Box-Studios erhalten ein Hintergrund×Zeit-Raster — eine Zelle wählen heißt Raum und Uhrzeit in einem Schritt wählen. Roll-down-Studios erhalten einen gemeinsamen Zeitplan und eine separate Hintergrundauswahl, die rein ästhetisch ist.
Dieselbe React-Hülle, dieselben Komponenten, anderes Datenschema von einem Endpunkt. Der Kunde muss den Unterschied nie kennen.
○ frei × belegt ● gewählt
Kunde überweist, macht einen Screenshot des Belegs, schickt ihn per WhatsApp. Filial-Admin öffnet die Mobile-Banking-App, sucht den passenden Betrag, antwortet „ok bestätigt" und trägt den Slot ins Notizbuch ein. Fünf Minuten pro Buchung an einem ruhigen Tag, viel länger am Samstag.
War der Admin in der Pause, wartete der Kunde. Wartete der Kunde zu lange, stornierte er.
Bestätigt automatisch.
Kein Screenshot nötig.
Für einen Filial-Admin am Samstag zwischen Öffnung und Mittag — die geschäftigste Zeitspanne. Dieselbe Person, derselbe Job, vor und nach dem Umbau.
Mit zwei Filial-Admins je einen ganzen Samstag verbracht. Zugeschaut, wie das Notizbuch gefüllt, die Chats jongliert und die Mobile-Banking-App aktualisiert wurde. Jeden Schritt aufgeschrieben. Alles gestrichen, was nicht nötig wäre, wenn eine Datenbank vorhanden wäre.
React + Vite PWA, Express + MySQL im Backend. Zwei Buchungsmodelle hinter einem Endpunkt-Schema, damit die UI nicht aufgespalten wird. QRIS-Händlerintegration mit Webhook-Fallback, damit ein instabiles Netz einen Kunden nie mitten in der Zahlung stecken lässt.
Admin SPA: Übersicht, Buchungskalender, Ausgaben, Umsatz, Berichte, Einstellungen. Erst eine Filiale gerollt (Kemang), eine Woche beobachtet, dann den Rest zu zweit ongeboardet. Notizbücher Filiale für Filiale ausgemustert.
Die Zahlen unten stammen aus der Live-Datenbank der Pilotfiliale (Kemang) plus der zwei Filialen, die danach online gingen. Kettenweite Zahlen werden hier erst veröffentlicht, wenn genug Monate echter Daten dahinterstehen.
Sechs Filialen in sechs Städten, ein Gründer, der das Dashboard auf dem Telefon in der Warteschlange im Café lesen können muss. Jede Entscheidung beantwortete eine Frage: Was passiert, wenn das WLAN in einer Filiale mitten im Samstags-Rush ausfällt?
Vom Homescreen installierbar. Seitenübergänge via Framer Motion. CSS Modules und eine strikte Schwarz-Weiß-Palette — die Fotos liefern die Farbe, die Chrome bleibt im Hintergrund.
Eine Datenbank, Filialen als Zeilen, Kapazitätsmodell als Enum. Slot-Schreibzugriffe laufen über einen einzelnen Endpunkt, der die Zeile sperrt, damit zwei gleichzeitige Buchungen nicht dieselbe Zelle gewinnen.
Pro Buchung ein dynamischer QRIS-Code mit 15-Minuten-TTL. Settlement-Webhook gibt den Slot frei; wenn der Webhook fehlschlägt, gleicht ein Poller binnen einer Minute ab. In jedem Fall sieht der Kunde dasselbe Häkchen.
Keine separate Admin-Codebasis. Gründer-Login landet im Desktop-Sidebar-Layout, Filial-Login in der Einzelfilial-Ansicht. RBAC auf API-Ebene, nicht in der UI — Klicken kann nie etwas gewähren, was der Server noch nicht genehmigt hat.
Kostenloses Erstgespräch. Wir nennen Ihnen die günstigste Lösung.
Systeme wie dieses laufen auf der Core Platform + Custom-Modulen — die meisten Buchungssysteme liegen zwischen $2.500 und $4.500. Alle Preise →