Wie aus einer Sonntags-Hundeschule eine rollenorientierte Wartelisten-Engine wurde

Als in mir zum ersten Mal die Idee aufkam, ein Buchungssystem zu entwickeln, ging es nicht um eine „Marktlücke“.

Es gab keine Roadmap, kein Pitch-Deck und auch keinen großen SaaS-Traum. Was es aber gab, war ein sehr bodenständiges Problem. Eines, das ich bis dahin schon viel zu oft in unterschiedlichen Formen gesehen hatte: ein Mensch versucht fair zu sein – und das System hilft ihm dabei nicht.

Hier beginnt diese Geschichte. Mit einer einzigen Person: Juli.

Juli, die Hundetrainerin – und der Papierzettel

Juli ist Hundetrainerin. Sie betreibt ihre Hundeschule allein. Keine Assistenz, kein Admin, kein „das regelt schon jemand“. Sonntags gibt sie Unterricht. Mit fester Kapazität: 7 Hunde. Nie mehr. Das ist keine Komfortentscheidung, sondern fachliche Verantwortung. Sind es mehr, leidet die Qualität, die Aufmerksamkeit bricht weg, die Stunde zerfällt.

Auch der Anmeldeprozess hatte sich eingespielt:

• Bis Freitag 18 Uhr kann man sich anmelden.

• Am Samstag finalisiert Juli den Plan.

• Am Sonntag finden die Stunden statt.

Das Online-Buchungssystem, das sie damals nutzte – nennen wir es OIF – funktionierte technisch. Geschäftlich jedoch nicht.

Das OIF konnte keiner Veranstaltung eine Warteliste zuordnen.

Das klingt zunächst nach einer Kleinigkeit. In der Praxis brachte es alles durcheinander.

Der Workaround, der alles verrät

Juli erfand deshalb einen Umweg. Für jeden Sonntag legte sie zwei Veranstaltungen zur gleichen Uhrzeit an:

1. Die „Stunde“ – mit 7 Plätzen

2. Eine zweite Veranstaltung namens „Warteliste“ – praktisch unbegrenzt

Allen schickte sie sowohl die öffentliche URL der Stunde als auch die der Warteliste, und jeder buchte dort, wo es ihm sinnvoll erschien. Juli bat sogar ausdrücklich:

„Wenn du dir nicht 100 % sicher bist, buche lieber die Warteliste.“

Das ist wichtig. Keine technische, sondern menschliche Logik.

Am Samstag schaute Juli auf die Zahlen. Typischerweise so:

• Stunde: 7 Personen

• Warteliste: 3 Personen

Hier begann etwas, das kein System von selbst überblicken konnte.

Die SMS-Kette und die Entscheidungen in Echtzeit

Juli ging nun rückwärts durch die Anmeldungen der Stunde. Den zwei zuletzt Eingetragenen schrieb sie eine SMS:

„Wenn es am Sonntag einen anderen Termin gäbe – könntest du kommen?“

Der alternative Termin überschnitt sich nicht mit dem ursprünglichen, meist lag er davor.

Wenn alle fünf (die 3 von der Warteliste + die 2 „Verschobenen“) zusagten, schrieb Juli den neuen Termin, die Namen und die Zahlen auf einen Zettel – fertig.

Ergebnis:

• Ursprüngliche Stunde: 5 Personen

• Neuer Termin: 5 Personen

Die 7-Personen-Grenze wurde nirgends überschritten. Alle profitierten.

Wenn niemand antwortet

Doch das Leben ist nicht immer so sauber.

Manchmal war jemand:

• verhindert,

• antwortete nicht,

• reagierte zu spät,

• unsicher.

Dann wartete Juli etwa eine Stunde und ging weiter rückwärts durch die SMS-Liste. Mit derselben Frage. So lange, bis der neue Termin die nötige Teilnehmerzahl erreichte.

Am Ende ging noch eine Bestätigungs-SMS an diejenigen, die im ursprünglichen Termin blieben:

„Alles in Ordnung, keine Änderung, du kannst zum ursprünglichen Termin kommen.“

Der Endzustand war immer gleich:
Juli mit einem Zettel in der Hand. Zwei Termine. Namen. Teilnehmerzahlen. Kontrolle.

