AI Process Automation Inside a $420M Agricultural Equipment Distributor: Warranty, Parts Kitting, and Dealer Order Routing
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
The Distributor and What Was Actually Broken
Our client is a $420M regional Agricultural Equipment Distributor with 24 dealer locations across seven Midwestern states. They carry tractors, combines, hay tools, planters, tillage, and full aftermarket parts programs for four major OEMs. About 640 employees. Their revenue mix runs roughly 58% equipment sales, 27% parts, 15% service.
None of this was a mystery to their leadership. They had been quoted twice by warranty automation vendors, once by a WMS vendor, and once by an OEM-branded dealer management overlay. Each quote was six figures for one workflow. They wanted a single AI process automation strategy across all three with one architecture and one internal owner, not three point tools aging separately.
What AI Process Automation Actually Means in This Context
We use the phrase AI process automation with a specific meaning. It is not RPA. It is not agentic autonomy across arbitrary workflows. It is the discipline of taking a process that already has structure, an owner, a data trail, and a defined outcome, then automating the deterministic steps with software and reserving the AI layer for the specific decisions where language understanding, retrieval, or classification actually matters.
For this client, that broke the work into a clear pattern per process. Deterministic extraction, retrieval, and routing on the outside. LLM-driven judgment only at the exact points where a human was previously reading unstructured text and matching it against policy or catalog data. That framing kept scope tight, kept auditability high, and kept the client's compliance and warranty finance teams comfortable throughout the build.
The 18-Week Sequence
Six phases across 18 weeks. Two workstreams in parallel after phase two, with dedicated client-side leads on each.
Weeks 1 through 3: Discovery and data foundation. Two-day on-site discovery per process. Shadowed the warranty analyst through 27 claims. Sat with both service writers through a full week of parts kits for the top 40 jobs. Rode along with the dispatcher for two days of order routing. Documented every system involved: their Dealer Management System, an OEM warranty portal per manufacturer, their parts catalog master, their WMS, and a legacy freight tender platform. Extracted 18 months of historical data into an Azure SQL staging environment.
Weeks 4 through 7: Warranty automation build. The heaviest AI process automation lift. Warranty claim adjudication starts with a scanned or emailed claim form (52% arrived as PDF, 31% as email attachments, 17% direct portal exports). We built a document intake pipeline in Azure Document Intelligence with a custom model trained on 640 historical claims. The classifier tagged claim type, equipment serial, dealer of origin, and parts involved. A retrieval layer pulled the applicable OEM warranty policy for that serial's coverage window. The LLM step, running against GPT-4o with a strict tool-use pattern, drafted the adjudication recommendation and cited the policy clause. Every claim above a $2,500 threshold routed to the analyst for review. Everything at or below auto-drafted, and the analyst approved or corrected in a Power App queue.
Weeks 8 through 11: Parts kitting build. The two service writers had 40 kits they rebuilt every season. Each kit was a combination of a job code, an equipment family, a labor time standard, and 12 to 38 parts with substitution rules. We migrated their spreadsheets into a governed table in Azure SQL and built a Power App interface for kit review. The AI layer sat behind the interface. When a service writer creates a work order in the DMS, the automation runs the job code and equipment against the kit master, applies substitution rules against current on-hand inventory, and produces a kit proposal with each substitution flagged and explained. The service writer approves or edits. The kit posts back to the DMS.
Weeks 12 through 15: Dealer order routing build. The dispatcher was making routing calls off memory and a phone. We built an order routing engine in Power Automate wired to the WMS, freight tender platform, and a small transfer-history warehouse. Deterministic rules drive location selection: on-hand availability, stock aging (rotating dead inventory), destination cost, and lane fit. The AI layer handles freight tender narrative parsing when carriers reply with counter-offers or cross-references, and it flags anomalous patterns for the dispatcher. Anomaly detection runs against 24 months of transfer history.
Weeks 16 through 17: Adoption and change management. We ran three role-specific training cohorts. Warranty finance and the primary analyst got a claim adjudication walkthrough with the audit trail exposed. Service writers got a parts kitting walkthrough with the DMS integration surfaced. The dispatcher and two backup coordinators got a routing walkthrough with the anomaly queue. All three cohorts got the same governance training on how to change rules, retrain classifiers, and file exception reports.
Week 18: Handoff and steering. Weekly steering with the COO and CFO through the whole engagement. Final week transitioned to a monthly cadence and named the operations analyst as the internal AI process automation owner. She left the engagement with the roadmap, the runbook, and the audit reports that finance had already signed off on.
The Architecture We Left Behind
Four layers, each with owners and audit paths. This is the same architectural pattern we run on most AI process automation engagements, adapted to the client's Microsoft-heavy stack.
Data platform layer. Azure SQL Managed Instance holds the governed masters (parts, kits, dealers, serials, warranty policies) and the historical claim, kit, and routing data. Azure Data Factory syncs from the DMS, WMS, OEM portals, and freight tender platform nightly. About 720 governed fields across 41 entities. Owned by the IT director.
Retrieval and document intelligence layer. Azure Document Intelligence for claim and freight document extraction. Azure AI Search for OEM warranty policies, parts substitution rules, and dealer contract terms. Every retrieval result carries provenance and links back to the source document. Owned by the operations analyst.
Automation and orchestration layer. Power Automate for the deterministic workflow steps. Three flows: claim intake, kit generation on DMS work-order creation, and order-routing decision. All flows are instrumented with run history exported to the data platform for closed-loop review. Owned jointly by the operations analyst and a citizen developer on the service team.
AI and application layer. GPT-4o for the language-heavy decisions (adjudication drafting, substitution reasoning, freight tender parsing). Three Power Apps for human-in-the-loop review: warranty queue, kit review, routing anomaly review. Every AI call is logged with prompt, tool calls, retrieved documents, and outcome. Owned by the operations analyst.
What We Chose Not to Automate
Three items we explicitly refused, on principle.
No fully automated warranty payout. Claims under $2,500 auto-draft, but the analyst still hits approve. We do not authorize payouts without a human in the loop, and we told the CFO that on day one. The point of the AI process automation build is speed and consistency, not blind approval.
No AI-driven parts substitution without explanation. Every substitution surfaces the rule that fired and the substitution history. Service writers reject substitutions all the time, sometimes for reasons that never make it into a rule, and the interface has to make that easy. If the AI process automation makes people afraid to override it, we have built the wrong thing.
No routing autonomy across OEM contract boundaries. OEM equipment orders route through OEM-approved paths only. We built the deterministic rule set to respect those boundaries and refused to let the AI layer propose off-contract routes even if they looked cheaper.
What Changed at 90 Days Post-Handoff
Numbers below are measured 90 days after the phase-six handoff, against a pre-engagement baseline documented in phase-one discovery.
Warranty claim cycle time: 4.2 business days on average pre-engagement, 1.1 business days at 90 days post. Analyst hours dropped from 34 to 38 weekly to about 12 to 15 weekly.
Warranty claim first-pass approval rate on OEM submissions: 71% pre-engagement, 86% post. Cited policy clauses in the AI-drafted narrative moved the needle with OEM claims analysts.
Parts kit turnaround: 45 to 60 minutes to build a kit manually pre-engagement, 6 to 10 minutes to review and post an AI-generated kit. Kit accuracy on planting and harvest ramp weeks improved measurably, with roughly 35 to 45% fewer parts-not-in-kit callbacks.
Dealer order routing: dispatcher time on routine routing dropped from about 22 hours weekly to about 8 hours weekly. Anomaly queue caught 14 stale-inventory rotations that would not have happened manually.
Total engagement cost: fixed hourly billing across 18 weeks. All-in labor came in at ~0.09% of annual revenue.
Internal ownership at 90 days: all three role cohorts still operating the systems. Operations analyst filed two change requests through the governance process and shipped one classifier retrain without external help.
When to Run an AI Process Automation Build, and When Not To
AI process automation is the right frame when three conditions are true. The process has enough volume that even a small per-transaction time saving compounds into real hours. The decisions inside the process are structured enough that a human can articulate the rules, or the exceptions to the rules. And the client has an operations owner who can carry the systems forward after the build.
If any of those three are missing, the answer is not AI. The answer is either process design, hiring, or a smaller pilot. We told this Agricultural Equipment Distributor exactly that in discovery. Their warranty, parts, and routing operations cleared all three tests, and the AI process automation build compounded across all three because we ran it as one architecture rather than three products bolted on. That is the difference we come back to on every engagement, and the one we will keep making the case for.
Comments