Why We Lost 3 Customers Over Data Import (And Spent a Year Fixing It)

Two years ago, we had seven beta customers testing our RFP response platform. The VPs loved it. Our optimization engine was solving real problems. But we lost three of those customers anyway.

The reason? Our data import process was harder than the current status quo: Excel.

That painful lesson kicked off a year-long obsession with something most software companies ignore: making it effortless to get data into the system. Since then, we’ve ingested over 10,000 RFP files with 95% importing automatically. Getting there taught me more about software adoption than any optimization algorithm ever could.

The Problem Everyone Skips

RFPs (requests for proposals) are how shippers and carriers negotiate freight contracts. It’s the lifeblood of trucking during bid season. And it’s a complete mess.

Every shipper has their own Excel format: different column headers, different ways to represent locations. You’d think “Atlanta, GA” would be straightforward, but I’ve seen it as “Atlanta,” “ATL,” “303” (zip3 code), “Fulton County,” and “AGAX17” - custom facility codes that mean nothing outside that company’s walls.

This is the Tower of Babel problem. Everyone’s sending structured data, but there’s no shared language for what “origin” or “Atlanta” actually means. Our job became building the Rosetta Stone.

The real cost isn’t the chaos - it’s the human time wasted. A 500-lane RFP with messy location data takes an experienced analyst 2 hours. Half a day for someone new, and they’ll make errors. Errors that might not surface until after you’ve submitted your bid.

Here’s a real story that still makes me wince. During bid season, one of our largest customers was pricing a major bid with dozens of lanes from Mexico - ‘Juarez, NL’ specifically. The analyst quickly mapped it to the city everyone knows: the massive border crossing in Chihuahua. They ran the numbers, submitted the rates, and a few weeks later won every single Mexico lane they bid on. Their celebration was cut short when the shipper called to discuss onboarding. That’s when they discovered ‘NL’ meant Nuevo León - a different Juarez, 650 miles away near Monterrey. That small error on the analyst’s Excel spreadsheet was about to turn into a quarter-million-dollar annual loss. The account manager had to make one of his most painful calls, explaining how they’d priced lanes to the wrong city entirely. While they kept some business, they lost a lot of credibility.

The Classic Customer vs. Consumer Problem

Our beta customers’ VPs loved our platform. The optimization engine was solid. Network visualizations gave them insights they’d never had before.

But the analysts - the people actually doing the work - hated the import process.

We built sophisticated optimization tools but forgot the loading dock for getting data in. The VPs (customers) saw the destination. The analysts (consumers) felt the friction.

Three of those seven beta customers churned. Their teams couldn’t justify processing data twice: once in Excel to clean it, then again in our system.

The frustrating part? We were already better at import than competitors. But “better than competition” wasn’t enough. If you’re not 10x better than Excel, users revert to what they know.

What “Import” Really Means

Most software treats import as copying Column A to Field B. That’s not import - that’s data transfer.

Real import requires language translation.

When we see “northern atlanta” in a location field, we translate it to “Atlanta, GA” with proper geocoding. When a trailer type column contains “RF,” our intelligence recognizes that means “reefer” (refrigerated). When the loading type says “Live loading preferred,” we understand that means both live loading and drop loading are acceptable - not just live.

We’re doing language translation, i.e. the Rosetta Stone for RFPs, not just run-of-the-mill data mapping. Excel can map exact matches. But it can’t understand that “St. Louis” and “Saint Louis” are the same city, or that “RF” means refrigerated trailer in trucking context.

When someone types “Hatlanta” by mistake, we catch it automatically. When a shipper’s file has city and state in one column (“Dallas, TX”), we split it seamlessly. When you upload 3 digit zip codes like “303,” we instantly map them to the correct metro areas - something that takes analysts hours of manual Google searches in Excel.

The Visibility Difference

Here’s what makes our approach fundamentally different: you can see exactly what we did with your data.

Remember that Mexico disaster? In our system, when you see ‘Juarez, NL,’ we show you: original value → interpreted location → calculated distance → highlight discrepancies. If you accidentally map to Ciudad Juárez, Chihuahua instead of Juárez, Nuevo León, our distance validation immediately flags it - the mileage would be off by 650 miles. You catch the error before pricing, not after winning the bid.

