Prepared with AI assistance and reviewed for clarity, relevance and unsupported claims.
A product return request workflow should help staff understand the case before they decide what happens next. It should not turn an incomplete message into an automatic rejection, or treat a customer’s description as a verified technical diagnosis.
For an electronics shop or another retail SME in Morocco, the first useful outcome is a review-ready record: the purchase can be located, the reported issue is clear, and an authorised person knows which approved policy and next step to consider. Intake itself does not approve a return, replacement or refund.
1. Define the boundary between intake and decision
Write down what the intake assistant may do. A sensible scope is to acknowledge the request, collect relevant information, locate the order where possible and route the case. Any authority to approve an outcome should be defined separately.
The assistant can explain the merchant’s approved review process using current wording. It should not invent conditions, make legal conclusions or present an internal policy as a complete statement of anyone’s rights.
Use distinct statuses such as “received”, “awaiting customer details”, “ready for review”, “under review” and “decision communicated”. Do not label a case “return accepted” merely because a form has been submitted.
Also separate review from logistics. Receiving a case does not authorise the customer to send a parcel to an address found in an old message. Shipping or drop-off instructions should come from the responsible team when appropriate.
2. Build a minimum useful intake checklist
Ask for enough information to find the purchase and understand the stated problem. Avoid making the customer repeat facts already present in an accessible order record.
- Order reference: or another approved way to locate the purchase if the reference is unavailable.
- Item concerned: product, variant and quantity involved, especially in a multi-item order.
- Relevant timing: purchase or delivery information available to the customer.
- Stated issue: what the customer observed, in their own words.
- Requested outcome: what they would like the merchant to consider, without implying approval.
- Prior contact: any existing case reference or action already discussed.
- Reply channel: where the team should send clarification or a decision.
Do not request a full identity document, complete bank details or unrelated personal information just to open a routine case. If a later approved step needs additional information, explain that step and use the merchant’s designated collection method.
A reference helps, but its absence should trigger an alternative lookup process rather than an invented conclusion about eligibility.
3. Preserve observations without inventing causes
“The charging light does not turn on” is a customer observation. “The battery is defective” is a diagnosis unless it has been established through an appropriate review. Keep those statements separate in the case record.
An AI summary can shorten a long exchange, but it may omit qualifications or turn uncertainty into certainty. Staff should be able to see the original message and correct the summary before making a decision.
Photos can sometimes identify an item or show a visible issue, but they are not universal proof of a cause. Request a specific image only when it serves the review, and ask customers to exclude unrelated documents, faces and private surroundings where practical.
The guidance on handling customer photos and voice notes explains why interpretation should remain cautious. Do not ask a customer to disassemble, power on or repeatedly test a device merely to satisfy an intake checklist; technical instructions belong to an approved process.
4. Route an incomplete electronics request for clarification
Consider this hypothetical message to an electronics shop: “The adapter I bought does not work. I want to return it.” The message gives a broad issue and a preferred outcome, but not enough detail to identify the purchase or item.
Staff: “I can record your request for review. Please send your order reference and tell us which adapter in the order is concerned. When you say it does not work, what do you observe? You do not need to carry out a new test for this message.”
Customer: “I cannot find the reference. It was the adapter collected on Saturday.”
Staff: “Thank you. We will use our purchase lookup process to try to locate it. The return outcome is still pending review.”
The case moves to “purchase lookup needed”, with a named owner. It should not cycle through the same automated request for a reference the customer has already said they cannot find.
If staff cannot confidently match the purchase, they explain which limited additional details would help. They should not disclose another customer’s order information while trying possible matches.
5. Package the case for policy review
A useful handoff lets the reviewer distinguish known facts from missing information quickly. Include the located order, item concerned, original customer description, requested outcome, relevant attachments and any unresolved questions.
Record the approved policy version or internal reference used for review, while retaining the purchase timing and earlier communications. If it is unclear which terms apply, escalate that uncertainty rather than automatically applying today’s wording to an older purchase.
Policy information needs an owner who can update it. The process for keeping support answers aligned with business information is especially relevant when return instructions change.
A strict completeness gate can reduce repeated clarification, but it can also block cases where the customer lacks a receipt or cannot provide a requested image. Permit a reviewer to accept an incomplete case with the missing facts clearly marked.
6. Close the communication loop
Every open case needs an owner and a next action. An acknowledgement should say what has been recorded, what remains missing and how the next update will arrive. Only provide a response deadline that the team has actually committed to.
When a decision is ready, staff communicate the outcome and any approved practical instructions. Keep the decision separate from subsequent completion: a return authorised for review is not the same as a parcel received or a refund processed.
To discuss a bounded intake process with FlowAgent, explore the WhatsApp chatbot service for enquiries and human handoff and share your approved policy and review steps.