Die meisten Gründer gehen die Entwicklung einer Salon-Buchungssoftware mit einer Funktionsliste an. Sie sieht aus wie ein Briefing. Ist sie aber nicht.
Eine Funktionsliste sagt nichts darüber aus, wie die Teile zusammenhängen. Buchung, Dienstpläne und Zahlungen sind keine drei getrennten Bildschirme. Sie sind ein einziges System, das in Echtzeit mit sich selbst übereinstimmen muss, jede Sekunde des Tages.
Wenn ein Kunde einen Termin um 2:30 PM bei Priya antippt, müssen vier Dinge gleichzeitig passieren. Der Termin wird gesperrt, Priyas Kalender aktualisiert sich, die Zahlungsreservierung geht durch und das Dashboard des Salonbesitzers zeigt es an. Hinkt eines davon hinterher, haben Sie eine Doppelbuchung und einen verärgerten Kunden am Empfang.
Die meisten Teams stellen fest, dass der Unterschied zwischen einer Funktion, die in einer Demo läuft, und einer, die an einem Samstagnachmittag mit 40 laufenden Terminen funktioniert, gar nicht in der Funktion selbst liegt. Er liegt in der Architektur darunter. Dieser Artikel zeigt, was jede Ebene tatsächlich braucht, damit Sie im Gespräch mit einem Entwickler die richtigen Fragen stellen oder bei einem Angebot erkennen, ob es gründlich oder dünn ist.
Die Kundenseite
Das ist der Teil, den sich jeder vorstellt, wenn er an die App denkt. Er ist auch täuschend leicht zu spezifizieren und überraschend leicht falsch umzusetzen.
Registrierung, Login und Profile
Die Kontoerstellung klingt nach einem gelösten Problem. Das ist sie größtenteils auch. Telefonnummer plus OTP oder Social Login kostet ein kompetentes Team ein, zwei Tage. Entscheidend ist, was beim zweiten Besuch passiert.
Ein wiederkehrender Kunde sollte seine Stylistin, seine übliche Leistung und das Datum seines letzten Termins sehen, ohne etwas einzutippen. Dafür braucht es einen Kundendatensatz, der mit der Buchungshistorie, den Zahlungsmethoden und allen Notizen des Teams verknüpft ist („allergisch gegen Ammoniak“, „bevorzugt den Termin um 9 AM“).
Leistungen und Preise
Jede Leistung braucht einen Namen, eine Dauer, einen Preis und eine Regel, welche Mitarbeiter sie anbieten, denn nicht jede Stylistin macht Balayage. Diese vier Felder steuern alles Weitere. Die Dauer bestimmt die Länge des Zeitfensters. Der Preis bestimmt den Zahlungsbetrag. Die Zuordnungsregel filtert, welche Mitarbeiter als verfügbar angezeigt werden. Die Architekturregel ist hier einfach: Diese Daten liegen an genau einer Stelle und aktualisieren sich überall sofort.
Mitarbeiterauswahl und Verfügbarkeit in Echtzeit
Das ist die Funktion, die am ehesten kaputtgeht, und sie geht leise kaputt.
Um wirklich freie Termine anzuzeigen, muss das Backend das Schichtmuster eines Mitarbeiters mit seinen bestehenden Buchungen verbinden. Es berücksichtigt außerdem Abwesenheiten, die Dauer der Leistung und etwaige Pufferzeiten zwischen Terminen und berechnet das live, für jede Stylistin, jedes Mal, wenn ein Kunde den Bildschirm öffnet.
Ein Termin, der als frei angezeigt wird, es aber nicht ist, ist der schnellste Weg, einen Kunden für immer zu verlieren. Er bucht ihn, bekommt eine Stunde später einen Anruf vom Salon und öffnet Ihre App nie wieder.
Die Terminlogik: Wo die Architektur der meisten Salon-Termin-Apps scheitert
Buchen, Umbuchen und Stornieren stehen in den meisten Funktionslisten als drei Positionen. Sie sind ein einziges System, und sie als drei zu behandeln ist der häufigste Grund, warum ein Salon-Buchungsprojekt auf halber Strecke das Budget sprengt.
Der Grund ist folgender. Eine Buchung ist einfach: freien Termin finden, sperren, bestätigen. Eine Umbuchung ist eine Stornierung und eine Buchung, ausgeführt als eine einzige atomare Aktion. Lässt sich der neue Termin nicht sperren, muss der alte zurückkommen, sonst hat Ihr Kunde gar keinen Termin mehr. Eine Stornierung muss den Termin freigeben, anhand der Frist in Ihren Bedingungen über eine Erstattung entscheiden und den Tag des Mitarbeiters aktualisieren. Sie passt außerdem die Umsatzprognose an und benachrichtigt gegebenenfalls einen Kunden auf der Warteliste.
Dann kommen die Sonderfälle, die niemand spezifiziert und auf die jeder stößt. Zwei Kunden tippen in derselben Sekunde auf denselben Termin. Eine Stylistin meldet sich krank, und zwölf Termine müssen in einer Kettenreaktion neu zugewiesen oder storniert werden. Ein Kunde bucht auf einen Termin um, der nur frei wird, weil jemand anderes gerade mitten in einer Stornierung steckt.
Das ist keine glamouröse Arbeit, und in einer Demo macht sie wenig her. Sie ist aber der Unterschied zwischen einer App, die auch bei großer Last hält, und einer, die jedes Wochenende eine Beschwerde produziert.
Wenn Sie ein Angebot prüfen, ist das der Abschnitt, bei dem Sie nachhaken sollten. Lassen Sie sich vom Entwickler erklären, was passiert, wenn eine Stylistin ihre Schicht mit neun Buchungen absagt. Die Qualität dieser Antwort sagt Ihnen mehr als der Rest des Angebots.
Das gleiche Problem gibt es bei Reservierungssystemen für Restaurants: Die Stornierung eines Tisches kann sich durch einen ganzen Service ziehen. Wir haben dieses System gebaut, und die Architektur ist identisch mit dem, was Sie für die Terminplanung im Salon brauchen.
Zahlungen, Bestätigungen und Benachrichtigungen
Zahlungen in einer Salon-App sind selten eine einzelne Abbuchung. Meist geht es um eine Mischung aus vollständiger Online-Zahlung oder einer Anzahlung, die den Termin sichert, dazu Trinkgelder sowie Guthaben aus Paketen oder Mitgliedschaften.
Jede dieser Varianten ist ein eigener Ablauf über das Payment-Gateway. Die Anzahlung ist der Punkt, den Gründer unterschätzen. Sie senkt nachweislich die Zahl der Nichterscheinenden, das ist in Dienstleistungsbetrieben gut belegt, bringt aber eine Erstattungsregel mit sich, die feststehen muss, bevor eine Zeile Code geschrieben wird. Bis wie lange vor dem Termin ist die Anzahlung erstattungsfähig? Wird sie auf die Karte zurückgebucht oder als Salonguthaben behalten? Was passiert, wenn der Salon absagt, und wer darf die Regel übergehen?
Entscheiden Sie das in der Spezifikationsphase. Erstattungslogik nachträglich in ein laufendes Zahlungssystem einzubauen ist teuer und einer der häufigsten Gründe, warum der Umfang bei solchen Projekten ausufert.
Benachrichtigungen gehören in dieselbe Kategorie des Unterschätzten. Bestätigungen, Erinnerungen 24 und 2 Stunden vorher, Stornierungshinweise und danach eine Bitte um Bewertung gehören alle hierher. Kunden bemerken sie nicht, wenn sie funktionieren, und sofort, wenn nicht. Technisch heißt das Push-Benachrichtigungen über einen Dienst wie Firebase, SMS als Ausweichkanal für Kunden, die Push deaktiviert haben, und E-Mail für Belege. Drei Kanäle, drei Zustellstatus, die verfolgt werden müssen, und eine Regel dafür, was passiert, wenn ein Push stillschweigend scheitert.
Die Betriebsseite: Verwaltung und Mitarbeitermanagement
Eine Kunden-App allein ist ein halbes Produkt. Was daraus eine zweiseitige Salon-Marktplatz-App macht, ist die Hälfte für den Betrieb, und die enthält mindestens so viel Logik wie die Kundenseite.
Mitarbeiter- und Dienstplanverwaltung
Dienstplansoftware für Salons muss mit Schichtmustern umgehen, die selten sauber sind. Teilzeit-Stylistinnen, die dienstags und samstags arbeiten. Eine Therapeutin, die 90 Minuten Mittagspause macht. Wechselnde Wochenenddienste, genehmigter Urlaub und eine Provisionsstruktur, die je nach Leistung variiert.
Jede dieser Regeln fließt direkt in die Verfügbarkeit ein, die ein Kunde sieht. Sie können den Verfügbarkeitsbildschirm für Kunden und den Dienstplan für Mitarbeiter nicht als getrennte Projekte mit einer Synchronisierung dazwischen bauen. Es sind zwei Ansichten desselben Kalenders. Genehmigt eine Führungskraft einen Urlaubsantrag, müssen die Termine aus der Kunden-App verschwinden, bevor die nächste Person sie öffnet.
Admin-Dashboard
Das Dashboard des Inhabers ist die Steuerzentrale.
Hier laufen die heutigen Buchungen aller Stylistinnen, die Erfassung von Laufkundschaft und das manuelle Anlegen von Buchungen für telefonische Kunden zusammen. Dazu kommen die Verwaltung von Leistungen und Preisen, Mitarbeiterrechte und die Möglichkeit, alles manuell zu übersteuern. Dieser letzte Punkt ist wichtiger, als er klingt. Echte Salons leben von Ausnahmen: einen Stammkunden noch dazwischenschieben, einen Termin verlängern, nach einer Beschwerde eine Leistung erlassen. Kann der Admin das System nicht übersteuern, hört das Team auf, das System zu nutzen. Die Architekturanforderung lautet, dass solche Eingriffe in dieselbe Datenebene geschrieben werden wie normale Buchungen und protokolliert werden, damit Ihre Berichte ehrlich bleiben.
Ein Dashboard, das aus einem verzögerten Replikat oder einem nächtlichen Batch liest, ist ein Terminkonflikt, der nur darauf wartet zu passieren. Live-Daten, sonst ist es kein Dashboard.
Termin- und Umsatzberichte
Umsatz pro Stylistin, pro Leistung, pro Tag. Auslastungsquoten. Anteil der Nichterscheinenden, Quote der Stammkunden und durchschnittlicher Bonwert. Das sind die Zahlen, die einem Inhaber sagen, ob er einstellen sollte, welche Leistungen er pushen sollte und wer eine Gehaltserhöhung verdient.
Und sie hängen vollständig von den vorgelagerten Ebenen ab. Ein Bericht ist nur so genau wie die Termin- und Zahlungsebenen, die ihn speisen. Wenn Stornierungen ihre Umsatzbuchungen nicht sauber zurücknehmen oder Anzahlungen getrennt von den Schlusszahlungen erfasst werden, sind Ihre Berichte auf eine Weise falsch, die sechs Monate lang niemand bemerkt. Das ist das deutlichste Argument dafür, warum die Architektur wichtiger ist als jede einzelne Funktion auf einer Liste.
Ihr Tech-Stack für die Salon-App, realistisch betrachtet
Node.js oder Laravel im Backend. PostgreSQL oder MySQL als primäre Datenbank, denn Buchungen sind relational und Sie brauchen transaktionale Integrität. Redis übernimmt das Sperren von Terminen und das Caching. Stripe oder Razorpay für Zahlungen, je nach Markt. Firebase für Push, Twilio als SMS-Ausweichkanal.
Nichts davon ist exotisch, und genau darum geht es. Ungewöhnliche Entscheidungen kosten Sie später, wenn Sie Leute einstellen oder das Projekt übergeben müssen. Entscheidend ist, dass der Stack echte Transaktionen und Echtzeit-Updates unterstützt, die beiden Dinge, mit denen Salon-Buchungen stehen und fallen. Auch die Größenordnung spielt eine Rolle, also legen Sie am ersten Tag fest, für welche der drei Sie bauen. Mehrere Standorte erst nachträglich einzuplanen bedeutet, Ihr Datenmodell neu zu schreiben.
Individuelle Salon-Buchungs-App oder Template: die Entscheidung
Ein Template-Skript bündelt diese Funktionen als feste, generische Module. Um zu testen, ob die Menschen in Ihrer Gegend überhaupt online buchen, ist das ein vernünftiger Weg, es günstig herauszufinden. Das wollen wir gar nicht bestreiten.
Einschränkend wird es in dem Moment, in dem Ihr Betrieb etwas Bestimmtes braucht. Provisionen, die je nach Erfahrung der Stylistin variieren. Ein Mitgliedschaftsmodell mit monatlichem Guthaben. Mitarbeiter, die zwischen mehreren Filialen wechseln, oder eine Anzahlungsregel, die je nach Leistung unterschiedlich ist. In einem Template ist jede dieser Anforderungen entweder unmöglich oder eine teure Änderung an Code, der Ihnen nicht gehört und den Sie nicht vollständig prüfen können.
Der ehrliche Einwand gegen eine Individualentwicklung sind Kosten und Unsicherheit. Die Entwicklungskosten einer Salon-App können bei einem offenen Stundenvertrag tatsächlich aus dem Ruder laufen. Deshalb arbeiten wir nicht so. Wir vereinbaren einen Festpreis und einen festen Launch-Termin, bevor die Arbeit beginnt, mit einer ersten Version ab $8,000, je nach Umfang. In über 18 Jahren und mit mehr als 1000 Unternehmen haben wir gelernt, dass die Disziplin, den Umfang vorab sauber festzulegen, beide Zahlen ehrlich hält.
Festpreis und fester Launch-Termin für Ihre Salon-App
Sagen Sie uns, was Ihr Salon, Ihr Spa oder Ihre Klinik wirklich braucht. Wie viele Standorte Sie haben, wie Ihr Team bezahlt wird und wie Ihre Stornobedingungen aussehen, fließt in den Umfang ein, gemessen an der oben beschriebenen Architektur.
Angebot anfordern. Festpreis, vereinbart vor dem Start.
Häufige Fragen
Brauche ich für den ersten Launch alle 13 Funktionen?
Nein. Grundlegende Buchung, Live-Verfügbarkeit und Zahlungen reichen meist aus, um zu prüfen, ob Kunden die App nutzen. Tiefergehendes Mitarbeitermanagement, Treueprogramme und Berichte können folgen, sobald echte Nutzungsdaten zeigen, was die Leute tatsächlich brauchen.
Kann ein nicht-technischer Gründer diese Anforderungen sicher vermitteln?
Ja. Sie müssen nicht wissen, wie Sperren auf Zeilenebene funktionieren. Sie müssen wissen, dass Terminkonflikte ein echtes Problem sind, und fragen, wie sie gelöst werden. Zu verstehen, wie die Ebenen zusammenhängen, reicht für ein produktives Gespräch mit jedem kompetenten Entwickler.
Wie lange dauert so ein Projekt?
Das hängt vom Umfang ab. Zum Vergleich: Wir haben vergleichbare zweiseitige Apps, darunter eine App für Medikamentenlieferungen mit Buchungsfunktion, in etwa 30 Tagen gelauncht. Mehr Standorte, mehr Zahlungsregeln und mehr Integrationen verlängern das, und deshalb halten wir den Termin vor Beginn schriftlich fest.
Bleiben die Kosten im Rahmen des ursprünglichen Angebots?
Innerhalb des vereinbarten Umfangs ja, genau das bedeutet Festpreis. Die Kosten ändern sich, wenn Sie den Umfang während der Entwicklung ändern. Das kommt vor und ist in Ordnung, aber es ist eine bewusste Entscheidung von Ihnen und keine Überraschung auf einer Rechnung.
Arun Andiselvam
LinkedInIch bin Gründer und habe fünf Marken aufgebaut. Die erste, ein SEO-Werkzeug, habe ich für einen sechsstelligen Betrag verkauft, und heute leite ich Appkodes und entwickle individuelle Mobile- und Web-Apps für Gründer und Unternehmen. Jede davon habe ich vom ersten Tag an selbst finanziert.
