Shipping Exception Handling at an Industrial Parts Distributor
An example project: an industrial parts distributor resolves about 250 shipping and order exceptions a day with an agent that looks up the ERP, warehouse and carrier systems and drafts the customer update, while a person approves every refund or order change, on one dedicated GPU.
This is an example project, not a customer story. The company is made up, and every number on this page is an assumption stated so you can replace it with your own.
Exception handling costs about $448,000 a year less, and the build pays back in about three months
Build cost assumes engineers at $180,000 a year fully loaded. Time from other staff, such as reviewers labeling examples, is not counted. Payback is counted from go-live. See the arithmetic.
Twelve people looking up the same three systems all day
A distributor of industrial parts (bearings, fasteners, hydraulic fittings) ships about 5,000 orders a day from three warehouses to maintenance departments and machine shops. About 5% of shipments hit an exception: an address the carrier cannot deliver to, a carrier delay, a line that was short-picked because stock ran out, or a backorder whose date has moved.
That is about 250 exceptions every business day. A team of twelve customer service staff handles them. For each one, a person opens the order in the ERP, checks stock and pick status in the warehouse system, looks up tracking on the carrier’s site, decides what to do, and writes to the customer. It takes about 18 minutes on average. Exceptions that arrive in the afternoon often wait until the next day, and customers learn about a delay when the part does not arrive and their machine stays down.
The goal is for every exception to be investigated within minutes of arrival, with a proposed action and a drafted customer update ready for a person. Refunds and order changes still need a person’s approval.
The model decides which lookup to make next; code holds every credential
The model chooses tools, reads their results and writes the draft. The tools, the approval queue and every write to the ERP are the distributor’s code.
Exception feed
distributor's codeCarrier exception events, short-pick reports from the warehouse system and failed address checks from the ERP go into one queue, with the order number attached. This is integration work against systems the distributor already runs.
Tools
distributor's codeA small set of functions with fixed inputs: look up an order, check stock by warehouse, get carrier tracking, check the customer’s shipping preferences, and two that propose an action (a refund or an order change). The proposal tools create an approval request; they do not change anything. The model never holds ERP or carrier credentials.
Investigate
model, with the distributor's agent loopThe model reads the exception, calls lookup tools one at a time, and reads each result before deciding the next step. Code runs each call and stops the task after 15 steps. Tool calling depends on the model and the serving engine, so confirm it for your deployment before building on it.
Propose an action and draft the update
modelThe model proposes what to do (reship from another warehouse, offer a substitute part, issue a refund, or only notify) and drafts the customer message from the facts it looked up, using the distributor’s templates for tone and required wording.
Approve and execute
existing customer service tool, then distributor's codeA person sees the exception, the lookups the agent made, the proposed action and the draft in the customer service tool the team already uses. They approve, edit or reject. Only after approval does code issue the refund or change the order through the ERP’s own API. Every run is logged for audit and for the evaluation set.
Tokens per task matter more than requests per day, and one GPU covers it
The arithmetic we would start from. Profiling on real traffic replaces these estimates before anything goes into a contract.
| Exceptions per business day | 250 |
|---|---|
| Model calls per exception, on average (lookups, the decision and the draft) | 8 |
| Instructions, tool definitions and the exception, sent with every call | 4,000 tokens |
| Context added per step (the model’s tool call, short reasoning and the tool result) | 850 tokens |
| Tokens per exception, summed over 8 calls whose input grows each step | 55,800 in, 2,000 out |
| New input per exception, if prefix caching reuses the earlier steps | about 10,000 tokens |
| Tokens per business day | about 14M in, 0.5M out |
| Busiest hour, if 20% of the day’s exceptions arrive in it (carrier scans in the early morning) | 50 exceptions, about 775 input and 28 output tokens per second |
| Starting configuration to profile | gpt-oss-120b on one H100 (80 GB) |
An agent task is a chain of calls that wait on each other and on the tools. If each model call takes about 4 seconds and each ERP or carrier lookup about 2, an 8-step task finishes in under a minute, well within the 5-minute target. Per-step latency matters because it multiplies by the number of steps, so profile with recorded agent runs rather than single requests.
Most of the input on each call repeats the previous call. Summed over a task the model receives about 55,800 input tokens, but with prefix caching only about 10,000 of them are new. At the busiest hour that is about 140 new input tokens per second. Even without caching the load is small for one GPU. Few tasks run at once, so the cache for their contexts fits easily.
OpenAI sized gpt-oss-120b to run on a single 80 GB GPU. A second worker is not needed for availability: exceptions wait in the queue if the worker restarts, and a few minutes of delay is acceptable here. The 4 seconds per call is the assumption to check first in profiling; if reasoning at the chosen effort level makes calls much longer, set a lower effort for lookup steps.
How the numbers add up
| Handling today: 62,500 exceptions a year at 18 minutes and $34 an hour loaded ($10.20 each) | $637,500 a year |
|---|---|
| 50% that need a refund or order change, approved in 3 minutes ($1.70 each) | about $53,000 a year |
| 25% that only need a customer update, sent automatically after the pilot, with 10% spot-checked | about $2,700 a year |
| 25% the agent cannot resolve, handed to a person with its lookups done, at 12 minutes ($6.80 each) | $106,250 a year |
| One H100 running all year, at our reference price of $3.15 per GPU-hour | about $27,600 a year |
| Ongoing cost with the agent | about $190,000 a year |
| Saving a year | about $448,000 |
| One-time build: two engineers for four months, at $180,000 a year loaded | $120,000 |
| Payback on the build, from go-live | about 3 months |
At these assumptions the cost of handling exceptions falls from $637,500 to about $190,000 a year, which frees about 14,000 staff hours a year. That time can move to work that waits today, such as calling customers about large backorders. The first year also carries the build, about $120,000, which the saving covers in about three months.
The key assumption is how many exceptions the agent resolves. If it cannot resolve half of them instead of a quarter, and only 15% are update-only, the total is about $279,000 a year, still well under today’s cost. A wrong proposal costs reviewer time, not money, because a person approves every refund and order change.
The update-only share is sent without review only after the pilot shows those drafts need no edits. Until then they are reviewed like the rest, at about 3 minutes each.
The benefit that does not show in the table is timing. Customers hear about a delay or a short shipment within the hour, while they can still find the part elsewhere.
How the project would run
Build the evaluation set
weeks 1 to 3Take 500 past exceptions across all four types, with what the handler did and the message the customer received. Record the ERP, warehouse and carrier responses for each as they were at the time, so evaluation replays them without touching production. Hold back 150 that no prompt is tuned on.
Compare models
weeks 4 to 5Run the candidate models on the replayed exceptions on a trial endpoint. Score whether the proposed action matches what the handler did, whether every fact in the draft came from a tool result, and the number of steps and tokens per task.
Shadow mode
weeks 6 to 9The agent runs on every live exception with read-only tools. Handlers work as before and see the agent’s proposal next to their own decision. Every disagreement is logged and reviewed by the customer service leads.
Pilot on carrier delays
weeks 10 to 12Start with carrier delays, the type with the simplest actions. Handlers approve every proposal and every draft. Add address problems, then short picks and backorders, when the previous type’s approval-without-edit rate holds steady.
Automatic updates
after the pilotFor exception types whose update-only drafts were approved without edits for four weeks, send those updates automatically and spot-check a sample. Refunds and order changes keep a person’s approval.
What to measure
Approval without edits
The share of proposals a person approves exactly as proposed, per exception type. It is the main quality measure and decides when a type can move to automatic updates.
Unresolved share
The share of exceptions the agent hands back without a proposal. It sets the remaining staff workload, so it drives the business case.
Time from exception to customer update
The p95, from the event arriving in the queue to the message being sent. Compare it with today’s next-day delays.
Steps and tokens per task
A rising average often means the agent is looping on a tool that returns errors. It also tells you when the endpoint needs resizing.
Models to test first
Candidates from our catalog, not a ranking. The project picks one by testing them on its own labeled examples.
gpt-oss-120b
The starting choice. Trained for tool use, with reasoning effort you can set per request: low for lookup steps, higher for the decision step. OpenAI sized it to run on a single 80 GB GPU, which fits this workload. Apache 2.0.
GLM-4.5-Air
Z.ai built GLM-4.5 for agent tasks. The Air model has 12B of its 106B parameters active per token, with a thinking mode for complex steps and a non-thinking mode for quick replies. Z.ai publishes an FP8 version, which takes about 106 GB and fits on one H200. MIT license.
Qwen3-235B-A22B-Instruct-2507
An instruction model without a thinking mode, which keeps each step short. Alibaba lists tool use among its improvements over the original Qwen3 release. Larger than this workload needs; test it to see whether the accuracy of the decision step is limited by model size.
Mistral-Small-24B-Instruct-2501
A dense 24B model with native function calling, under Apache 2.0. Its weights are about 48 GB in 16-bit precision, so it fits on one RTX PRO 6000. A lower-cost option if the lookup steps turn out to be simple enough.
Sizes are total parameters as listed in our catalog. Mixture-of-experts models use only part of them for each token. Check each model's license for your use. Several, such as the Llama and Gemma licenses, carry their own terms.
When fine-tuning helps
Fine-tune when the agent calls the distributor’s tools almost right: it checks the wrong warehouse first, or proposes a reship when the handlers would offer a substitute part. Logged runs that a handler corrected are the training data, and shadow mode produces hundreds of them.
A LoRA adapter on those runs can also teach the distributor’s own policies, such as which customers get free expedited reshipping. Keep policies that change often in the instructions rather than the weights.
When the data has to stay put
Tool results contain customer names, delivery addresses, contract pricing and order history. The distributor’s larger customers have contracts that treat their pricing as confidential. The model runs inside the distributor’s network, next to the ERP and warehouse systems, so prompts and tool results stay there, and the ERP and carrier credentials stay with the distributor’s code.
Tell us about your project
Bring us your volumes and a sample of your data. We will tell you which models to test, what the endpoint would need, and what a performance commitment would cover. Self-service accounts can create inference endpoints to try the platform, but not on our top-tier GPU capacity.