Order status chatbot: a live answer to «where is my order?»

«Where is my order?» — support's most repeated question

In almost every company that sells online, a large share of support messages is the same question: «where is my order?». An agent opens the order system, finds the number, reads the status and writes back. It takes a minute or two, but repeated a hundred times a day it becomes the team's biggest time sink. And customers usually ask it when they are worried — they sense a delay and expect a quick answer.

An order status chatbot can answer with live data — on one condition: the bot has to be able to read the order system in real time. This article covers the status flow, verifying the customer's identity, delivery and return questions, integration requirements and when the bot has to hand over to an agent.

Why the knowledge base is not enough here

A knowledge base is for fixed information: delivery rules, the return period, payment methods. An order's status differs for every customer and changes during the day. The bot can say «delivery takes 2–3 days», but to say «your order was handed to the courier today» it has to read the order system.

In Vexvon the bot can call a company's own APIs as tools — bringing a live answer from the order system to «where is order #1234?» works exactly this way. The API belongs to the company, and the bot sends only the requests it is allowed to.

The status flow

1. 1IntentThe customer writes: «Where is my order?», «When will it come?», «The courier didn't call». The bot recognises these as status questions.
2. 2IdentificationThe bot asks for the order number. If the customer already gave it, it does not ask again.
3. 3Identity checkA second detail to confirm the order belongs to this customer — the phone number, the name on the order or an email. The order number alone is not enough.
4. 4AnswerThe status in plain language: «Your order was handed to the courier this morning and will arrive by 18:00.» Not a system code like «status: SHIPPED_3».
5. 5Next step«Would you like to change the delivery time?» or «If you have another question, I'm here.»

Identity checks: how much and when

Order numbers are often sequential and easy to guess. Someone typing another person's number must not see their address, phone or what they bought.

1. 1Low risk — status onlyOrder number plus the last four digits of the phone. The reply gives only the status and estimated date, not the address or item list.
2. 2Medium risk — a changeChanging the delivery time or address. An extra check is needed, and this step is often given to an agent.
3. 3High risk — paymentRefunds, payment details. The bot does not perform these; it only takes the request and hands it over.

On WhatsApp the enquiry arrives with the customer's phone number — if it matches the number on the order, that is a natural check. In the website widget the customer is anonymous, so the check matters more.

Delivery questions

• «When will it arrive?» — status and estimated date, from live data
• «Do you ship to the regions?» — the rule, from the knowledge base
• «The courier didn't call» — the status is checked and, if needed, passed to the courier service or an agent
• «Can you send it to another address?» — medium risk, usually an agent
• «It's late — why?» — the status and the reason for the delay if the system has one; if not, an honest «let me check» and a handover

The return rule

With a return question the bot has to separate two jobs: explaining the rule and starting the return.

1. 1Explaining the rulePeriod, conditions, exceptions — from the knowledge base, word for word. This can be fully automatic.
2. 2Checking eligibilityIf the order date and product type come from live data, the bot can say «your return window ends in 5 days». It informs; it does not decide.
3. 3Starting the returnThe reason, a photo and the preferred outcome — exchange or refund — are collected and passed to an agent as a ready request. Approval stays with a person.

Handover to an agent

• The order cannot be found or the identity check fails
• The status has not changed for a long time — probably a problem
• The customer received a damaged or wrong item
• Refunds, compensation, an address change
• The customer is unhappy or asks the same question a second time

At handover the agent should see the order number, the status, the customer's question and what the bot has already said.

Integration requirements

On the technical side the status flow needs three things, and they should be checked before the project.

• A read API in the order system — status, date and delivery details by order number
• A field for the identity check — phone or email
• A plain-language translation of status codes — one sentence per code
• An error case: if the API does not respond, what the bot says and who it hands over to

The integration architecture — live reads, writes, events and failure cases — is covered in detail in chatbot API and webhook integration. Which systems can be connected is shown on the integrations page.

A translation table for status codes

In the order system a status is a short code. The customer needs a sentence: what happened, when it will arrive, and whether they need to do anything. The table is written in advance:

1. 1Received«Your order has been received and is being prepared. It usually goes to the courier within 1 working day.»
2. 2With courier«Your order is with the courier and will be delivered today. The courier will call before arriving.»
3. 3Not delivered — customer not reached«The courier couldn't reach you. I'm passing you to an agent to choose a new time.» — the bot does not set the time itself.
4. 4Cancelled«The order has been cancelled.» If the reason is in the system, it is given; if payment was made, the conversation goes to an agent.

When a new status not in the table appears, the bot must not show it to the customer as a code — it should say «let me confirm the status» and hand over.

What to measure

• How many status questions the bot answered completely
• Conversations that stop at the identity check — is the check too complicated
• Conversations handed over because of an API error
• Customers who write to an agent after the status answer — the answer was unclear
• The change in total status questions — sometimes the problem is delivery itself

Limits

The bot can only report the status the system holds. If courier data reaches the order system with a delay, the bot's information will be delayed too — showing «last updated» in the reply is the honest way to handle it. The bot does not issue refunds, does not change an address without a risk check, and does not guarantee the courier's time.

Conclusion: the most asked question needs a live answer

An order status chatbot can close support's most repeated question, but only with live data, a proper identity check and status text in plain language. For returns, the bot explains the rule and prepares the request, leaving the decision to a person. A flow built this way takes the most time-consuming part of an agent's day off their hands.

Building a support bot in stages is covered in the customer support chatbot; the rest of the section is in this category. To discuss connecting your order system, get in touch.

Frequently asked questions

1. 1What system does an order status chatbot need?An API that returns the status for an order number. It can be in the online shop platform, the CRM or the company's own system.
2. 2Can the bot change the address?Technically possible with an integration, but risky. Usually this step is done with an extra check or by an agent.
3. 3What can the bot do without an API?Give the general rules, collect the order number and the problem, and hand over to an agent.