Shipping is the question shoppers ask before buying and the one they chase afterwards, which makes it the highest-value page in your content. A chatbot for shipping questions can settle cost, delivery time, destinations, cut-offs and tracking, but only if the shipping page states those numbers in text rather than in a table image or a courier's PDF.
The five facts a shipping answer needs
| Fact | How customers ask | What the page must state |
|---|---|---|
| Cost | "How much is delivery?" | Price per method and destination, and the free-delivery threshold |
| Time | "How long does it take?" | Working days per method, counted from dispatch or from order |
| Destinations | "Do you ship to Norway?" | Countries or zones you serve, and any you do not |
| Cut-off | "If I order now, does it go today?" | The daily cut-off time, the time zone, and which days count |
| Tracking | "Where is it?" | Whether tracking is provided, when the link arrives, and which courier |
Two of these are routinely missing. The cut-off time is often known only by the warehouse, and the excluded destinations are usually implicit, which leaves the assistant unable to say no. Both are quick to add and both prevent complaints.
Structuring the page
- A heading per destination group: domestic, EU, rest of world. Within each, the methods with cost and days.
- Numbers in the text. A rate table as an image cannot be read by the assistant, and often not by a screen reader either.
- Working days defined. Say whether weekends and public holidays count, because "3–5 days" means different things to you and the customer.
- The cut-off with a time zone. "Before 3pm UK time, Monday to Friday" is answerable; "same-day dispatch" is not.
- Duties and taxes for international orders, stated plainly, including who pays them. This is the single most expensive surprise for cross-border shoppers.
- One copy of each number, so the checkout, the footer and the FAQ cannot disagree.
The general writing format is in how to write a chatbot knowledge base, and the same discipline applied to returns is in a chatbot for returns and refunds.
Estimates are not promises
This is a guardrail worth setting deliberately: the assistant should quote the range from your content and never convert it into a specific date, unless you genuinely offer a guaranteed service and say so on the page. The wider set of rules is in chatbot guardrails for online stores.
Peak season needs a different page, not a different bot
Delivery questions change character in November and December: the wording shifts from "how long does it take" to "will it arrive in time", and the cost of a vague answer rises. The fix is a dated section on the shipping page listing the last order date for each destination and method, written as a question and kept current. With that in place the assistant quotes real cut-off dates instead of hedging, and you can remove the section in January rather than editing the assistant. Add one line about what happens when a courier misses a deadline, because that is the follow-up question, and it is far better answered by your policy than improvised at 11pm on a Sunday.
Where is my parcel?
Once an order exists, the question moves from policy to data. With the store plugin connected, the assistant looks up the order by number and email and reports the status and tracking link, which is the single most requested task in store chat. What it should not do is interpret the courier's scan history or predict a new date. If tracking has stalled or the parcel shows delivered but is missing, that is a person's job, and the handover should carry the order reference and transcript, as set out in chatbot human handover. The platforms where lookup works without custom development are listed on the integrations page.
Wording for the awkward cases
- Delayed parcel: "Tracking last updated on Tuesday, which is slower than usual. Couriers sometimes stop scanning in transit. If there is no movement by Friday I will pass this to the team to chase."
- Delivered but missing: "Tracking says delivered yesterday at 14:12. That needs a person, so I am passing it on now with the order number. They reply Monday to Friday 9–6."
- Country you do not serve: "We do not currently ship to that country, so I would not want you to place an order that cannot be fulfilled. The full list of destinations is on the shipping page."
- Cut-off just missed: "Today's dispatch closed at 3pm, so this will go out tomorrow morning, then 2–3 working days."
- Customs charge: "Orders outside the UK may attract duties and import VAT, which the carrier collects on delivery and which are not included in our prices."
Why it matters beyond support
Delivery terms influence the purchase, not only the support queue. Baymard's research on cart abandonment lists unexpected delivery costs and slow delivery among the reasons shoppers leave a checkout, and an assistant that answers cost and timing on the product page removes that hesitation before it becomes an exit. In our own conversation data across real stores, shipping sits among the largest topic buckets alongside order status; the figures and the method behind them are in our ecommerce chatbot statistics. The underlying mechanism, an assistant searching your pages and composing an answer rather than following a script, is described in Lewis et al., 2020.
A half-hour of work that pays
Rewrite the shipping page with a heading per question, put every number in text, add the cut-off with its time zone, name the destinations you do not serve, and state who pays duties. Connect the plugin so tracking questions become lookups. Then ask the assistant the five facts and the five awkward cases above and score the answers, using the method in how to test AI chatbot accuracy. Every Vatdi plan includes order lookup, handover and the dashboard; the allowances are on the pricing page, and the wider setup order is in the AI chatbot implementation guide.
Frequently asked questions
Can a chatbot answer delivery questions?
Yes, for cost, timing, destinations, cut-offs and tracking, provided your shipping page states those in text. Before an order exists the answers come from the page; afterwards they come from a live lookup through the store plugin. What it should avoid is converting a range into a specific delivery date.
Why does the bot not know my delivery date?
Because your page almost certainly quotes a range of working days rather than a guaranteed date, and the courier decides the rest. An assistant that invents a date creates an obligation nobody agreed to. If you genuinely sell a guaranteed service, say so on the page and the assistant will quote it.
How should the shipping page be structured?
A heading per destination group, methods with cost and working days beneath each, the daily cut-off with its time zone, the free-delivery threshold, who pays duties, and the countries you do not serve. Numbers in text rather than images, and one authoritative copy of each figure.
Can it tell customers where their parcel is?
With the store plugin connected, it looks up the order by number and email and reports the current status and tracking link. It should not interpret courier scans or predict a new arrival date. A stalled or missing parcel goes to a person with the order reference attached.
What about international duties and taxes?
State the position plainly on the page: whether prices include duties, who pays, and that the carrier usually collects on delivery. Cross-border shoppers hit with an unexpected charge frequently refuse the parcel, so a clear sentence before purchase costs far less than the return afterwards.
Does this work in other languages?
Yes. The assistant replies in the language the shopper wrote in, using your page as the source, so one well-written shipping page serves several markets. Accuracy still depends on the page: if the cut-off is missing in English, it is missing in every language.
