Service Document Intake for an Equipment Dealer

This is a representative case study based on the kind of engagement we run for local equipment dealers and service-heavy businesses. Specifics are anonymized; the architecture, approach, and outcome shape are real.

The Problem

An equipment dealer with a busy service department was drowning in paperwork. Every service ticket, warranty claim, and parts order came in as a PDF, a faxed scan, an emailed photo, or — sometimes — handwritten on a paper form scanned by the front desk.

Someone on the team spent two to three hours every day typing this into the dealer's management system. The work was important — incorrect data entry meant warranty denials, mis-shipped parts, and unhappy customers — but it was also exactly the kind of work that humans get tired of doing.

The team wasn't going to grow. The paperwork volume was. We needed to take this off the human's plate without losing the accuracy.

The Approach

This was a Custom Build engagement — bigger scope than a single sprint because we were touching three different document types and three different downstream systems.

• Weeks 1–2: Discovery. Inventory every document type. Pull a sample of 200 representative documents (good scans, bad scans, handwritten, multi-page, weird edge cases).
• Weeks 3–5: Build the document classifier and extraction pipeline. Different document types route to different extractors. Confidence thresholds determine what's auto-posted vs. what's queued for human review.
• Weeks 6–7: Build the review UI. The team sees a queue of low-confidence extractions side-by-side with the original document and can correct, approve, or reject. Their corrections feed back into the model's confidence calibration.
• Week 8: Launch + parallel-run mode for the first week (humans review every extraction even if the AI was confident). After confidence is established, the system auto-posts the high-confidence cases.

What It Does

• Accepts documents via email, upload, or fax-to-email gateway.
• Classifies the document type (service ticket, warranty claim, parts order, returns authorization).
• Extracts the structured fields for that document type (customer info, equipment serial number, parts list, labor codes, warranty terms, etc.).
• Posts high-confidence extractions directly into the dealer management system.
• Queues low-confidence extractions for human review with the original document and the AI's draft side-by-side.
• Learns from corrections — every human edit improves the next extraction.

Outcome

Three months after launch:

• Daily document processing time down from ~3 hours to ~25 minutes — humans only review the queue, they don't type from scratch.
• The two-week paperwork backlog cleared within two weeks of launch.
• Warranty denial rate down modestly — partly because data entry errors went down, partly because the AI catches missing fields the human reviewer used to gloss over.
• The team member who used to do this work was redeployed to higher-value customer follow-up work she wanted to do anyway.

What We Handed Over

• The running production system on the dealer's accounts (Railway, Neon).
• Source code in their GitHub.
• A simple admin UI for adding new document types or adjusting confidence thresholds (no developer required).
• Runbook for handling edge cases: bad scans, unrecognized document types, system failures.
• Three hands-on training sessions: one with the office manager, one with the team member running the review queue, one with IT for system administration.

Tech Used

• Claude for document classification and field extraction.
• Python for the document processing pipeline (PDF/image handling, OCR fallback for low-quality scans).
• Next.js for the review UI and admin panel.
• Postgres on Neon for the document queue, audit log, and learned corrections.
• Railway for hosting.

On Graduation

This was a bigger project than our typical sprint, and we were upfront about the implication: the team owning it needs more than one person. The dealer assigned a primary owner (the office manager) and a backup (their bookkeeper). Both attended every training session. We did a check-in 30 days post-launch and another at 90 days, then sunset the engagement.

They've since brought us back twice — once to add a fourth document type, once for an unrelated automation. Exactly the working relationship we want.