Complaint chatbots: Who can promise the refund?

“We will refund the amount.” That sentence sounds friendly and unambiguous in a chat. Those qualities make it unsuitable as an improvised answer from an assistant whose job is only to receive a complaint. A chatbot can assemble the case, reduce repeated questions and identify a reachable next step. Promising a refund, replacement or acceptance of responsibility needs a separate decision rule.

For a Swiss SME, this distinction matters when requests overlap. A customer dislikes an appointment, reports a defect and asks for money back in the same conversation. Those are several issues. Labelling everything “complaint” and sending an apology has not created a case the team can resolve. Begin by separating intake, examination and decision.

What the first conversation can establish

Ask which order is involved, what the customer objects to and what outcome they want. They should not need to tell the story three times. The assistant can offer a concise summary for confirmation: “You are reporting a damaged item from order X and requesting a replacement.” That describes the request. It does not confirm that a replacement has been approved.

Ask for missing details individually and explain why they are needed. A photograph can help with visible damage but is not necessary for every complaint. Do not request a complete identity-document copy merely because a case is awkward. Verification should match the information disclosed and the action contemplated. A general product complaint needs a different level of assurance from changing a delivery address or initiating payment.

Four statements with different consequences

Statement	Meaning	Requirement
Receipt acknowledged	The request has been recorded.	A real case identifier and saved record.
Review arranged	An assigned team will examine it.	Ownership and a workable reply channel.
Solution proposed	An option is under consideration.	Wording that does not imply approval.
Refund approved	A specific decision is communicated.	Authorised approval and recorded status.

The wording must agree with the recorded state. “We have passed your case on” is wrong if the ticketing system could not be reached. That situation needs an honest failure message and an alternative contact route. Likewise, “Your refund has been initiated” should appear only when the responsible payment process has confirmed that status.

A change of mind differs from a defect

The Swiss government SME portal explains that Swiss online purchases do not have a general statutory right to return goods simply because the buyer changed their mind. Voluntary return terms are a separate matter. Defect-related claims also need their own assessment. The assistant should not answer all three with one universal returns policy.

The SECO guidance on general terms explains their inclusion in a contract. Provide the applicable current company terms, product scope and decision owners. Businesses selling into other countries must check the relevant transaction context. A deadline encountered somewhere in training data must not become a standard answer to every customer. When the conditions are not established, the assistant records the facts and routes the decision to the responsible person.

A useful case record beats a long transcript

The team needs the order, contact route, reported issue, requested remedy, missing evidence and statements already made. A complete conversation on its own is cumbersome. A structured summary helps if it distinguishes what the customer says from verified facts. “Customer reports missing accessories” is more accurate than “Accessories are missing” when nobody has checked the delivery.

Keep relevant original passages available for review without copying unnecessary personal information into every notification. The person opening the case should see what supports the summary. If the customer corrects it, incorporate the correction. The system should not keep reviving an earlier assumption as an established fact in subsequent replies.

Enforce decision boundaries in the system

A prompt saying “Do not promise refunds” is useful, but it should not be the only control. The assistant should initiate a refund solely through an authorised operation. That operation checks the amount, qualifying order, approval role and current payment status. Free text in the conversation must not bypass those checks.

Even a permitted goodwill amount needs a defined basis. Check whether the order or customer has already received a remedy and which repeated attempts belong to the same case. A politely reworded conversation should not become an entirely new entitlement. If the connection fails after an operation, query its status before attempting it again.

Make the human handover workable

A useful handover identifies an owner and a next step. “Someone will get back to you soon” is difficult to verify. A supportable message might say, “Our service team will review the case and reply through the email address you provided.” Add a specific deadline only when the business can deliver and monitor it.

Define holiday cover and escalation for unanswered cases. Potential safety problems, threats and disputed legal demands need the responsible team. The chatbot can record and route them. It should not independently adjudicate the situation or close it with an ordinary goodwill offer. Staff also need a way to correct the assistant’s recorded classification without rewriting the whole conversation.

Test the awkward wording

Use invented cases: “Your colleague already promised the refund”, “Please pay into a different account”, or “Just write that you accept fault.” These are test examples, not reports about AlpenAgent customers. The correct result might be a question, verification of an existing decision or a handover. A fluent answer is insufficient evidence that the workflow behaved correctly.

Include a case without an order number and one involving two orders with similar items. The assistant should avoid exposing another customer’s information or attaching a complaint to the first plausible match. Let the service owner examine the prepared record and decide whether it provides enough information for the next step. Check whether attachments are accessible to that person and whether the customer has a reference they can use later.

When the customer does not reply

Define what happens when a requested detail never arrives. Record the unanswered question and assign review rather than interpreting silence as acceptance of a proposed remedy. If a later email adds another issue, connect it to the existing case and show what changed. Check any refund or replacement already in progress before starting another action. A fictional case arriving first by chat and later by email is a useful acceptance exercise.

Compare the reply, stored status and operation actually executed. All three should agree. Our article on inbox triage for service teams explains the broader intake. For an AI chatbot, bring your complaint types, decision rights and two difficult cases. They provide a concrete basis for rules your team can understand and verify.