The Part Was in the Warehouse

Luis is at a restaurant in Plano with a rooftop unit that stopped cooling on the hottest afternoon of the year. He has been on site for thirty-five minutes. The diagnosis took eight of them: a failed condenser fan motor, a common failure on that model at around nine years old.

He does not have the motor. He has two others, for different units, which he stocked in April because that was what he ran out of in March.

He calls dispatch. The part is in the warehouse, forty miles away, and it is now nearly three o'clock. The next available slot for a return visit is Friday morning. The restaurant has a dining room at 31 degrees and a Saturday booking sheet that is full.

The information needed to bring that motor was all present before Luis left the yard at seven that morning. The equipment record held the make, the model and the install date. The service history showed two prior visits to that unit. The customer's phone call, transcribed by the answering service, said the fan was making a noise and then stopped. The firm has replaced eleven condenser fan motors on that exact model in the past three years, all between eight and ten years of age.

Nothing joined those four facts together, so the van was loaded on the basis of what Luis remembered running short of five months earlier.

This is, when stated precisely, a parts distribution system whose forecasting model is twenty-two separate memories, whose inventory record is the back of each van, and whose reorder trigger is a technician standing in front of a broken unit forty miles from the warehouse. Luis did not decide to arrive unprepared. He loaded the van from memory because nobody had ever given him anything else to load it from.

Commercial HVAC service and maintenance, Dallas, Texas. Thirty-eight employees: 22 field technicians, 4 dispatchers, 5 office and accounts, 3 sales, 4 management. $9.4M annual revenue, split roughly 60% planned maintenance contracts and 40% reactive service calls. Customers are restaurants, small retail chains, medical practices and light industrial units across the Dallas-Fort Worth area.

Service calls last year: 4,800. First-time fix rate: 68%. The industry benchmark for a well-run commercial operation sits between 75% and 85%, and the firm has known its number is low for three years.

Return visits: approximately 1,536. Of those, the service manager estimates 61% were parts-related, which is 938 trips that happened because a technician arrived without something. The remainder were access problems, additional faults found, or work that genuinely needed two visits.

Cost per return trip: 1.5 hours of drive time and roughly an hour on site, at a loaded technician cost of $68 per hour, plus vehicle running costs, plus the billable slot that trip displaced. About $310 all in. Across 938 trips that is $290,780 a year spent driving to jobs the firm had already visited.

Expedited freight adds to it. When a technician discovers a part is needed and the customer is a restaurant in July, somebody pays for overnight shipping. Roughly 40% of parts-related returns involve an expedite premium averaging $85: another $31,900.

The vans hold an estimated $183,000 of parts between them. That figure is an estimate because nobody has counted. There is no van inventory system, no periodic stock take, and no standard kit. Each technician stocks what they personally ran short of, which means 22 vans carry 22 different interpretations of what is likely to break.

Two contracts were lost last year at renewal, both citing responsiveness. Neither customer mentioned parts. They mentioned waiting until Friday.

The pattern behind all of it: a firm that holds nine years of repair history on every model it services, and loads its vans from memory.

Four stages. The core insight: this is a prediction problem the firm already has the data to solve. Nine years of service records show which parts fail on which models at which age, in which season. The prediction does not need to be perfect. It needs to be better than one technician's recollection of March.

Stage 1: Enrich the job at booking

Triggered when a service call is created in the field service management system. The agent attaches the equipment record: make, model, serial, install date, refrigerant type, warranty status, and every prior repair on that specific unit.

It also attaches the customer's own description of the fault, whether that arrived as a transcribed phone call, a portal submission or an email. The words a customer uses about a noise are diagnostic information, and they are currently read once by a dispatcher and never again.

Stage 2: Predict the part

Claude Sonnet reads the symptom description against the equipment record and the firm's own repair history for that model and age band. It returns a ranked list of likely parts with a confidence score for each.

The history is the asset here. A generic model would guess at HVAC failures in the abstract. This one is reading what actually failed, on these models, in this climate, in the hands of these technicians.

Below a confidence threshold the agent predicts nothing and marks the job as diagnostic. A low-confidence guess that sends a technician out with the wrong part is worse than no prediction, because it produces the same second visit with more steps.

Stage 3: Check the van, before departure

The predicted parts are checked against the assigned technician's van stock. Part present: dispatch is told, nothing else happens. Part in the warehouse: a pull ticket goes to the parts desk the evening before or first thing, so it is waiting when the technician arrives. Part nowhere in the business: it is ordered with a real lead time and the customer is told at booking rather than discovered at 2:40pm.

This stage depends on knowing what is on the vans, which the firm currently does not. That is the hard prerequisite and there is no way around it. It means a one-off stock take across 22 vehicles, then a barcode or app-based check-out whenever a part is consumed. Roughly two days of work and a change in technician habit, and without it the rest of the design cannot function.

Stage 4: Learn, and restock by season

Every completed job records the predicted part against the part actually used. That comparison is the accuracy measure, and it feeds back into the prediction.

It also produces the weekly restock recommendation: given the jobs booked for next week and the failure patterns for this time of year, here is what should be on each van. Condenser fan motors in July, heat exchangers and igniters in January. The standard kit stops being a matter of individual memory and becomes a decision the parts desk makes with evidence.

The van inventory is the prerequisite, and it is the part firms skip. Everything downstream compares against what is on the van, so an inventory that exists only approximately produces predictions that are confidently wrong. This is a two-day stock take and a habit change, and it is unglamorous next to the prediction model. It is also the component without which nothing else works.

