Refund Request Triage
Overview
Verifies customer refund requests against the bank before approving them. Signs in to AcmeBank through two-factor, pulls every shipment charge from the operating account and groups them by reference; then works the helpdesk's refund queue, and for each ticket looks up the disputed charge to decide whether the customer was really billed twice. Approves the genuine duplicates and escalates the rest to a human with evidence. Writes a decision CSV.
Refund Request Triage
A customer writes in: "you charged me twice, refund the duplicate." Sometimes that is true. Sometimes it isn't. A support agent who just refunds everyone loses money; one who refuses everyone loses customers. The right move is to check the bank — and that is exactly the swivel-chair work nobody enjoys: helpdesk in one window, banking in another, matching references by eye.
This flow does the checking. It reads each refund request, looks the disputed charge up in the actual bank account, and decides: genuine duplicate, or a single charge the customer misread. It approves the real ones and escalates the rest to a human — with the evidence attached, never an automatic denial.
It runs against two fictional training sites: Grumpdesk (the helpdesk) and AcmeBank (the bank). All data is synthetic.
What it produces
refund-decisions.csv in your home folder — one row per ticket: the customer, the disputed bank
reference, how many charges the bank actually held under it, the decision, and the action taken. On
the seeded queue that comes out to 5 approved and 3 escalated.
How it works
1. Scan the bank first
One trip to AcmeBank: sign in through two-factor, open the Globex operating account, and pull every shipment charge in a single search. Grouping them by reference gives a map of how many times each charge appears — two or more under one reference is a genuine duplicate, one is a single charge.
Doing this once, up front, means the robot never has to swivel back to the bank per ticket. It verifies eight tickets against one scan.
2. Read the refund queue
Sign in to Grumpdesk and open the All view — the refund tickets are assigned to agents, so they
are not in the default Unassigned view. Filtering by the refund tag narrows the list to the
requests that need a decision.
3. Decide each ticket against the bank
For each ticket the robot reads the bank reference the customer is disputing — the one piece of input a human would copy across — and looks it up in the map built from AcmeBank. Two or more charges: duplicate. One: not a duplicate.
The robot forms its own verdict from the bank record. The helpdesk happens to display its own guess, but the flow ignores that and trusts the bank. As a safety rail, Grumpdesk only enables its Approve button when it agrees a duplicate exists, so the robot's decision and the button always line up — if they ever disagreed, the approve click would simply fail rather than pay out wrongly.
4. Approve or escalate
Genuine duplicate: apply the refund-approved macro and solve the ticket. Not a duplicate: leave an internal note with the evidence — one charge under this reference, no duplicate found — and escalate to a human with the priority raised.
This is the point of the whole thing. The robot disagrees with three customers, politely, with the bank record to back it up, and hands those three to a person instead of auto-denying them.
Running it
Ready to run as-is. It signs in with the published training credentials for the two demo sites
(svc.rpa@grumpdesk.example and hiroshi.tanaka@globex.example, with the static two-factor code),
which are not secret. Real system credentials belong in the Robomotion Vault, never in a flow.
A couple of things worth knowing if you adapt this:
- AcmeBank's session is not persisted, so after two-factor the flow navigates client-side (dashboard → account → transactions) rather than by URL; a full reload would drop it back to the login screen. Grumpdesk does persist its session, so the ticket loop navigates by URL freely.
- The bank is scanned once and the tickets are decided from that map. On a real bank with far more than a page of charges you would search per reference instead.
More web automation templates
See all 16 →- Bank ReconciliationTakes the payments and receipts the ERP could not reconcile and confirms each one against the real bank statement. It pulls the ERP's flagged paid-bill exceptions and open invoices awaiting cash, then signs in to the bank, searches the operating account by reference and reads what actually settled - quantifying the four ways money and ledger drift apart: a missing payment, a transposed amount, a double payment and unapplied cash. Writes a reconciliation CSV. The story is evidence: the ledger raises the question, the bank statement answers it, and every discrepancy comes out with a number attached.
- Logistics Exception CenterBuilds one worklist of every active delivery exception from the carrier, then dedupes it against the systems that may already be handling it - the mailbox that was notified, and the help desk where a ticket may already exist. Joining the three on the tracking number tells the robot which exceptions were mailed, which already have a ticket, and which nobody has picked up yet. Writes a consolidated exception CSV. The story is consolidation: three systems each hold part of the picture, and the robot joins them so a stuck shipment is neither missed nor double-worked.
- Monday Morning BriefingOne robot, every system, the whole week's work on a single page. It signs in to the CRM, the mailbox, the ERP, the carrier and the help desk in turn, reads the one number that matters from each - duplicate contacts, invoices to post, ledger exceptions, stuck shipments and refund requests - and writes a consolidated briefing with a total across all five. The story is reach: the back-office queues a team would open one browser tab at a time, gathered into one report before anyone has had coffee.
- CRM Duplicate CleanupCleans up a CRM by merging duplicate contacts - the same person entered twice under name variants like Bob and Robert. Signs in, switches the contact list to its duplicates view, and merges the first remaining pair until none are left, keeping the primary record and folding each variant into it. Writes a before-and-after report. The "your CRM cleaned itself while you slept" demo.
- E-Invoice Portal HarvestDownloads every e-invoice for a tax period from a government portal and builds an index spreadsheet of what was collected. Signs in with a one-time code, walks the paged register until the portal says there are no more pages, then opens each document to read its government reference number and pull down both the XML and the PDF. Every download is gated behind a confirmation dialog and an "I am not a robot" checkbox.
- Friday Payment RunPrepares a weekly vendor payment run in the ERP. Signs in, proposes every bill due within seven days and confirms the run, then separately opens the bills list, filters to the blocked bills the run left out, and reports each one with the reason it is on hold - a pending goods receipt, a quantity or price mismatch against the purchase order, or a missing PO reference. Writes a CSV of what will be paid and what will not.