The scheduling system that would not stop double-booking

The situation

The build was for a business that staffs people into shifts across the week. The team lived in Slack. Records lived in HubSpot. The commerce side ran on Shopify. None of those tools were the problem.

The problem was how shift requests arrived. They came as free text, in whatever channel was closest: a Slack DM, a reply to an old email thread, a message relayed through a manager. "Can I grab Saturday morning?" "Drop me Thursday, I have an appointment." "Swap me with whoever has the early shift, I owe them one."

A coordinator read each message, checked the schedule, made a judgment call, updated the record, and replied. That took hours every time the schedule churned. And under load it broke in one specific way: two people would ask for the same shift a few minutes apart, and both would get a yes.

That is a double booking, and it is worse than an empty shift. An empty shift is a visible gap someone can fill. A double booking sends two people to the same slot and tells both of them they were right. Someone rearranges their week around a shift that was never theirs, and then the coordinator has to take it back. That conversation costs more trust than any software bug.

The constraint we were handed was firm: you cannot make people change how they ask. The team had tried before we arrived. Reminders, pinned instructions, a "please use the sheet" message every few weeks. Requests kept coming as prose, because prose is fast, and the fastest channel always wins.

What we tried first, and why it failed

Attempt one was a stricter form. Required fields. A dropdown limited to open shifts only. Validation on everything. The theory was reasonable: messy input causes messy schedules, so stop the mess at the door.

It failed for a boring reason. People ignored the form. Not out of defiance. The form was a second place to go, and Slack was already open. Every ignored request still had to be handled, so now the coordinator was running two systems: the form for the few who used it, and the inbox for everyone else. We had made the job bigger.

There is a general lesson here that we now apply on every intake build. A form competes with the easiest possible alternative, which is typing a sentence to a human. If the form loses that race, its validation rules protect nothing, because the data simply goes around them.

Attempt two kept the messy intake and added a guard inside the workflow. Zapier was already picking up requests (we cover when Zapier is the right runner in Zapier vs Make vs n8n), so we added a check before every assignment: look up the shift, and only assign if it is empty.

This pattern is called check-then-write, and it has a gap you cannot close from inside the workflow. Two requests arrive seconds apart. Both runs check the shift. Both see it empty, because neither has written yet. Both write. The second write does not throw an error. It just lands. In the Zap history, every single run looks correct: trigger fired, check passed, record updated, green check marks all the way down. The bug only exists between the runs, and no log shows you "between."

We proved it in testing by firing two requests at the same shift a few seconds apart. Both came back confirmed. That one test told us the real shape of the problem.

The thing that mattered most: ownership locks

Double booking is not an input problem. It is a concurrency problem. The question is never "was the request well formed?" It is "what happens when two valid requests hit the same shift at the same time?" Once we asked it that way, the answer was old and well known: the record needs an owner, and claiming the record has to be an operation that only one request can win.

So each shift became a record in HubSpot with an owner field, and "claiming a shift" became a small, strict procedure. Here are the honest mechanics, because HubSpot and Zapier do not hand you a database lock out of the box:

1. The workflow writes its claim to the owner field, tagged with a marker unique to that one request.
2. It waits a short, fixed beat, so any near-simultaneous write has time to land.
3. It reads the record back. The field can only hold one value, so only one request can see its own marker there.
4. If the marker is yours, you own the shift and the workflow proceeds. If it is not, a competing request won, and your run takes the "already taken" branch and replies accordingly.

Exactly one request ends up owning the record. The losing request does not fail silently or collide. It gets a clean, polite no, and the person gets an immediate answer instead of a false yes.

The deeper point is where the rule lives. Enforce it where the data lives, not where the data enters. Interfaces multiply: Slack, email, the form nobody used, a manager editing HubSpot directly. The record is the one place every path converges. Put the rule there and every door is covered, including doors you have not built yet.

Where the rule lives	What it looks like	Why it holds or fails
Interface	Form validation, required fields, dropdowns	Fails. It guards one door, and people use the other doors.
Workflow	Check-then-write inside the automation	Fails under concurrency. Two runs can both pass the check before either writes.
Data layer	Claim-then-verify on the record itself	Holds. Every path converges on one record, and the record can only hold one owner.

