The difficult moment in an automated sales conversation often comes after the answer has been sent. A customer has relied on a delivery date or product description. The business now has to honour the promise or explain why it cannot.
A chatbot’s technical owner may not control stock, fulfilment or refunds. That gap is a management problem. The person maintaining the tool and the person responsible for the customer’s outcome need a shared understanding of what the assistant is allowed to say.
Define the promise boundary
WCRC’s analysis uses Guru Codex’s Stakeholder Trust lens to separate information from commitment. Explaining a published delivery policy is different from guaranteeing an exception. Repeating a product specification is different from advising that it meets an unusual requirement.
A practical review would list the questions that require human confirmation. The purpose is to give staff and customers a reliable route when the system reaches its limit. A generic instruction to “contact support” is weak if support cannot see the conversation or change the decision.
Give corrections an owner
If an answer was wrong because a catalogue was outdated, the remedy involves more than changing a prompt. Someone must update the underlying information and check whether other customers received the same answer. Keeping a record of the correction helps identify whether the problem is isolated or recurrent.
OECD’s work on SMEs and AI provides wider adoption context, including implementation constraints. It does not establish that a particular business has made a misleading promise. Source context.
This explainer makes no allegation about a named company. Its test is prospective: before delegating customer conversations, a business should be able to name who can approve a promise, who can reverse it and who tells the customer what happens next.
Success would be demonstrated through fewer unresolved commitments and a clearer customer experience. It cannot be inferred from the number of conversations automated.