Wetel
Go back

Order support for an online shop: what the AI employee does, step by step

Think about the person who answers the inbox at a small online shop. Most of the morning goes on two kinds of message. “Where’s my order?” and “Does this jacket run small?” The first is answered by opening the order system and reading the status. The second is answered from the size guide, the warranty page and the returns policy. Neither is hard. Both arrive at all hours.

That person also knows where their job stops. They do not refund an order because a customer sounds upset, and they do not promise a delivery date the courier has not given. Those decisions belong to a manager, or to the order system’s own rules.

An AI employee for order support should work the same way: read the shop’s systems, answer from the shop’s own material, and stop at the same places. This post walks through our documented order-status and product-support recipe step by step, and is honest about what it does not cover.

The short answer: two jobs, one conversation

The AI employee in the recipe does two things: it looks up an order’s live status in the shop’s order system, and it answers product and policy questions from a knowledge base built from the shop’s own catalog and FAQ. A customer can ask both in the same conversation, and each message is sent down the right path.

It does not refund, cancel or change orders. It reads. Anything that changes an order is a separate decision, covered further down.

How a message moves through it

Each message is classified as an order question or a product question, then sent down one of two paths. This is the shape the recipe documents:

flowchart TD
  M["Customer message"] --> C["Work out what<br/>the customer wants"]
  C --> R{"Which path?"}
  R -- order_status --> X["Pull the order number<br/>out of the message"]
  X --> L["Look up the order in<br/>the shop's order system"]
  L --> RO["Reply with the status"]
  R -- product_question --> K["Answer from the shop's<br/>catalog and FAQ"]
  R -. no match .-> K
  K --> RK["Reply"]
  RO --> E["End"]
  RK --> E

Here is what each step does.

1. It works out what the customer wants. A classification step labels the message as an order question or a product question. A router then follows the path whose label matches exactly. If the label matches neither, the recipe sends the message to the product-question path, on the reasoning that letting the knowledge base try is more useful than a dead-end “I didn’t understand.”

2. It pulls out the order number. A separate extraction step reads the message and returns only the order number, or a “no number found” value if there is none. The recipe assumes numeric order numbers. The step is framed as a pipeline step, not the assistant talking to the customer, so it does not try to chat.

3. It looks up the order in the shop’s own system. The recipe calls the shop’s order system directly with a webhook step. That system has to be reachable from the public internet: an address on a private network is refused when the workflow is saved. The call waits for an answer, up to a time limit you set (10 seconds by default, never more than 30). If you later put the order system behind a connector, a tool step is the longer-term fit and works the same way.

4. It replies with what the system said. The reply is built from the order system’s answer, so the status the customer reads is the status the shop’s system holds at that moment, not a guess.

5. Product questions are answered from the shop’s own material. The answering step has a knowledge base attached. The most relevant passages from the shop’s catalog and FAQ are handed to the model as reference before it replies, so a sizing or warranty answer comes from the shop’s own pages.

A safer version: check the number before you look it up

Our worked examples add one more step: check that an order number was actually found before calling the order system. A condition step sits between extraction and lookup. If a number was found, the lookup runs. If not, the customer gets a specific question back: “I couldn’t find an order number in your message. Could you share it so I can look it up?”

It sounds small. It means a message like “where is my parcel?” gets a clear question instead of a failed lookup, and the order system is never asked about an order that does not exist. The condition docs recommend writing the check so that anything unclear (a missing value, a zero, a stray word) takes the branch that does nothing, which is the safe side.

What it will not do

It reads and answers; it does not change orders, invent statuses or speak for the shop beyond its material. Specifically:

Two honest caveats about failures:

One design decision is yours, not ours: the recipe looks an order up by its number alone. Decide what your order system should return to someone who only has an order number, because that is what the AI employee will repeat.

Where people stay in charge

The shop’s staff keep the decisions, the systems and a full record of what the AI employee did. In practice:

  1. The order system decides. The status is whatever the shop’s system says. The AI employee reads it; it does not override it.
  2. A manager approves anything that changes an order. If you add a refund or cancellation, the approval step pauses the workflow until a workspace owner approves or rejects it, with an optional edit to fields you allow. Owners get an in-app notice; email notice is not available yet. If nobody decides in time (72 hours by default), the workflow follows an “expired” path you wrote. The human approval walkthrough uses a refund as its example, and it is worth putting a reply before the approval step so the customer knows a person is checking.
  3. Conversations that do not fit have somewhere to go. The recipe has no hand-over step of its own. The router can be given a safety net: after a set number of messages in a row that fit no path, the conversation is sent to a branch you choose, typically one that tells the customer how to reach your support team. What that branch says is up to you; the recipe does not move the conversation into a staff inbox.
  4. Staff can read the run record. For each conversation, a signed-in user of your workspace can ask the API for every workflow run and see which steps ran, in order, what each one produced, the exact request sent to the order system, the error the order system returned if it refused, and for the answering step, which knowledge-base passages were retrieved or whether retrieval failed. See observability. These queries need a signed-in staff login; the customer-facing credentials cannot read them.

That record is how you check “the AI employee answered correctly” against evidence instead of trusting the reply. It is also how you find the gaps: a run of messages falling through to the default path tells you the classification list needs another category.

What this walk-through does not tell you

The recipe is a documented starting configuration, not a measured deployment. We have not published how many questions it answers, how often its answers are right, or how much time it saves, and we will not imply a number we have not measured.

It also does not cover returns handling, changing a delivery address, order numbers that contain letters, or anything that writes to the order system. Each of those is a change you would design, test and, where it changes an order, put behind an approval step.

Before customers see it, try it as a draft on your own catalog and read the run records. Point the lookup at a test order system while you do: plan as if a draft test calls it for real. Our post on trying a workflow safely before customers see it is a good start, and when not to use an AI employee is worth reading too.

To build it yourself, start from the order-status and product-support recipe.

Share this post:
Share this post on Whatsapp Share this post on X Share this post on Linkedin Share this post via email
Next Post
What is a run record, and how do I read one?
Previous Post
Why we label everything live, being built or direction