Internal · Slack API · LLM confidence scoring · Field normalisation · Diff review UI

IRIS

A confidence-gated content-fix engine that lives in Slack.

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.

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.

Content fix cycle time

4.5 days

Poorly scoped tickets, 70% of the total

Under 5 minutes

Every ticket, regardless of scoping

TODO(ayush): confirm the observation window before this publishes. Measured since launch, but the claim needs its dates.

Writer hours spent on content fixes

2,161

Per year, across 4,608 tickets

384

Per year

The 2,161 baseline is measured. The reduction follows from the cycle time above.

Fix tickets a year

Split 70% poorly scoped, 30% well scoped.

Products in scope

A scope statement, not an impact claim.

Writer time freed

Projected, not realised. A business case I authored, equivalent to 74 working days.

What it looks like in practice

A banned keyword had to come off product pages, landing pages, shoulder pages and meta descriptions. It took two days to make the changes and a week to verify them. That is the shape of the problem: the edit was never the hard part.

How it works

  • Slack intake, so the request happens where the person already is.
  • Field normalisation, so a vague request becomes a specific set of changes.
  • Product and variant mapping, so one request reaches every page it should.
  • Confidence scoring on each proposed change.
  • High confidence ships straight to our content admin system.
  • Anything lower goes to our review tool as a side-by-side diff.
IRIS resolving a content fix from a single Slack message.