Und dann fiel der Satz, der alles ins Rollen brachte:

„Das müsste man doch automatisieren können.“

Hier entstand der eigentliche Bedarf

Es ging nicht um ein simples „Termin buchen“. Sondern um Folgendes:

• wie die Verteilung fair bleibt,

• wie Juli nicht willkürlich entscheiden muss,

• wie sie sich nicht merken muss, wem sie wann geschrieben hat,

• wie sie nicht bis Samstagabend ausbrennt.

Das ist kein Kalender mehr. Das ist Entscheidungsunterstützung.

Und hier kam der Overflow-Splitter-Algorithmus ins Spiel (oder einfacher: der Splitter).

Was bedeutet der Splitter-Algorithmus wirklich? Was macht er?

Als wir diese Anforderung erstmals formulierten, habe auch ich sie vereinfacht:

„Verteile die Buchungen gleichmäßig zwischen Root-Event (ursprünglicher Termin) und Geschwister-Events (z. B. neuer Sonntagstermin).“

Technisch stimmt das. Geschäftlich reicht es nicht.

Das geschäftliche Ziel des Splitters ist nicht die Verteilung.
Sondern die Entscheidungs-Last vom Menschen zu nehmen.

Was heißt das konkret?

• Es gibt ein Root-Event (die ursprüngliche Stunde).

• Es gibt Geschwister-Events (neu geöffnete Termine).

• Es gibt eine Warteliste, die kein Parkplatz ist, sondern Potenzial.

• Es gibt einen Parameter movables=true, der bedeutet, dass Buchungen vom Root-Termin verschoben werden dürfen – aber nicht, dass „jeder überall hin wechseln kann“.

• Er bedeutet: nur so viele werden verschoben, wie für das Gleichgewicht nötig sind.

• Die andere wichtige Einstellung ist round_robin („die letzten zuerst“). Das steht hier nicht für Gerechtigkeit, sondern für eine konservative Lastverteilung (kreisförmige Verteilung der Verschiebbaren auf Ziel-Events).

Genau so, wie Juli es im Kopf und per SMS gemacht hat.

Automatisierung – aber nicht kopflos

Juli wollte nicht, dass „jeder einfach umbuchen kann“.

Ganz im Gegenteil.

Die Automatisierungsidee sah so aus:

• Wenn die Kapazität in die Warteliste überläuft,

• gehen Benachrichtigungen an die Betroffenen,

• ein neuer Termin öffnet sich,

• aber nicht jeder kann umbuchen,

• die Wartelistengröße passt sich dynamisch an etwa die Hälfte der Gesamtkapazität an.

Das ist keine Marketinglogik. Das ist Betriebslogik.

So wurde daraus ein rollenorientiertes System

An diesem Punkt wurde mir klar, dass das System nicht „für alle gleich“ sein kann.

Juli:

• ist Ressource,

• Entscheidungsträgerin,

• und verantwortlich.

Die Teilnehmenden:

• sind keine Admins,

• keine „Kunden“ im klassischen Sinn,

• sondern Menschen mit Unsicherheit, Flexibilität und Reaktionszeiten.

Deshalb wurde das System rollenorientiert:

• der Admin sieht etwas anderes,

• der Wartelistenteilnehmer bekommt etwas anderes,

• und jemand mit festem Platz wieder etwas anderes.

Und deshalb wurde die Warteliste ein aktives Element – keine Nebenfunktion und kein über Umwege erzeugtes Konstrukt.

Was am Ende entstanden ist

Was aus all dem geworden ist, ist heute eine der Grundideen von Bookcessful.com.

Nicht, dass „man buchen kann“.
Sondern dass Menschen keine schlechten Entscheidungen treffen müssen, weil das System schlecht ist.

Der Splitter ist nicht schlau.
round_robin ist nicht genial.
movables=true ist keine Magie.

Es bildet lediglich eine reale, erprobte, menschliche Arbeitsweise ab.

Die Logik einer Sonntags-Hundeschule.

Und für mich war hier klar:
Wir bauen kein Buchungstool,
sondern ein Entscheidungssystem, das Last tragen und Verantwortung respektieren kann.

Das war das erste echte Kundenbedürfnis.

Alles andere war nur Folge – und ist heute Geschichte.