We have an errors and warnings tab in our import process where every transformation is logged. Distance deviations over 5% trigger manual review. Ambiguous city names get flagged. Every decision is auditable.

Compare this to Excel: VLOOKUP silently fails, formulas hide errors in cells, and you don’t know something’s wrong until a customer asks why you didn’t bid on their lanes. Worse, someone copies an RFP from last month, accidentally overwrites formulas with static values, and your fuel surcharge calculations are frozen in time. Bids go out 15% too low. You win everything and lose money on every load.

The Unglamorous Path to 95%

I wish I could say the solution we built is all AI magic. But the reality is that it was systematic, unglamorous iteration.

Every time a user had to manually intervene, we logged it. Every week, we analyzed root causes. Then we fixed the biggest problems. Week after week, month after month.

When we started, less than 10% of RFPs imported cleanly. The number crept up: 20%, 40%, 70%. The last 10% was brutal - that’s where LLMs (Claude, GPT, Deepseek, etc) became useful for edge cases.

But most of our processing uses deterministic methods: heuristics, fuzzy matching algorithms, geospatial lookups, and our custom routing engine. Using LLMs for an entire 10,000-lane Walmart RFP would be slow, expensive and dangerous. With even 1% hallucination rate, that’s 100 potentially wrong prices - and good luck identifying which ones. When a customer asks why you bid $3,200 on lane #4,237, you need to reproduce that decision exactly. Non-deterministic LLMs can’t do that.

The 10x Better Threshold

While our competitors were adding AI chatbots, we spent a year on data import. Here’s why:

Processing a 500-lane RFP in Excel takes an hour minimum. Our system does it in under a minute. That’s 60x faster.

But speed is just a symptom. The real advantage is error prevention. Excel introduces silent errors that surface after you’ve won bids. Our validation catches them upfront. That’s not 10x better - it’s infinitely better because the errors don’t happen.

Data Is Foundational

I’ve had executives ask us to make them “AI-enabled.” When I see their data situation, I politely decline.

You can’t build intelligent systems on messy data. Everything - optimization, analytics, AI - sits on your data foundation. If it’s crumbling, nothing works reliably.

In my opinion this is one of the biggest reasons you see articles reporting that 95% of AI initiatives fail in companies. Companies skip the unsexy foundation work and jump to sexy AI features. It doesn’t work.

We’re Not Done Yet

We still have an automated alert that pings our engineering team whenever a user has to manually intervene during import. It fires much less frequently now. Imports that need help are few and far between.

But when it does ping us, we investigate and fix it if we can. We push fixes in weekly feature releases. That’s a different cadence than the industry’s typical yearly release cycle, but it’s necessary when you’re committed to continuous improvement.

The Ironic Truth

That VP who told me “this is harder than Excel” changed how I think about software. For a year, I thought we were building better analytics and optimization. But we were actually building a translator - converting the messy, human language of logistics into something systems could perfect.

The unsexy truth? Most B2B software fails not because the algorithms aren’t sophisticated, but because the data never makes it in correctly. Fix the on-ramp, and suddenly your sophisticated features actually get used.

The irony is that we ARE an AI company - but focusing on this boring problem made our AI better. Clean, structured, validated data is what makes our optimization and intelligence features actually work. You can’t build a great AI company without first building a great data company. We spent a year on the most boring problem in logistics. It became our moat.

This specific problem remains largely unsolved in the industry. Watching 95% of RFPs import cleanly while others still require manual cleanup, I’m convinced it was the right hill to die on.

Thanks to Luis Arellano and Anupam Krishnamurthy for feedback on drafts of this post.

Neil Fernandes is the founder of EnrouteAI, where his team has spent a year obsessing over data quality in transportation software. He has a background in Industrial Engineering and Operations Research from the University of Michigan, Ann Arbor and has spent over a decade applying optimization to transportation problems. Before founding EnrouteAI, he worked on Supply Chain Optimization at OPSRules, founded by MIT Professor David Simchi-Levi.