Product PRD Workbench

HarborDesk controlled bulk closure — pilot PRD

Synthetic example run. All company names, observations, and source numbers are fictional simulation data from the supplied source packet. This is a complete practice deliverable, not a shipped product or measured customer result. Design choices below are recommendations; validation has not been run.

1. Executive summary

Recommend a capped, tenant-local pilot that reuses the filtered ticket list and single-ticket close operation. A support lead selects resolved tickets, reviews their identities and reasons, confirms the exact selection, and receives a verified result for every item. Use an orchestration layer only if execution-time eligibility checks, safe retry handling, and an operator recovery procedure can be verified within the resource limit. Do not make atomic batch processing or one-click undo a pilot dependency by assuming either exists.

The intended behavior is deliberate closure of a reviewed group without repeated navigation, while retaining individual accountability. The expected business benefit is less repetitive handling; neither time savings nor commercial impact has been established. The strongest risk is closing a ticket whose state or assignment changed after preview. A confirmation screen alone cannot prevent that harm.

Authorize discovery and implementation preparation first. Authorize live writes only after the safety gate below. If those prerequisites cannot fit two engineers over two weeks, test the guided single-ticket alternative instead. Expansion requires demonstrated operational reversibility and comparative evidence of user value.

2. Problem and evidence

Support leads need to close groups of already-resolved tickets. Leads benefit immediately from fewer repeated actions. Leads also gain review and exception-handling work; support operators may gain recovery work. A faster close action can encourage larger selections and hide individual errors, so success must reward correct final states rather than volume of clicks.

Why now: the supplied two-week pilot opportunity can test value and safety before larger investment. There is no supplied competitive deadline, revenue threat, or launch commitment.

3. Outcomes, experiment, and measurement

Hypothesis: For support leads closing already-resolved groups, a capped preview-and-confirm flow will reduce active handling time versus a guided single-ticket flow while preserving authorized, correct closure and recoverability. The mechanism is reduced navigation, an inference to test.

Randomize the order of the two flows within participating leads using comparable group-size and change-risk bands. Start with controlled tasks before live use. Record actual preview-to-result handling time, correctness, and recovery effort for both. Do not treat the source median as the control arm. Tenant, lead, group size, changed-state reason, and experimental order must be inspected before pooling results.

All rate windows use actual pilot exposure, with a seven-day follow-up proposed for recovery review. Counts must include all participating tenants, including those disabled mid-pilot. Review by segment before aggregates; do not remove changed-state rejections to improve yield. Minimum exposure and uncertainty analysis are TBD: choose after measuring group variation, before live enrollment. An underpowered favorable sample permits continued bounded learning, not scale.

4. Boundaries and options

Goals: deliberate grouped closure, complete per-item accounting, visible exceptions, preserved authorization, and verified recovery. Non-goals: cross-tenant batches, automatic selection or closing, AI-generated eligibility, guaranteed atomicity, unverified undo, unlimited batch size, and unrelated ticket-management redesign.

Proposed cap: 20 selected tickets per operation, chosen to keep preview and exception review manageable. Validate readability and execution load before adopting that cap; it is not an existing limit. The strongest counterargument is that a guided single-ticket queue captures most benefit with less operational risk. The comparative experiment decides whether batching adds enough value.

5. Experience, states, and acceptance criteria

1. A support lead opens the existing tenant-scoped filtered list. Selection is explicit and capped; select-all across unseen pages is excluded initially.
2. Preview lists ticket identifier, current resolved status, current assignment, intended reason, and count. The canonical definition of eligible resolved tickets must be confirmed before build. No action has executed yet.
3. Confirmation binds to the displayed IDs, tenant, reasons, and preview revision. Changing the selection or reason returns to preview. Cancel has no write effect.
4. For each item, the server rechecks lead permission, tenant membership, current eligibility, and relevant revision/assignment at the write boundary. A separate read followed by an unchecked write is insufficient. A changed assignment or reopened ticket is rejected for fresh review, even if still apparently closable.
5. The system presents per-item results. Successful items remain closed; failures are never portrayed as a fully successful batch. Unknown outcomes enter reconciliation; the lead may leave and return without losing result visibility.
6. A lead may retry selected rejected items only after refreshed preview and confirmation. A timeout is reconciled before any retry. Recovery requires an authorized operator and protects newer legitimate changes.

Proposed lifecycle: previewed -> confirmed -> attempted -> succeeded | rejected | unresolved. Before attempting, cancellation/disablement can yield not_attempted. A succeeded item may later enter reversal_requested -> rolled_back | reversal_rejected | reversal_unresolved. Rolled_back means the approved compensating state was verified, not that a recovery button was clicked. Operational reversal is not equivalent to database transaction rollback.

Required reconciliation: confirmed items = attempted + not-attempted; attempted items = succeeded + rejected + unresolved. Rolled-back items are a subset of succeeded items, not an additional mutually exclusive attempt outcome. Preserve the gross success record when deriving net success. A batch is complete only when each confirmed item is accounted for; it is cleanly successful only when every item meets the intended post-state.

6. Technical and operational gates

This pilot adds no AI agent. No automated authority beyond confirmed intent is proposed. Ticket storage is authoritative; the audit log records evidence and does not substitute for post-state verification.

Engineering responsibility is proposed, but its named owner is unknown. Before live writes, verify single-close API behavior, conditional execution, operation correlation, duplicate submission handling, reconciliation, and an authorized compensating recovery path. The presence of an existing audit log does not prove all required fields are available. Confirm data retention and access policy rather than inventing a retention period.

If atomic batch is verified, assess it separately against the same authorization and recovery contract. If undo is verified, verify its treatment of later changes. If either is unavailable, continue only with a tested bounded alternative. Disable the pilot if there is no safe write-boundary guard or no recoverable operational procedure; an attractive preview is insufficient.

Proposed phases: controlled concurrency and recovery tests; internal task comparison; an explicitly enrolled tenant-local pilot; expansion review. Dates and enrolled counts are unknown. Within the supplied resource limit, trim scope or choose the guided alternative rather than treating the plan as a two-week delivery promise.

Use tenant feature controls and a global write stop. On a safety incident, stop new attempts, preserve the operation ledger, reconcile in-flight writes, notify the responsible operator through a process still to be named, and use only verified recovery. Feature disablement does not reverse already-closed tickets. Preserve filtered single-ticket close as fallback when safe.

7. Risks, decisions, and next actions

No product approval, assignment, release, or measured validation is recorded. Decisions requested: accept conditional scope and proposed thresholds; select actual owners and dates; authorize controlled discovery; then separately decide whether evidence satisfies the live-write gate.

Delivery review performed: The document separates verified components from unknown batch/undo behavior, covers stale eligibility and authorization, reconciles per-item states and reversal, and keeps interviews/time savings appropriately bounded. Implementation, safety tests, and experiment outcomes remain unrun.