Chatbot on a Shop: The Five Questions It Should Answer on Day One

Spend a week reading an ecommerce support inbox and the shape of the work becomes obvious. A handful of question types repeat until they blur, and someone answers each one by hand, usually pasting the same three sentences they pasted an hour earlier. That repetition is the case for automation. It is also the trap.

Why Day One Matters More Than Feature Lists

Rollouts fail when a shop launches a bot meant to handle everything a customer might possibly ask. The ones that work start narrow: pick the questions that dominate the inbox, answer them properly, leave the rest alone. Ambition on day one produces a bot that improvises, and improvisation in customer support means wrong answers at scale.

Five buckets cover the overwhelming majority of what a shop receives: order status, delivery time, returns, stock and sizing, and payment. From the customer’s side they look like the same kind of question. Behind the scenes they behave completely differently. Narrowing the scope this way is easier when you know which features actually answer shop questions and which ones only look useful in a demo.

Here is the split that decides everything. Some answers come from static knowledge you already have written down. Others need live data pulled from your shop at the moment of asking. Confusing the two is the single biggest cause of a bot that lies to customers. A knowledge base cannot know where a specific parcel is right now, and pretending otherwise damages trust faster than having no bot at all.

Question One: Where Is My Order?

Highest volume in almost any shop, and the one owners expect a bot to solve first. It is also the one least suited to a knowledge base alone. A genuine status lookup means pulling that customer’s order record live, which requires an integration and a way to verify who is asking. No uploaded document produces that. Ever.

What a knowledge-base bot handles well on day one is everything around the status: how tracking works, which email address the tracking link goes to, what each carrier status label actually means, how long a parcel sits in limbo before it counts as lost, and what the shop does next. Customers asking “where is my order” often want exactly this, and nothing more.

For a small team, ship the explanatory version with a clean route to the tracking page and stop there. For a larger operation building the integration, scope the failure path before launch: what does the bot say when the lookup times out or comes back empty? What breaks is a bot that guesses at status because nobody told it that it does not have the data.

Question Two: When Will It Arrive?

Delivery time is a different question from order status, and it arrives before the purchase at least as often as after it. Someone deciding whether to buy wants to know if it lands before the weekend. So this is a revenue question, not just a support one.

Almost all of it is answerable from static sources: order cut-off times, dispatch windows, carrier options, country-by-country ranges, and what happens across weekends and public holidays. Feed the bot your shipping policy plus the internal note nobody publishes - how dispatch stretches during sale weeks, or before Christmas.

The common failure is structural. Shipping rules usually live in three places at once: the policy page, the checkout copy, and a spreadsheet in operations. They contradict each other, and the shop survives because no customer reads all three. A bot reads all three and exposes the contradiction to everyone at the same time. Reconcile the sources before you upload anything - the bot will only ever be as consistent as the files behind it.

Question Three: How Do I Return This?

Returns questions are procedural, repetitive and almost entirely policy-driven, which makes them the strongest automation candidate on day one. Nothing here needs live data. Window length, condition requirements, who pays return postage, refund timing, exchange rules, category exclusions - all of it sits in a document you have already written.

• The exact return window and whether it counts from order date or delivery date
• Condition requirements: tags attached, original packaging, unworn or unused
• Who pays return shipping, and whether that changes for faulty goods
• How the return label is obtained and what the customer does with it
• How long the refund takes once the parcel is received, and to which payment method
• What cannot be returned at all, named by category rather than implied

Damaged goods and disputes are judgement calls, not policy lookups. Use the admin panel scope settings to define what the bot must never decide and where it sends that customer instead. Those cases need a handover to your team that keeps the context, because making the customer repeat the whole story is what turns a return into a complaint. Tone matters more here than anywhere else: someone asking about a return is already mildly unhappy, and a cold answer is what turns mild into escalated.

Question Four: Do You Have It, And Which Size Should I Take?

This one hides two questions with completely different data needs. Treat them as one and you get a bot that is confidently wrong half the time. Getting stock levels right depends less on the bot itself and more on how you prepare the source documents behind each answer.

Stock availability is live data by definition. Without a feed, the honest response is that the bot cannot confirm current availability and the product page shows the real number. A bot repeating a stock figure from a document uploaded three weeks ago is worse than silence, because the customer believes it.

Sizing is the opposite. Fit notes, measurement tables, materials, care instructions, compatibility details - static, stable, and usually the most neglected content in the entire shop. They sit in supplier PDFs and product guides nobody ever indexed. Which is exactly what knowledge base upload is for.

This is the highest-value pre-purchase use of a chatbot on a shop, and I would build it first if the inbox let me. A fast, specific fit answer prevents an abandoned cart and a return in the same exchange. Personalised answers and multilingual support carry real weight here, since sizing conventions differ by market and a shopper reading a foreign size chart usually guesses wrong. If a second market is already sending you messages, running a bot in two languages is a smaller job than most shops expect.

Question Five: Why Did My Payment Fail?

Lowest volume of the five, highest urgency, and the only one where a slow reply loses the sale outright. Someone staring at a declined card will not wait until morning. They close the tab and buy elsewhere.

Much of it is static and easy to document: accepted payment methods, currency handling, the usual reasons a card gets declined, when an authorisation hold releases, why a duplicate charge often appears on a statement and then disappears, plus invoice and VAT questions from business buyers.

Never let the bot near anything requiring card details or account access. Set the scope configuration to forbid it outright, and word the refusal as a redirect rather than a dead end. Encrypted HTTPS transmission covers the conversation itself, but good design keeps sensitive credentials out of that conversation entirely.

Building The Five Answers Without Building A Project

The assembly order is unglamorous and takes an afternoon rather than a quarter. Collect the documents you already own: shipping policy, returns policy, size guides, payment FAQ, supplier specification sheets. Reconcile the contradictions you find, because you will find them. Upload the reconciled set, then configure the bot’s name, tone and scope in the admin panel.

Scope is the setting that decides whether the rollout succeeds. Define explicitly what the bot answers and what it refuses, so unknown questions get pointed somewhere useful instead of improvised.

Test with real messages from your inbox, in the customer’s own wording, typos included. Clean test sentences you wrote yourself prove nothing. Botino gives you a free first voicebot after registration, which is enough to run this exercise properly before committing. If you would rather have the document work and the setup done for you, that is what our implementation offer covers.

Start Narrow, Then Widen

The honest division holds up. Returns, delivery windows, sizing and payment questions are answerable from documents you can upload today. Order status and stock availability need live data, or a clear, deliberate admission of the limit.

Judge the first month by accuracy, not volume. The number that matters is how many questions the bot answered correctly without a human rewriting the reply afterwards. A bot handling everything badly is a liability disguised as productivity.

And the durable point is this: most of the work sits in the source material, not the technology. Reconciled shipping rules, a specific returns policy and properly indexed size guides make the shop better whether or not the bot is switched on tomorrow.