Field service parts inventory staleness: AI dispatch first-time fix vs idle time 5 minutes

This guide gives a decision rule for AI dispatch when parts inventory may be stale.

It compares a five-minute refresh wait against the cost of a second truck roll.

How staleness gates AI dispatch

Treating a part-location record as fresh or stale is a state transition, not a label. A record is fresh when its last-verified timestamp falls inside the staleness horizon and stale when it is older. TanStack Query discussion #1685 defines staleTime as the duration until a query transitions from fresh to stale; copy that boundary by measuring elapsed time since verification rather than relying on a generic "recently checked" impression.

AI dispatch consumes three state variables before a technician is assigned: SKU-on-truck, SKU-at-depot, and depot ETA. A single stale boolean on any one of them changes the first-time-fix probability, because the assignment is made from a snapshot whose age may already exceed the horizon. The gate therefore starts with the record's timestamp, not with the technician's availability.

The 5-minute choice is a refresh budget for moving a stale record back to fresh, not a standing delay. It is justified only when re-verification can realistically finish inside that window and the stale flag is actually set; otherwise the dispatch should proceed on the current snapshot and verify parts en route. This keeps the wait tied to a state transition rather than to a routine pause.

Before assignment, run two checks: compare the record age with the staleness horizon, and compare the expected re-verification time with the 5-minute budget. If the record is fresh, dispatch without refresh. If it is stale but cannot be re-verified inside the budget, dispatch now and move verification into the route. If it is stale and can be re-verified inside the budget, refresh first.

Keep freshness separate from retention. In TanStack's terms, staleTime governs when data becomes stale, not when it is removed from cache. Apply the same separation to parts inventory: an old record may still be retained for audit or fallback, but it must not be treated as current for dispatch until its timestamp is refreshed.

Evidence you can verify, not borrow

This section maps each named source to exactly what it supports and what it does not, so an analogy from cached web data or a general technician definition is not treated as a measured input in a dispatch decision. Every number in the dispatch rule must come from your own service ledger, not from the sources listed here.

The TanStack Query discussion on staleTime supports the fresh/stale mechanism: fresh data is served without network, while stale data permits refresh. That is a useful boundary analogy for inventory records, but it does not supply field-service parts staleness rates, so it cannot by itself justify a dispatch wait.

Wikipedia's Technician entry supports only a general definition of a technician as a worker proficient in a relevant skill, with a practical understanding of the underlying principles. It supports the assumption that an assigned technician is a competent human verifier, but it does not list verified en-route inspection behaviors, an idle-cost benchmark, or a refresh window, so it cannot by itself justify a dispatch delay. Treat en-route parts verification capability as something your own service data must confirm.

ServiceNow Store shows GRC application downloads, not parts freshness. It is useful for application availability evidence, but it does not establish inventory staleness, technician verification behavior, or the cost of a second trip.

Use the table as a pre-dispatch check: before a number enters the rule, name the source that measured it. If no source measures it, label it as an assumption and test it against your own service data rather than treating borrowed evidence as proof.

That separation is the practical value of convergence: it shows where the evidence is strong enough to reuse and where the organization must collect its own field-service measurements before changing dispatch behavior.

Wait, dispatch now, or hybrid?

The dispatch choice is a cost comparison, not a preference. Dispatch immediately when p_stale × C_second_trip is less than 5 × C_idle_min; wait up to 5 minutes when that inequality reverses. The first option protects technician time; the second protects against a second truck roll when stale parts are likely to matter. Read the inequality as expected avoidable cost versus idle cost, not as a parts-accuracy score.

Hybrid dispatch with en-route verification is the winner when refresh latency is no more than 5 minutes and the technician has pre-arrival travel time. In that case, dispatch now, push the parts task to the technician, and refresh inventory in parallel; the travel window absorbs much of the refresh work instead of adding idle time at the depot. The technician can still act on the refreshed record before arrival if it completes during travel.

