Product feedback triage notes

Weekly triage 3 items declined this cycle 1 needs reproduction Internal only

How we sort every incoming Relay API request into evidence, plan or decline, and the decisions made this cycle. Prepared by Product for the customer-facing leads who submit requests. Request names, accounts and reach figures in this template are synthetic sample data.

Sample template: the firm, people, clients and figures are fictional, and the embedded view holds synthetic sample records.

Live example from the Dashboards app, shown with Willow & Peak's demo data.

Triage rules

The evidence table

Sorted by reach, highest first. Reach counts distinct accounts or interviews citing the request; it is a proxy for demand, not a promise to build.

How a request moves through triage

flowchart LR
    A[New request logged] --> B{Reach 15+ or a security or data-loss risk}
    B -->|Yes| C[Triaged: weekly decision meeting]
    B -->|No| D{Evidence link attached}
    D -->|Yes, reach 5 to 14| C
    D -->|No| E[Needs evidence: request interview or ticket]
    E -->|Evidence gathered| C
    C --> F{Decision}
    F -->|Clear reach, fits roadmap| G[Planned]
    F -->|Weak evidence or out of scope| H[Declined]

Decisions this cycle

Declined this cycle

Follow up with requesting customers

Reach tells us how many accounts asked. It never tells us whether the fix is small enough to ship this month; that is still a judgment call in the Friday meeting.

Waiting on evidence

These requests stay in Needs evidence until we can reproduce them or gather more interviews: custom approval states, the accounting sync failure above, two-way CRM contact sync, portal language options and time tracking on tasks. None move to Triaged until that evidence exists, no matter how urgent the priority label reads.

Two out of five. Pine Hollow has reported the failure only once and has not replied to our last two follow-up messages, so reproduction depends on hearing back from them first.