Iris
Why I 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 four and a half days, 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.
How the tickets arrive.
Roughly 70% of tickets land without enough context to act on. Each sits open about 4.5 days while the scope gets worked out by hand.
The rest arrive ready to execute: ten to fifteen minutes each, start to finish.
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.
2,161
Writer hours a year, across 4,608 tickets
384
Writer hours a year
A difference of 1,777 hours, equivalent to 74 working days. Writers keep the judgement calls and stop doing the retrieval.
The 2,161 baseline is measured. The 384 is a projection I authored, and it follows from the resolution time rather than being observed separately.
4.5 days
Poorly scoped tickets, 70% of the total
Under 5 minutes
Every ticket, regardless of scoping
The 4.5 days was never the edit. It was the request, the triage and the queue in front of the edit, and that is the part Iris removes.
Demonstrated end to end in the walkthrough above, on a working build rather than a prototype.
4,608
Projected annual volume. Split 70% poorly scoped, 30% well scoped.
11,656
A scope statement, not an impact claim.
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.
If you are trying to make content compound rather than accumulate, that is the problem I like most. Email is quickest, and my calendar is open.