If refresh latency exceeds 5 minutes or there is no travel buffer, do not default to hybrid. Use the break-even comparison to choose between immediate dispatch and a full wait: dispatch now when the expected second-trip cost is below the idle cost of waiting, and wait when it is above. This keeps the decision tied to the same two costs rather than to a fixed habit.

Before selecting hybrid, verify the two inputs that make it valid: measured refresh latency and actual pre-arrival travel time. If either is unmeasured, treat it as unknown and fall back to the cost comparison rather than assuming the buffer exists. Also confirm that the parts task can be pushed to the technician without blocking safety-critical pre-arrival checks.

A useful operating check is to log which option was chosen and whether a second trip occurred. Over time, that record shows whether the 5-minute threshold and travel buffer are calibrated to your routes, but it does not replace the cost comparison for an individual dispatch.

Break-even costs and edge limits

C_idle_min is the fully loaded technician labor cost plus any SLA downtime penalty for one idle minute; C_second_trip is the avoidable cost of a second truck roll, including the roll itself, part write-off, and customer credit. Both are operating costs, so pull the rates from finance and the asset, warranty, and service-history values from CMMS rather than from this guide.

The break-even probability is p_stale* = (5 × C_idle_min) / C_second_trip. Compare the estimated probability that staleness causes a second truck roll with that threshold: wait up to five minutes only when p_stale is greater than p_stale*; dispatch immediately when it is equal to or less than p_stale*. The five minutes is the maximum refresh window, not a target, and the comparison uses the same cost basis on both sides.

If p_stale* is at or above 1, no realistic estimate justifies the wait; dispatch now and verify parts en route. If it is very small, even modest staleness risk can justify a short refresh, but only inside the limits below.

The formula assumes the refresh can actually complete inside five minutes and that the cost inputs are current. If either assumption fails, treat the case as dispatch-now.

When a limit applies, dispatch immediately and move verification into the route: confirm the part at the truck, at the site, or through the CMMS record before installation. That keeps the decision rule intact while preventing a stale record from becoming a second trip.

Worked Example: Run the Numbers

Illustration only: an AI dispatcher reviews a parts record for a technician's field job. The record's last-verified timestamp is older than the staleness horizon, so the decision is whether to spend up to five minutes refreshing inventory or dispatch now. No calendar date, vendor, or rate is assumed; each input must come from your own service ledger.

The inputs are p_stale, the estimated probability that staleness causes a second truck roll; C_second_trip, the avoidable cost of that second trip; and C_idle_min, the cost of one minute of technician idle time. No vendor price, fee, or rate is assumed; each cost must come from your own service ledger.

Copy the worksheet into the dispatch console as a pre-dispatch check, not as a permanent price list. Replace the illustrative $2.00 and $300.00 with your own measured idle and trip costs, keep the probability source named, and record which branch was taken so the rule can be audited against actual second trips.

If the probability source is missing or stale itself, treat that as a data-quality exception rather than a dispatch decision: do not invent a probability, and do not let the worksheet become a reason to wait by default.

What to do next

Frequently Asked Questions

When should dispatch wait up to five minutes for a parts inventory refresh?

Wait up to 5 minutes only if p_stale × C_second_trip > 5 × C_idle_min.

What should dispatch do if p_stale × C_second_trip is not greater than 5 × C_idle_min?

If p_stale × C_second_trip ≤ 5 × C_idle_min, do not wait; check parts while traveling.

What does StaleTime mark?

StaleTime marks when cached inventory data becomes stale.

How is a part-location record considered fresh?

A record is fresh when its last-verified timestamp falls inside the staleness horizon.

What does TanStack Query discussion #1685 define staleTime as?

TanStack Query discussion #1685 defines staleTime as the duration until a query transitions from fresh to stale.

What does the guide compare a five-minute refresh wait against?

It compares a five-minute refresh wait against the cost of a second truck roll.

Quick answers

Also worth reading: Warranty checks for field service: 28-second verify vs blind dispatch: Warranty checks for field service: · Work order closeout with voice: 18 to 3-4.2 minutes, dispatch or skip: Work order closeout with voice: · The AI dispatch metrics that actually move the needle: AI dispatch metrics that actually