How to Build an Order Tracking Agent

Where is my order is the most common question any commerce operation receives, and most answers to it are unsatisfying because they restate a tracking page the customer already read. Answering it well requires knowing what the order contains, whether it shipped, in how many parcels, where each is, whether anything has gone wrong, and what can be done about it. This guide covers building an agent that does that, drawing on FISTA Solutions' AI agents delivery in commerce and logistics. It complements ai in last mile delivery and how to build an ai customer service agent.

What data does the agent need?

Source	Provides	Without it
Order management system	Order contents, status, splits, holds	Cannot say whether it shipped
Warehouse or fulfilment	Pick, pack, dispatch events	Cannot explain pre-shipment delay
Carrier tracking	Parcel scans, estimates, exceptions	Cannot say where the parcel is
Inventory	Stock position for unshipped items	Cannot give a realistic date
Customer record	Contact channel, history, value	Cannot personalise or prioritise
Returns system	Return status where relevant	Cannot answer return questions

Carrier tracking alone is the common shortcut and it answers only the last leg of the question. An order that has not shipped has no tracking number, and that is precisely the case where the customer is most anxious.

Why is proactive detection the biggest win?

Because the contact that never happens costs nothing. Monitoring shipments for exceptions, no carrier scan for longer than typical on that lane, an estimated delivery date that has passed, a return-to-sender or address-issue scan, a parcel scanned into the wrong hub, means the organisation knows before the customer does.

Contacting the customer at that point with the situation, a revised expectation, and options removes the inbound contact and, more importantly, changes the customer's experience from discovering a problem to being told about one. That is the difference between a complaint and a resolved issue.

How should delays be communicated?

Honestly. The temptation is to give an optimistic revised date because it sounds better; the result is a second slip, a second contact, and a customer who no longer believes anything the organisation says. A realistic date, given once, with a plain explanation of what happened, produces fewer contacts and better outcomes even when the date is worse.

Where the organisation genuinely does not know, saying so with a commitment to update by a specific time is better than a guess. The message should come through the channel the customer used or prefers.

What resolution actions fit?

Those within a defined policy the agent can apply: reshipment after a no-movement period, refund within a value limit, redirection to another address or a collection point where the carrier supports it, cancellation before dispatch, and expedited reshipment for time-sensitive orders. Each with the policy limits encoded and the action logged.

Offering an action is the difference between information and service. A customer told their parcel is stalled and offered a reshipment has been helped; one told only that it is stalled has been informed.

How should bad carrier data be handled?

By expecting it. Carrier tracking is frequently stale, occasionally wrong, and sometimes says delivered when the customer has nothing. The agent should treat tracking as evidence rather than truth, recognise patterns that indicate stale data such as no update for an unusual period, and never contradict a customer flatly.

A customer who says a parcel marked delivered has not arrived is describing their reality; the correct response is to take it seriously, check the delivery detail such as location and signature, and escalate to the claims process, not to repeat that the system says delivered.

What should escalate?

Lost and damaged shipments needing a carrier claim. Disputed deliveries. High-value orders where the resolution limit is exceeded. Anything with a complaint attached. Repeat contacts on the same order, which indicate the agent has not resolved it. And any case where what the customer describes conflicts with the systems, because that is where judgement is required.

How does this work across channels?

The same logic serves the website's order status page, the messaging assistant, the voice line, and proactive outbound notifications. Building the order status reasoning as a service that each channel calls, rather than separately per channel, keeps answers consistent, which matters because a customer who gets different answers from the chat and the phone line has a worse experience than one who gets the same imperfect answer twice.

How is it evaluated?

Resolution verified by absence of a repeat contact on the same order. Contact volume on order status, before and after, including the proactive effect. Accuracy of revised delivery expectations against actual delivery. Escalation rate and quality. Customer satisfaction on order status interactions measured separately. And the operational measure: the proportion of delivery exceptions the organisation detected before the customer reported them.

What does the build sequence look like?

One week on data integration across OMS, carrier, and inventory. Two weeks on the order status reasoning as a service, with the exception logic. One week on proactive detection and notification for the most common exception types. One week on resolution actions with policy limits. Then channel integration, starting with the highest-volume one.

What goes wrong?

Carrier tracking as the only source. Optimistic revised dates. Information without actions. Contradicting customers about deliveries. Proactive notification built last or not at all, which leaves the largest gain unclaimed. And separate implementations per channel that give different answers.

What about international and multi-carrier shipping?

Both multiply the failure modes. International orders add customs holds, which look identical to a stalled shipment in carrier data but have a different cause, timeline, and resolution, and the agent should recognise and explain them rather than reporting a delay with no explanation. Duties and taxes owed by the recipient are a common cause of parcels sitting undelivered, and telling the customer that is far more useful than telling them it is in transit.

Multi-carrier estates add inconsistent data quality, different exception codes, and varying scan frequency by carrier and lane. Normalising carrier events into a common model, with per-carrier expectations for scan cadence, is what lets one piece of exception logic work across all of them rather than tuning thresholds per carrier and never finishing.

How FISTA Solutions helps

FISTA Solutions builds order tracking agents that join order, fulfilment, and carrier data, detect exceptions proactively, communicate revised expectations honestly, offer policy-bounded resolution actions, and escalate disputes and claims to people, served consistently across every channel, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime and 47% efficiency gains where measured.

To answer where is my order before it is asked, message FISTA on WhatsApp, or read ai in last mile delivery.