UK airline group · one mailbox reserved for in-flight wifi refund requests
In-Flight Wifi Refunds, Automated End to End, for a UK Airline Group
When a passenger writes "the wifi was bad, refund me", nobody should have to read it before the right form is sent. Each email a person reads is time taken from the cases that really need judgement. We built a flow that turns a free-text complaint into an automatic refund once the checks pass, or into a ticket for the refunds team when the details do not line up.

- Industry
- Retail Customer Service
- Function
- Customer Service & Contact Centre
- Region
- United Kingdom
Results
- 1
- mailbox, used as the trigger
- It has one purpose, so intent classification was not required. A scope figure, not a saving.
- 2
- stages between email and decision
- A form gathers the purchase details, then the transaction is matched and checked. A scope figure, not a saving.
- 0
- manual triage steps anywhere in the flow
- Each request ends in a refund or a refunds-team ticket. By design; volumes were not recorded.
01
The challenge
The client is an airline group based in the UK that sells wifi on board its flights. Passengers who are unhappy with the connection write to a mailbox set up for refunds, in their own words. A typical message runs along the lines of "The wifi was awful, can I have my money back?"
Someone had to read each of those emails, track down the right transaction in the airline's bespoke transaction platform, check whether it qualified, and then either process it or pass it up. All manually, and at volume.
Where the time went
- Staff reading vague emails. Until someone reads a free-text complaint and asks for the purchase details, there is nothing to act on.
- Manual matching. Nothing else could happen until each request was located in the transaction platform.
- Eligibility by eye. For every request, the purchase date, the refund window and the remaining rules were checked by hand.
- Expert time on routine work. Each routine refund handled manually was time taken away from the truly exceptional cases.
02
What we did
Our answer was an automation with one job, driven by rules. It takes a complaint email all the way to either a completed refund or a refunds-team ticket, and nobody triages anything by hand along the way.
Six steps, two possible endings
- A trigger with one purpose. The automation monitors the wifi refund mailbox. Because the mailbox exists only for this, it is the signal on its own. We did not need communications mining or intent classification.
- Collecting details. Each new email is answered with a form asking for what we need to identify the customer's purchase.
- Finding the transaction. Once the customer returns the form, a second stage searches the airline's custom platform for the transaction.
- Applying the rules. The transaction is tested against the refund rules, for example whether the purchase is still inside the refund window. Money goes back only once every rule has passed.
- Refund and confirmation. If the transaction is found and eligible, the refund runs automatically and the customer gets an email confirming it.
- Ticket for exceptions. If the transaction cannot be found, or anything else is wrong, the automation opens an internal ticket for the refunds team to look at. It never fails without a trace and never guesses.
Why we left AI out
If a mailbox only receives wifi refund requests, the topic of every email is already known. Intent classification would have brought a model to train, watch and maintain, plus the chance of misclassifying, and it would not have made any decision the flow actually needed. The structured form hands the rules all the information they need.
Stack
| Layer | Tools |
|---|---|
| Trigger | Mailbox monitoring and email automation |
| Data capture | Web form emailed to the customer |
| Transaction platform | Link into the airline's bespoke platform for transactions and refunds |
| Decision | Eligibility checks driven by rules, refund window included |
| Exceptions | Internal tickets raised for the refunds team |
03
The outcome
Each request now finishes in one of two ways: a refund that has been processed and confirmed by email, or a ticket that puts the case in front of the refunds team.
| Before | After | |
|---|---|---|
| Working out what each complaint is about | Read by a person | Unnecessary, the mailbox tells us |
| Getting the purchase details | One case at a time | Form goes out automatically |
| Locating the transaction | Manual | Looked up automatically |
| Refund window and eligibility rules | Manual checks | Applied before any refund is paid |
| Requests where something does not fit | Handled manually, like every other | Raised as a ticket for the refunds team |
- Nobody triages by hand between the complaint arriving and the refund or ticket.
- A refund is paid only once the eligibility rules pass, refund window included.
- Nothing fails quietly and nothing is guessed. What the automation cannot finish turns into a ticket.
- The refunds team spends its time on exceptions, not on routine refunds that already qualify.
- No numbers to report. Volumes and timings for this project were not kept, so the figures here describe scope, not savings.
A risk that is easy to miss
A refund robot that guesses does more harm than having no robot. One that fails quietly is worse again: the customer waits, nobody is aware, and the complaint returns angrier. If a transaction cannot be found, the safe outcome is a ticket that hands the case to a person. Build that path first, then the happy path.
A related build that handles many intents: inbox triage and one-click help for agents at a car rental group. There, five types of request share one inbox, and every email gets a classification and a confidence score.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.

Bulgarian accounting firm · 10-15 people · bookkeeping for 100+ client companies
Hands-Free Bank Statement Retrieval
- client companies handled twice a month
- 70+
- client companies handled twice a month
- bank portals driven by RPA
- 3
- bank portals driven by RPA

Listed multi-utility · Italy · energy, water, waste and public services across five provinces
UiPath Automation Programme for a Listed Italian Multi-Utility
- automations live in production
- 20+
- automations live in production
- in operation, from 2020 to 2025
- 5 yrs
- in operation, from 2020 to 2025

US oil and gas producer · listed on the NYSE, roughly 120 companies in the group
UiPath Robot Reconciles EnergyLink Partner Invoices for a US Producer
- of manual work taken over by automation
- 1 FTE
- of manual work taken over by automation
- of report downloads cut each month
- ~10 days
- of report downloads cut each month