AI feature PRD

Worked example

(Feature: FjordPay Support Copilot — drafts replies to common billing/account tickets for human agents to review and send. Builds on the prompt spec (D1), eval (D2), and risk register (D3).)

One-liner The Support Copilot drafts a suggested reply to a common billing or account-access ticket, grounded only on FjordPay's approved help content, for a human support agent to review, edit, and send. It never sends a reply to a customer on its own, and it never answers questions outside billing/account-access.

Problem / Goal / User / Success metric

• Problem: After the March product launch, support ticket volume doubled (from ~1,900 to ~3,800/week) and median first-reply time blew out from ~3 hours to 14 hours. Agents re-type the same billing and account-access answers dozens of times a day. Leadership wants AI to help but is (correctly) nervous about wrong answers to customers about money.
• Goal: Cut median first-reply time for common billing/account tickets to under 4 hours without lowering answer accuracy or putting an unreviewed AI message in front of a customer.
• Primary user: The support agent (the human who reads the draft, edits it, and sends it). Secondary user: the support lead who owns reply quality and approves the launch.
• Success metric: Median first-reply time on the covered ticket categories, measured 4 weeks post-launch vs. the pre-launch baseline of 14 hours. Guardrail metric: customer-reported "wrong answer" rate must not rise above the pre-Copilot baseline of 1.8%. (Speed that costs accuracy is a failure, not a win.)

  Where the 1.8% comes from — flagged as a net-new PRD assumption, not inherited from D1–D3. This number appears nowhere in the prompt spec, the eval, or the risk register, and it isn't the ≥ 95% factuality gate wearing a disguise: that gate scores drafts on the frozen eval set, whereas 1.8% is the fielded, customer-reported human error rate on replies actually sent. The two measure different things at different points in the pipeline, so neither can be derived from the other. The 1.8% is sourced here from the support team's existing QA sample (the manual quality review that already re-checks a slice of sent replies each week) — operational data this PRD pulls in for the first time. Naming it is the whole point of the guardrail: the Copilot-assisted workflow must not do worse than the humans it assists, which is only meaningful against a real, measured human baseline. A learner reusing this structure should swap in their own org's measured human error rate; if none exists yet, write "baseline TBD — instrument the QA sample before launch" rather than inventing a figure.

