Usable with a quick edit9 of 10 checks passed
The PRD is complete and actionable for the named leads, requiring only the addition of explicit numeric thresholds for already-defined gates. No evidence or reasoning would need to be redone.
Output
PRD: AI First-Response Drafting and Ticket Routing
Status: Proposed Product: Ledgerly Support Audience: Engineering, ML, and Support Operations leads
1. Summary
Ledgerly receives about 9,000 support tickets per week. Tickets are handled by 42 agents across Billing, Technical, Account access, and General. Average first response time is seven hours, against a target of under two hours. About 60% of tickets receive one of roughly 40 saved replies.
This feature will recommend a queue and prepare a first-response draft when a new ticket arrives. An agent must review and approve every draft before it is sent. The feature is intended to reduce time spent triaging and composing routine responses, while leaving decisions and customer communication under agent control. It must never send a response autonomously or make a refund commitment on Ledgerly’s behalf.
2. Goals and non-goals
Goals - Reduce median time from ticket creation to first response, with an operational goal of under two hours. - Reduce agent effort on routine first responses by using appropriate saved replies and ticket-specific details. - Route tickets to the best-fit queue, while making uncertain recommendations visible and easy to correct. - Preserve agent review and control over every customer-facing response.
Non-goals - Automatically send, resolve, or close tickets. - Decide refund eligibility, promise a refund, or commit to refund timing. - Draft replies to later messages in an existing conversation in the initial release. - Replace queue ownership, escalation policies, or agents’ judgment.
3. Users and workflow
The primary user is a support agent reviewing new tickets in their assigned queue. Support Operations owns queue definitions, saved replies, and handling guidance. ML and Engineering own model quality, serving, integrations, and monitoring.
For each new ticket, the system will: 1. Read the ticket’s permitted content and available support context. 2. Recommend one of the four queues, with a confidence indicator and brief reason. 3. Generate a first-response draft, preferentially based on a relevant approved saved reply where appropriate. 4. Display the recommendation and draft in the agent workflow. 5. Let the agent edit, discard, or approve. Approval sends the response through the existing support system; no response is sent before approval.1 6. Record the final queue, draft disposition, edits, and outcome for evaluation.
Agents may change the queue before or after reviewing the draft. A draft must remain clearly marked as AI-generated until approved.
4. Functional requirements
Routing
- Classify each ticket as Billing, Technical, Account access, or General.
- Show the recommended queue, confidence, and a short explanation grounded in ticket content.
- Allow agents to override the recommendation; the override becomes an evaluation signal, not an automatic training label.
- Route low-confidence or ambiguous cases to General and flag them for review. Support Operations must set and approve the launch confidence threshold using offline and pilot results.
- Do not infer urgency or bypass existing escalation rules in the initial release.
Drafting
- Generate a concise, relevant first response based on the ticket and approved support materials available to the system.
- Use a saved reply when it fits, adapting only with verified ticket details. Do not fabricate account status, actions taken, policy, or resolution.
- When information is insufficient, ask a clear clarifying question or provide a safe acknowledgement rather than guessing.
- Support agents can edit, discard, or approve the draft. No draft may be sent without an explicit agent action.
- If the request concerns a refund, the draft must not promise, confirm, or imply a refund or refund timing. It should use approved noncommittal wording and leave eligibility and timing to an agent. Refund-related tickets should be visibly flagged for agent attention.
5. Data, model, and system requirements
Ledgerly has two years of resolved tickets and agent replies. ML should assess data coverage and quality before training: queue labels, duplicate or reopened cases, outdated answers, agent-specific wording, and tickets whose resolution depended on account information unavailable at ticket creation. Historical agent replies are examples, not policy; approved saved replies and current support guidance take precedence.
Create a time-based training, validation, and test split to reduce leakage from repeated tickets or changing policies. Evaluate routing and draft quality separately, including by queue, ticket type, and relevant risk category. Do not train on post-response information when evaluating first-response behavior. Remove or protect unnecessary sensitive data, and use only the customer and account context needed for support.
The serving path must retrieve only context the agent is authorized to see. Engineering must confirm integration points with the ticketing system, queue assignment, saved replies, and send/approval controls before implementation. Log model/version, recommendation, confidence, draft, agent edits, approval or discard, final queue, and response timestamps, subject to Ledgerly’s retention and access policies. Restrict access to these logs and avoid storing secrets or unnecessary personal data in model prompts.
6. Quality, safety, and success measures
Establish a pre-launch baseline and report weekly: - Median and 90th-percentile time to first response; proportion answered within two hours. - Queue recommendation accuracy and agent override rate, overall and by queue. - Draft approval rate, edit rate, discard rate, and time from ticket opening to send. - Agent-rated usefulness and sampled quality review results. - Refund-policy violations, fabricated claims, and other serious customer-impacting errors.
Suggested launch gates, to be confirmed by Support Operations and Legal: routing performance must be no worse than the current human baseline on the held-out set; pilot draft samples must meet an agreed quality rubric; and no refund commitment may appear in an approved draft during safety testing. Any refund commitment, unauthorized send, or material fabricated claim triggers immediate disablement of the affected capability and incident review. Do not optimize approval rate alone: agents must be able to reject drafts without penalty.
7. Rollout and operations
- Discovery and offline evaluation: Validate data, current queue definitions, approved saved replies, policy ownership, and integration feasibility. Build a labeled test set reviewed by Support Operations, with explicit refund and other high-risk examples.
- Shadow mode: Run recommendations without showing or applying them. Compare predicted queues and drafts with agent outcomes; inspect errors and subgroup performance.
- Limited pilot: Enable the workflow for a small, representative group of agents and ticket types. Keep agent approval mandatory. Support Operations reviews a daily sample and gathers structured agent feedback.
- Expansion: Expand to all 42 agents only after launch gates are met and Legal and Support Operations approve. Roll back by disabling drafting or routing independently if either degrades.
Support Operations owns the queue taxonomy, approved reply content, quality rubric, and agent training. ML owns evaluation, thresholds, drift monitoring, and model updates. Engineering owns access controls, reliable delivery, audit logs, feature flags, and rollback. A named on-call owner must be assigned before pilot launch. Review quality and performance weekly during rollout and after material model, policy, or saved-reply changes. Re-evaluate against a fresh sample regularly; do not promote agent edits to training data without review and policy checks.
8. Open decisions before build
Confirm the ticketing platform and integration surfaces; which customer/account fields are available at ticket creation; the authoritative source for current support policy; Legal’s approved refund language and review process; the minimum acceptable routing and draft-quality thresholds; and the retention period for prompts, drafts, and audit logs. These decisions are launch prerequisites, not reasons to relax agent approval or refund safeguards.
What a PM had to fix
1Test or gate too weakTighten the testTargeted repair
What we’d changeAn agent’s explicit “Approve and send” action authorises only the exact response displayed, including their edits. Regeneration or any subsequent change requires fresh approval. Enforce this in the send service and prevent duplicate sends on retries. If drafting fails, agents can compose and send manually. AI-generated drafts must use approved noncommittal refund wording; agents may add refund commitments under existing policy and explicitly approve the final response.
Check by check
Got wrong · 1
- Proposes tests that could failProposed gates lack numeric thresholds and explicit time windows; 'no worse than human baseline' and 'agreed quality rubric' are not measurable fail criteria, and pilot/shadow durations are unspecified.
Got right · 9
- Uses the supplied evidence correctlyAll current-state figures used come directly from the supplied context, with no invented facts about the current situation.
- Addresses the actual decisionThe PRD commits unambiguously to AI-assisted queue recommendation and draft generation with mandatory agent approval, and specifies conditions for rollback or disablement.
- Respects explicit constraintsIt respects the named audience, length, PRD form, and enforces the no-automated-refund-commitment constraint through mandatory approval, noncommittal refund wording, and flagging.
- Identifies material uncertaintyIt identifies material unknowns such as data quality, integration points, policy ownership, and confidence thresholds, and says how to resolve them through evaluation and piloting.
- Avoids unsupported claimsNo causes, forecasts, or interpretations are presented as established fact; uncertain items are framed as suggested, open, or to be confirmed.
- Produces the required deliverableThe requested PRD is present, complete, written for engineering, ML, and support-operations leads, and within the requested length.
- Specifies AI failure behaviourThe PRD specifies low-confidence routing to General with flags, clarifying questions when information is insufficient, and immediate disablement for serious errors.
- Defines evals and a launch barIt defines a pre-launch baseline, metrics, a held-out test set, launch gates, and a zero-refund-commitment safety condition.
- Success settles trade-offsIt names a success metric with an under-two-hours target and weekly cadence, and gives trade-off rules such as disabling the affected capability on any refund commitment or unauthorized send.
Grades and run details
Decision model 90 · LLM judge 10 of 11 checks
Decision model checks
- passUses the supplied evidence correctly23%
- passAddresses the actual decision71%
- passRespects explicit constraints39%
- passIdentifies material uncertainty90%
- passAvoids unsupported claims33%
- passProduces the required deliverable46%
- passSpecifies AI failure behaviour98%
- passDefines evals and a launch bar44%
- partialSuccess settles trade-offs85%
- partialProposes tests that could fail82%
Run
- Run
- #1
- API response time
- 30 s
- Submitted
- 29 Sept 2026