Endelir
Start free
Use case

Returns, refunds and cancellations on WhatsApp

Endelir lets customers start a return, refund or cancellation in a WhatsApp chat, collects what your policy asks for, routes it to a person, and sends the status back. Every business gets the message that starts "I want to return this" or "can I cancel?". Endelir gives that message one place to arrive, collects what your policy actually needs before a person reads it, and keeps the customer told while the decision is made. The decision stays yours.

Start free for 14 daysTalk to us
A young woman behind a shop counter replying to a customer on her phone
Live
Message to inbox in under a second.

The request arrives everywhere, and then goes quiet

A return request comes in by whatever route the customer finds first — a message to the number on the packaging, a reply under an old order confirmation, a call to the shop, an email nobody has opened since Friday. Each one arrives with a different half of what you need. One has an order number and no reason, the next has a long explanation and no way to tell which of three orders it is about.

Then comes the chasing. The customer has heard nothing, so they write again, and again on a different channel, and the second person to answer knows nothing about the first conversation. Meanwhile nobody can say how many requests are open, which are waiting on a decision, and which were settled a week ago and never told to the customer.

One route in, one record, one owner

The request comes to your business number and lands in the shared inbox with the rest of that customer's history. Before anyone reads it, a chat flow can ask for the order or booking reference, the reason, and a photo where the condition of the item matters — images and documents arrive in the chat like any other message. The answers are written onto the contact record, so a person opens a request that is already complete rather than one that needs three rounds of questions.

From there it is assigned to whoever handles post-purchase, and the assignment is visible so two people do not answer the same customer with two different outcomes. Endelir does not decide whether the refund is due — your policy and your people do that, in the system that holds the order. What Endelir carries is the conversation around it: the request going in, the decision coming back, and each status update reaching the customer without anyone having to remember.

How it works

  1. 1 The customer asks They write to your business number — from the packing slip, an earlier order message, a website button or a QR code — and say they want to return, refund or cancel something.
  2. 2 The order is identified A flow asks for the order or booking reference and saves it to the contact record. Endelir does not hold your orders, so the reference is what ties the conversation to the record in your own system.
  3. 3 Your policy is stated The flow replies with the terms as you wrote them — the window, the condition, what can and cannot be sent back — so the customer knows where they stand before they pack anything.
  4. 4 The details are collected Reason, preferred outcome, photographs of the item, a pickup address. Each answer goes onto the contact record, and the pictures stay in the conversation.
  5. 5 It reaches a person The flow hands the conversation to the team that handles returns. When someone takes over, the automation stops on that conversation so the customer is not answered twice.
  6. 6 A person decides Approve, refuse, offer an exchange, or send it for review. Endelir does not approve refunds on its own and does not move money — the credit is issued in your payment system.
  7. 7 The customer is told The outcome and each step after it go back on the same thread. Inside the service window your team simply replies; later than that, the update is an approved template.

What this looks like in practice

A retailer sells clothing and gets returns every day. Before, the requests arrived on three channels and were tracked in a spreadsheet somebody updated in the evening. Customers who had already sent an item back wrote to ask where their money was, and the person answering had to go and find out.

Now the request starts on the business number. A flow asks for the order number, the reason, and a photograph if the item is faulty, then hands the chat to the returns desk with all three already saved against the contact. The person on the desk checks the order in the shop system, approves it there, and the credit is issued there. As the refund moves, the shop system calls Endelir and the customer gets an update on the same thread — received, approved, refunded — without asking for it.

What can happen next

A person takes it on The assigned team member answers from the shared inbox, with the order reference, the reason and the photos already in front of them.
The request reaches your system A flow step can call a URL of yours as the request is made, so a ticket or a return record is opened in the system you already use.
A status update comes back out When your system marks the return received, the refund approved or the money sent, it calls Endelir and the customer is told on the same thread.
An alternative is offered Your team can propose an exchange, a credit note or a different date instead of a refund, and the customer answers in the chat.
It is passed on A request that turns out to be a complaint, or one that needs a manager to allow an exception, is reassigned with its history intact.
It is answered outside the window If the customer has gone quiet for more than a day, the next update goes out as an approved template rather than a free reply.

What to know before you set it up

