Episode 2 February 2026 7 min read

I Was the User Who Became the Builder

In 2004, I was a valet attendant using an automation system. The idea was good. The execution didn't match operational reality. So I built a system that actually worked.

In 2004, I was a valet attendant using an automation system. The idea was good. The execution didn't match operational reality. It was difficult to use in actual operations.

I knew exactly where it failed because I lived it every shift. Cold hands couldn't type on touchscreens. Couldn't read displays in bright sun. Needed one hand free for keys and tickets. Customers standing there waiting - every second counted.

The system was built by people who'd never done the job. They made assumptions about how valet operations work. Every assumption was wrong.

So I built a system that actually worked.

VIRTUAL DATA ENTRY

The bottleneck was information entry. Valets had to manually type make, model, color, license plate - all while holding keys, standing in weather, with a customer waiting.

Instead of making valets type vehicle information, I implemented VIN scanning with Bluetooth scanners. One motion, done.

Then I extended it. Scan anything. New York registration? Scanned. The system automatically entered vehicle info, flagged oversized vehicles for automatic upcharges, processed everything without the valet touching a keyboard.

I called this Virtual Data Entry.

The valets actually used the system because it was faster than the old manual method. That's the only reason automation survives in the real world - it has to be easier than what it replaces.

PROXIMITY DISPATCH

Think about a 5-story parking garage with 2,000 vehicles parked across multiple levels.

When a customer requests their car, which valet should get the job?

Software people would build an algorithm based on workload distribution or queue fairness. That's optimizing for the wrong thing.

I built internal mapping that tracked where employees parked each vehicle. The system assigned requests to whoever was physically closest to that car.

This wasn't rocket science. It was understanding physics.

AI can find the car in the database instantly. But the valet still has to walk there. Distance matters. Time matters. The customer is standing at the front desk waiting.

Proximity dispatch cut retrieval times significantly. Not because of better AI. Because I understood the operational reality of moving through physical space.

THE UNIVERSAL FRAMEWORK

I used the same exact framework for belldesk operations.

Track items. Track workers. Assign based on proximity. Validate the right person has the right item. Audit everything.

The framework wasn't specific to parking or hotels. It was specific to operational reality: humans moving physical items through physical space under time pressure.

Years later, a billion-dollar rideshare company built their entire business model on proximity-based dispatch.

I was using it in 2004 because operational reality demanded it.

WHY AI IS MAKING THE SAME MISTAKES

The pattern I'm seeing now with AI tools is identical to what I saw with automation systems 20 years ago.

Technical people build features they think are useful. They don't understand the operational constraints. They've never done the job.

The warehouse manager trying to use AI to build an inventory system faces the same problem the valet faced with the bad automation system.

The AI builds something technically impressive that fails in reality because nobody asked about gloves, cold temperatures, one-handed operation, spotty WiFi, or the fact that workers are moving fast and won't stop to type.

The "obvious" operational details never make it into the requirements.

The AI isn't hearing what operators actually need.

THE REAL OPPORTUNITY

Business operators aren't behind because they can't code or write perfect prompts.

They're ahead because they understand operational reality.

The AI companies building for technical users are missing the market. The real value isn't in the 5% who already know how to use these tools. It's in the 95% who know how businesses actually run.

Those operators hold the knowledge that makes automation actually work. Their expertise is the missing piece.

The question isn't how to teach them technical skills.

The question is: Can AI actually hear what operators know and translate it into systems that survive reality?

I've solved this gap before. I'm solving it again.

If you're an operator who knows your business but can't get AI to understand what you need, you're not the problem. The tools are.

If you're building AI products, the operators aren't "non-technical users." They're experts whose knowledge you need to capture. You need to ask: Can you hear me? And actually listen to the answer.

I'm working on the bridge between operational reality and AI capability.

If you're working on the same problem, reach out.

Follow the Series

New episodes on LinkedIn and here on 72knots.ai

Follow on LinkedIn