Home · Solutions · Customer service
Solution · Customer serviceEvery return gets an RMA number, a label and a refund date on the day it is requested
Returns and refunds without a ping-pong of emails
Eligibility, RMA, label, inspection, credit note and refund run as one flow; the customer is told what happens next at every step and only genuine exceptions reach a person.
Executive summary
Three weeks, two phone calls and eleven emails to give a customer their money back.
We build one flow that owns the return from request to money.
The customer learns the outcome on the day they ask, instead of waiting for an agent to reach their place in a queue.
SAP S/4HANA (returns order, credit note, stock); the payment provider refund API; the carrier label API
Business problem
Returns management
A return is not one process. It is three decisions taken by three departments: service decides whether the item may come back, the warehouse decides what condition it arrived in, finance decides when the money leaves. Each holds a third of the answer, none can see the other two, and the only person following the case end to end is the customer.
What joins those decisions is email, and email has no state. An accepted request looks exactly like one nobody has read. The RMA number lives in a sent item. A parcel that arrived on Tuesday waits on the bench until someone has time, and the inspection result is written on a printed list before it is typed anywhere. Finance is asked for a credit note with no way of knowing whether the goods are back. Every gap becomes a day, and every day becomes a customer message answered without new information.
Returns are also the journey that gets worse exactly when volume peaks: the week after a promotion, the fortnight after the holidays. The desk absorbs the surge with overtime, refunds slip past the statutory window, and unbooked stock loses value while it waits.
How it works today
A return arrives as free text in most retailers with more than one sales channel, whatever the ERP.
- PersonThe customer writes to the returns address or fills in a web form; an agent copies the details into a spreadsheet
- PersonThe agent checks order date, channel, payment method and warranty in the webshop admin and SAP, then decides
- WaitingAnything unusual waits for the hub or the category manager, typically one to three working days
- PersonAn RMA number is taken from a numbering sheet, a label created in the carrier portal and pasted into an email
- WaitingThe parcel queues on the goods-in bench; the inspection result is written on a printed list and typed up later
- PersonFinance is asked by email for a credit note, and chased weekly until it appears
- SystemThe refund is triggered by hand in the payment provider's back office and reconciled at month end
- Risk of errorUnreadable RMAs, double refunds and credit notes for goods that never arrived surface weeks later
Why the current process costs more than it appears
Time that disappears before anyone measures it.
- Handovers, not handling, produce the calendar days. The work is three or four short touches in different teams; between them the case sits, which is why a two-week refund holds a quarter of an hour of effort.
- Every customer chaser is rework paid twice: by the agent looking up a status no system holds, and by the customer, whose view of the brand is formed by the wait, not the product.
- Stock nobody has booked in cannot be sold. Units on the bench are invisible to the ERP, neither available for resale nor written down, and electronics lose value every week they wait.
- Refund errors are quiet and expensive. A double refund, a credit note without goods, or a refund to a method the customer no longer holds surfaces at reconciliation, and correcting it costs more than the transaction did.
- Peak season is when the process is worst and matters most. A desk that copes in a normal month needs overtime in December, the only lever it has.
Cost of inaction
December is solved with overtime, the spreadsheet grows a tab a month, and the desk keeps coping. What accumulates is quieter: refunds that miss the legal deadline in a small share of cases, returned stock losing value on a bench, and a cost per return nobody can quote because it was never measured.
The exposure worth naming to a board is the compliance one. A distance seller owes the money back within a fixed period from the moment a customer announces a withdrawal, and a median of two and a half weeks leaves no margin for a sick day.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European electronics retailer: 90 stores in four countries, its own webshop, two marketplace channels, about 2,400 employees, SAP S/4HANA, Microsoft 365 E3 and one central returns hub.
5,500 return requests a month; roughly 55% webshop withdrawals inside the statutory 14 days, 30% warranty claims inside the two-year legal guarantee, 15% store returns settled centrally.
Requests arrive by email and web form, are logged in a spreadsheet, checked against the webshop admin and SAP by hand, given an RMA from a numbering sheet, inspected on a printed list, then turned into a credit note and a refund by two manual steps.
About eleven minutes of handling per return split over three or four touches, plus the waiting between them. Median request-to-refund is two and a half weeks, and half of all customer messages carry no new information.
One intake form and one queue; eligibility from a rule table service and finance own; RMA, label and confirmation within minutes; inspection as a Teams task at the hub; returns order, credit note and refund posted by robots in SAP and through the payment provider API.
In the modelled case request-to-refund falls to a few days after the parcel is scanned in, the share of returns needing an agent drops to inspection plus the exception tail, and the desk stops answering "where is my money". Illustrative, not a client result.
Proposed solution
We build one flow that owns the return from request to money. Requests arrive through a Microsoft Forms return form on the webshop and in stores, through the marketplace feeds, and through the mailbox that keeps receiving them anyway. Each becomes a transaction in a UiPath Orchestrator queue carrying the order and serial number, and a robot reads order, delivery date, channel, payment method and warranty status from SAP to apply the eligibility rules: withdrawal window, legal guarantee, sealed or opened, serial matched to the invoice, value against the goodwill threshold. Eligibility is a rule table service and finance own and version, not a judgement made from memory on a Friday afternoon.
Accepted requests are answered in minutes. The robot issues the RMA number, calls the carrier API for a label, sends a confirmation stating the expected refund date, and books the expected parcel so the hub knows what is coming. When it is scanned in the customer is told it arrived, which removes the most common reason for a phone call. The hub operator completes a UiPath Action Center form task, delivered as an actionable notification in Microsoft Teams: condition code, accessories, serial match, photographs. Where the hub wants its own goods-in screen we build a Power Apps canvas app that returns the same result through the UiPath connector for Power Platform, currently Preview and premium-licensed.
The money leg then runs without anybody asking. Robots post the returns order and credit note in SAP, release the stock movement so the unit becomes visible for regrading, refund the original payment method through the provider API, and write the provider reference against the credit note so reconciliation matches at posting.
There is no AI here, by design. Eligibility and credit-note logic are rules with legal and accounting consequences, and a rule an auditor can read beats a model somebody has to trust.
Microsoft Forms responses as an intake trigger; UiPath Orchestrator queues, triggers and audit; UiPath Action Center form tasks with actionable notifications in Microsoft Teams; Microsoft Teams Approvals app; SAP BAPI and SAP OData connectors; UiPath Integration Service Connector Builder
The eligibility rule table and its version history, RMA numbering and documents, the inspection form and condition codes, SAP returns-order and credit-note posting, the refund call and its reconciliation reference, customer messages, exception routing, the dashboard
Carrier label and payment refund APIs as Connector Builder connections; marketplace feeds through seller APIs, or a scheduled export where none exists
How the automated process works
- AutomationA return form, a marketplace feed row or a store till record creates one case in an Orchestrator queue with the order and serial number
- SystemThe robot reads order, delivery date, channel, payment method and warranty status from SAP and applies the eligibility rules
- AutomationAccepted requests receive an RMA number, a carrier label and a confirmation stating the expected refund date
- PersonRequests outside policy, including goodwill, late withdrawal and missing proof of purchase, reach the service manager as a Teams approval
- AutomationThe parcel is scanned in at the hub, the case moves to inspection and the customer is told it arrived
- PersonThe hub operator completes the inspection task: condition code, accessories, serial match, photographs
- AutomationRobots post the returns order and credit note in SAP, move the stock, refund the original payment method and archive the evidence
- AutomationThe customer receives the refund confirmation with the credit note; the dashboard shows every open case, its age and who holds it
Human-in-the-loop model
Automation handles
- Intake from every channel, deduplication, and the eligibility decision against order, delivery and warranty data
- RMA numbering, carrier label, expected-parcel booking and the four status messages
- Returns order, credit note, stock movement, refund call and write-back of the provider reference
- Reminders, SLA timers and the daily view of what is waiting and with whom
People decide
- Goodwill, late withdrawals and anything the rules mark as outside policy, inside delegated limits
- The physical condition of the item and whether it is complete, the judgement no rule makes from data
- Disputed cases: serial mismatch, transit damage, returns where customer and inspection disagree
- The rules themselves: withdrawal windows, condition codes, deductions and thresholds
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- Microsoft Forms return request
- webshop and marketplace return feeds
- store till returns export
- the returns shared mailbox
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
- UiPath Integration Service
Target systems
- SAP S/4HANA (returns order, credit note, stock)
- the payment provider refund API
- the carrier label API
Human touchpoints: inspection tasks in Microsoft Teams; Teams Approvals for out-of-policy refunds; the Power Apps goods-in screen
Technologies used
queue every return, run the eligibility rules, post to SAP, retry, log and audit
Ainspection and exception tasks completed where the hub already works
Athe return request form on the webshop and in stores; each response starts a case
Agoodwill and above-threshold refunds approved with evidence attached
Aoptional goods-in screen on the returns-hub PC
Aorder, serial and warranty lookups; returns order, credit note, stock
Acarrier label and payment refund APIs as one governed connection
AIllustrative economic model
What it is worth, with the arithmetic shown.
Eleven minutes per return is three or four short touches across service, the hub and finance, including answering chasers, and €22 is a fully loaded hourly cost for a returns-desk role in Central Europe. Both illustrate typical ranges; neither is a measurement taken at a client. We model released capacity, not headcount, and leave out the resale value recovered by faster regrading, usually the larger number.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- The customer learns the outcome on the day they ask, instead of waiting for an agent to reach their place in a queue
- Refunds leave inside the statutory window because the credit note and the payment call follow the inspection result, not an email to finance
- Returned units become visible in the ERP the moment they are scanned, so regrading and resale start days earlier
- Inbound "where is my refund" contacts fall, because the status is pushed to the customer four times
- Peak weeks are absorbed by the queue rather than by overtime, and the same team covers new stores or channels
- Policy is applied identically everywhere, removing the gap between what the website promises and what the desk does
The management view
- Returns stop being a black box: cost per return, cycle time and exception reasons are measured for the first time, by channel and category
- Policy becomes an instrument you can steer. Changing a withdrawal window or a restocking rule is a versioned edit to a table, live the same afternoon in every market
- Approval limits are enforced by the flow, so goodwill spending is bounded rather than found later
- The process survives holidays and resignations, because eligibility sits in the rule table, not with four people
Board-level KPIs
Security and governance
Control is not an add-on.
- Robots run under their own SAP accounts, limited to returns orders, credit notes and related stock movements; no employee shares a password with an automation, and every posting carries the case reference
- Refunds are bounded by design: only to the original payment method, only up to the original amount, and above the configured threshold only after a named approval in Teams
- Card and payment identifiers are never held in the flow; the robot keeps the provider's transaction reference, not the instrument
- Case data, documents and inspection photographs stay in your Microsoft 365 tenant, the automation layer in the UiPath Automation Cloud EU region
- Rule-table changes and approval limits are versioned and signed off, so an audit can reconstruct which rule applied on any day
Why now
A distance seller in the EU must reimburse a withdrawing customer within 14 days of being told, under Consumer Rights Directive 2011/83/EU, and honour a minimum two-year legal guarantee under Directive (EU) 2019/771. Both are met by process design, not by asking the desk to try harder
The modelled €22,200 a month of handling capacity is the visible part; what appears in no budget is the resale value lost while unbooked units wait in the busiest weeks
Integration work that made this a portal project five years ago is now configuration: human tasks are completed inside Microsoft Teams, and a carrier or payment API is a governed connection
Relevant executive roles
Returns become a measured operation with a cycle time and a cost per unit, not the queue that absorbs whatever the front end sends
Credit notes are posted against goods demonstrably back, refunds reconcile at posting, and goodwill spending is visible before it reaches the margin
The desk answers questions that need judgement instead of re-reading its own emails; four status messages replace most inbound contact
Common questions and objections
Most are not exceptions, they are unwritten rules. Three months of history usually shows a handful of conditions covering most decisions, and anything genuinely unusual goes to a person with the evidence attached.
Nothing new is decided. The rules are the policy you already publish, written down and versioned, and the flow applies the thresholds you set. Above them a named manager approves in Teams, and every decision keeps its rule reference.
They do not have to open Teams for anything else. The inspection task arrives as a notification they complete in a few taps, and where the hub prefers a goods-in screen we build one that writes back the same result.
When this is not the right solution
- Teams handling fewer than a few hundred returns a month, where a shared inbox with a good template and a weekly review is cheaper
- No usable link between request and original order, for example marketplace channels exposing no order reference; matching comes first
- A policy that exists only as case-by-case negotiation, with no channel-level rules anybody will write down
A question for the next management meeting
Between a customer telling us they want to return something and the money leaving our account, how many days pass, and on how many of those days is anyone working on the case?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- Return history for three months: channels, reasons, policy exceptions, cycle times and where the days accumulate
- The eligibility rule table, written with service and finance, versioned and owned there
- Intake from the Forms request, the marketplace feeds and the mailbox into one queue
- RMA numbering, carrier label integration, the customer messages and the expected-parcel booking
- The inspection task in Action Center and Teams, condition codes, and a goods-in screen if wanted
- SAP returns-order, credit-note and stock posting, the refund call and the reconciliation write-back
- Pilot on one channel, then rollout with hypercare and a runbook for desk and hub
We need from you
- Three months of return history with the matching SAP documents and dates
- The returns policy per channel and country, including goodwill practice as applied
- Technical accounts for SAP, the carrier portal and the payment provider API
- A process owner in customer service and a counterpart in finance for credit-note rules
Stages
Discovery
History, channels, policy exceptions, volumes and real cycle times with the owners
Design
Target flow, rule table, condition codes, approval thresholds, messages, security
Build
Robots, queue, SAP posting, carrier and payment connections, Teams touchpoints
Validation
Replay of historical returns, exception handling, acceptance by desk and hub
Go-live
Controlled start on one channel with supervision, then the rest
Optimisation
Monitoring, rule tuning, new channels, reporting on cost and cycle time
Departmental. Effort follows the number of channels and countries with different policies, the number of payment providers, and how much policy exists only as practice.
Eleven days after the parcel went back, nobody can say where it is.
Send us one month of return statistics: requests by channel and reason, your policy rules, and the dates of request, receipt and refund. We come back with a cycle-time breakdown of where the days go and which decisions are already rules.
Price one month of returnsThe neighbouring process usually has the same problem
Every third customer contact asks where an order is; the answer already sits in SAP and the carrier portal.
View solution Customer serviceEvery customer email classified and routed on arrivalYour best agents spend their morning sorting mail instead of answering it.
View solution Supply chainCustomer orders from PDFs and emails straight into the ERPCustomer POs still get retyped from PDFs into SAP and confirmed hours later. Stop paying your order desk to type.
View solutionIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerce