Market, price and trust · Trust and regulation

The report button

Design what happens after an agent reports a bad draft: routing by severity, who may read the report, and the response time committed for each kind.

designeasyExercise · 3 min · 51 of 59

On this page

A report button that writes to a table nobody reads teaches agents to stop pressing it within a week. The trust lesson put the button on every draft; this is what happens after the click.

The situation

The drafting feature serves 200,000 drafts a day across 12,000 seats. On the golden set, 8% of drafts are not acceptable: half a point wrong on a fact (one draft in 200, the most the launch gate allows), 7.5 points on tone. Assume agents report one in ten of the drafts they reject, and that a third kind the golden set has never caught, a draft containing another customer's details or abusive text, is reported about twice a day.

Ticket text is kept 30 days, and a tenant must opt in before its tickets can become eval cases. One eval owner can review 50 reports a day properly. Support ops already runs an on-call rota for outages with a one-hour acknowledgement. The large tenant's contract has a clause on factual errors in customer-facing text, and its admin has asked to see her agents' reports. The design lead proposes a thumbs-down icon that writes to a log.

The question

Design what happens after the click: what the agent sees, where each kind of report goes and who may read it, and the response time you commit to for each.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

Counts first: 200,000 × 8% = 16,000 rejected drafts a day; one in ten reported is 1,600 reports, about 100 on facts and 1,500 on tone, plus 2 severe. Too many to read, too few to ignore, so the design is routing.

The click offers three choices, wrong fact, wrong tone, harmful or private, plus an optional line. The agent sees "Reported. Edit or discard this draft"; reporting never sends anything.

Severe, about 2 a day: pages the existing on-call, acknowledged within 1 hour, cause found within 1 business day; the on-call can switch drafting off for that tenant while they look.

Wrong fact, about 100: each reaches the tenant admin by next morning, grouped by the help-centre article the draft cited, because a stale article causes most fact errors and only the tenant can fix it. The eval owner reads 50 a day, half of them, for causes the grouping misses.

Tone, about 1,500: no individual response; counted weekly per tenant and fed to the prompt backlog.

Who reads what: the agent sees their own reports and status; the tenant admin sees her tenant's reports, with text. The vendor sees category, article id, and model and prompt version from the audit log, and ticket text only for severe cases and the sampled 50, inside the 30 days. Only opted-in tenants' reports become golden-set cases.

Commitments, published in the help centre: 1 hour, next morning, weekly. Metric: reports per 1,000 drafts per tenant, a drift alarm that moves before the weekly eval. What changes the design: severe reports above about 10 a day, which means the eval gate failed and drafting goes off.

Rubric

Turns the reject rate into daily counts per kind: 1,600 reports, about 100 fact and 1,500 tone, and the 2 severe.
Routes by severity, with the severe kind paging a person who has a per-tenant switch in reach.
Says who may read ticket text, for how long, and that eval use needs the tenant's opt-in.
Commits a response time for each kind and publishes it.
Closes the loop to the reporting agent and to the tenant admin.
Names a metric and the threshold that changes the design.

Where answers go wrong

"A thumbs-down that writes to a log." That is 1,600 rows a day nobody reads and no response time. Agents learn within a week that reporting does nothing, and the field signal the eval set grows from dries up.
"Support reviews every report within 24 hours." At 3 minutes each, 1,600 reports is 80 hours a day, ten people, and the two severe reports wait in the same queue as 1,500 tone complaints.
"Send every reported ticket to the model team to improve the model." The ticket is the tenant's customer's text, there is no opt-in, and after 30 days it no longer exists. The design breaks the consent and retention defaults it sits on.