With the lock in place, the AI step's job got smaller and safer, which is exactly what you want. The OpenAI step parses "drop me Thursday and swap with whoever has the early close" into structured intent: which person, which shift, which action. It translates. It never decides. If the parse is low confidence, or it names a shift that does not exist, the request routes to a human in Slack instead of guessing.

The lock is what makes the AI step safe to run at all. Even a wrong parse cannot double-book anyone, because the worst it can do is lose a claim race or fail validation. That division of labour, the model handles language and deterministic rules handle decisions, is how we build most AI automation now.

What shipped

The finished flow, end to end:

1. A request arrives in Slack or email, as whatever sentence the person felt like typing. No form.
2. Zapier picks it up and passes it to an OpenAI step, which returns structured fields: person, shift, and action (take, drop, or swap).
3. A validation step checks those fields against real records. An unknown shift or an ambiguous name routes to a human in Slack.
4. The claim attempt runs against the shift record in HubSpot, using the ownership lock described above.
5. If the claim wins, the schedule updates, an encrypted confirmation goes out automatically, and Slack is notified. Confirmations carry personal scheduling details, so they do not travel in plain text. If the claim loses, the person gets an immediate reply that the shift is taken, along with what is still open.

What changed, limited to what we can stand behind: allocation went from hours of coordinator work to near-instant, double bookings stopped because every booking path now runs through a record that can only be claimed once, and confirmations went out encrypted without anyone touching them. The coordinator's job shrank to exceptions: low-confidence parses and swaps that genuinely need judgment.

One honest qualifier on "near-instant." The parse and the claim take seconds, not zero. And ambiguous requests still wait for a person, on purpose. Speed on the clear cases is only worth having if the unclear cases stay safe.

What we would do differently

Start at the data model, not the intake. The form was the polite first answer, and we built it even though we had watched forms lose this race on other builds across 600+ workflows. The lock should have shipped first. Intake can be messy forever if the layer underneath cannot be corrupted.

Test the race on day one. Two requests at one shift, seconds apart, in a sandbox. It was the cheapest test we ran and the most informative. We ran it after attempt two failed. It should have been the first thing we did.

Log losing claims from launch. A lost claim is not noise, it is demand data: which shifts are contested, who keeps missing out, where to add capacity. We added that logging later. It belonged in version one.

Say the unpopular thing earlier. "What if we just let people type whatever they want?" sounds lazy in a kickoff meeting, so we did not lead with it. It was the right design. The intake that matches real behaviour beats the intake that looks disciplined.

And the part we owe you straight: you may not need this build at all. If one person owns the schedule, volume is low, and nothing else writes to it, you do not have a concurrency problem. A shared calendar and a fixed weekly routine will beat anything we could build, at zero software cost. The lock earns its keep only when more than one actor, human or automation, can write to the schedule at the same time. If you are not sure which situation you are in, count the writers first, or work through our operations leak audit before paying anyone $150 an hour. If you want a second opinion on whether your double bookings are a process problem or a concurrency problem, send us your messiest example and we will tell you which one it is, including when the answer is "you do not need us."

FAQ

What is an ownership lock, in plain terms?

It is a rule that says a record can have exactly one owner, enforced on the record itself. Claiming works by writing your claim with a unique marker, waiting a beat, then reading the record back. Only one request can see its own marker, so only one request wins. Everyone else gets a clean no instead of a silent collision.

Can you build this in Zapier and HubSpot without custom code?

Yes. Claim-then-verify is just a write, a short delay, and a read-back with a branch, all standard steps. You do not need a database administrator. The same pattern works in Make or n8n, because the lock lives in how you use the record, not in any one tool's feature list.

Do we need an AI step for this to work?

No. The lock works on its own and is the part that stops double bookings. The AI step earns its place only when requests arrive as free text and you cannot change that behaviour. If your requests are already structured, skip the model and keep the lock.

Why not just make people use a form?

Because they will not, and we have the failed attempt to prove it. A form competes with typing one sentence in Slack, and it loses. Even if it won, form validation only guards one door. Requests that arrive by email, by relay, or by a manager editing the record directly all bypass it. The data layer is the only place every path passes through.