A customer who writes to you first opens a service window, and inside it your team answers freely — no template needed for the back and forth of a return. An update sent after that window has closed is a business-initiated message and uses a template Meta has approved in advance. An update about a return, a cancellation or a refund the customer actually asked for is transactional, and that is the permission it rests on. Add a discount to tempt them back and the message becomes Marketing, which needs recorded consent — Endelir refuses a marketing campaign to contacts without it, so send the win-back offer separately, and only to customers who have given it.

Endelir does not hold your orders, your bookings or your money. There is no packaged shop connection to switch on today, so the order is identified by the reference the customer gives, and the refund is approved and paid in your own systems. Where you want the two joined up, a flow step can call your URL when a request is made and your system can call Endelir's API when the state changes. That is a small piece of developer work, not a setting.

Nothing here approves a refund by itself, and that is deliberate. A flow can state your policy, collect what the policy asks for and route the request, but eligibility is a judgement about your own terms and a person makes it. The same goes for exceptions: a request that falls outside your stated window is passed to someone who can decide, rather than answered with a promise nobody authorised.

What to watch

  • How many return, refund and cancellation requests arrive each week
  • How long a request waits before a person owns it
  • How long it takes to go from request to decision
  • How many end as a refund, an exchange, or a refusal
  • How many customers write again to ask for a status
  • How many requests fall outside your stated policy window

Questions people ask

Can customers request a return through WhatsApp?

Yes. The request arrives on your business number and a chat flow collects what your return policy asks for before a person reads it: the order reference, the reason, the item, and a photograph where the condition matters. Those answers are saved onto the contact record and the pictures stay in the conversation, so the person who picks it up has the whole request in one place. Endelir does not hold your orders, so the reference the customer gives is what ties the chat to the record in your own system.

Can a customer cancel a booking through WhatsApp?

They can ask to, and the request reaches the right person with the booking reference and the reason already captured. What Endelir does not do is cancel the booking itself — there is no calendar or reservation book inside it, so the actual booking is released in whatever system holds it. That matters practically: until someone updates the booking there, any reminder you have scheduled for it will still go out. Where you want this joined up, a flow step can call your own URL the moment a cancellation is requested, so the system that holds the booking hears about it as it happens.

Can Endelir approve a refund automatically?

No, and that is on purpose. Eligibility is a judgement about your own terms — the window, the condition of the item, what was promised at the time of sale — and a person makes it. A chat flow can state your policy, gather everything the policy asks for and put the request in front of the right team quickly, which is where most of the delay actually sits. The approval happens in your system, and Endelir has no part in moving the money.

Can customers receive refund status updates?

Yes. Once a refund exists in your system, that system can call Endelir's API each time the state changes and the customer gets an update on the same thread they started: request received, approved, processing, money sent. Because the message is triggered by the real state, it says what is actually true rather than what somebody assumed. Inside the service window it goes out as an ordinary reply; if the customer has been quiet longer than that, it goes out as an approved template instead. Your team can also send any of these by hand from the inbox.

Are refund and cancellation updates Utility messages?

A non-promotional update about a transaction the customer started — a return they requested, a booking they cancelled, a refund already in progress — generally fits Utility. Keep the content to the facts of that transaction and it stays there. The line is crossed when you add something promotional: a discount code to keep them, or a suggestion to buy something else. That is Marketing, a different template category, and it needs recorded consent. Endelir enforces consent on marketing campaigns, so the practical advice is to send the two as separate messages rather than folding an offer into a refund note.

Can a customer exchange an item instead of returning it?

Your team can offer one in the conversation, and a flow can ask the question with the options you wrote into it — exchange, credit note, refund — then take a different path depending on which one the customer answers with. What it cannot do today is read live stock and tell the customer which size or colour is available, because Endelir holds no catalogue and has no packaged connection to a shop. In practice that means the alternatives are either options you configured, or ones the person handling the request checks and offers themselves.

What happens if a return is outside the allowed period?

The flow states your policy as you wrote it, and the request is routed to a person rather than refused by the software. Nothing invents an exception on your behalf: there is no assistant improvising terms you never agreed, so a late request simply reaches someone who is allowed to decide, with the order reference and the reason already collected. They can approve it as a goodwill exception, hold it for a manager, or explain the position — and whichever they choose, it is recorded on the same conversation for the next person who opens it.

Keep post-purchase requests in one place, from the first message to the refund.

Put returns, refunds and cancellations on your business number and give each one an owner. We set the number up with you on a call and walk through your own policy while we do it.

Start free for 14 days Talk to us

14 days free. No credit card. We call you to set the number up.