story

How a Sunday Dog School Turned into a Role-Oriented Waitlist Engine

December 31, 2025

When the idea of building a booking system first came up, it wasn’t about spotting a “market gap”.

There was no roadmap, no pitch deck, and no big SaaS dream either. What there was, however, was a very down-to-earth problem. One I had already seen too many times in different forms: someone tries to be fair, and the system does not help them do that.

This story starts here. With a single character: Juli.

Juli, the dog trainer – and the paper note

Juli is a dog trainer. She runs her dog school alone. No assistant, no admin, no “someone else will sort it out”. She holds classes on Sundays. With a fixed capacity: 7 dogs. Never more. This is not a comfort decision, but professional responsibility. With more dogs, quality drops, attention breaks, the session falls apart.

The application process had also settled into a routine:

Until Friday 6 PM people can sign up.
On Saturday Juli finalizes the schedule.
On Sunday she holds the classes.

The online booking tool she used at the time – let’s call it OIF – worked in a technical sense. In a business sense, it did not.

The OIF could not assign a waitlist to an event.

At first glance this seems like a minor detail. In practice, it broke everything.

The workaround that reveals everything

So Juli came up with a workaround. For every Sunday she created two events for the same time slot:

The “class” – with a capacity of 7
Another event called “waitlist” – practically unlimited

She sent everyone both the public URL of the class and the waitlist, and everyone booked wherever they felt was right. Juli even explicitly asked:

“If you’re not 100% sure, please book the waitlist.”

This matters. Not technical logic, but human logic.

On Saturday, Juli checked the numbers. Typically like this:

Class: 7 people
Waitlist: 3 people

This is where something started that no system could see or understand on its own.

The SMS chain and live decisions

At this point, Juli worked backwards through the people registered for the class. She texted the two who had booked last:

“If there were another time slot on Sunday, could you make it?”

The alternative slot did not conflict with the original one – it was usually scheduled before the main class.

If all five (the 3 from the waitlist + the 2 “moved”) said yes, Juli wrote the new time, the names, and the numbers on a piece of paper, and that was it.

Result:

Original class: 5 people
New slot: 5 people

The 7-person limit was never exceeded. Everyone won.

When people don’t respond

But life is not always this clean.

Sometimes someone:

was busy,
didn’t reply,
responded late,
was uncertain.

In these cases, Juli waited about an hour, then continued backwards through the SMS list. Same question. She repeated this until the new slot reached the required headcount.

Finally, one more confirmation SMS went out to those staying in the original class:

“Everything’s fine, no changes, you can come at the original time.”

The end state was always the same:
Juli with a piece of paper. Two time slots. Names. Headcounts. Control.

And then came the sentence that started everything:

“This could surely be automated.”

This is where the real need was born

This was not a simple “book an appointment” problem. It was about this:

how allocation remains fair,
how Juli does not decide arbitrarily,
how she doesn’t have to remember who she messaged and when,
how she doesn’t burn out by Saturday evening.

This is no longer a calendar. This is decision support.

And this is where the overflow splitter algorithm (or simply: splitter) entered the picture.

What does the splitter algorithm really mean? What does it do?

When we first wrote down this requirement, I oversimplified it myself:

“Distribute bookings evenly between the root event (the original time slot) and sibling events (for example, the new Sunday slot).”

Technically, this is true. Business-wise, it’s not enough.

The business goal of the splitter is not distribution.
It is removing the burden of decision-making from the human.

What does this mean in practice?

There is a root event (the original class).
There are sibling events (newly opened slots).
There is a waitlist that is not parking, but potential.
There is a parameter, movables=true, meaning bookings may be moved from the root slot – but not that “anyone can move anywhere”.
It means: only as many people are moved as required for balance.
The other key setting is round_robin (“last few go first”). This is not about fairness here, but about conservative load balancing (cycling movable bookings across target events).

Exactly the way Juli did it in her head and via SMS.

Automation, but not mindlessly

Juli did not want “everyone to be able to rebook”.

Quite the opposite.

The automation concept was this:

When capacity overflows into the waitlist,
notifications go out to those affected,
a new slot opens,
but not everyone can rebook,
the waitlist size dynamically adjusts to roughly half of total capacity.

This is not marketing logic. This is operational logic.

This is how it became a role-oriented system

At this point it became clear to me that the system could not be “the same for everyone”.

Juli:

is a resource,
a decision-maker,
and responsible.

The participants:

are not admins,
not “customers” in the classic sense,
but people with uncertainty, flexibility, and response times.

That’s why the system became role-oriented:

the admin sees one thing,
the waitlisted person gets another,
and someone with a fixed spot gets something else.

And that’s why the waitlist became an active element, not a side feature or a workaround-object.

What ultimately emerged

What all of this became is now one of the core ideas behind Bookcessful.com.

Not that “booking should be possible”.
But that people shouldn’t have to make bad decisions because of a bad system.

The splitter is not smart.
The round_robin is not brilliant.
movables=true is not magic.

It simply maps a real, tested, human way of working.

The logic of a Sunday dog school.

And for me, this is where it became clear:
we are not building a booking tool,
but a decision system that can handle load and respect responsibility.

This was the first real customer need.

Everything else was just consequence – and by now, history.