Ein praktischer Erfahrungsbericht aus einem aktuellen DevLK-Projekt — wie wir ein Fotostudio von E-Mail-Chaos und Tabellen zu einer Buchungsplattform gebracht haben, die das Team tatsächlich mag. Stack-Entscheidungen, Fehler und Ergebnisse.

Als ein Fotostudio aus Colombo uns zum ersten Mal kontaktierte, lief die gesamte Buchungsabwicklung über einen gemeinsamen Gmail-Posteingang und eine Google-Tabelle. Drei Mitarbeiter beantworteten dieselben Nachrichten. Doppelbuchungen passierten etwa zweimal im Monat. Preisfehler waren häufiger als das.

Dieser Artikel ist ein praktischer Erfahrungsbericht über den Neuaufbau. Kein Marketing-Geplapper: Was haben wir geändert, was ist schiefgelaufen, was würden wir anders machen, und welche Zahlen können wir wirklich messen.

Das eigentliche Problem war nicht die Software

Bevor wir eine Zeile Code geschrieben haben, saßen wir zwei Nachmittage lang direkt neben dem Empfangspersonal. Dort fanden wir das wahre Problem: Der Studio-Inhaber hatte eine andere Preisliste im Kopf als die, aus der sein Team Angebote machte. Das „System", auf das alle schimpften, war nur ein Symptom.

Das Erste, was wir ausgeliefert haben, war daher keine Software — es war eine einzige, verbindliche Preisliste als geteiltes Dokument mit Versionsverlauf. Allein das hat Streit über Rückerstattungen reduziert, bevor wir Code angefasst haben.

Die Lektion, die wir immer wieder lernen: Wenn der bestehende Prozess kaputt ist, bricht Automatisierung ihn nur schneller. Erst den Prozess reparieren, dann das Werkzeug bauen, das ihn durchsetzt.

Der Stack, den wir gewählt haben, und warum

Wir nutzen Laravel + PostgreSQL standardmäßig für diese Art von internen Geschäftsanwendungen — und das war auch hier unsere Wahl. Die Gründe, ehrlich:

• Das Team kennt Laravel sehr gut. Wir können vorhersagen, wie lange eine Funktion darin dauert.
• PostgreSQL bringt echte Transaktionen, echte JSON-Spalten und echte Constraints mit. Doppelbuchungen sollten auf Datenbankebene unmöglich sein, nicht nur auf Anwendungsebene überprüft.
• Hosting ist in Colombo und auf regionalen Clouds langweilig und günstig — ein VPS für 20 USD/Monat reicht für ein Studio mit ein paar hundert Buchungen pro Monat.

Wir haben kurz ein No-Code-Tool erwogen. Es wäre schneller für eine Demo gewesen, aber wir hätten die Geschäftsregeln, die dem Inhaber wichtig waren, nicht erzwingen können (Sperrzeiten, paketspezifische Anzahlungen, Verfügbarkeit pro Fotograf). Wenn ein Tool Ihre Regeln nicht ausdrücken kann, landen sie wieder im Kopf von Mitarbeitern — genau dort, wo sie angefangen haben.

Der eine Datenbank-Constraint, auf den es ankam

Die einzelne wertvollste Codezeile in diesem Projekt war ein Exclusion-Constraint auf der Buchungstabelle. In Klartext: Die Datenbank selbst lehnt es ab, zwei sich überlappende Buchungen für denselben Fotografen am selben Tag zu speichern.

Vor diesem Constraint hatten wir Prüfungen auf Anwendungsebene. Solche Prüfungen haben eine Race Condition — zwei Tabs offen, zwei Bestätigungen geklickt, eine gelingt, eine scheitert, und man merkt es erst um 18 Uhr, wenn beide Kunden auftauchen. Nach dem Constraint endet dieselbe Race mit einer freundlichen Fehlermeldung für den zweiten Klicker. Der ist vier Sekunden lang genervt; das Studio hat keinen Notfall am Abend.

Wenn Sie eine Sache aus diesem Text mitnehmen: Setzen Sie harte Regeln in der Datenbank durch, nicht im Framework.

Was wir beim ersten Anlauf falsch gemacht haben

Wir haben eine erste Version ausgeliefert, in der Kunden bis 24 Stunden vor dem Shooting selbst stornieren konnten. Wir dachten, das würde Verwaltungsaufwand sparen. Es hat praktisch nichts gespart — und ein neues Problem erzeugt: Stornierungen häuften sich freitags abends, wenn Anzahlungen an zweite Fotografen längst ausgezahlt waren.

Wir haben die Funktion zurückgenommen und durch einen „Stornierungsanfrage"-Flow ersetzt, der beim Personal landet. Das ist nicht die elegantere Lösung. Es ist die, die zu dem passt, wie das Geschäft tatsächlich läuft.

Lektion: Self-Service-Funktionen sind nur dann ein Gewinn, wenn die operativen Kosten, die sie abnehmen, real sind. Manchmal erledigt die bestehende Reibung unsichtbare, aber wichtige Arbeit.

Wie die Zahlen aussehen

Drei Monate nach Go-Live, bei gleichem Volumen an Anfragen:

• Doppelbuchungen: null (vorher ca. 2/Monat).
• Zeit bis zur Buchungsbestätigung: ca. 40 Minuten (vorher ein halber Tag).
• Admin-Stunden für Buchungs-E-Mails: von ca. 8 auf ca. 3 pro Woche.
• Strittige Rückerstattungen: eine, in einem Tag gelöst (vorher mehrere pro Monat, jede zog sich über eine Woche).

Wir haben bewusst keinen Umsatzanstieg gemessen, weil das Studio ohnehin ausgelastet war. Der Gewinn waren operative Klarheit und ein Team, das sich nicht mehr vor dem Montagmorgen fürchtet.

Wenn Sie so etwas für Ihr Unternehmen überlegen

Ein paar Dinge, die wir SMEs in so einem Gespräch mitgeben:

• Liefern Sie die langweiligen Teile zuerst. Die Kalenderansicht und das Rechnungs-PDF sehen nicht beeindruckend aus, aber sie sind das, was das Team jeden Tag benutzt.
• Seien Sie skeptisch bei Feature-Listen von Wettbewerbern. Die meisten dieser Features existieren, weil ein lauter Kunde sie angefragt hat. Sie sind nicht umsonst — jemand wartet sie.
• Planen Sie damit, dass Ihr Team die erste Version zwei Wochen lang hassen wird. Das ist kein Scheitern. Das ist der Preis dafür, eine Gewohnheit zu ändern.

Wenn Ihre Situation ähnlich ist — manuelle Abläufe, die durch Tabellen zusammengehalten werden, ein engagierter Inhaber und ein Team, das von Klarheit profitieren würde — scopen wir so etwas üblicherweise in Zwei-Wochen-Schritten. Gerne ein Gespräch.

Original Source: https://devlk.com/blog-details.php?slug=neuaufbau-einer-studio-buchungsplattform-lessons-learned