Iris
Why we built it
A wrong product description is not an operations problem, it is a live page converting worse than it should. The fix usually already existed. It was the request, the triage and the queue that took roughly ten days at the 75th percentile, not the edit.
The decision that mattered
Confidence gating, rather than full automation. High-confidence fixes ship on their own; anything less lands in a side-by-side diff for a writer. Writers review, they do not re-execute. Automating the whole thing would have been easier to build and impossible to trust.
How a request comes in.
A requester sends one Slack message with the product ID and what needs changing. IRIS asks follow-up questions when the request is unclear, maps every field that needs updating, executes high-confidence fixes automatically, and routes medium and low confidence ones to a side-by-side diff for a writer to approve. No form, no ticket, no back-and-forth.
What happens to 100 tickets.
The system identifies the fix, makes the change and closes the ticket automatically.
The system has already identified the right actions. The writer reviews and closes the ticket.
The writer needs to modify what the system proposed.
Usually because context is missing, the request is misrouted, or several kinds of fix are bundled into one ticket.
How it works
Iris does the request handling, the mapping and the routing. Writers only touch the judgement calls.
Slack intake
The request happens where the person already is.
- A requester sends one Slack message with the product ID and what needs changing.
- Iris asks follow-up questions when the request is unclear.
- No form, no ticket, no back-and-forth.
See Iris in action.
A walkthrough of one real request: a plain Slack message, the fields Iris finds, the changes it applies and the ones it sends for review.
From two days to five minutes.
A banned keyword, "skip the line", had to come off every surface it appeared on: product pages, landing pages, shoulder pages and meta descriptions. It took two days to make the changes and a week to verify them. Iris does the same pass in minutes.
… skip the line and enjoy …
… skip the line tickets | …
Skip the line access
… skip the line entrance …
… enjoy priority access …
… priority tickets | …
Priority access
… priority entrance …
What changes, and by how much.
35%
Of product-content fixes close with no writer touching them
90%
The target, not a result
At today’s volume that is roughly 280 tickets a month handled without writer intervention, and about 720 a month at the target.
10 days
A typical product-content fix, 75th percentile
24 hours
The same measure, as of 3 September
The goal for straightforward fixes is under 60 minutes, from ticket raised to content fixed to ticket closed.
200
Of roughly 350 fix tickets a week. The scope of version one of the system.
86%
Roughly: the zero-touch tickets plus those a writer only reviews.
Built at a hackathon. Absorbed into the workflow.
Iris was never a product with a roadmap. It was an argument about how content fixes should work, made in working code.
A working build, in a hackathon week
Slack intake, field normalisation, product and variant mapping and confidence scoring, all running. The connection into our content admin system was stubbed for the demo.
Demonstrated to the company
Not a deck. The code, and the fixes it makes, walked through on real content requests.
The existing ticketing workflow took it on
The company already ran its own ticketing workflow. That workflow has since taken on this code and this process, which is a better outcome than a second tool nobody has to adopt.
More projects.
Let’s build something that scales.
I build systems that turn growth opportunities into scalable outcomes. Have a challenge worth solving? Let’s connect.