Case Study Details
Client: Mid-size logistics & fulfillment company (name withheld under NDA) Industry: Logistics / Supply Chain
Service: Intelligent Systems & AI
Engagement length: 11 weeks build + phased rollout, ongoing support
The Problem
By the time they came to us, their operations team had grown to five full-time employees whose entire job, in practice, was re-keying information from one place to another. The company ran a mid-size fulfillment operation serving around 40 active vendors, and every day, somewhere between 300 and 500 documents landed in their inbox and shared drive: purchase orders, shipping manifests, customs paperwork, and vendor invoices. None of it arrived in a consistent format. Some vendors sent clean PDFs. Others sent scanned faxes. A few still emailed photos of handwritten packing slips taken from a warehouse floor.
Every one of those documents had to be opened, read, and manually typed into their internal ERP system before anything downstream — inventory counts, billing, dispatch scheduling — could move. On a normal day, the team could keep roughly a few hours behind. During peak season, that lag stretched past a full day, and dispatch would sometimes schedule trucks based on stale inventory data because the "real" numbers hadn't been entered yet.
It wasn't just slow; it was fragile in ways that compounded. A transposed digit in a quantity field, or an SKU typed one character off, wouldn't get caught at the point of entry. It would surface two or three systems downstream: a warehouse team pulling the wrong quantity, a customer getting under-shipped, a reconciliation report that didn't add up at month-end. Their operations lead, whom we'll call the Ops Lead throughout this case study, described it during our first working session:
"We're not a tech company. We move boxes. But we were spending like a tech company just to keep up with typing things into a screen. And the worst part is, we still couldn't trust the numbers."
They'd tried to fix this once before. About a year before working with us, they'd licensed a generic OCR tool marketed as a document automation solution. On paper, it worked — but only on a narrow set of clean, standardized templates. The moment a vendor changed their invoice layout, used a slightly different font, or sent a lower-quality scan, accuracy collapsed. The tool couldn't tell the difference between a form it understood and one it was guessing at — it returned a confident-looking answer either way, which meant someone still had to manually check nearly everything it produced. In practice, the tool didn't remove the bottleneck. It just added a new step in front of it, and the team quietly stopped trusting its output within a few months.
By the time they reached out to us, there was real skepticism in the room. Understandably, they'd already spent budget and time on a version of this exact promise once, and it hadn't held up.
Why We Didn't Start With a Build
Before writing a line of code or proposing any architecture, we spent the first several days simply observing. Two members of our team sat with their operations staff for two full working days, not interviewing them about their process in the abstract, but watching them handle real documents as they came in, in real time.
That direct observation surfaced something the initial project brief hadn't captured: the hard part was never "reading text off a document." Off-the-shelf OCR is genuinely good at that now. The hard part was everything around it, deciding what a given field probably meant on a document that didn't match any known template, catching when a number looked wrong given the vendor's order history, and knowing the difference between "confident and correct" versus "confident and wrong." That distinction is exactly where their previous tool had failed silently, and it became the central design constraint for everything we built afterward.
We also mapped which document types were causing the most damage versus which were merely annoying. Roughly 60% of the daily volume came from just six vendors, and those six accounted for the majority of downstream errors — because they were the ones sending the least standardized paperwork. That reprioritization changed our rollout plan significantly, and we'll come back to it below.
What We Built
We designed an intelligent document-processing system with three distinct layers, built specifically so that no single point of failure could silently corrupt its data the way the previous tool had.
1. Extraction layer: We combined OCR with a language model trained to understand documents contextually rather than by fixed position on a page. Traditional OCR-plus-template systems break the moment a layout shifts, because they're looking for data in a specific X/Y location. Our approach instead asked, in effect, "given everything on this page, what is the quantity being ordered, and how confident am I in that read?" — which meant it could handle a scanned fax, a photographed packing slip, and a clean digital PDF from three different vendors without needing a separate template for each one.
2. Validation layer: Every extracted field was cross-checked against the company's own historical data before it was allowed anywhere near their live system — known vendor names and ID formats, typical order quantities per SKU per vendor, valid SKU lists, and expected price ranges. If a purchase order came in for a quantity ten times larger than that vendor had ever historically ordered, the system didn't just accept it. It flagged the anomaly automatically, the same instinct an experienced ops person would have, just applied consistently and instantly instead of only when someone happened to notice.
3. Human-in-the-loop review queue: Anything the system wasn't confident about, such as a low-confidence extraction, a flagged anomaly, or an unfamiliar vendor format, was routed into a simple review queue rather than pushed straight into the ERP. The specific field in question was highlighted, alongside the system's best-guess suggestion, so a reviewer could confirm or correct it in a few seconds. This was a deliberate design choice: the goal was never full unsupervised automation on day one. It was to remove the repetitive 95% of the work while keeping a human firmly in control of anything genuinely ambiguous.
How We Rolled It Out
Given the team's earned skepticism from the previous tool, we didn't launch this company-wide. We started with the two vendors sending the messiest, most error-prone documents, the ones the observation phase had identified as causing the most downstream damage, and ran the new system in parallel with the existing manual process for two weeks. Every extraction was compared against what a human had entered, and discrepancies were reviewed daily with the Ops Lead.
Once accuracy held up consistently over that trial window, we expanded to the rest of the highest-volume vendor group, then to the full vendor list over the following month. We also built a lightweight, plain-language dashboard so the Ops Lead could see — without needing to ask us — exactly what the system was processing automatically, what it was flagging for review and why, and how accuracy was trending week over week. No black box, and no need to take our word for how well it was working.
The Impact
Within six weeks of full rollout across all vendors:
- ~30 hours per week of manual data entry work eliminated across the operations team
- Error rate on processed documents dropped by more than 80%, since the majority of mistakes were now caught by the validation layer before ever reaching the ERP
- Three of the five employees previously doing full-time manual entry were reassigned to higher-value operations work — vendor relationship management and exception handling — with no layoffs
- Turnaround time from "document received" to "data live in the ERP" dropped from an average of over 4 hours to under 10 minutes
- During the following peak season, the team processed roughly the same document volume as the prior year's peak without falling behind at any point — no backlog, no delayed dispatch decisions caused by stale inventory data
Roughly six months after launch, the Ops Lead came back to us with a request we hadn't originally scoped: extend the same system to a second document category (customs paperwork) that hadn't been part of the initial engagement. That request came proactively, not because anything had broken — which, internally, is the signal we look for that a system has actually earned trust rather than just hit its initial metrics.
"We didn't just get faster. We got our team back. They're doing the work we actually hired them for now - managing vendors and catching real problems - not retyping numbers into a screen all day. And honestly, after the last tool we tried, I wasn't sure I'd trust a system like this again. This one earned it."
— Operations Lead
This case study reflects a real client engagement. The client's name and identifying details have been withheld in accordance with a confidentiality agreement; the Ops Lead's title is used in place of a name for the same reason.