How can a chatbot explain an order delay when the tracking system has no update?

A chatbot can explain the lack of an update honestly, but it cannot explain the cause of a delay without evidence. It should state the last verified event, distinguish missing information from a missed delivery commitment, and arrange human follow-up when needed. It must not invent a courier problem or promise an arrival date.

For a South African retailer considering AI chatbots, the useful decision is where the bot should stop answering and start handing over. The workflow below is a proposed design, not a native delivery-management feature. All example records, times and thresholds are hypothetical.

1. Decide whether the order is late or the information is missing

Treat delivery timing and tracking visibility as separate questions. An empty tracking record tells you that information is unavailable, not why the parcel has not arrived.

Proposed classifications are:

• Within the delivery window, no new event: describe the latest verified state without calling the order late.
• Delivery window passed, no new event: acknowledge the missed window, but leave the cause unknown.
• Courier exception recorded: explain only the customer-safe reason actually returned by the courier.
• Lookup unavailable: explain that the system could not retrieve tracking, rather than claiming the courier has not updated it.
• Conflicting records: avoid selecting whichever result sounds most reassuring; send the conflict for review.

Store the delivery commitment separately from the courier estimate. An estimate changing does not automatically change what the business previously promised.

If the commitment is absent, the chatbot should not calculate lateness from a generic delivery policy. Ask a person to establish the applicable commitment. This distinction gives the team a clear boundary between a known missed window and an information gap.

2. Return a small, verified tracking record

Give the chatbot a controlled status lookup, not unrestricted access to order records. The application should verify the customer's access and bind the lookup to the authorised order before returning delivery information.

OpenAI's Source: function-calling documentation describes a flow where the model requests a function and the application executes it, then returns the result. In this proposed workflow, your application would perform the tracking lookup and enforce its permissions.

Define the returned fields clearly:

• order_reference: the authorised order being discussed.
• lookup_status: success, unavailable or not found.
• last_event and event_at: the verified event and its timestamp, or null.
• retrieved_at: when the application checked the source.
• delivery_window_end: the applicable commitment, or null.
• courier_exception: an approved reason, or null.
• parcel_scope: the shipment or parcel covered by the result.

Keep event time separate from retrieval time. A successful lookup now may still return an old scan. Display customer-facing timestamps in a clearly labelled timezone, such as SAST, after validating the conversion. A technical timeout should never become a delivery status.

3. Build the reply from evidence, uncertainty and action

Use a short reply with three parts: what is confirmed, what cannot be confirmed, and what happens next. A useful message need not explain the cause when the cause is unknown.

A hypothetical reply after a missed window could read:

The latest tracking event for order SA-1048 is “Collected”, recorded on Monday at 14:10 SAST. The delivery window recorded for your order has passed. I cannot confirm the reason or a new arrival date from the available tracking information.

Add the next step only once it is known. Before a task is accepted, say that you are attempting to send the enquiry to support. After acceptance, provide the returned reference and any approved follow-up commitment.

Avoid statements such as “the depot is busy”, “your parcel is safe” or “it will arrive tomorrow” unless the relevant record supports them. An apology can acknowledge inconvenience without pretending to know what happened.

The wider customer-service agent workflow should preserve this distinction between answering a question and resolving the underlying delivery problem.

4. Keep delivery policy separate from live order evidence

Use approved policy documents to explain the process, not to establish a parcel's location. A delivery policy may describe how enquiries are handled, but it cannot prove why this order has no scan.

OpenAI's Source: file-search documentation describes retrieval from uploaded files through semantic and keyword search. That can support a proposed policy lookup, provided the files are ready for use and the application selects the appropriate knowledge base.

Keep current policies identifiable by version, owner and effective date. Where a policy differs by delivery service or destination, return the applicable scope alongside the passage. If no applicable policy is found, omit the procedural promise rather than borrowing one from another service.

For example, a hypothetical policy might permit a support enquiry after the recorded delivery window ends. That is a rule about escalation, not evidence of courier fault.

Treat retrieved text as reference material, not permission to change orders. Staff should approve policy wording and assess legal implications. Refund eligibility, replacement approval and consumer disputes require appropriate human judgement rather than a chatbot's interpretation of a document.

5. Create a human task that can actually be worked

Escalate with enough evidence for a person to investigate without asking the customer to repeat the whole conversation. The task should identify the order, the missing information and the question that remains unanswered.

Proposed escalation triggers include a passed delivery commitment, conflicting parcel records, a customer disputing a delivered scan, or a tracking lookup that remains unavailable after the application's bounded retry. Operations staff should approve those triggers and any response targets.

Include the authorised order reference, affected parcel, last event and timestamp, lookup outcome, delivery commitment, customer concern and permitted contact route. Label customer statements as customer statements. “Customer says nothing arrived” must not become “parcel lost”.

The application should search for an existing open delivery enquiry before creating another. Use an application-controlled duplicate-prevention key tied to the order, parcel and enquiry type. If an open task exists, append the new concern and reuse its reference.

The AI CRM integration glossary provides context for connecting this handover to customer records. Access controls, retention and contact permissions still need review by the responsible people.

