Free Order Status Tracker Chatbot Template: WISMO

The Order Status Tracker is a ready-made Conferbot flow that answers the single most common question in retail support: where is my order. Instead of a customer emailing your inbox and waiting, the bot identifies the order, reads back its status and estimated delivery date, and then offers the handful of follow-up actions people actually want next -- tracking the parcel, changing the order, reading the return policy, or talking to a person.

It ships as a seventeen-node conversation with every branch already wired, so there is nothing to design from scratch. What you are buying, in effect, is the conversation architecture: the decision about which three ways a customer may identify an order, what happens when they cannot identify it at all, and where each dead end routes so that nobody is left staring at a chat window with no button to press. Those are the decisions that take the longest to get right when you build a support flow yourself, and they are the ones this template has already made.

The flow is built entirely from standard Conferbot nodes -- a welcome node, two branching choice nodes, a custom question, an email capture, a yes-or-no question, a redirect, two human handover nodes and a set of message nodes. That matters because it means every word the bot says is editable in the visual builder, and every branch can be rerouted by dragging an edge. There is no hidden logic and no code. If you can read the flow diagram, you can change the bot.

The template is aimed at any business that ships physical goods and gets repetitive status enquiries: online retailers, subscription boxes, direct-to-consumer brands, marketplace sellers, spare-parts distributors and the small operations teams that sit behind them. It is a particularly good fit when your order volume has outgrown a shared inbox but has not yet justified a dedicated helpdesk deployment. If your problem is narrower and sits further down the supply chain -- freight, multi-leg shipments, customs -- look at the logistics shipment tracking chatbot instead, and if the conversation you really need to automate is the one after delivery, the return and exchange assistant covers that ground.

One thing to be clear about before you start: the copy that ships with the template is sample copy. It refers to a generic store, quotes a thirty-day return window and prints a placeholder support address. None of that is a Conferbot policy or a Conferbot statistic -- it is filler written so the flow reads sensibly in a demo, and rewriting it is the first job of your setup.

Here is the flow exactly as it ships, following the edges from the welcome node. Reading it in order is the fastest way to decide whether the template fits your process or needs reshaping.

1. Welcome

The welcome-node opens with: "Welcome to our Order Status Tracker! I'm here to help you check the status of your order. Let's get started!" There is no menu here and no delay -- the bot moves straight on, which keeps the first turn short.

2. How would you like to identify your order?

An n-choices node asks "How would you like to identify your order?" and stores the answer in the variable identification_method. The three options are Order Number, Email Address and I don't have my order information. That third option is the detail worth noticing. Most home-built status bots assume the customer is holding a confirmation email; this one assumes some of them are not, and gives that group somewhere to go rather than leaving them to abandon the chat.

3a. Order number path

Choosing Order Number leads to an ask-custom-question node: "Please enter your order number:" saved as order_number. Because this is a free-text question rather than a validated field, it will accept whatever the customer types, so the format hint you put in the prompt is doing real work -- say whether your numbers carry a prefix and how many digits to expect.

3b. Email path

Choosing Email Address leads to an ask-email node: "Please enter the email address associated with your order:" saved as customer_email. This node validates the format and replies "Please enter a valid email address" on a bad entry, so typos are caught in the conversation rather than in your queue.

3c. No order information

Choosing I don't have my order information hits a message node -- "I understand you don't have your order information. Let me connect you with a customer service representative who can assist you further." -- which flows immediately into a human-handover node. That handover is configured with medium priority, automatic agent assignment, a five-minute maximum wait, a handover email notification, an audible alert for the agent, and the tags order_inquiry and no_information. If nobody picks up inside the wait window the fallback message apologises and points the customer at a support email address. Those two tags are useful: they let you count, later, how many of your chats arrive from customers who could not find their own order details, which is usually a signal about your confirmation emails rather than about your bot.

4. Retrieval and status read-back

Both identification paths converge on a message node that sets expectations -- "Thank you. I'm now retrieving the status of your order. This may take a moment..." -- and then on the status message itself: "Your order #{order_number} is currently {order_status}. The estimated delivery date is {delivery_date}." The first variable is captured in the conversation; the other two are placeholders you fill from your own system, which is the one integration decision this template forces you to make and which the setup guide below covers.

5. Anything else?

An n-choices node then asks "Is there anything else you'd like to know about your order?" storing further_assistance, with five options: Track shipment, Modify order, Return policy, Speak to customer service and No, I'm done. This node is the hub of the whole flow -- three of the five branches loop back to it, which is what stops the conversation from being a one-shot lookup.

6. The five follow-up branches

Track shipment goes to a user-redirect node labelled "Track your shipment", prompting "Click here to track your shipment" and pointing at a tracking URL that already interpolates the captured order number. After the redirect the customer is returned to the hub.