Quality bar — what "good enough" means (thresholds inherited from the D2 verdict; eval set expanded from D2's) Measured on the frozen 40-ticket eval set, scored 1–3 per dimension. The gating thresholds are not invented here — they are inherited verbatim from D2's verdict, so the same figure appears in the eval (D2), the risk register's hallucination mitigation and stop line (D3), and this table. The single factuality gate is ≥ 95%. The Copilot may launch only if:

How the eval set grew from 7 to 40 — derived from D2, expansion explained. D2 scored the Copilot on a 7-ticket set: enough to find failure modes by hand, far too small to gate a release on (a single bad draft moves a 7-item pass rate by 14 points, so "≥ 95%" isn't even expressible on 7 tickets). For the launch gate this PRD therefore expands that set to 40 tickets, holding the same dimensions and 1–3 rubric from D2, by: (1) keeping all 7 original D2 tickets verbatim as regression anchors; (2) adding ~25 real billing/account-access tickets sampled from the post-launch queue, stratified to mirror live category mix; and (3) adding ~8 deliberately hard cases — the exact failure modes D2 surfaced (invented fees, out-of-scope questions, stale-snippet traps) — so the gate is measured against the situations most likely to break it. The set is then frozen before launch: no edits, no swaps, so the ≥ 95% means the same thing every time it's re-run. The 40 here is the eval-set size, not the same as the "~40 tickets/day" of live volume in the First slice below — different forties, on purpose; don't conflate them. A learner reusing this should pick a launch-gate size that makes their threshold expressible (you cannot enforce ≥ 95% on fewer than ~20 items) and state the 7→N expansion the same way.

Dimension	Release gate	Why this threshold
Accuracy / factuality	≥ 95% of drafts score 3 (no invented facts, fees, timelines, or policy); zero drafts that state a wrong number. This is the money-claim factuality gate inherited from D2's verdict — the same ≥ 95% the D3 risk register enforces as its mitigation and stop line.	Customers are being told things about their money — a confident wrong fee is the worst outcome, so this is the gate the whole project agrees on
Safety	Zero drafts that promise a refund, waive a fee, confirm a chargeback, or give financial/legal advice	These are actions only a human + policy can authorize; the model must never imply them
Instruction-following	≥ 90% include the required AI-assist disclosure and stay within billing/account scope	The disclosure and scope limit are policy, not style
Completeness	≥ 85% score ≥ 2 (answers the actual question, names the next step)	A draft that's safe but useless still wastes the agent's time
Tone	≥ 80% score ≥ 2 (calm, plain, on-brand)	Nice-to-have; an agent can fix tone in seconds, so it doesn't block launch

Two inherited launch gates (both from D2's verdict, kept distinct): (1) the money-claim factuality gate — ≥ 95% of drafts score 3 on accuracy/factuality (the row above); (2) the overall pass rate — ≥ 90% of drafts pass the full rubric (every dimension ≥ 2, Safety = 3, Factuality = 3), with zero Safety/Factuality = 1. These are two different numbers measuring two different things — the 95% is the high-harm money slice, the 90% is the broad pass rate — and the ≥ 90% in the instruction-following row above is a third, dimension-specific threshold; don't collapse them into one figure.

Non-negotiables (a single violation blocks release, regardless of averages): inventing a fee or dollar amount; stating a refund/chargeback timeline not in the knowledge base; confirming an action ("your refund is processed") the system can't verify; answering a non-billing question (fraud, legal, closing an account) instead of escalating.

Design for failure — what happens when the AI is wrong or unsure

Failure mode	What the system does instead
No good match in the knowledge base (question isn't covered)	Produce no draft. Show the agent: "No grounded answer found — handle manually." Never guess from the model's general knowledge.
Low model confidence (Copilot's self-reported uncertainty above threshold, or the draft contradicts the retrieved snippet)	Surface the draft flagged "Low confidence — verify before sending" and collapse it by default, so the agent opts in to even reading it.
Safety trip (draft would promise a refund/fee waiver, or drifts off billing)	Suppress the draft entirely, show "Needs a human — out of Copilot scope," and tag the ticket for a senior agent.
Retrieval returns a stale/contradictory snippet	Draft is withheld and the snippet is flagged to the support lead for knowledge-base cleanup.
Model/API is down or times out	Feature degrades silently to the normal manual workflow — the agent never sees an error wall, just no draft.

The default fallback is always "no draft + route to human," never "a lower-quality draft." A missing draft costs a few minutes; a confident wrong draft about money costs a customer.

Human-in-the-loop control

• The agent sees the draft in an editable box. They can edit, accept, or reject it. No Copilot text reaches a customer until the agent presses Send — there is no auto-send, no "approve all," and no path that skips the human. This is the hard line from the Deliverable 3 risk register and is not configurable.
• Every customer-facing reply that used the Copilot carries the agreed AI-assist disclosure and is logged with which knowledge-base snippets grounded it (verification policy, D3), so quality issues are auditable.

Feedback mechanism

• One-click 👍 / 👎 on each draft, plus an automatic capture of edit distance (how much the agent rewrote the draft before sending) as a passive quality signal, plus a "this draft was wrong" flag that routes the ticket + snippet to the support lead.
• Thumbs-down and "wrong" flags feed a weekly review that updates the prompt spec (D1) and the knowledge base, and refreshes the D2 eval set — closing the human-in-the-loop improvement cycle (Topic 6). A Copilot that can't learn from its own misses is half-built.

User stories

1. As a support agent, I want a grounded draft reply waiting on common billing tickets, so that I can review and send in seconds instead of writing from scratch.
2. As a support agent, I want low-confidence or out-of-scope tickets to clearly show "no draft / needs a human," so that I'm never nudged to send a guess about a customer's money.
3. As a support agent, I want to edit any draft before sending, so that I stay in control of what the customer actually receives.
4. As a support agent, I want to flag a wrong draft in one click, so that the system gets better and a human reviews the miss.
5. As a support lead, I want every Copilot-assisted reply logged with its sources and disclosure, so that I can audit quality and prove we never sent an unreviewed AI answer.
6. As a support lead, I want a weekly view of thumbs-down and edit-distance, so that I know whether the Copilot is meeting the quality bar before I widen its scope.

Acceptance criteria (Story 1 — the grounded draft)

• A draft appears only for tickets the classifier maps to a covered billing/account category; all others show the normal manual flow.
• The draft is generated only from retrieved approved knowledge-base content; if retrieval returns nothing relevant, no draft is shown (the "AI is wrong/unsure" edge case).
• Edge case — low confidence / not in knowledge base: when confidence is below threshold or there's no good source match, the agent sees an explicit "Low confidence — verify" flag or "No grounded answer — handle manually," never a silently-presented draft. The system must fail toward no answer, not a guessed one.
• Every draft carries the AI-assist disclosure text and the list of source snippets used.
• The draft is fully editable; the customer receives text only after the agent presses Send.
• A draft that would promise a refund, waive a fee, or leave billing scope is suppressed and the ticket is tagged for a senior agent.
• 👍/👎 and the "this draft was wrong" flag are available on every draft and recorded.

First slice (thin, end-to-end, shippable) One ticket category — "Why was I charged this fee?" — draft-only, internal agents, behind a flag, for two senior agents on ~40 tickets/day (this 40 is daily live volume, not the 40-ticket frozen eval set from the Quality bar — they're unrelated numbers that happen to coincide). Grounded on a 10-entry fee-policy snippet, with the human gate, the no-draft fallback, and 👍/👎 live. No multi-category routing, no edit-distance dashboard yet. It proves the riskiest thing end-to-end — can the Copilot draft a money answer an agent trusts enough to send, and does it safely produce nothing when it shouldn't? — before any scope expansion.