In October 2025, my co-founder and I made a decision that most people in our position don't make: before building anything, we stopped and went to watch.

We reached out to 12 trucking companies. We asked if we could sit in on their dispatch operations for a few days each. Seven of them said yes. Over the next 90 days, we logged nearly 300 hours in dispatch offices, break rooms, and truck cabs across Texas, Ohio, Tennessee, and Georgia. We watched people work. We asked a lot of questions. We took notes on everything.

What we came back with upended almost everything we thought we knew going in.

Here are five things we got completely wrong.

1. We thought dispatchers wanted to be replaced. They don't — and that's the right instinct.

Before the research, our pitch deck literally had a slide that said "AI replaces the dispatcher." We deleted it on day four.

The dispatchers we spent time with were not people who wanted to be automated out of existence. They were deeply skilled professionals who had built years of institutional knowledge — carrier relationships, lane expertise, driver personalities — that no software system in 2025 could replicate.

What they wanted to be replaced was the 40% of their day that felt like clerical work. The status calls. The document filing. The rate confirmations. The load board refreshing.

The repositioning from "replace the dispatcher" to "replace the tasks the dispatcher shouldn't be doing" sounds small. It's not. It changes everything about how you build the product, how you price it, how you sell it, and how you talk about it.

2. We thought the problem was information access. It's actually information trust.

We assumed that dispatchers lacked visibility. That they needed better dashboards, better maps, better data. We were wrong.

Most experienced dispatchers had a near-photographic mental model of their entire fleet at any given moment. They knew where every driver was, roughly, and what every load was doing. The problem wasn't that they couldn't see their operation — it was that they couldn't trust any software to see it as accurately as they could.

A dispatcher in Memphis told us something that reshaped the entire product: "Every tool I've used shows me wrong information confidently. I'd rather have no information than wrong information."

That's why we built Lens around confidence signals, not just data. When Lens flags a document discrepancy, it shows you exactly what it found and why it thinks it's a problem. It doesn't just say "BOL issue detected." It shows you the specific field, the specific mismatch, and the specific load. Because a system that shows you wrong information confidently will be abandoned in a week.

3. We thought speed was the top priority. It's reliability.

Every conversation we had before the research pointed toward speed. Faster dispatch, faster broker responses, faster route assignment. We built our first prototype around latency — how quickly could the system do things?

Wrong metric.

After week two, we noticed something: the dispatchers who were most stressed weren't the ones who were slowest. They were the ones who didn't know if their tools had worked. Did that email go through? Did the broker get the confirmation? Is that load status actually updated or is it cached from three hours ago?

The enemy wasn't slowness. It was uncertainty.

We rebuilt our confirmation architecture from scratch around this insight. Every action Relay takes generates a visible, timestamped record that the dispatcher can see in real time. Not a notification — a record. Because a dispatcher doesn't need to be told something happened. They need to be able to see that it happened, with their own eyes, and trust it.