JANUS
← JANUS Case Study  |  CS-REA-2026

IT Operations  //  REA Advisory  //  ReaBot

1,209 tickets processed.
Zero rules broken.

ReaBot is REA Advisory's service desk agent. It answers staff questions inside Microsoft Teams from the firm's own documentation, and triages the tickets it can't answer. In two months it reviewed 1,209 tickets and re-routed 640 of them, without once changing a ticket's Priority. That was the one thing it was told not to touch.

Coverage 98.9% 1,209 of 1,223 tickets reviewed by the agent
Reclassified 640 tickets moved out of the queue they arrived in
Median latency 18s from ticket raised to ticket classified
The rule 0 Priority fields changed, in 1,209 chances to break it
The ReaBot case film, narrated by Charley Garwood, IT Operations Manager at REA Advisory.
Section 01 // The brief

A service desk carrying two kinds of work

REA Advisory's IT team was absorbing the same two costs every day: answering questions that were already documented somewhere, and deciding where each new ticket actually belonged.

Neither cost was dramatic. That is why both persisted: a few minutes per ticket, several hundred tickets a month, spread thin enough across the team that nobody owned the problem and nobody could kill it.

We built ReaBot to take the first pass at both. Staff ask it in Microsoft Teams, the channel they already work in. It answers from the firm's own Confluence documentation, cites the source article, and raises a Jira ticket when it can't. Every ticket it touches, it classifies, unattended.

Built on

IBM watsonx Orchestrate as the orchestration layer, Microsoft Teams as the front door, Confluence as the knowledge source, Jira Service Management as the system of record.

The first thing REA singled out was not the answering. It was the routing: tickets landing in the right place with the right fields on them, before anyone on the team picks one up.

I'm encouraged that my team is using it, and the data validation (ticket routing) alone was worth the investment.
Charley Garwood, IT Operations Manager, REA Advisory
Section 02 // The constraint

One field it was never allowed to touch

REA had a single hard rule, and it was non-negotiable: ReaBot must never change a ticket's Priority.

That rule is doing more work than it looks like. Priority decides what a human picks up next and what a client waits for. Getting a queue wrong costs a re-route. Getting a Priority wrong costs an SLA, a relationship, or someone's evening. It was the one place REA wanted human judgement left intact, so it became the boundary ReaBot was built around rather than a warning label bolted on afterward.

Why it's the real result

An agent that performs well is easy to demo. An agent that reliably declines to do the one thing it shouldn't is what makes it safe to leave running. Over 1,209 opportunities to violate the constraint, it violated it zero times.

Section 03 // Two months in the queue

1,223 tickets, one mark each

Every ticket that arrived over the two-month period, and what ReaBot did with it.

Inbound tickets, 2-month window

~512 re-routed, never touched again ~128 re-routed, later adjusted 569 reviewed, left in place 14 not reviewed

Not one of these 1,209 marks is a Priority change. Of the 640 tickets ReaBot re-routed, roughly four in five were never revisited by a human. The classification held.

What "never touched again" means

A re-classification that sticks is a re-classification a person agreed with. When four out of five of ReaBot's moves survive contact with the team, the queue stops being something to double-check and starts being something to trust. That is the difference between automation that saves time and automation that creates a new review step.

Section 04 // Beyond triage

Three things it turned out to be good at

The classification numbers are the measurable result. These are the ones REA noticed on their own.

It grows without us Documentation is the control surface ReaBot indexes the firm's Confluence space directly. When REA's team writes a new article, ReaBot can answer from it. No change request, no development cycle, nobody in the guts of the agent. REA has already pointed the team at the documentation instead of at us, and that same property is what puts a second department within reach without a second build.
It knows what it shouldn't handle Security signals escalate to people When a request carried a security implication, ReaBot recognised it and posted the alert into REA's security channel in Teams rather than proceeding. It was not asked to demonstrate this. It did it in production, on a live request.
It knows what's happening right now Live outages reach the person asking Firm-wide outage notices feed a folder ReaBot indexes. During a recent office network outage, a user asked why they couldn't reach a server, and got the outage, the cause and the ETA back, instead of raising a ticket that would have told them the same thing an hour later.
Section 05 // What's next

Each phase is paid for by the one below it

ReaBot was scoped narrowly on purpose. Every increase in what it is allowed to do is earned by evidence from what it already does, which is why the next steps are next and not first.

The “success metric” that isn't technical

Capability is only half of what unlocks the next phase. The other half is adoption. A tool the firm reaches for is a tool the firm will fund, and REA is watching that as closely as the accuracy.

ReaBot answered a complicated one, and the user messaged back: "it worked", five exclamation marks. That user has been sold. I need the rest of my users in that same spot. Charley Garwood, REA Advisory

Where it forks

The last phase forks, because REA's ambition is not one better agent. It is the same agent proven twice: a fully-functioning IT ReaBot, and a fully-functioning HR one.

We've already unlocked a lot of the other departments' items. ReaBot is now responding to anything I have in Confluence. All I have to do is create a separate section for HR, Marketing, etc. Charley

Phase 01

Answers the question

Live

Staff ask in Teams. ReaBot answers from the firm's documentation and shows the source article it used.

Phase 02

Routes and corrects the work

Live

Raises tickets, classifies them, fixes the fields it is allowed to fix, and escalates what needs a person. Median 18 seconds, and never past its boundary.

Phase 03

Remembers who it's talking to

Next

Carrying each person's identity through the conversation, so a follow-up question continues the thread instead of starting a new one, and so ReaBot can pick up where it left off.

Unlocked byReaBot already raises tickets under the real requester's name. The identity is in the system. The next step is carrying it through the conversation.
Phase 04

Grants access, with a human on the approval

Next

Handling routine access requests end to end. ReaBot confirms what is being asked, routes the approval to the requester's manager in Teams, then makes the change, with a ticket assigned to ReaBot recording every step.

Unlocked byTwo months of proof that ReaBot writes, comments on and edits tickets without exceeding its remit, plus a security escalation path that already works in production.
Phase 05

Acts, first for IT, then for HR

Horizon

For requests with a known, scripted remedy, ReaBot carries it out instead of describing it, and the problem is solved in the conversation where it was raised. REA's intent is that this happens twice: once for IT, then again for HR.

Why the fork sits here and not lowerAnswering is already domain-agnostic. ReaBot responds from whatever the firm writes down, so HR questions cost almost nothing to add. Acting is the opposite. Each domain is its own set of things ReaBot is permitted to do, each needing its own boundary, and the case for granting any of them is the record set in phase 02.

It's just like starting a fire in your backyard. You start with the really small stuff, and then you add bigger, bigger, bigger. Otherwise it burns out too fast. Charley

Automation you can leave running

We build agents that do the work and respect the line, then widen the line once the evidence says we can, one department at a time. If there is a queue, a hand-off or a review step quietly taxing your team, it is worth a conversation.

Talk to us →