Buchungsregeln aus dem Kopf holen: warum wir bei den abgelehnten Anfragen anfangen

Buchungsregeln stehen in den wenigsten Betrieben auf Papier, und trotzdem wendet das Team sie bei jeder Anfrage an: ob ein Termin passt, wie viel Puffer davor bleibt, ab wie vielen Personen eine Tour stattfindet. Bevor eine eigene Buchungs- oder Bestellstrecke entsteht, holen wir diese Entscheidungen aus den Köpfen, sonst bestätigt die Plattform, was am Telefon abgelehnt worden wäre.

Was am Telefon entschieden wird, muss das Formular können

Solange Anfragen per Telefon, E-Mail oder über ein Portal hereinkommen, sitzt zwischen Kunde und Kalender ein Mensch. Er weiß, dass die Werkstatt am Freitagnachmittag keine langen Aufträge mehr annimmt, dass ein Zimmer nach der Abreise erst gereinigt werden muss und dass eine Familie mit kleinen Kindern nicht auf die Abendtour gehört. Kein Portal kennt diese Buchungsregeln vollständig, also fängt der Mensch sie ab.

Ein eigener Kanal, über den Kunden selbst buchen oder bestellen, nimmt diesen Filter heraus. Was vorher eine Rückfrage war, ist jetzt eine bestätigte Buchung, die jemand wieder absagen muss, und die Absage kostet mehr Vertrauen als ein Nein am Telefon. Öffnungszeiten und Preise zu übernehmen, reicht deshalb nicht; die Plattform braucht die Entscheidungen, die heute im Gespräch fallen.

Buchungsregeln in den abgelehnten Anfragen finden

Fragt man ein Team nach seinen Buchungsregeln, nennt es die offensichtlichen: Öffnungszeiten, Kapazität, Preise. Die aufschlussreichen zeigen sich dort, wo jemand Nein gesagt oder einen anderen Termin vorgeschlagen hat. Wir bitten den Betrieb deshalb, eine Zeit lang jede abgelehnte oder umgelenkte Anfrage in einem Satz zu notieren: was angefragt war und warum es so nicht ging.

Aus diesen Notizen entsteht die erste Liste. Typisch darauf sind Puffer zwischen Terminen, die nirgends vermerkt sind, Mindest- und Höchstgrößen, die je nach Wochentag schwanken, Leistungen, die nur zusammen mit einer anderen verkauft werden, und Ausnahmen für Stammkunden, die niemand als Regel bezeichnen würde, weil man sie „einfach so“ macht. Gerade diese Ausnahmen entscheiden später, ob Stammkunden den neuen Kanal annehmen.

Den Kalender rückwärts lesen

Die zweite Quelle ist die Vergangenheit. Wir gehen mit dem Betrieb einen zurückliegenden Zeitraum in Kalender, Warenwirtschaft oder Portal-Exporten durch und fragen bei jeder Auffälligkeit nach: Warum liegt hier eine Lücke, warum wurde diese Buchung verschoben, warum steht dieselbe Leistung zu zwei Preisen im System? Nicht jede Antwort ist eine Regel, manche ist schlicht ein Versehen, und das zu unterscheiden, ist Sache des Betriebs.

Hier liegt die Grenze der Methode. Was im betrachteten Zeitraum nicht vorkam, zeigt auch der gründlichste Blick zurück nicht: den Feiertag, der dieses Jahr anders fällt, die große Gruppe, die nur selten anfragt. Für solche Fälle bauen wir keine Automatik, sondern einen Weg zurück zum Menschen. Die Anfrage landet als Anfrage beim Team, nicht als bestätigte Buchung.

Genauso gehen wir mit Bestellungen um. Ein Fachhändler, der Ware reserviert, liefert oder montiert, hat seine eigenen ungeschriebenen Regeln: welche Artikel nur nach Rücksprache verkauft werden, welche Postleitzahlen ein bestimmtes Lieferfahrzeug nicht erreicht, wann eine Bestellung erst nach Zahlungseingang in die Warenwirtschaft geht. Auch sie stehen selten im System, sondern in der Erfahrung derer, die Bestellungen annehmen.

Wenn Buchungsregeln sich widersprechen

Stehen die Regeln erst auf einer Liste, zeigen sich Widersprüche, die im Alltag niemandem auffallen, weil verschiedene Leute im Betrieb sie verschieden auslegen. Größere Gruppen werden an einem Tag nur vormittags angenommen, am nächsten auch nachmittags, je nachdem, wer den Anruf entgegennimmt. Am Telefon ist das Flexibilität, in der Software ein Fehler, denn sie braucht genau eine Antwort.

Diese Stellen entscheiden nicht wir. Wir legen sie dem Betrieb als Frage vor, mit den Fällen aus Notizen und Kalender, und seine Antwort geht als Regel in die Plattform. Manche Betriebe wollen bewusst Ermessen behalten; dann wird genau dieser Fall nicht automatisch bestätigt, sondern zur Freigabe vorgelegt. Ebenso wichtig ist, wo eine Regel später geändert wird: Stornofristen und Gruppengrößen wechseln mit der Saison und gehören in eine Verwaltungsoberfläche des Betriebs, nicht in den Quellcode.

Wie wir das vor der Entwicklung festhalten

Die Regelliste gehört bei uns in die erste Lieferung einer Buchungs- oder Bestellstrecke: jede Regel als Satz in der Sprache des Betriebs, dazu die Fälle, aus denen sie stammt, und die Stelle, an der der Betrieb sie später selbst anpasst. Der Betrieb geht die Liste durch und bestätigt sie; erst darauf bauen Datenmodell und die Abnahmekriterien der folgenden Lieferungen auf.

Wie aus der Liste das System hinter dem Kanal wird, mit Verfügbarkeit, Preisen und Verbindung zu Portalen und Kalender, zeigt die Seite Softwareentwicklung. Die Oberfläche, über die Kunden buchen und bestellen, entsteht unter App-Entwicklung.