Modify order is honest about its limits: a message node explains that modifications need the support team, and the edge runs straight into the second human-handover node -- same medium priority and five-minute wait, tagged order_inquiry and customer_service.

Return policy states the sample policy and asks whether the customer wants more detail or help starting a return. That leads to a yes-or-no-choice node -- "Would you like to initiate a return for your order?" with the labels Yes, initiate return and No, just more information, saved as initiate_return. Yes routes through a short confirmation into the customer service handover; no prints the longer policy text and drops the customer back at the hub.

Speak to customer service goes directly to the handover node, and No, I'm done ends with "Thank you for using our Order Status Tracker. If you need any further assistance, please don't hesitate to contact us. Have a great day!" Both handover nodes also terminate at that same closing message, so every path in the flow has a proper ending.

Understanding the node types is what lets you extend the template confidently rather than only editing its text. Seven types do all the work here.

The welcome-node is the entry point and simply prints an opening line. The n-choices-node is the workhorse: it renders a prompt with tappable buttons, writes the chosen label to a variable, and gives each choice its own outgoing edge. Both branch points in this flow -- identification and the follow-up hub -- are n-choices nodes, which is why they are so easy to reorder or extend.

The ask-custom-question-node captures free text against a named variable and is used for the order number. The ask-email-node does the same for an email address but adds format validation and a configurable retry message. The yes-or-no-choice-node is a two-option branch with editable labels, used for the return decision -- note that the labels do not have to read "yes" and "no", and in this template they do not.

Message nodes are one-way statements with no input; they are where the status read-back and all the reassurance copy live. The user-redirect-node presents a link with its own call-to-action text and can interpolate captured variables into the URL, which is how the tracking link is personalised without any code.

The human-handover-node is the most configurable node in the flow. Beyond the message a customer sees, it controls priority, whether agents are assigned automatically or by strategy, how long to wait before giving up, what the fallback says, whether your team gets an email and a sound alert, and which tags are attached to the conversation. Live-chat handover and the unified inbox are available on every Conferbot plan, including the free plan, so you do not need to upgrade to make the escalation paths in this template work.

What the template deliberately does not include is a calendar node, an image node, or an AI knowledge-base step. It is a deterministic flow: the customer picks from buttons, and the bot follows edges. If you would rather the bot understood typed questions in natural language, that is a layer you add -- Conferbot supports OpenAI GPT, Anthropic Claude, Google Gemini, DeepSeek and seventeen other providers -- but the value of the shipped template is precisely that its behaviour is predictable.

Five design choices in this template are worth calling out, because they are the ones people get wrong when they build a status bot themselves.

The escape hatch

A status bot that only accepts order numbers fails for exactly the customers who need it most -- the ones who deleted the confirmation email, ordered as a guest, or are chasing a gift sent to someone else. Giving that group an explicit "I don't have my order information" button, tagged so you can measure it, turns a silent abandonment into a tracked support conversation.

The hub pattern

Most of the template's usefulness comes from one structural decision: the follow-up question is a hub, not a terminus. A customer can read the return policy, come back, check the tracking link, come back again, and only then say they are done. That is why a seventeen-node flow can cover four distinct jobs without feeling like four separate bots.

Escalation as a first-class path

There are two handover nodes rather than one, and they carry different tags. That separation lets you tell the difference between "I could not identify my order" and "I want to change or return something" in your analytics, which is the data you need to decide what to automate next. Both routes land in the same live chat inbox, where agents see the full transcript and every variable the bot captured, so nobody has to ask the customer to repeat their order number.

Six steps take the template from library to live. None of them require code.

Step 1: Open and fork the template

Find the Order Status Tracker in the support and FAQ template library and create your own copy. Forking gives you an editable flow in your workspace; the original stays untouched, so you can fork it again later if you want to compare against the shipped version.

Step 2: Rewrite every line of demo copy

Work through the nodes in order and replace the sample text. The specific items that must change are the placeholder support email address in both handover fallback messages, the thirty-day return window in the return-policy node, the bracketed "[Include detailed return policy information here]" stub in the detailed-policy node, and the example tracking URL in the redirect node. Leave any of those in place and your bot will confidently tell customers something untrue about your business.

Step 3: Decide how the status read-back gets its data

This is the one real decision in the build. The status message references an order status and a delivery date that the conversation does not itself collect. You have three honest options. The simplest is to keep the flow informational -- rewrite the message so it sends the customer to your own tracking page via the redirect node, and let your storefront supply the status. The second is to wire a webhook or API call that looks the order up in your own system and writes the result back into the conversation; webhook and API access require the Starter plan or above. The third is to lean on the escalation paths and let an agent answer the status question in the inbox, using the bot purely to collect and tag the enquiry. Pick one before you publish -- a status node that prints raw placeholders is worse than no bot at all.

Step 4: Configure the handovers and notifications

