Build a shipment-status assistant that can say the evidence is missing

A confident guess is worse than a delayed truck in B2B logistics

When a B2B customer's plant planner asks, "Will LR-88419 reach our Hosur factory before the 14:00 IST line-feed cutoff?", the worst possible response from a customer-service assistant is a smooth, ungrounded reassurance: "Your shipment is on schedule and will be delivered by 14:00 IST today." If the underlying truck actually broke down near Krishnagiri three hours ago—or if the last PTL hub scan is eighteen hours old because the regional partner has not uploaded its manifest—that fabricated reassurance prevents the factory from arranging emergency buffer stock and destroys trust in the logistics provider.

In customer-service automation for freight and warehousing, the defining quality metric is not how fluent the chatbot sounds when data is clean. It is whether the assistant recognises when tracking evidence is stale, incomplete or contradicted, states only what has been verified with its exact timestamp, and hands the exception to an accountable coordinator.

That design principle aligns directly with the confabulation-control and human-escalation practices outlined in the NIST — AI 600-1 Generative AI Profile. The assistant should act as a strictly scoped evidence retriever over your TMS and WMS read APIs—never as an autonomous dispatcher or commercial negotiator.

Separate what the assistant may answer from what it must escalate

Before connecting a language model or conversational workflow to customer enquiries, define a deterministic three-bucket routing policy based on query intent, data freshness and caller authorisation:

1. Bucket 1 — Grounded status retrieval (Direct answer permitted): The caller is authenticated and authorised for the shipment, the query asks for factual progression (current location, last hub scan, dispatch confirmation, e-Way Bill validity window or confirmed POD status), and the underlying system holds a verified event within the lane's freshness SLA (for example, GPS ping < 2 hours old or expected hub scan on schedule). Every reply includes the observation timestamp ("Last observed at Hub Bhiwandi Out-Gate on 15 Oct at 11:20 IST").
2. Bucket 2 — Stale, conflicting or appointment-blocked status (Disclosure + Escalation): The caller is authorised, but the last GPS or hub scan is older than the freshness threshold (for example, > 12 hours without an update), or the GPS location conflicts with the promised ETA, or delivery awaits consignee slot confirmation. The assistant states the last known verified timestamp honestly ("The last verified scan was at Nagpur Hub on 14 Oct at 19:40 IST; we do not have a confirmed post-departure update yet") and immediately creates a priority control-tower callback ticket.
3. Bucket 3 — Out-of-scope commercial, claims or unauthorised queries (Immediate refusal / handoff): Queries attempting to look up another client's LR number, negotiate detention or freight charges, lodge a shortage/damage claim, or re-route an in-transit truck to a new address.

Illustrative example: evaluating 80 B2B shipment enquiries before production rollout

Suppose a 3PL control tower tests its shipment-status assistant across a benchmark set of 80 realistic B2B customer enquiries spanning clean tracking queries, stale-telemetry exceptions and adversarial or commercial dispute prompts.

The arithmetic across the 80-enquiry evaluation makes the operational boundaries explicit:

• 50 enquiries (62.5%) have fresh, verified tracking evidence and are resolved directly with timestamped source facts.
• 18 enquiries (22.5%) involve stale telemetry (>12 hours) or appointment holds; rather than hallucinating an on-time arrival, the assistant reports the last verified scan timestamp and opens an exception ticket for human follow-up.
• 12 enquiries (15.0%) involve unauthorised cross-tenant LR numbers, address changes or commercial rate disputes and are blocked or handed off immediately (50 + 18 + 12 = 80).

Enforce object-level authorisation and data minimisation inside the retrieval tool

A conversational assistant is only as secure as the backend function it calls to fetch shipment data. Apply the security controls from the OWASP — API Security Top 10 2023 and the privacy safeguards in the MeitY — Digital Personal Data Protection Rules 2025:

1. Bind tenant identity in code, never in the prompt: When an authenticated user from Client A asks about LR-9012, pass authenticated_tenant_id = Client A directly from the session token into the database query (WHERE lr_number = :lr AND tenant_id = :tenant). Never pass an unscoped tool to the model and rely on a system prompt instruction saying "Only answer questions about Client A."
2. Project a strict customer-safe view: The JSON object returned by the retrieval function to the assistant context should contain only customer-authorised fields: LR number, PO reference, carton/pallet count, origin/destination city, current milestone, observation timestamp, source type and official customer-facing exception code. Strip out carrier buy-rates, gross margins, driver personal mobile numbers, Aadhaar/licence identifiers and other customers' LRs on the same truck before the payload reaches the model.
3. Treat shipment notes as untrusted text: Free-text dispatcher or broker remarks sometimes contain internal shorthand, unverified speculation ("driver not picking up phone, maybe tyre burst") or untrusted external strings. Expose only curated, approved status reason codes to external customer responses.

Make the human handoff useful to the control-tower coordinator

When one of the 18 stale-telemetry enquiries triggers an escalation to a human coordinator, do not force the customer to repeat their LR number and question from scratch. The escalation ticket created by the assistant should pre-populate:

• The customer account, contact person and verified LR / Shipment ID.
• The exact reason for escalation (for example, Telemetry Stale: Last GPS ping 14h 20m ago at Dhule Toll Plaza; customer cutoff at 14:00 IST).
• The assigned carrier/broker contact and vehicle number so the control-tower analyst can immediately place the verification call.

Next actions

1. Define your freshness thresholds by transport mode (for example, FTL GPS ping age vs PTL hub scan interval) beyond which the assistant must disclose uncertainty rather than confirming an ETA.
2. Build a dedicated, read-only customer-safe shipment projection API that enforces server-side tenant_id filtering and strips carrier costs, driver PII and raw internal dispatcher notes.
3. Test the assistant against an 80-case benchmark covering fresh scans, stale telemetry (>12 hours), cross-tenant LR guesses, address-change requests and commercial rate disputes.
4. Connect stale-data escalations directly to the control-tower exception queue with pre-populated vehicle and carrier details so coordinators can resolve the missing update rapidly.