BulkRefundChecks
bulk-refund-checks:BulkRefundChecks
Confirms the refund type, ingests and deduplicates tickets, sequences the four specialists, then collates the single Approve / Flag result set. Owns everything the sub-skills don't.
One pipeline runs a batch of refund tickets end to end — ingest, triage, verify, check, collate — into a single Approve / Flag result set, while holding the line against fraudulent refunds.
Four one-time steps. Do these the first time you use it — the checks and fallbacks rely on each one — and every run after just works. The full companion guide lives on Notion.
Powers the service-status check: when our own records can't answer, it falls back to the live train-times sites (Recent Train Times / On Time Trains).
Without it, any row that needs the fallback comes back as service status unknown and is flagged — never wrongly approved.
The pipeline always reads Zendesk to gather tickets; writes let it send the automatic replies for the few matched flag reasons.
Left off, matched replies are recorded as (writes disabled) to send by hand. Notes, status and tags are always on.
On the first run, when the process reaches the UTN (barcode) check, it prompts you to log in with the TTK device username and password.
The password is never shown on screen, written into the output files, or stored in the tool itself.
That's it — then just tell Claude ‘Do the bulk refunds’ and it takes it from there.
You point it at the tickets. It does the checks.
One tool works through a whole batch of refund tickets in one go — it gathers them, decides which it can handle automatically, confirms who the customer is and whether they're owed a refund, runs its safety checks, and hands back two lists.
It clears the easy, obvious refunds on its own, stops the dodgy or ineligible ones getting through, and passes anything unclear to a person instead of guessing. You don't run the checks yourself — you tell it the refund type and point it at the tickets.
Refund due if the train was cancelled, delayed or rescheduled and the customer chose not to travel. Claim within 28 days.
Refund due if First Class was declassified or not provided. Claim within 28 days.
That's a Train Operating Company matter — Delay Repay, not a Seatfrog refund.
The short version: used the ticket → no refund from us. Didn't travel because the service was cancelled or disrupted → refund. Travelled but delayed → send them to the train company.
Every refund follows the same route. The orchestrator, BulkRefundChecks, owns the ingest and the final collation and hands each stage to a specialist skill. It calls at five stops before the verdict.
Pull the New refund tickets from a Zendesk view, search, or id-list — read across every page and reconciled against the view count, so nothing is missed. Deduplicate by booking key, and leave out anything raised today (travel must have passed).
Read the customer's own words (and any clear screenshot) to decide what the request really is: a genuine cancellation or declassification, or something for a person — a mistake, a change of mind, or a travelled-but-delayed claim. For upgrades it also splits cancellation from declassification.
One lookup confirms identity and the 28-day window, then returns the booking — route, travel date, ticket numbers, receipt total. Upgrades match on User ID + Sale ID; Flex matches on the booking reference, and the ticket email must match the booking's owner email.
The fraud guard: a UTN check asks whether the barcode was used — tapped in, tapped out, or a Delay Repay claim started. Cancellations then get a service check — did the booked train actually run — from our own records first, live sources only as fallback. A clearly-used ticket skips the service check.
Each ticket lands on one outcome — Approve, Flag, or Deny — written to two lists in your Downloads folder. The only time the tool writes back to a customer is a small set of matched flag reasons with an approved canned reply.
The pipeline is five composable skills. The sub-skills run in pipeline mode inside the orchestrator; the two check skills also run standalone for a one-off scan or service lookup.
bulk-refund-checks:BulkRefundChecks
Confirms the refund type, ingests and deduplicates tickets, sequences the four specialists, then collates the single Approve / Flag result set. Owns everything the sub-skills don't.
…:RefundTriageAndClassify
Reads ticket text and any clean screenshot to set the disposition, and for upgrades the cancellation / declassification category. Makes no admin lookups.
…:RefundVerifyAndHydrate
The single query. Enforces the identity and 28-day gates and returns the hydrated sale record the rest of the pipeline reuses.
…:BulkUTNChecks
Reports each sale's UTN scan status as APPROVE / FLAG / DENY. Standalone or in pipeline. Scan status only — no service lookup.
…:BulkServiceStatusChecks
Looks up whether the booked train was cancelled, delayed, or disrupted — refunds-hsp archive first, RTT / OTT via Chrome as fallback. Makes no refund decision.
The scan gates, the actuals confirm. A delay never auto-approves — that is a Train Operating Company matter, not a Seatfrog refund.
Didn't travel and the upgrade was unused, or the actuals confirm the booked segment was cancelled or disrupted. Safe to refund.
Needs a human: ambiguous scan, unknown service, identity mismatch, out-of-scope request, or a duplicate ticket.
Proof of use — a clip or exit scan — or a Delay Repay claim, or a claim raised more than 28 days after travel.
| UTN check says | Result | Why |
|---|---|---|
| Used on board the train or Delay Repay claim already made | Deny | They used the upgrade, so the declassification claim doesn't hold up. |
| Unclear | Flag | A person should look. |
| Not used | Approve | We can't disprove it and the upgrade wasn't used → refund stands. |
| UTN check | Did the train run? | Result | Why |
|---|---|---|---|
| Used | Not checked | Deny | Scanned and accepted for travel — any delay is a TOC claim. |
| Not used | Cancelled / disrupted on their leg | Approve | Didn't travel → refund. |
| Not used | Ran (on time / only delayed) | Flag | Claim not supported — a delay is for the train company; a person decides. |
| Not used | Can't tell | Flag | Needs a person to review. |
| Unclear | — | Flag | The scan isn't clear enough; needs a person. |
Both land in your Downloads folder, named by product and date. The first column of each is refund_type — each product is refunded through a different system, so it must show on every row.
refund_type,zendesk_ticket_id,sale_id,
user_id,category,utn,service_status
flag_type,refund_type,zendesk_ticket_id,…,
reason,service_status,related_ticket_id,macro_reply
| flag_type | What it means | What you do |
|---|---|---|
| DENY | The checks would refuse it — proof they travelled, Delay Repay, or a claim over 28 days after travel. | Work the refusal — reply / decline. |
| FLAG | Needs judgement — unclear scan, unknown train status, email didn't match. | Review and decide. |
| SURFACE | Triage caught it as not belonging here — a mistake, a delay claim, an early termination. | Handle by hand. |
| DUPLICATE | A second ticket for a booking already in the batch. | Close it against the primary (in related_ticket_id). |
Both written to ~/Downloads · the customer's email is never written to any file — you find them by zendesk_ticket_id
The tool writes back to a customer in exactly one situation, and it keeps the two lists honest so no ticket is worked twice.
A small set of flag reasons have an approved canned reply, sent whole so the right tags and fields go on too. Everything else is left for you to send by hand. If Zendesk replies are switched off, the tool skips the send and marks the row (writes disabled).
| Type | Reason | Canned reply |
|---|---|---|
| Upgrade | Wrong / unconfirmable reference | Incorrect reference |
| Upgrade | Delay Repay already claimed | Upgrades: Delay Repay Already Started |
| Flex | Delay Repay already claimed | Claimed for Delay Replay |
Before you start (and now and then as you go), the tool re-checks each ticket's status. Any ticket that's no longer New has already been picked up — by a colleague, an earlier step, a merge, or an automatic rule — so it comes off the list rather than being worked.
As each ticket is worked, it comes off the list. Working a ticket moves it off New, so it shouldn't stay on the list. The lists shrink to empty as the batch clears — which is what stops two people refunding or replying to the same ticket.
Read-only ticket ingestion, and the gated public-reply macros — the pipeline's only outward write.
RDS sale & flex_state_prod queries, the refunds-hsp archive, and TTK scan lookups.
Only for the Recent Train Times / On Time Trains service-status fallback.
Check the refund type first. It decides the list, the details, and how tickets are sorted.
Today's tickets are always skipped — travel has to have happened first.
We never refund a used ticket, and a delay is always a train-company matter, never an automatic yes.
A mismatched email means flag, not decline — it's almost always a typo, not fraud.
Refund figures always include the Platform Fee — the receipt TOTAL, £3 per passenger on upgrades.
Never work a ticket that isn't New — someone's already on it. When in doubt, it gets flagged, not guessed.
More macros Claude can send automatically — even less manual handling of flagged cases.
Claude will merge duplicate requests automatically.
After the checks run, Claude will surface flagged cases in the terminal to review and action — removing them from the Flag list as they're worked, and completing any investigation needed.