Critic comment
Mobile roughly doubles MVP scope for no proven value.
DCP READ-ONLY: CONNECTED DEVELOPMENT / UI PREVIEW DCP BATCH 5/6 SOAK IN PROGRESS TELEMETRY: UNKNOWN COMMAND EXECUTION LOCKED
Customer Support Ticketing
Product data source: MOCK STATIC UNKNOWN· MOCK = example fixture · STATIC = documented/committed template · UNKNOWN = no evidence. UNKNOWN is never shown as PASS.
MOCK EXAMPLE · development-only product-planning data. No production project, no live backend, no execution, no mutation endpoint. Genuine local artifacts are marked STATIC; example fixtures are marked MOCK.
- Slug
- customer-support-ticketing
- Stage
- OWNER_DECISION
- PRD gate
- NEEDS_OWNER_DECISION
- Build readiness
- 10/13 VERIFIED
Idea Brief — IDEA-001
- Title
- Customer Support Ticketing
- Status
- DISCOVERY
- Owner intent
- Ari wants a simple way to track customer support requests instead of losing them in chat.
- Problem
- Support requests arrive in chat/email and get lost; no shared queue and no status.
- Who is affected
- Support staff, Customers
- Desired outcome
- A single queue where a request is visible, assigned and resolved with a status.
- Why now
- Request volume is growing and the manual process is failing.
- Existing solution
- Informal chat threads; no ticketing system.
- Initial scope
- Create/assign/resolve tickets
- Shared queue view
- Potential MVP
- Web-only ticket queue
- Assign + status
Constraints
- No production deployment from the planning cell
- Development-only in this task
Assumptions
- Support volume stays modest (< 1000 tickets/month).
- Staff all used the internal portal before.
Open questions
- Is email ingestion required for the MVP?
Kill criteria
| ID | Criterion | Outcome | Evidence | Owner decision |
|---|---|---|---|---|
| K-001 | existing system solves >= 80% of the need | PASS | No existing ticketing system in use. | no |
| K-002 | no clear user/problem owner | PASS | Support staff own it. | no |
PRD — PRD-001
- Title
- Customer Support Ticketing
- Status
- CRITIC_REVIEW
- Executive summary
- A shared, web-only ticket queue for support requests.
- Problem statement
- Support requests are lost in chat and email; there is no shared queue or status.
- Business objective
- Reduce lost requests and make status visible.
Users / Personas
- Support staff — Handle and resolve requests
- Customer — Get a request acknowledged and resolved
Scope
- Create a ticket
- Assign a ticket
- Resolve a ticket
- List tickets in a shared queue
Non-scope (must not leak into tasks)
- Mobile application
- Customer self-service portal
- Analytics dashboard
- Multi-tenancy
MVP
- Web-only ticket queue
- Assign
- Status
Later phases
- Email ingestion
- Analytics
- Customer self-service
Functional Requirements
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| FR-001 | REQUIREMENT | Create a ticket with a title and body | CONFIRMED | MOCK |
| FR-002 | REQUIREMENT | Assign a ticket to a staff member | CONFIRMED | MOCK |
| FR-003 | REQUIREMENT | Set a ticket status | CONFIRMED | MOCK |
Non-Functional Requirements
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| NFR-001 | REQUIREMENT | Web pages respond within 2 seconds | CONFIRMED | MOCK |
Security Requirements
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| SEC-001 | REQUIREMENT | Only authenticated staff can view tickets | CONFIRMED | MOCK |
| SEC-002 | REQUIREMENT | Reuse existing authentication if available | CONFIRMED | MOCK |
Data Requirements
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| DATA-001 | REQUIREMENT | Store tickets with title, body, status, assignee | CONFIRMED | MOCK |
API / Integration Requirements
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| no items recorded — UNKNOWN, not PASS | ||||
Dependencies
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| DEP-001 | DEPENDENCY | Existing authentication capability (if usable) | PROPOSED | MOCK |
| DEP-002 | DEPENDENCY | Existing PostgreSQL instance | PROPOSED | MOCK |
Risks
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| RISK-001 | RISK | Email ingestion may be needed sooner than expected | PROPOSED | MOCK |
Assumptions (never auto-requirements)
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| A-001 | ASSUMPTION | Support volume stays modest. | PROPOSED | MOCK |
Open Questions (stay open until answered)
| ID | Class | Statement | Status | Source |
|---|---|---|---|---|
| Q-001 | OPEN_QUESTION | Is email ingestion required for the MVP? | OPEN | MOCK |
User stories
- As a support agent, I want see all open tickets, so that nothing is lost.
- As a support agent, I want assign a ticket to myself, so that ownership is clear.
Acceptance criteria
- AC-001: When a ticket is created it appears in the queue [testable]
- AC-002: A ticket status must be one of the allowed values [testable]
Definition of Done
- All acceptance criteria pass
- Security review complete
- No non-scope item implemented
Milestones
- M1: MVP queue — Create/assign/resolve
- M2: Later phases — Email, analytics
Initial test scenarios
- Create a ticket
- Assign a ticket
- Reject an invalid status
Kill criteria
| ID | Criterion | Outcome | Evidence | Owner decision |
|---|---|---|---|---|
| K-001 | existing system solves >= 80% of the need | PASS | No existing ticketing system. | no |
| K-002 | no clear user/problem owner | PASS | Support staff own it. | no |
| K-003 | idea duplicates existing capability | PASS | No ticket tool exists yet. | no |
Product Critic Review — CR-001
Product data source: MOCK STATIC UNKNOWN· MOCK = example fixture · STATIC = documented/committed template · UNKNOWN = no evidence. UNKNOWN is never shown as PASS.
MOCK EXAMPLE · development-only product-planning data. No production project, no live backend, no execution, no mutation endpoint. Genuine local artifacts are marked STATIC; example fixtures are marked MOCK.
- Recommendation
- NEEDS_OWNER_DECISION
- Summary
- Core value is clear; scope must shrink to a web-only MVP. Reuse existing auth; defer analytics and mobile.
- Value challenge
- Value is supported for support staff; customer self-service is not yet justified.
- Scope challenge
- Mobile and analytics are scope creep for the MVP.
- Architecture challenge
- No new database; reuse PostgreSQL.
- Operations challenge
- Low operational burden if web-only.
- Security challenge
- Reuse existing auth; do not build a second one.
- Dependency review
- Depends on existing auth + PostgreSQL; confirm availability.
- Acceptance-criteria review
- Criteria are testable.
- MVP review
- MVP must exclude mobile and analytics.
Blocking issues
- none
Non-blocking issues
- unnecessary queue — Plan mentions 'message queue'. Prefer SIMPLE first; justify or drop.
Reuse opportunities
- Reuse existing authentication.
- Reuse existing PostgreSQL.
Missing owner decisions
- OD-001
- OD-002
Proposed changes (traceable; never overwrite the original)
Original
Scope includes a mobile application.
Proposed change
Remove mobile from the MVP; keep it a later phase.
Owner decision
PENDING
PRD Gate
| Gate | Result | Detail |
|---|---|---|
| G1 PROBLEM_CLEAR | PASS | problem statement present |
| G2 USER_CLEAR | PASS | users identified |
| G3 OBJECTIVE_CLEAR | PASS | objective present |
| G4 SCOPE_CLEAR | PASS | scope defined |
| G5 NON_SCOPE_CLEAR | PASS | non-scope defined |
| G6 OWNER_DECISIONS_COMPLETE | FAIL | 2 owner decision(s) unresolved; 0 blocking item(s) |
| G7 ACCEPTANCE_CRITERIA_TESTABLE | PASS | all acceptance criteria testable |
| G8 MVP_SMALL_ENOUGH | PASS | MVP judged small enough |
| G9 DEPENDENCIES_IDENTIFIED | PASS | dependencies identified |
| G10 RISKS_IDENTIFIED | PASS | risks identified |
| G11 SECURITY_CONSIDERED | PASS | security requirements considered |
| G12 KILL_CRITERIA_CLEAR | PASS | all kill criteria evaluated PASS |
| G13 CRITIC_REVIEW_COMPLETE | FAIL | critic requires owner decision |
| G14 TECHNICAL_HANDOFF_READY | UNKNOWN | technical handoff readiness UNKNOWN |
Build Readiness
Build Readiness
10/13 VERIFIED
VERIFIED only · UNKNOWN is never a pass
Problem
VERIFIED
Users
VERIFIED
Scope
VERIFIED
Requirements
VERIFIED · 7 confirmed requirement(s)
Acceptance Criteria
VERIFIED · all testable
Dependencies
VERIFIED
Risks
VERIFIED
Security
VERIFIED
MVP
VERIFIED
Owner Decisions
BLOCKED · unresolved owner decision
Critic Review
WARNING · owner decision required
Kill Criteria
VERIFIED
Technical Handoff
UNKNOWN
Blockers
- Owner Decisions — unresolved owner decision
Warnings
- Critic Review — owner decision required
Unknown
- Technical Handoff — unknown
Owner Decisions
OD-001 · UNANSWERED
- Question
- Use existing auth or build new auth?
- Why it matters
- Determines security review and integration effort.
- Options
- Reuse existing auth — Less to build; depends on the existing system.
- New auth — Independent; more to build and secure.
- Product Architect recommendation
- Reuse existing authentication.
- Product Critic view
- Reuse — avoid a second auth system.
OD-002 · UNANSWERED
- Question
- Web only or mobile included?
- Why it matters
- Mobile roughly doubles MVP scope and operational burden.
- Options
- Web only — Smaller MVP, faster.
- Web + mobile — Much larger scope; defer.
- Product Architect recommendation
- Web only for the MVP.
- Product Critic view
- No mobile app in the MVP.
OD-003 · UNANSWERED
- Question
- MVP includes analytics?
- Why it matters
- Analytics is not required to prove the core value.
- Options
- Later phase — Keep MVP small.
- Include now — Extra scope.
- Product Architect recommendation
- Analytics as a later phase.
- Product Critic view
- Defer analytics — not needed for the MVP.
No technical handoff. A handoff is only created after PRD approval.