Specialists at a neurology center brought me a system design problem: 50 paid slots a month, 100 people competing for them, three booking channels that didn't talk to each other. No client, no contract, just a puzzle I couldn't drop.
The problem, in three lines
A clinic had 50 to 60 paid slots a month. Demand was over 100 people. Three ways to book, all opening at once on the 1st, none of them talking to each other. The phone line died in minutes, a crowd formed in the lobby, and because no channel knew what the others had done, the same slot could get handed out twice.
It looked like a scheduling problem. It's really an old one in disguise: a scarce resource handed out under peak load.
Same shape as concert tickets or visa slots.
Three ideas, three dead ends
I came up with four designs. The first three were wrong, and I want to walk through why, because the wrongness is where the actual thinking happened.
First idea: rank people by urgency, skip the race entirely. Dead in ten seconds. The service is paid, so ranking by medical need is both unethical and legally shaky here. I asked the model to poke holes in it before I got attached, and it asked one plain question: who decides "urgent," and on what basis. I tried to answer. Couldn't. There was no clean answer. Idea gone.
Second idea: spread appointments across different days by specialty. Sounded reasonable on paper. When I laid it out loud, the gap showed itself: this changes when people apply, not how a slot gets assigned. Two different axes of the same problem, and I'd fixed the wrong one. The queue doesn't care what day it is.
Third idea: remove the walk-in path entirely. Warmer, but incomplete. The crowd didn't go home, it moved to the phone and hit redial at 9am. Same fight, different channel, same losers.
That third failure is what made the real insight visible: people don't queue because slots open on one day. They queue because showing up in person gives them a better shot. Take that advantage away, and the line clears itself. None of the first three ideas removed the advantage. The fourth one had to.
Building the fourth idea with a second pair of eyes
The design I landed on: two remote channels, a website and a phone menu, both writing to one shared list of slots. The phone side names the next free slot, locks it the instant it says it, in one atomic step instead of "check now, book a second later".
That gap between checking and booking is exactly where double-bookings live.
If the caller agrees, it books against their number and sends an SMS. A person calls back later, off-peak, to confirm the details. The stressful part runs without a human; the human work moves out of the rush.
This is where having an AI in the loop actually changed the outcome, not just the speed. At every iteration I'd land on something that felt clean, and the model would ask who loses under this specific version. When I got attached to the phone-tree design, it didn't tell me it was wrong. It asked me to describe the actual person dialing in: someone with a hand tremor, at 9am, trying to hit the right button on the third menu level.
I hadn't pictured that person once. The model didn't have a stake in my idea being good, which turned out to be the useful part.
Where I'd fooled myself
Then I asked the question I'd been avoiding: did any of this add a single appointment?
No. Fifty slots for a hundred people before, fifty after.
I hadn't shrunk the shortage, I'd made the rejection politer. The same fifty people go home with nothing, they just hear it from a calm phone menu now instead of an angry line.
I also had zero real numbers behind any of it. How many calls actually come in. How many people genuinely have no internet. And a question I only got to on a second pass: who benefits from the current mess staying broken. Systems that stay chaotic for years in an institution usually stay that way because someone's informal workaround depends on the chaos. I'd designed an entire architecture without once asking who'd quietly resist a transparent, trackable version of it.
What actually changed how I work
This is the same judgment I bring to automation and AI workflow projects generally: what does the machine get to decide, and where does a human have to stay in the loop, and, in this case, where does my own judgment need a second opinion that isn't invested in my ego.
A clean system that solves the wrong problem is just a tidy way to be wrong. I'd built a good answer to a question nobody had actually measured. The part worth keeping isn't the architecture. It's the discipline of asking an outside voice, even a model, to find the person my design forgot, before I mistake elegance for correctness.
What I'd do differently
Watch the real thing for a week before drawing a single box. Count the calls. Ask who loses under each option and who's currently benefiting from nobody asking. Only then design.
The thinking holds up. The habit of checking it against something outside my own head is the part I want to keep.
Top comments (0)