A Claude sidekick for the support desk
When a ticket lands in your lap, Scout has already scouted ahead - read the customer's history, pulled the auction, sale and refund state from our systems, and worked out what's likely wrong. You make the call. It does the legwork.
The problem
Before an agent can help anyone, they're hopping between Zendesk, the admin panel, and half a dozen internal lookups just to understand what happened. Scout collapses that.
How it works
A tight loop with you in the middle. Claude never acts on its own judgement - it hands you the picture and waits for your call.
A ticket is assigned or a customer replies. Claude reads the live ticket and pulls everything relevant from our systems.
→You get who the customer is, what they're asking about, what our systems actually say, and the likely cause.
→You pick an action from the menu - or tell it what to do in your own words. The decision is always yours.
→Claude sends the reply, applies the change, or - where there's no safe automated path - flags exactly what needs doing.
You set the pace
The biggest worry with anything automated is that it'll bury the team. Scout can't. There's a human at the keyboard the whole time, and one word puts it on hold.
Tickets keep queuing safely while you're paused - nothing is lost, nothing bounces to a customer. You come back and pick up exactly where you left off. It surfaces one ticket at a time, at your speed, never a flood.
/scout-pauseStop pulling new tickets - finish what's in hand. Toilet break, lunch, heads-down./scout-resumeStart pulling again when you're ready./scout-skipNot for you? Release the ticket back to the queue for someone else./scout-stopEnd the session entirely. Clock off./scout-statusWhat's in hand, are you paused or running, how deep is the queue.Why it's worth it
Minutes of context-gathering per ticket disappear. You open a ticket to a full picture, not a blank page.
Claude presents and recommends; the human makes every call. No action happens without your explicit go-ahead.
Refunds and credits are never fired automatically. Where there's no safe path, it flags precisely what needs doing.
Customers already mid-conversation are worked first. Fresh tickets wait behind the people who've been waiting longer.
New abilities - a refund tool, a credit tool - slot in and light up automatically. No rewrite when the toolkit expands.
It combines Zendesk, our production systems and rail data behind a single conversation. No tab-juggling.
Trust is built in, not bolted on. Every action is logged, gated, and impossible to run away with.
Every action - taken or flagged - is written back to the ticket as an internal note, tied to the human who approved it.
Its own notes and replies are ignored by the pipeline by design, so it can never re-trigger itself into a spiral.
Actions that move money or change a booking have no automated path today - Scout flags exactly what's needed for a human to do. That boundary is locked by an automated test; nothing financial can fire by construction.
Where it is today
Straight with you on status - the whole loop is real and running. What's left is proving it on live tickets and hardening it for scale.
Signed, replay-protected Zendesk ingestion → two priority queues → a live session woken with zero cost while idle. Proven end to end on a real device.
The full interactive loop: identify the customer, gather across our systems, present the picture, and carry out your decision - reply, note, status, tag - with a hard confirmation on anything customer-facing.
Pause, resume, skip, stop, status - all shipped. A pause lands in about two seconds, and the queues are never touched while you're away.
Scout claims a ticket as it opens it - never one a colleague already owns - and /scout-skip or an offline agent's stranded reply reroutes cleanly to whoever's free.
Anything that moves money or changes a booking is flag-only - no code path can execute it - and that boundary is locked by an automated test. Nothing financial can fire, by construction.
Prove it on live tickets with a CS agent; then the scale work - a claim/dedup guard, deeper observability, and a dedicated access role.
The roadmap
Today Scout flags anything that moves money or changes a booking, because there's no safe automated path to do it. Each of these is that path. Build the tool and - with no change to Scout itself - the flag turns into a confirmed, one-click action. The registry lights it up automatically.
Our payment gateway. A safe, idempotent write path here lets Scout issue a refund or a payment adjustment on your confirmation - instead of flagging "£X refund needed, do it by hand." The single biggest chunk of manual money-work.
The rail retailing engine behind reissues, exchanges, seat changes and rebookings. A write path here turns "reissue this ticket / change this seat - do it manually" into an executed action, confirmed by you.
Extend our own toolkit to write, not just read: add credit or goodwill to a customer's account, apply a voucher, adjust an order. The everyday "just sort them out" gestures that today mean a hand-off to another system.
Each is a self-contained MCP server - the same shape as the Zendesk and Seatfrog ones Scout already runs on - built and reviewed on its own, then declared as a dependency. When it lands, its flags become executes with the same confirm-the-exact-amount and full-audit-trail guarantees as every other action. No rewrite; the toolkit just grows.
What it's built on
Scout isn't monolithic - it stands on two self-contained MCP plugins, each with its own page. They're the reason a new ability can slot in without a rewrite.
A read-only Claude bridge to our AWS estate - DynamoDB, CloudWatch, RDS, X-Ray and more - with domain knowledge for 25+ services. This is how Scout reads the auction, sale and refund state.
All of Zendesk in front of Claude - 48 read tools over 253 operations, plus tiered, gated writes. This is how Scout reads the ticket and, on your word, replies.