Catalog Scanner
Building a behavior bridge between physical catalogs and digital ordering.
PROBLEM_ID
ERR_ADOPTION_LOW
When I joined Agrictools, app adoption among dealers was low — and not because the app didn't work. It did. The problem was that it asked dealers to change a workflow they'd spent years getting comfortable with.
The existing flow looked like this: a dealer would open a physical catalog, find the parts they needed, write down SKU codes or item names on paper or in a WhatsApp message, send that to a sales rep, and wait. Prices only came back after the sales order was created. If something needed to change — a quantity, a swap, an addition — another call, another wait.
Technically, the app allowed self-serve ordering. In practice, typing B2B line-item lists SKU by SKU into a mobile form was painful enough that dealers just didn't. A full order could take 30 minutes. Most chose the phone call instead.
Talking to dealers and shadowing them made one thing obvious:
Core Insight
They weren't avoiding the app because it was unfamiliar — they were avoiding the data entry.
The catalog and the list? Those they trusted. That part of the workflow wasn't broken. What frustrated them was the slow, manual step of turning that list into a live order with real prices attached. So the question shifted from how do we get them to use the app to:
"How do we remove the part they hate while keeping the part they trust?"
Instead of building a better search bar or a faster form, I designed a bridge. Let them keep their catalog. Let them keep writing their list. Just point a camera at it.
Proposed Architecture Flow
Physical Catalog
Dealer writes order list
OCR Scanner
Capture & Extract SKUs
Catalog API
Live Matching & Pricing
The idea: take a photo of a handwritten order list or an open catalog page, have the app detect the SKUs, match them to the live catalog, and surface real prices immediately — skipping every step that required a sales rep. This wasn't about replacing their behavior. It was about making the last mile — list to order — nearly instant.
I built the first prototype myself before involving the broader team. I integrated an off-the-shelf OCR model, wired it to a basic matching layer against our catalog API, and started testing it on real dealer inputs — photos of handwritten lists, catalog pages, screenshots, and other messy real-world samples.
Early accuracy was poor due to a few compounding issues:
Lighting & Reflections
Physical catalogs under different lighting conditions produced inconsistent OCR output. I improved this through image pre-processing before the OCR pass.
The 0 / O Classification Error
Our SKU format uses a lot of zeros and never uses the letter O. The OCR model didn't know that. It would confidently read a 0 as an O, breaking the catalog lookup entirely.
Classification Resolution Protocol
O in a position where only a digit made sense got normalized to 0.After iterating on real samples until match rates felt reliable, I brought in the rest of the team to ship the polished version — a fine-tuned model replacing the off-the-shelf one, and an extended feature: if the handwritten list had quantities next to the SKUs, those got pre-filled too.
From a dealer's point of view, the flow collapsed to four streamlined steps:
Keep your existing list or catalog open
No behavior change required before opening the app.
Open the scanner, take a photo
Works on handwritten lists, printed catalogs, or screenshots.
Review matched SKUs with live prices
Set quantities and add items to cart or a saved list as you go.
Review and place the order
One final check, then done.
State Comparison Matrix
REF: METRIC_01Manual Workflow
Building an order manually through a sales rep.
Scanner Workflow
Point, scan, match, and order instantly.
Order creation time reduced from ~30 mins to 3-5 mins.
Resistant dealers successfully bridged into self-serve digital workflows.
Internal sales processed significantly more orders without adding headcount.
Overcame App Resistance
Dealers willing to try the scanner because it didn't ask them to change how they worked — it just made the part they already did faster. It acted as a low-resistance entry point.
Internal Efficiency
The internal sales team started using the same scanner flow to process dealer-submitted WhatsApp lists faster.
Three Core Pillars
Behavior-first framing: The feature was designed around what dealers already did, not what we wanted them to do. That reframe — from "teach them the app" to "meet them with the catalog" — was the real product decision. Everything else was execution.
Prototype-first process: Building it myself first compressed the feedback loop. The 0/O issue wouldn't have been obvious in a spec — it only surfaced when running real dealer photos through a real OCR pipeline. Prototyping is where unknown-unknowns live.
Targeted technical depth: The fix for the 0/O problem wasn't sophisticated — it was a simple normalization rule. But finding it required understanding both the failure mode (OCR character confusion) and the domain (our SKU structure). That combination is where product and engineering judgment overlap.
This project is a good example of what I think product work should look like at early-stage companies: tight feedback loops, willingness to get hands dirty in the prototype, and a bias toward understanding actual behavior before designing for it.
The scanner feature didn't require a large team or a long roadmap. It required the right framing, a fast prototype, and enough technical understanding to debug the right problem.