Predict conservatively. The temptation is to maximise the prediction rate, because a prediction feels like value. A wrong part on the van costs a second visit and a restocking charge, and it erodes the technicians' trust in the system within about three weeks. Set the confidence threshold high at go-live and lower it once the accuracy data justifies it.

The technician still diagnoses. The agent's job ends when the van is loaded. Nothing in this design tells Luis what is wrong with the unit; it tells the parts desk what is likely to be needed. Presenting a prediction as a diagnosis is how you get a technician replacing a fan motor on a unit with a control board fault.

The Dave pattern recurs. Dave in Chicago held warranty dates on 340 units in a spreadsheet and paid $4,200 for a covered repair. Same structure: the firm owned the record, the record was right, and nothing brought it to the moment of the decision.

Recommended stack: n8n for orchestration. ServiceTitan, Housecall Pro or FieldEdge for job records, equipment history and dispatch (all expose APIs; where none exists, a nightly export works). Claude Sonnet for symptom-to-part prediction, Haiku for classifying inbound call transcripts. A barcode app or simple mobile form for van stock check-out. Postgres for the van inventory, prediction log and accuracy store.

Step 1: Count the vans (Days 1-2). Physical stock take across all 22 vehicles. Build the van inventory table: technician, part number, quantity, last counted. This is unglamorous and it is the foundation. Do it before writing any code, because it will also tell you how bad the problem is.

Step 2: Build the history dataset (Days 2-5). Export nine years of completed jobs: equipment model, age at time of repair, symptom text, parts used, season. Clean it. This is the training context for the prediction and its quality sets the ceiling on everything. Expect to find that symptom text is missing on older records; use what exists.

Step 3: Build job enrichment (Days 5-7). Trigger on job creation. Pull equipment record, prior repairs, warranty status and the customer's fault description. Transcribe voice calls if they are not already text. Store as an enriched job record.

Step 4: Build the prediction (Days 7-11). Claude Sonnet reads the enriched record against the model-specific history. Returns ranked parts with confidence. Test against 200 historical jobs where the part used is known, and measure precision before going near a live van. Target 70% or better on high-confidence predictions.

Step 5: Build the van check and pull ticket (Days 11-14). Compare predictions to van stock. Generate pull tickets to the parts desk with the job, the technician and the part. Build the check-out flow so consumed parts decrement the van record.

Step 6: Pilot on four vans (Days 15-45). Four technicians, six weeks. Measure first-time fix rate against the other eighteen. Measure prediction accuracy. Fix the confidence threshold on real data. Roll out only when the pilot group's fix rate is clearly higher.

Estimated build time: 14 to 16 days for a competent n8n developer, plus the two-day stock take. Five to six weeks if learning alongside. The history cleaning in step 2 is where overruns happen.

Monthly running costs:

Claude API detail: prediction across roughly 400 service calls a month, each reading a symptom description plus model history, costs about $44. Call transcript classification via Haiku, about $3. The volume is the driver here rather than the complexity of any single call.

Build costs if hiring: 14 to 16 days at $450 to $650 per day = $6,300 to $10,400, plus two days of stock take at internal cost. Self-built: $0 plus roughly three days including the count.

Year-one total: $7,428 to $12,620 with a developer, or $1,128 to $2,220 self-built. Compared against $290,780 in return visits and $31,900 in expedited freight. Moving the first-time fix rate from 68% to 80% removes roughly 460 return trips, worth about $142,600 a year.

The van inventory drifts within a month. Technicians consume parts under time pressure and forget to scan. The record degrades, the predictions start failing, and the technicians conclude the system does not work. Build the check-out into the job completion step so it is one action rather than two, and audit two vans a week against the record.

The prediction is confidently wrong on an unusual model. Rare equipment has thin history, so the model has little to reason from. Weight confidence by how many prior repairs exist on that model, and predict nothing below a floor of prior instances.

Technicians stop diagnosing. The genuine risk. If a prediction arrives before the technician has looked at the unit, some will fit the predicted part first and think second. Present predictions to the parts desk and dispatch, not to the technician's job sheet.

Stocking to the prediction inflates van inventory. The obvious response to a prediction is to carry everything. That converts a fix-rate problem into a working capital problem across 22 vehicles. Cap van value per vehicle and let the weekly recommendation work within it.

Seasonal patterns mislead in an unusual year. A mild July or an early cold snap will make the seasonal kit wrong. Use rolling recent data alongside seasonal history and re-run the kit recommendation weekly rather than quarterly.

Refrigerant regulation changes what can be stocked. Phase-downs affect which parts and refrigerants are legal to hold and sell, and rules differ by state and change over time. Verify current EPA requirements and any state-level rules before building a standard kit around a refrigerant type, and check again annually.

If your business sends people to fix things and stocks their vehicles from memory, your first-time fix rate is a measure of how well your technicians happen to remember last quarter.

Luis is a good technician. He diagnosed the fault in eight minutes and he was right. None of that helped, because the van had been loaded five months earlier by a person guessing, and the firm's nine years of records on that exact model sat in a database nobody had asked.

The agent does not diagnose anything. Luis still opens the unit, reads the fault and decides what is actually wrong. The agent reads what has broken before on that model at that age in that season, checks whether the part is already on his van, and tells the parts desk while there is still time to do something about it.

One visit or two. Same fault. Same technician. Same part. Different Tuesday.

This is Blueprint #57 in the AdAI series. Every week we publish the full architecture of a real AI agent design: the bottleneck, the build guide, and the costs. Free to read. Free to build from.

Want the next one? Subscribe to AdAI News. New blueprint every week.

by AK
for the AdAI Ed. Team