Label every verbatim as a decision, not a filter: the classification it enters, a reportability flag raised independently of it, and the clock it starts, held for the named reviewer who confirms it.
A verbatim arrives, and the words the reporter used are kept beside the label that follows.
02
A label is applied, and a reportability flag is raised apart from it, on rules of its own.
Reason
03
A verbatim reads like a safety event, and 21 CFR 803.17(a)(2) makes that judgement a process.
04
A duplicate is proposed, and merging is treated as a claim about count, not as tidying up.
05
A cluster is merged, and the earliest member timestamp is carried forward as the clock start.
Decide
06
A report is unverified, and it stays in the population — 49 CFR 579.4(c) is explicit.
07
A label is written, and the input, the model version, the threshold and the reason are kept.
Out
08
An item fits no class, and it is raised as unclassified rather than pressed into the nearest one.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Intake, labelling, flagging and routing belong to the agent. The reportability determination belongs to a named reviewer, who makes it on the record and owns it.
Example workflow
One verbatim, intake to determination
AgentHuman
1Feedback item receivedSupport ticket, app-store review, sales note, survey verbatim or field report
2Product and market resolvedWhich product it names, which market the reporter sits in, the channel it came on and when
3Label and flag proposedThe primary class, the reportability flag, the clock start and confidence
4Controls appliedTaxonomy checks, duplicate-merge checks, flag-suppression checks and confidence
No human action required
Stages 1 to 4 run unaided, and nothing is reported at any of them — the agent is labelling, and the reviewer lane opens at the reportability gate.
5DecisionSplits at the reportability gate
Routine class, no flag
Goes to the named reviewer to confirm.
Any flag raised
Adds a safety-lead read first.
Reviewer decision
The item is held with its verbatim, its flag, its clock start and the confidence.
Confirm · Reclassify · Send to safety review
Confirmed — by the named reviewer▼
6Ticketing and complaint records updatedOnly where write access and records policy allow it
7Outcome evaluatedLabel correctness, missed flags, reviewer overrides and what review found
Overrides
A label found wrong later is reopened, re-timed and counted.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Deciding whether an event is reportable.
Filing a report with any regulator.
Closing a flagged item without a review.
Collapsing a cluster into one reportable event.
Automation boundaryAgent acts unaided
✓Label the item and record why that label was given.
✓Raise the reportability flag on rules of its own, apart from the class.
✓Carry the earliest member timestamp forward as the clock start.
✓Hold a flagged item for the named reviewer to decide.
No report leaves the company except by a named reviewer, inside the agreed boundaries.
Judging whether a complaint concerns your product.
Telling a regulator an event was not reportable.
Setting the confidence threshold for a flag.
Changes to the taxonomy, the flags or the routing.
Example output
One feedback item, annotated
An FDA warning letter of 22 November 2024 found complaints unevaluated because the firm had classified the server as not a medical device; here is one item.
Classification output · single itemIllustrative example
Channel
Verbatim
Class
Reportability flag
Confidence
Held for
App-store review, consumer market
Device ran hot while charging
Bug, hardware
Raised, routed to review
Clock start, 3 August 2026
The named reviewer, by name
As receivedTaken from the store review and the intake record — nothing on this side is written by the agent.
What the record holdsThe verbatimProduct namedReporter market
Why no filing hereWhether an event is reportable is a call the named reviewer makes.
ActionConfirmReclassifySend to safety review
What the score decidesBelow the configured threshold an item gets a safety-lead read before the reviewer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every verbatimFrom the channel it arrived on
03Labelling
What the label decides
A voice-of-customer agent ties themes to the words behind them; this one decides which bucket an item enters, and one of those buckets starts a statutory clock.
01Approved path
A label is a decision
The same verbatim can carry a twenty-four-hour duty or a thirty-day one, and neither attaches to the class you filed it under.
02Human review
What was checked, and not found
No law of general application requires an ordinary software company to classify product feedback at all. Every duty found here is sectoral — devices, vehicles, consumer products, mortgage servicing — and it attaches to what you sell, never to the fact that feedback arrived.
04Build an evidence trail
The verbatim, the label it was given and the analyst who confirmed it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Support and ticketingZendesk · Intercom · Freshdesk Support tickets and chat threads
App stores and reviewsApp Store · Google Play · G2 Public reviews and ratings
Sales and field notesSalesforce · HubSpot · Gong Field reports and win-loss call notes
Agent
Feedback classification
Reads the item Proposes the label Holds for the reviewer
Complaint and quality recordsJira · Linear · Azure DevOps Complaint handling and CAPA files
A class-level escalation figure can read clean while safety-adjacent verbatims absorb most of the reviewer overrides. Nestack reports the override rate by feedback class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Safety-adjacent verbatims
13.2%
3.7×
Review
Merged duplicate clusters
9.4%
2.6×
Review
Non-English verbatims
5.9%
1.7×
Watch
Routine feature requests
2.8%
0.8×
Normal
Bar: override-rate lift vs. routine-request baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What the wrong bucket costs
A cycle ends when the safety report filed under a bug label is a standing case. That suite is what the next batch classified is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Override rate rises on safety-adjacent verbatims.
02Diagnose
The insulin-logging report filed under UX bug, on the morning the clock quietly started, is pulled apart until a single cause remains.
03Improve
The change ships numbered, and the verbatims that forced it ride with it.
04Verify
One label case still failing is enough to hold the release back.
05Learn
It is kept for good, and the labelling rules are amended in the same commit.
Learn → DetectThe return edge. The next batch is labelled against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, labelling workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Feedback-taxonomy and automation-boundary definition.
02Support, store and field source assessment.
03Taxonomy-to-verbatim and reportability-flag mapping.
04Multi-channel intake.
05Label, flag and clock-start binding.
06Confidence scoring and review routing.
07Reviewer confirmation workflow.
08Ticketing-system integration.
09Label and escalation cases.
10Guardrails and routing controls.
11Label-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne channel, one quarterProductionProduction feedback workflowAdvancedMultiple channels / markets
Introduced at Pilot
Label and flag to your taxonomy✓✓✓
Named reviewer confirmation✓✓✓
Feedback-corpus baseline✓✓✓
Introduced at Production
Reporting by label class—✓✓
Reviewer workflow in your systems—✓✓
Approved write-back—✓✓
Ticketing-and-store integration—✓✓
Introduced at Advanced
Multiple taxonomies——✓
Multi-team review chains——✓
High feedback volume——✓
Multi-channel intake controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, feedback volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live feedback channels and the taxonomy you label with→Taxonomy capture and reportability-flag designWeek 1
02Representative verbatims from each of your live channels→Channel binding, label logic and the corpus baselineWeek 2
03Your escalation path and the reviewers it names→Taxonomy mapping, flag design and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Support, store and field source assessment, then integration setupWeek 2
05Labels you would not want audited→Escalation cases and the failure-mode roundWeek 4
06What no label may close→Confidence scoring, flag routing, guardrails and release controlsWeek 3
07A named reviewer who confirms the label→Reviewer confirmation workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
The bands below are measured, not spaced for looks; week five carries two because those two overlap.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Feedback channel discovery, taxonomy mapping and the automation boundaryW2Source integration and the feedback-corpus baselineW3Labelling workflow, flag logic and reviewer release controlsW4Evaluation suite, escalation cases and failure-mode testingW5Ticketing and store integration, pilot batches and correctionsW6One feedback quarter run under the product owner, then Agent Care handover
Reading the bandA band sits on the weeks its work is actually named in, and the week five doubling is real.
At the end of W6When the label record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Product AI agent
Build a feedback agent around the label your taxonomy has no name for.
Show us one quarter of feedback and the taxonomy you sorted it into. Every label in that quarter decided something: which queue an item joined, who read it, and whether a clock started. If no class exists for a reportable event, the safety signals landed in bug.
