Phone order intake
Phone orders are rarely just a list of products. A caller may use an informal item name, change a quantity, ask whether a substitute will work, provide a new delivery address, or need approval on price and availability. If staff write the request in free-form notes, the fulfillment team has to interpret it later and may still need to call back.
An AI phone agent can structure the intake portion of the call. It can ask for the approved customer and product references, query a connected catalog or order system, repeat the requested items and fulfillment details, and submit a confirmed order request. ThunderPhone does not capture payment by phone, so any payment step must use the organization's separate approved process or a human handoff.
A concrete order-intake call
Suppose a returning business customer calls to reorder maintenance supplies.
Agent: I can collect your order request and check approved item information. What account reference should I use?
Caller: Use our warehouse account. We need the same filter used on our last service order, plus replacement belts.
Agent: I found the account, but I need the approved item reference or equipment model before I can identify the filter. I should not guess from the description. Do you have either one?
Caller: I have the equipment model. For the belts, I need the standard size listed for that model.
Agent: The connected catalog returned a matching filter and belt entry. I will read back the item names and requested quantities before submitting anything. Should this use the saved delivery address, or do you need a different location reviewed?
The agent confirms each item, quantity, unit or pack description, delivery or pickup preference, contact details, and any purchase-order reference the business requires. It then submits the request through the integration. If the system confirms only that a request was received, the agent uses that wording. It does not say the order is accepted, in stock, priced, or scheduled unless the authoritative response confirms those facts.
This function can support wholesalers, restaurants, pharmacies, equipment suppliers, and ecommerce teams, but their authorization and restricted-product rules differ. Use the industry examples to frame those requirements instead of turning one generic prompt into policy for every seller.
How to configure the workflow on ThunderPhone
Build the prompt around the exact record needed by the order team. Define the identifiers the agent may request, which customer details it may repeat, the required item fields, how it handles variants and substitutions, and the final confirmation language. Require it to distinguish an order request from a completed order.
Set hard boundaries for catalog questions. The agent may state approved information returned by the system or found in selected organization documents. It should not infer compatibility, recommend regulated goods, invent discounts, calculate an unconfirmed total, or substitute an item without an explicit rule. ThunderPhone's knowledge base accepts selected text, Markdown, CSV, PDF, and DOCX files and provides built-in mid-call search, but changing inventory and price should come from the system that owns them. Uploaded documents must be attached to the agent and maintained by the organization.
Use an inbound demo U.S. number for tests only; it is inbound-only and is not intended for production. Bring the live order line through a supported direct connection or manual SIP configuration. Define transfer targets for payment, authorization failure, restricted products, unavailable items, disputed pricing, and high-value exceptions.
Connect the systems that can validate and receive the request:
- Use a REST integration to look up accounts, catalog entries, inventory state, or order rules and to submit the confirmed request.
- Use signed webhooks to deliver the call outcome to an order or fulfillment workflow.
- Use Salesforce or HubSpot when the request belongs on an existing customer or deal record.
- Use Google Sheets when a controlled sheet is the approved request queue.
- Use Slack to notify staff about review conditions or failed submissions.
- Use Zapier MCP for approved actions exposed by the connected server.
If the caller only needs pricing for staff follow-up, use quote request intake. Existing customers asking where a submitted order is should go to the order status line, while return requests belong in returns and exchanges intake.
Test exact item references, informal product names, quantity changes, invalid accounts, duplicate requests, unavailable inventory, ambiguous units, substitution requests, payment attempts, integration failure, and callers who need a person. ThunderPhone supports browser mic tests, reusable simulations, graded call logs, regression suites with minimum pass-rate gates, and live-traffic A/B experiments. Simulations are billable real calls, and the charge appears before a run.
What to measure
Track required-field completeness, successful request submission, caller corrections during read-back, unrecognized-item rate, duplicate-request rate, integration rejection rate, and the share routed to staff. Compare submitted item references, quantities, and fulfillment details with the confirmed call data. A high submission rate is misleading if the order desk must reconstruct ambiguous requests.
Separate appropriate exceptions from avoidable failures. Payment, restricted-product approval, unusual substitutions, and disputed pricing should often end with a person. Repeated handoffs for common catalog wording may instead signal that the source data or prompt needs improvement. The integration action itself is an example of function calling: the conversation gathers context, while the connected system performs the controlled operation.
Honest limits
ThunderPhone does not capture payment by phone. The agent also cannot physically verify inventory, inspect an item, determine compatibility without approved data, authorize credit, or resolve a contract or pricing dispute. It should never create the impression that a request is a fulfilled or paid order when the back-office system says otherwise.
Humans remain responsible for regulated or age-restricted sales, fraud concerns, tax and shipping exceptions, negotiated pricing, substitutions that require judgment, and sensitive account changes. Keep a clear handoff route and let the seller's authoritative systems decide what can actually be sold and fulfilled.