The Bot's Job Starts Where a Good Email Ends

The hardest ecommerce chatbot decision is not which model to use. It is deciding which questions the bot is allowed to answer.
Start with the questions customers already ask: order status, delivery windows, stock, returns, product fit, and exceptions. Some have a current answer in a system your team trusts. Some can be prevented with a clearer email or product page. Some need a person. Treating all three groups as one automation project creates avoidable risk.

Map the answerable surface

Call that the answerable surface: the questions for which a correct answer already exists in a source the chatbot can reliably reach. That might include order state, delivery window, stock, or policy. Outside that surface the bot is guessing. A fluent guess is often worse than no answer because the customer cannot see the uncertainty until it costs them time or money.
Before automating a question, write down the source that should answer it and the condition that makes the answer current. A policy page may be enough for a general return window. It is not enough for a specific order state. If the source is missing, stale, or unreachable, the correct behavior is a visible boundary and a useful next step.

Use the cheaper-surface test

A question belongs in chat only if it is answerable and a cheaper surface does not solve it first. Put a tracking link in the shipment notice. Explain the return window on the product page. Send a plain delay update when the expected date changes. Chat should handle the remaining questions that still benefit from a conversation.
The same rule explains two common failures. A bot pointed only at generic FAQ text guesses when a question needs current operational data. A bot that tries to pass as human hides the boundary instead of managing it. One is an integration problem; the other is an honesty problem.
A demo cannot prove that production sources are connected, current, or complete. It can help you inspect the interaction: whether the answer is specific, whether the boundary is visible, and whether the next step makes sense. Verify production claims separately against the intended data and workflow.

A five-step scoping exercise

1. List the ten questions your team receives most often.
2. Remove the questions a better email, product page, or status notice can prevent.
3. For each remaining question, identify the exact source that holds the correct answer.
4. Automate only the questions whose source is reliable and reachable.
5. Define a visible next step for everything outside that boundary. ## Run a three-prompt review For each workflow, prepare three prompts before launch:
6. Answerable: the approved source contains one specific expected answer.
7. Missing: the source does not contain the requested detail, so the bot should say so.
8. Human: the request needs judgment or action, so the bot should route it clearly. Record the expected answer, source, boundary, and next step before testing. A response that merely sounds fluent does not pass. Where HoverBot fits For a design-partner pilot, bring one bounded support or lead-capture workflow. The useful starting point is an accessible source, one expected answer, one boundary case, and a human next step. Applying starts a fit review; it does not create an account or guarantee an invitation. Fix preventable questions first. Then map what remains. That is the chatbot's actual job. Explore the catalogue demonstration Apply for a design-partner pilot