Open both human-handover nodes. Set the priority you want order enquiries to carry, choose automatic assignment or a specific agent group, and adjust the five-minute maximum wait to something your team can actually meet. Keep the handover email and sound alerts on while you are learning the volume. Confirm the tags, since those are what make the analytics useful later. Then connect the notification and record-keeping integrations you need -- Conferbot ships native connectors for Gmail, Google Sheets, Google Calendar, Google Meet, Google Docs, Google Drive, Slack, Discord, HubSpot, Zoho CRM, Notion, Airtable, Stripe, OpenAI, Zapier and webhooks, with a great many more apps reachable through Zapier. Logging each enquiry to Google Sheets and pinging a Slack channel on handover is a common starting pair.

Step 5: Choose channels and test the branches

Publish to the website widget first and walk all five hub branches plus both handover paths yourself. Check that the redirect URL resolves with a real order number substituted, that the email node rejects a malformed address, and that a handover actually appears in your inbox with the right tags. Then add the other channels you want.

Step 6: Watch the first fortnight

For the first two weeks, read transcripts rather than just dashboards. You are looking for three things: which identification method customers actually choose, how often the no-information branch fires, and which hub option gets picked most. Those three numbers tell you what to automate next and what copy to tighten. After that the flow largely runs itself, and you can revisit it when your policies change.

The shipped flow is a starting point, and the node types it uses make several extensions straightforward.

Add a third identification route. The identification node is an n-choices node, so adding a fourth button costs one option and one edge. Tracking number and phone number are the usual additions -- for the latter, use an ask-phone-number node rather than a custom question so the input is validated.

Split the hub by order state. Today every customer sees the same five follow-up options. If your orders have meaningfully different states, you can branch after the status read-back so that a customer with an undelivered order is offered tracking first while a customer with a delivered order is offered the return path first. That is one extra choice node and some re-routed edges.

Capture satisfaction at the end. Drop a rating-choice or opinion-scale-choice node before the closing message to find out whether the lookup actually helped. If you want that scored and trended for you, the CSAT dashboard is available on the Pro plan and above; otherwise write the answers to Google Sheets and read them yourself.

Slow the bot down deliberately. A delay node after the "retrieving your order" message makes the pause feel intentional rather than broken, which matters more on messaging channels than on a website widget.

Enrich the handover. Both handover nodes support pre-chat questions, so you can ask a customer to summarise the problem in their own words before an agent joins, and post-chat survey questions for a rating afterwards. The technical support triage template is worth reading for how much further that pattern can be pushed.

Localise it. If you ship internationally, either duplicate the flow per language or look at how the multilingual customer support template routes by language at the top of the conversation.

Replace the buttons with understanding. If your customers would rather type "where's my parcel" than tap a menu, add an AI step in front of the identification node using the natural language layer and let the deterministic flow handle everything after intent is known. Keep the button path as a fallback -- it is the part that never surprises anyone.

Conferbot publishes the same flow to ten channels -- the website widget, WhatsApp, Facebook Messenger, Instagram, Telegram, Slack, Discord, LINE, Microsoft Teams and the mobile SDK -- and channels are not gated by plan, so the choice is about where your customers are rather than what you are paying.

For order status specifically, three channels do most of the work. The website widget is the natural home, because a customer chasing an order is usually already on your site, and the redirect node can drop them straight into your tracking page. WhatsApp suits markets where order confirmations already arrive there; the button-driven design of this template travels well to messaging, since every branch point is a tappable list rather than a typed answer. Instagram and Messenger matter for social-first brands, where a large share of status questions arrive as direct messages on the same account that ran the ad.

Telegram and LINE are worth enabling if your customer base skews to regions where those are the default messengers. Slack and Microsoft Teams are less about customers and more about your own staff -- a wholesale or B2B operation can run the same tracker internally so that account managers self-serve order status instead of asking operations. Whichever channels you enable, conversations land in one omnichannel inbox, so the handover experience is identical regardless of where the chat started.

On plans, the flow itself runs on the free tier: one chatbot, 600 conversations a month, two team members, and full access to live-chat handover and the unified inbox, which are the two capabilities this template depends on most. You move up when you outgrow the conversation allowance or when you want the API and webhook access that makes a real order lookup possible -- that begins at Starter, at nineteen dollars a month with 2,000 conversations and three bots. Pro adds white-labelling, A/B testing and the CSAT dashboard; Business adds an audit trail and single sign-on. Paid plans carry a fourteen-day trial and a seven-day refund window, and the current breakdown is on the pricing page.

A closing note for 2026: a status tracker is the highest-volume, lowest-complexity conversation most retailers have, which makes it the right first automation rather than the most impressive one. Get this flow answering accurately, watch which branches customers actually use, and let that decide whether your second bot is a returns assistant, a post-purchase survey or something you have not thought of yet.