Get started

Order status line

“Where is my order?” calls are repetitive, but the answer is not static. Staff must identify the order, open the correct record, translate an internal status into useful language, and recognize when the caller needs more than an update. A shipment marked delivered, a backordered item, and a package awaiting pickup require different next steps.

An order status line gives callers a direct phone path to the current information exposed by the business’s order system. The AI phone agent collects the lookup fields, uses an approved tool, reads back the returned status, and separates simple updates from exceptions. It complements a phone order intake flow; it does not take a new order or collect payment.

A concrete order-status call

Consider a caller waiting for a replacement part.

Agent: I can check the status returned by our order system. Please say your order number.

Caller: It’s 48371.

Agent: Thank you. For the verification step set by the business, please confirm the billing postal code.

Caller: 97205.

Agent: I found the order. It is marked shipped, with an expected delivery date of Friday, August 28. Would you like me to repeat that date?

Caller: The tracking page says it was delivered yesterday, but I do not have it.

Agent: That needs a delivery exception review rather than another status lookup. I’ll record that the package is missing and try the support team now. Please hold while I brief them.

The agent has not invented a location or guaranteed an arrival. It reports what the connected system returns, notices that the caller’s problem conflicts with the ordinary status, and moves the issue to a person with the authority to investigate.

How to configure it on ThunderPhone

Write the prompt around statuses and exceptions, not a free-form promise to “help with orders.” Define:

  1. The lookup fields to request and how many attempts to allow.
  2. The verification fields the business requires before disclosing order information.
  3. Plain-language wording for each returned status, without adding facts that the tool did not return.
  4. Exception triggers such as no matching order, failed verification, late delivery, damaged goods, a delivered-but-missing report, or a request to change an address.
  5. The next step for each exception: follow-up record, cold transfer, eligible warm transfer, or a clear callback expectation.

Expose the lookup through a tool attached to the agent. A REST endpoint can return only the fields needed for the call, or a remote Zapier MCP server can be added by URL, synchronized for tool discovery, and attached to the agent when the business has built the corresponding approved action. ThunderPhone supports static HTTP headers for remote MCP connections. Keep the tool narrow: a status line generally needs to read an order and submit an exception, not gain broad access to every customer record.

HubSpot or Salesforce may be used for the follow-up side when that is where the business manages customer cases. For a custom order platform, use REST and subscribed webhooks. ThunderPhone webhook endpoints have separate secrets and event subscriptions, HMAC-SHA256 request signatures, and exponential-backoff retries for non-blocking deliveries. Map the order number, verification result, returned status, caller-stated problem, and final call disposition into the receiving workflow.

Connect an appropriate production number for live traffic. Demo U.S. numbers are useful for inbound testing but are inbound-only and not intended for production. If exception calls should reach a person, configure the transfer target and fallback. On an eligible production number, attended warm transfer can place the caller on hold, privately brief the recipient, and connect after acceptance. If the recipient declines, does not answer, or reaches voicemail, the agent can return to the caller with the outcome. Demo numbers and browser calls are limited to cold transfer.

Build reusable tests for a normal shipment, an invalid order number, failed verification, partial fulfillment, a missing package, and an unavailable support team. Grade whether the agent states only returned information and follows the right exception path.

What to measure

Useful operating measures include:

  • successful lookup rate;
  • failed verification and no-match rates;
  • status-only calls completed without staff involvement;
  • exception rate by reason;
  • transfer acceptance and fallback completion;
  • repeat calls for the same order; and
  • reviewed calls in which the spoken answer differed from the tool response.

Measure containment carefully. A contained status request may be successful; a contained fraud concern or missing-package report may indicate a broken escalation rule. Compare the result with caller intent, not call length alone.

Honest limits

ThunderPhone does not make inaccurate source data accurate. If the fulfillment platform has a stale scan or vague status, the agent should report that limitation and route the caller. The line should not disclose details after failed verification, decide refunds, change delivery addresses, or promise replacements unless the connected workflow explicitly supports the action and its controls. High-value orders, suspected fraud, repeated delivery failures, and angry callers need a person.

Keep returns policy and return requests in a separate returns and exchanges intake flow so an order lookup does not drift into unsupported decisions.

Create your ThunderPhone account to configure and test an order status line.