6. Check the action result before confirming anything

Make the reply depend on the support system's acknowledgement, not the model's intention. Requesting a task is not the same as successfully saving one.

A proposed application response should distinguish created, existing_task_updated, failed and outcome_unknown. Return a task reference only when the support system confirms it. If a request times out after submission, check whether it succeeded before retrying. Otherwise, a retry could create a duplicate.

OpenAI's Source: structured-outputs guide describes schema-constrained responses. You could use a schema for fields such as evidence state, customer message and escalation outcome. A valid structure is not proof that the facts inside it are correct, so the application must still compare claims with source values.

Provide a fixed fallback when output is incomplete, refused or fails validation. For example, explain that tracking could not be confirmed and offer an approved support route. Do not tell the customer to wait for a callback unless a task and contact commitment exist. Keep payment, refund and replacement actions outside this status-only workflow.

7. Evaluate exceptions before widening the workflow

Test whether each reply accurately reflects the record and whether each handover reaches a usable queue. Pleasant wording alone is not enough to judge this workflow.

Build a hypothetical evaluation set covering fresh scans, old scans, no events, failed lookups, missing commitments, split shipments, conflicting statuses and repeat enquiries. Include a customer asking the bot to guess the reason and a customer demanding an immediate refund.

For each case, an operations reviewer should check:

1. Does every factual statement match the returned evidence?
2. Is missing data distinguished from confirmed lateness?
3. Is the reply scoped to the correct parcel?
4. Does escalation contain an order reference and an unresolved question?
5. Does the claimed task outcome match the system acknowledgement?
6. Are unsupported causes, dates and consequential actions absent?

A proposed release rule is to block wider use when evaluation reveals unsupported delivery promises or false escalation confirmations. Track the frequency of those defects, duplicate tasks and incomplete handovers without assuming a target has already been achieved.

This can form a scoped AI automation project. Any potential improvement in consistency or staff workload needs evaluation against the existing process.

Reusable delivery-status response checklist

Use this proposed checklist for each order-status enquiry. Operations staff should approve the escalation rules and follow-up commitments before use.

Reusable reply pattern: “The latest verified update for order [reference] is [event] at [time and timezone]. [State the recorded delivery-window position, or say it is unknown.] I cannot confirm [missing fact]. [Give only the acknowledged next step and reference, if available.]”

Worked walkthrough: a normal enquiry and unresolved exceptions

Apply the same evidence checks even when the customer's wording suggests the order is definitely late. The following records and outcomes are hypothetical.

Normal case: Order SA-1048 has one parcel. At 10:00 SAST on Tuesday, the lookup returns Monday's collection scan and a delivery window ending Wednesday. The bot states the collection event and says no newer tracking event is available. It does not call the parcel delayed or guarantee Wednesday arrival. Under the proposed rule, no exception task is required unless another concern warrants review.

Missing-data case: The same order is checked on Thursday. Its Wednesday delivery window has passed, but the lookup returns no events. The bot acknowledges the missed window and says the cause and current location are unconfirmed. The application creates a task containing the order reference and missing evidence. A support person checks dispatch records and contacts the courier before giving a revised estimate.

Duplicate and ambiguous case: The customer enquires again through WhatsApp. There is already an open task, and separate parcel records now show “Delivered” and “In transit”. The application updates the existing task with both parcel references. The bot explains that the records differ between parcels; it does not declare the whole order delivered. A person checks which items each parcel contains and whether the customer disputes receipt.

For channel planning, the WhatsApp business agent resource is relevant, but the order-level evidence and task history should remain consistent across channels.

FAQs about silent tracking and delivery handovers

The safest answers depend on the record and the confirmed handover outcome, not on a reassuring script.

Can the chatbot say the courier caused the delay?

Only when a verified, customer-safe courier exception supports that statement. A missed delivery window establishes that the recorded commitment has passed; it does not establish responsibility. If a record says an address check is required, describe that recorded exception without adding blame. If the reason is absent, say it is unconfirmed and ask a person to investigate. Do not turn common delivery problems into an explanation for this particular order.

What should it say if tracking and task creation both fail?

It should describe the limitation plainly: tracking could not be retrieved, and the support enquiry could not be confirmed. Offer the business's approved support route, using existing contact details rather than invented ones. If task creation has an unknown outcome, the application should check for an existing task before resubmitting. A person should review unresolved failures. The bot must not promise that someone will call when no accepted handover exists.

Should every order with no new scan go to a person?

Not necessarily. A proposed rule can allow an honest status reply while the recorded delivery window remains open. Escalation becomes appropriate when the window has passed, records conflict, the customer disputes delivery or another approved exception applies. Operations staff should adapt this rule to their services and staffed support hours. Missing tracking must not become indefinite waiting: unresolved enquiries need an owned review process, with follow-up commitments approved by people.

If your business needs help defining this boundary, get in touch to discuss a scoped delivery-status chatbot workflow. Start with the evidence fields, response checklist and human queue before expanding what the bot can do.

Sources

• OpenAI function calling
• OpenAI structured outputs
• OpenAI file search