[{"data":1,"prerenderedAt":92},["ShallowReactive",2],{"content:blog:buchungsregeln-aus-dem-kopf":3,"content:blog":33},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":32},"buchungsregeln-aus-dem-kopf","Buchungsregeln aus dem Kopf holen: warum wir bei den abgelehnten Anfragen anfangen","Puffer, Gruppengrößen, Stornofristen, Ausnahmen für Stammkunden: wie ein Betrieb vor der Entwicklung seines eigenen Kanals aufschreibt, was das Team heute am Telefon entscheidet","2026-09-09","Buchungsregeln erfassen, bevor die Plattform entsteht","Buchungsregeln vor der Entwicklung erfassen: wie Betriebe in Deutschland Puffer, Gruppengrößen und Ausnahmen aus dem Telefonalltag in prüfbare Regeln fassen.","Am Telefon erkennt ein erfahrener Mitarbeiter sofort, ob eine Anfrage passt. Ein Buchungsformular kann das nur, wenn diese Entscheidung vorher als Regel formuliert wurde. Wie wir solche Regeln vor der ersten Entwicklungsetappe finden und warum die abgelehnten Anfragen mehr verraten als die angenommenen.",4,[13,14,15],"Arbeitsweise","Anforderungen","Vertriebskanal",[17,20,23,26,29],{"id":18,"text":19},"telefon","Was am Telefon entschieden wird, muss das Formular können",{"id":21,"text":22},"ablehnungen","Buchungsregeln in den abgelehnten Anfragen finden",{"id":24,"text":25},"kalender","Den Kalender rückwärts lesen",{"id":27,"text":28},"widersprueche","Wenn Buchungsregeln sich widersprechen",{"id":30,"text":31},"vorgehen","Wie wir das vor der Entwicklung festhalten","\u003Cp>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.\u003C\u002Fp>\u003Ch2 id=\"telefon\">Was am Telefon entschieden wird, muss das Formular können\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2 id=\"ablehnungen\">Buchungsregeln in den abgelehnten Anfragen finden\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2 id=\"kalender\">Den Kalender rückwärts lesen\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2 id=\"widersprueche\">Wenn Buchungsregeln sich widersprechen\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2 id=\"vorgehen\">Wie wir das vor der Entwicklung festhalten\u003C\u002Fh2>\u003Cp>Die Regelliste gehört bei uns in die erste Lieferung einer \u003Ca href=\"\u002Flexikon\u002Fbuchungsstrecke\">Buchungs- oder Bestellstrecke\u003C\u002Fa>: 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.\u003C\u002Fp>\u003Cp>Wie aus der Liste das System hinter dem Kanal wird, mit Verfügbarkeit, Preisen und Verbindung zu Portalen und Kalender, zeigt die Seite \u003Ca href=\"\u002Fleistungen\u002Fsoftwareentwicklung\">Softwareentwicklung\u003C\u002Fa>. Die Oberfläche, über die Kunden buchen und bestellen, entsteht unter \u003Ca href=\"\u002Fleistungen\u002Fapp-entwicklung\">App-Entwicklung\u003C\u002Fa>.\u003C\u002Fp>",[34,42,67],{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":35,"toc":36},[13,14,15],[37,38,39,40,41],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"id":30,"text":31},{"slug":43,"title":44,"subtitle":45,"date":46,"metaTitle":47,"metaDescription":48,"excerpt":49,"readingMinutes":11,"tags":50,"toc":52},"buchungsplattform-vorher-nachher-messen","Buchungsplattform vorher und nachher: welche Zahlen vor dem Start feststehen müssen","Direkte Buchungen, Wiederkehrer, Pflegeaufwand, Rückfragen: woran ein Betrieb erkennt, ob der eigene Kanal wirkt – und warum der Ausgangswert erhoben wird, bevor die Entwicklung beginnt","2026-08-20","Buchungsplattform: Kennzahlen vor und nach dem Start","Buchungsplattform vorher und nachher: welche Kennzahlen Betriebe in Deutschland vor dem Start festhalten, damit die Wirkung des eigenen Kanals prüfbar wird.","Nach dem Start einer eigenen Plattform fragt jeder, ob es sich gelohnt hat. Beantworten lässt sich das nur mit Zahlen, die vorher erhoben wurden. Welche wir mit dem Betrieb festlegen, woher sie kommen und was ein Ergebnis wie +47 % Direktbuchungen zeigt und was nicht.",[13,51,15],"Kennzahlen",[53,56,59,62,65],{"id":54,"text":55},"ausgangswert","Warum die Messung vor der Buchungsplattform beginnt",{"id":57,"text":58},"kennzahlen","Vier Zahlen, die wir vor dem Start festhalten",{"id":60,"text":61},"quellen","Woher die Zahlen kommen",{"id":63,"text":64},"nachher","Nach dem Start: die Buchungsplattform am Ausgangswert messen",{"id":30,"text":66},"Wie wir das in einem Auftrag festlegen",{"slug":68,"title":69,"subtitle":70,"date":71,"metaTitle":72,"metaDescription":73,"excerpt":74,"readingMinutes":11,"tags":75,"toc":77},"portale-behalten-eigenen-kanal-daneben","Buchungsportale behalten, eigenen Kanal daneben bauen: in welcher Reihenfolge","Warum wir Portale beim Aufbau einer eigenen Buchungs- oder Bestellstrecke nicht abschalten und welche Schritte vor dem ersten Direktkunden liegen – für Betriebe, die heute über Plattformen Dritter verkaufen","2026-07-29","Buchungsportale behalten, eigenen Kanal aufbauen","Buchungsportale behalten und daneben einen eigenen Kanal aufbauen: in welcher Reihenfolge Betriebe in Deutschland Bestand, Anbindung und Direktkunden ordnen.","Wer Provisionen an Portale zahlt, will oft sofort raus. Wir raten davon ab: Der eigene Kanal braucht zuerst einen sauberen Bestand, dann eine Verbindung zu den Portalen und erst danach einen Grund, direkt zu buchen. Die Reihenfolge, in der wir das aufbauen.",[13,76,15],"Schnittstellen",[78,81,84,87,90],{"id":79,"text":80},"ausgangslage","Warum Buchungsportale nicht der Gegner sind",{"id":82,"text":83},"bestand","Schritt eins: ein Bestand, der nicht im Portal wohnt",{"id":85,"text":86},"verbindung","Schritt zwei: Buchungsportale anbinden, bevor der eigene Kanal öffnet",{"id":88,"text":89},"anlass","Schritt drei: ein Grund, direkt zu buchen",{"id":30,"text":91},"Wie wir den eigenen Kanal aufbauen",1789406623369]