The system behind a slot that stays available | Headout Hackin'

We noticed a simple problem guests were facing: the time slot they had chosen could disappear just as they were about to book. Hundreds of guests encounter this on Headout every day, not always because demand suddenly spiked, but because the availability we showed them was already out of date. Somewhere between our last check with the supply partner and the moment the guest tried to pay, someone else had taken the slot.

Internally, we call this a Live Inventory Check failure. To the guest, it simply feels like a broken promise. So we decided to fix it during Hackin' and called it Clockwork.

Why fresher inventory is not a simple fix

Headout connects guests to experiences through dozens of supply partner systems, each with its own APIs and restrictions on how often we can ask what is still available.

The obvious solution is to refresh inventory more frequently, but every partner limits the number of API calls we can make, and exceeding that allowance can throttle every experience connected through the account. We had a fixed budget of calls and needed to spend it where it would have the greatest impact. The idea of an intelligent sync optimizer had surfaced before, but the problem could still be managed manually, with someone increasing the frequency of one tour and reducing another when failures became visible.

That approach worked just well enough to delay a better one.

When Hackin’ at Headout began, the ability to configure every tour independently had just shipped, giving us the foundation to build the system properly: fully automated, with no manual knobs.

The scoring problem became a systems problem

From the outside, Clockwork looked like a ranking exercise: score every tour by how urgently it needed fresh inventory, then assign a sync frequency.

The first brainstorming session revealed the iceberg underneath. Booking velocity mattered, but a fast-selling tour with a high failure rate required a different response from one selling just as quickly with almost no failures. The model had to balance several signals, ignore small fluctuations so it did not react to noise, and treat frequency changes proportionally, so moving from 15 to 30 minutes felt equivalent to moving from six to 12 hours.

It also had to respect rate limits across tours sharing the same partner account, distribute the budget fairly when demand exceeded supply, detect zero-inventory segments wasting calls, pause broken tours automatically and spread schedules out so refresh jobs did not fire together. Every feature had to coexist without producing contradictory behaviour, and one aggressive configuration could overwhelm a partner API and throttle the entire account.

Clockwork had stopped being a weekend scoring model and become a genuine systems design challenge.

0:00
/0:35

Proving that fresher data changed outcomes

Before building the complete system, we tested the eight tours with the highest Live Inventory Check failure rates and increased their sync frequency to once every 15 minutes.

The aggregate failure rate fell from 10.6% to 4.7%, more than halving the problem and confirming that stale inventory was a root cause we could directly influence.

We then extended inventory windows for tours from a major theme park partner, fetching availability further into the future than before. That generated hundreds of incremental bookings from guests planning months ahead, bookings that could not have happened earlier because the inventory had never been available to see.

Three people, one production system

Madhav and Himanshu built the scoring engine, rate-limit distributor, pipeline and dashboard, while Shriyan brought the product context needed to ensure the team was building something complete enough for production, not merely clever enough for a demo. In less than two days, the team worked through the partner constraints and failure modes that had kept the idea on the backlog and turned it into a functioning system.

What is live now

Clockwork is now in production through a phased rollout across Headout’s supply partner network. It scores tours, adjusts sync frequencies, respects partner-level rate limits, pauses broken tours, reduces calls to zero-inventory segments and diffuses schedules so jobs do not spike simultaneously, all without manual intervention.

The next step is to extend inventory windows across more partners, turning the theme park experiment into a platform-wide capability.


Hackin’ at Headout is our internal hackathon, where small teams have less than two days to turn real problems into working products. Interested in building with us? Explore open roles at Headout.

Headout Studio’s Profile Image

written by Headout Studio

The builders behind Headout. We design, code, experiment, break things, fix them and create new ways for people to experience the real world.

Dive into more stories