Chatbots for returns and complaints with clear approvals

EU. “I do not like it” and “it arrived broken” describe different situations. EU consumer distance purchases generally carry a 14-day withdrawal right, with exceptions; remedies for defective goods are a separate matter. The EU consumer guide to returns and withdrawal explains the framework. It does not justify automatically rejecting every report received after 14 days.

Switzerland. Switzerland does not provide a general withdrawal right for every contract; retailers may offer contractual return rights. The Swiss Federal Consumer Affairs Bureau explains that distinction. Do not generate one DACH-wide deadline without assessing the particular transaction. Sources checked on 26 September 2026.

Approved rules. Maintain approved rules by market, contract type and product. Route legally unclear or disputed cases to the responsible staff. Customers must still be able to report a complaint when the standard form does not fit their circumstances.

Start with the reason for contact and the desired next step. General guidance about returning an item does not yet require personal order information. When the bot reads or changes a specific case, use the approved identity and authorisation process.

The table lists five return and complaint requests with the context each requires and the approved next step.

Photographs may help, but collect them purposefully through an appropriate channel. Do not ask for complete payment details or identity documents merely because a generic conversation flow permits attachments. Explain which details are required and which simply assist review.

Two reasons. A fictional customer ordered two products. She dislikes item A, while item B arrived damaged. The chat identifies each order line and records the reasons separately. It does not classify the entire order as either a change-of-mind withdrawal or a damage claim.

Two next steps. In the example, the return portal may accept a request for A. The service team must assess B under its approved complaint rules. The confirmation explains both next steps. A shared case reference can preserve the relationship while item, quantity and processing state remain distinct.

Partial outcomes. If label generation for A fails, the successful recording of complaint B must remain visible. Conversely, creating a label for A does not approve a refund for B. Acceptance testing should include precisely these partial outcomes rather than only a single-item demonstration.

A traceable process can distinguish these states:

• requested
• reviewed
• label available
• in transit
• received
• decision made
• refund confirmed

Required steps depend on the approved workflow. Translate those states into language customers understand.

Precise confirmation. “Your return is complete” is misleading when only a label has been generated. A more precise confirmation says that the request was recorded and identifies the items covered by the label. Payment commitments must come from the process responsible for them.

Repeat contact. When a customer asks again three days later, the chat should recognise the existing case. Otherwise it may generate duplicate labels, competing tickets or repeated reviews. Use a unique case reference and clarify repeat contact before another write operation.

Uncertain result. Record uncertainty explicitly. If the label service times out after accepting a request, investigate its actual result before creating another label. Do not turn a missing response into an invented success or an automatic second purchase.

Triggers. An explicit request for a person, a disputed rejection or conflicting order details should open a clear service route. Repeating the same questions to preserve a high automation percentage does not help resolve the issue.

Transfer these details when a return or complaint goes to staff:

• the request
• affected items
• verified identity state
• previous actions
• the outstanding decision

Preserve the distinction between the customer's original statement and a generated summary. A model must not turn “arrived damaged” into “customer damaged the item”.

Outside staffed hours. Outside staffed hours, provide an available contact route. Do not promise a response deadline the team has not committed to. If case creation fails, explain that failure instead of inventing a ticket number or implying that work has started.

Include these cases in the acceptance test for a returns and complaints chatbot:

• partial returns
• split shipments
• an existing case
• missing authorisation
• an unreadable image
• an unavailable label integration
• a report after the ordinary return period that actually concerns a defect

The expected result is the appropriate assessment rather than automatic rejection based on the date.

Inspect the customer's understanding too. Is it clear where the goods should go, which items are covered and whether further action is needed? Correct internal records are insufficient if the customer sends the wrong product or omits the information needed to identify it.

Test any external portal and downloadable label as part of the journey. The chatbot may explain the process accurately while an inaccessible form or expired link still prevents completion.

Track complete requests, correct routing, duplicate cases, repeat contacts and time to a confirmed result. Treat necessary staff review as an intended process outcome rather than automatically calling it chatbot failure.

An approved solution needs subject rules, an accountable team, supported system actions and clear status messages. Begin acceptance with one complete return case and one complete complaint case. Their documented results show whether the automation actually helps customers and staff progress through the workflow.

These pages cover the service overview, the industry page for online merchants and the related decisions for returns and complaints in chat:

• AI chatbots for customer service
• AI automation for online merchants
• Shopify order-status chat without exposing other customers
• Customer-service AI chatbots: plan the human handover
• AI workflow approvals: who checks which action?

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.