The Bot's Job Starts Where a Good Email Ends

Merchants are not arguing about whether AI chat works. They are arguing about scope, and they have been right about it longer than most vendors have been selling it.

Two public ecommerce discussions in two days made that case better than a product roadmap could. In the first, a store owner asked whether AI chat was worth adding, not for tool recommendations but for operating experience. The narrowest answer was also the most useful: use it for order status, shipping estimates, return policy, and the questions already sitting in an FAQ that customers will not open. There is a real answer waiting, so nobody needs the model to improvise. The approach falls apart the moment someone has an actual problem.

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.

Then the second discussion took the best example away.

An ecommerce operator explained what actually reduced order-status tickets, and it was not a chatbot. It was rewriting the messages already going out: put the tracking link in the confirmation as soon as it exists, send a plain notice when a shipment slips, and make the delivery email useful rather than ceremonial. Many anxious check-ins never happen when the customer already knows what changed.

That is not a counterargument. It is the missing half of the rule.

Use the cheaper-surface test

A question belongs in chat only if it is answerable and nobody has found a cheaper, simpler surface for it. Order status is the clearest case in both directions: perfectly answerable, but often better handled by a timely email. What remains, the lost message, the unusual exception, the question that arrives after hours, is real and smaller than most chatbot pitches imply.

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.

The harshest objection deserves respect. Some merchants see a chatbot as proof that a seller cut corners on service. They are usually describing a bot deployed across a surface it cannot cover, which is what most customers have encountered.

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.

Fix preventable questions first. Then map what remains. That is the chatbot's actual job.

Test the boundary in the catalogue demo

Apply for a design-partner pilot