Reese is the COO of Mercantile Coffee, a specialty roaster and distributor we'd been onboarding across four warehouses in Oregon and Washington. They roast about 380 tons of coffee a year. They were one of our first multi-site customers. And by their sixth week with Nautilus, they were ready to send us packing.

This is a case study, but not the kind that ends with a 70% improvement and a photogenic quote. It ends fine. We're still working together. But the path from week six to "still working together" wasn't pretty, and we think it's more useful to walk through what went wrong than to pretend the rollout was clean.

What Mercantile is

Specialty coffee distribution looks deceptively simple. The product is a bag of beans. You receive bags from origin, you roast them (in Mercantile's case, in-house at two of their four facilities), and you ship them out. About 1,900 active SKUs. Maybe 80% of inventory turns inside 14 days. Most of their orders are wholesale to cafés and grocery, with a smaller direct-to-consumer line on Shopify.

What complicates this is that coffee changes state. Green beans come in. They're stored. They get roasted, which produces a new SKU. They're packaged, which produces another SKU. The packaged product goes out within a few weeks because beyond that it's stale and unsellable. Some lots get blended. Lot tracking is non-negotiable for traceability and recall.

Their stack before us: a custom-built inventory tool one of their developers wrote in 2019 that read and wrote to a shared Access database, with a brittle bridge to QuickBooks. They'd been trying to replace it for two years.

Week one through three: cautiously fine

We did a phased rollout, starting at their smallest warehouse. (This is what we recommend; the alternative is a big-bang cutover and we've never seen one go well.) The first warehouse, in Eugene, handles their direct-to-consumer side and is the simplest of the four. Fewer SKUs, no roasting, no blends.

Eugene came up clean. Three days of double-entry parallel operation, then live. Their team adjusted quickly. Their warehouse manager, who'd been pushing for a system upgrade for years, was happy.

Then we moved to Portland.

Week four: the first cracks

Portland is one of the roasting facilities. It has about 700 SKUs across green beans, roasted, packaged, and blends. Three things broke in week four.

The first was the barcode situation. Mercantile had been printing their own labels on a Brother thermal printer using a layout that hadn't been updated in years. The labels included an internal Mercantile SKU as a Code 39 barcode. When they brought in coffee from origin, the origin supplier's labels were already present on the bags, in Code 128, encoding their own SKU. Both barcodes coexisted on the same physical bag. Our scanner was reading whichever one its camera locked onto first, which meant some receipts were getting logged against the wrong SKU.

The second was the humidity. Portland's green coffee storage is climate-controlled in a way that produces persistent condensation on phone and scanner lenses. After about ten minutes on the floor, the scanners couldn't focus. Their team had a workaround for this (they kept a microfiber cloth in every pocket), but our app didn't know about the workaround, so when scans failed it would queue an "unscannable item" alert that piled up faster than anyone could clear it.

The third was that their procurement team was on a week-long offsite. Procurement runs the receiving process at Portland. The two people who came up cold to receiving during that week had not been part of the training sessions. They learned by doing, and the doing produced about 140 misallocated receipts that someone, eventually us, would have to unwind.

Week six: the conversation

Reese is direct. The Wind Down call was 22 minutes long. She had a list. The list was specific. Several of the points were fair.

What landed hardest was a phrase she used early: "Your software does not understand coffee." She was right. We had spent enormous effort building a flexible WMS that could handle anything from auto parts to electronics to apparel. We had not spent any effort thinking about what it means when a SKU literally cannot exist for more than three weeks before its value drops by half. We had no good answer for state changes (green → roast → packaged) other than treating each as a separate SKU with a separate receipt event, which is how you get 140 misallocated entries.

We did the only thing we could think to do: we asked for another week before they made a decision, and we put two engineers on-site at Portland the next morning.

What we changed

In the week that followed, we shipped four things, most of which came out of conversations on Mercantile's floor.

We added multi-barcode disambiguation. If a single physical item is observed to have two barcodes (we detect this when a scan resolves to two different SKUs in our database, both matching their origin context), we now ask the user once which to treat as canonical. This was a half-day fix. It should have been the default behavior from launch. We'd just never encountered a customer with the layered-barcode pattern before.

We added state transitions for stateful SKUs. Instead of treating roast and package as separate inventory events with no link, we introduced a transformation action: scan input SKU, scan output SKU, record a lot. This is much closer to how real food and beverage operations think about their inventory and we ought to have built it sooner.

We added a weekly drift report that flags receiving events with timestamps clustered within their first hour of access. If a new operator is being trained on receiving, almost every one of their first hour's scans will need review. Flagging the cluster makes that obvious to a supervisor.

And we wrote training material specific to coffee operations, including a checklist of equipment quirks (lens condensation, ladder-pick patterns at high-volume green storage, the way light spills change inside the bays at sunset) for their team to extend.

None of these were heroic engineering. The four together took eight working days. The reason they hadn't existed was that we'd never confronted the workflows that required them. It is, in retrospect, embarrassing that the multi-barcode case wasn't part of our v1.

Six months later

Mercantile is now using Nautilus across all four facilities, with the Tacoma site coming up two months ago. Inventory accuracy is at 99.4% as of their last quarterly count, up from a self-reported 94-ish before we arrived. Roast batch traceability went from spreadsheet-by-hand to a query that takes 90 milliseconds.

More important than any number: they trust the software now. Reese still sends pointed emails when something is wrong. She also sent us a five-pound bag of their Ethiopia Yirgacheffe at Christmas, with a note that read, "Don't get cocky."

What we kept from this

Three things, mostly procedural.

We now scope rollouts by product type, not by warehouse count. A food and beverage customer with two warehouses is harder than an auto-parts customer with five. Our onboarding now begins with a product-type interview that includes seventeen specific questions about state changes, lot tracking, expiration, and label layout.

We bring an engineer on-site to the second warehouse of any multi-site rollout, not the first. The first warehouse is always the simplest and always goes well; the second is where the customer's actual operational complexity shows up.

And we hold a Wind Down rehearsal with every multi-site customer at the four-week mark. It is exactly what it sounds like. We explicitly ask them what would have to be true for them to fire us, and we work backwards from there. This is uncomfortable to do. We have learned more in those conversations than in any QBR.

PublishedApr 04, 2026

CategoryCase Study

Read time9 min