Answering "where is my order" on WhatsApp in one workflow

Step 1: Start the workflow from WhatsApp

Add the WhatsApp trigger to a new workflow and point your WhatsApp Business webhook at it. Every incoming message starts one run with the sender’s number and the message text.

Add Mark As Read as the first action, so the customer sees their message was received while the lookups run.

Step 2: Decide what the message is

Not every message is about order status. An Agent block classifies the text into a few labels: order status, return or exchange, product question, other. It also pulls out an order number if there is one, in formats such as "#51907" or "order 51907".

Only order status questions continue down this path. The rest go to your existing support flow, or straight to a person. Keep the labels few. A classifier with four labels is easy to check in the run log; one with twenty is not.

Step 3: Find the order in Shopify

With an order number, use the Shopify Get order operation. Without one, use List orders filtered by the customer’s phone number and take the most recent open order.

From the order, keep: financial status, fulfilment status, items, the tracking number and the courier name. If the order is not yet fulfilled, the workflow can answer straight away: "Your order is being packed and will ship within two working days." The wording comes from a delivery policy document in the Knowledge Base, so it matches what your site promises.

If more than one open order matches, the workflow sends a list message with Send Interactive and lets the customer pick.

Step 4: Ask the courier for the latest scan

Couriers and shipping aggregators such as Delhivery, Shiprocket or iThink Logistics are not native integrations. Use the generic API block to call your courier’s tracking endpoint, with the API key stored as a workspace secret. Map the response to three fields: latest status, location and time of the last scan, and expected delivery date if the courier provides one.

If you use more than one courier, add a condition on the courier name and one API block per courier. Each returns the same three fields, so the rest of the workflow does not care which courier carried the parcel.

Step 5: Reply with buttons

Because the customer wrote first, the 24-hour service window is open and you can reply with an interactive message. Send Interactive sends the latest scan in plain words with up to three reply buttons:

• Track shipment sends the courier’s tracking link.
• Change delivery asks what they need and records it for the team. Changing the address in Shopify is a person’s job: the Shopify order update covers note, tags and email only.
• Talk to us hands the chat to a person, every time it is pressed.

Step 6: Hand off what the workflow should not handle

A rule decides when a person takes over. Typical conditions:

• No courier scan for more than 72 hours.
• The courier status says delivered, but the customer says it has not arrived.
• The order is marked RTO or the courier reports a failed delivery attempt.
• The message reads as a complaint, or the customer has asked twice in a day.

On a hand-off, the workflow sends a short holding reply ("A teammate is checking this with the courier"), then posts a card to a Slack channel or creates a ticket in your help desk with everything it found. The agent who picks it up does not repeat a single lookup. For failed attempts, the non-delivery follow-up playbook covers what happens next.

Step 7: Keep a record and watch the numbers

Each run writes a row to a conversations table in Tables: order, courier, status found, reply sent, and whether it was handed off. A small dashboard on that table shows questions per day, the share answered without a person, hand-offs by reason, and which courier hubs produce the most "no scan" cases.

That last panel often matters more than the replies. A hub that goes quiet for three days shows up in the table before it shows up in your reviews.

Controls

Every run is in Logs with each block’s input and output, so when a customer says the bot told them the wrong date, support can see the courier response it was based on. Phone numbers can be masked in logs with PII redaction, and the workflow runs from a deployed version, so a change to the reply wording is reviewed before customers see it.