“Where is my order?” Automate Shopify and WooCommerce order-status support

A shipping policy explains the usual dispatch window. It cannot tell a particular shopper whether their parcel was shipped. Connect your website reads the public catalog; Orders connects the private order system. Installing a widget, training policy pages and connecting a catalog do not grant order access.

Open an agent in your intoCHAT account, go to Actions and find the Orders card below Booking. Choose Shopify or WooCommerce. One store connects per agent. The agent reads orders, but cannot cancel, change or refund one. Keep shipping and missing-parcel procedures in Knowledge so it can explain the next step when the order data is incomplete.

Use the permanent .myshopify.com address, not your customer-facing custom domain. If Install on Shopify is available in your Orders card, follow it and approve the requested read access in Shopify. If that installation is not available, use the documented custom-app option.

Test and connect checks access and whether Shopify permits reading the order email needed for matching. If protected customer data access prevents reading email, resolve that permission before proceeding. An order with no readable email is never shown to the visitor.

Enter your WordPress site’s HTTPS address in the Orders card. Plain HTTP and private or internal network addresses are refused. In WordPress, open WooCommerce → Settings → Advanced → REST API → Add key. Select a user who can manage orders, choose Read permissions and generate the key.

Paste the consumer key and consumer secret into intoCHAT and select Test and connect. The connection check asks the store for its name and the ID of a recent order; it does not show customer data. If credentials are refused or the REST API is unreachable, correct the permission or store configuration before testing a visitor question.

WooCommerce does not supply shipment tracking by itself. Tracking is available only with the Shipment Tracking extension or a plugin that stores data in the supported format. A custom order-number plugin can also affect lookup: intoCHAT searches for an exact match, but finding the number depends on that plugin.

For a visitor without a supplied signed-in email, the tool needs the order number and the email used for that order. A wrong email receives the same visitor-facing result as a missing order. With identity verification and an email passed by your site, that email is used and an email typed into the chat is ignored. Only the user ID is signed: this is not independent proof of email ownership.

Fictional example: Alpine Desk is an invented merchant, and order #1042 is invented. An illustrative first reply is: “What email address did you use at checkout? I need it to check the order.” If a successful tool result reports paid, fulfilled and a tracking link, an illustrative reply is: “Order #1042 is paid and fulfilled. Here is the tracking link returned by the store.” This describes expected behavior; no real merchant or order was tested for this guide.

The model receives the order number and date, payment and fulfillment status, cancellation state, item titles, variants and quantities, available carrier and tracking details, and the total with currency. The allowlisted view excludes addresses, phone numbers, card details, customer notes, email and other orders. A fulfillment status does not establish an arrival date.

Different failures need different next steps. A provider outage is not a failed ownership match. The cases below are illustrative expected behavior, not results from an actual connected store.

Adapt this to your support process. These instructions do not enable Orders, grant store permissions or create a carrier connection.

Enable email handoff or live chat in Setup if your team should take over. Live chat needs somebody online; email handoff asks for agreement and a reply address. Say the conversation was sent only after the action succeeds, and avoid promising a response time your process does not supply.

Returns and exchanges is a separate switch in Orders and is off initially. When enabled, the agent collects the items, quantities, return or exchange choice and reason, then verifies the order again. A successful result records a request for the team. It does not approve the return, issue a refund, create a label or change the store.

Fictional expected reply after a successful return request: “Your request for one item from order #1042 was received. The shop will follow up.” Keep approval and resolution in your normal support process. Returns appear in the Leads tab; notifications depend on your configured channels.

Start from the order-tracking template and adapt the policy sources and support destination. In the Playground, use a test order you control: first a correct match, then a deliberately wrong email, an order with no tracking and your fallback route. Playground lookups are real and count toward lookup limits; email handoffs and return requests can notify your team, so coordinate the checks.

Inspect Why this answer for Order lookup and the Orders card’s access log to diagnose the result. Simulated-customer tests are useful for dialogue rules, but their order lookups and returns are simulated; they cannot prove that live store access works. This guide reports no actual store test or measured reduction in support requests.

The public store demo below lets you explore public product discovery only. It cannot access private orders or validate this workflow. To implement order-status support, create an intoCHAT account, configure Orders with authorized store access and follow the order documentation. Use the Swiss shop launch guide for the wider multilingual rollout.