The real cost of manual feedback triage
Manual feedback triage is the work of reading everything customers say — in Slack, support tickets, sales calls, GitHub — and turning it into something a team can act on: deduplicated, tagged, counted, filed. Most teams account for it as a few hours a week of somebody's time.
That accounting is wrong in an interesting way. The hours are the smallest cost. The expensive parts are the distortions manual triage introduces into decisions, the attention it burns in people whose attention is the company's scarcest resource, and the follow-ups that never happen. Worth pricing each one.
The visible cost: the hours
Start with the obvious line item. Someone — a founder, a PM, a rotating engineer — reads channels, copies quotes into a doc or spreadsheet, decides whether each item is new or a duplicate, tags it, and files a ticket. At any real volume this is a recurring multi-hour weekly commitment, and it scales linearly with feedback volume, which scales with growth. The work that grows fastest as your company succeeds is the work you least want a senior person doing by hand.
But if hours were the whole cost, triage would be an intern problem. It isn't, because of what the manual process does to the data.
The distortion cost: fragmented counts
Manual triage across channels systematically undercounts demand. The same request arrives as a Slack thread, two Zendesk tickets, and a line in a sales call, and unless one person reads all four channels with perfect recall, it gets recorded as separate weak signals. IdeaLift's write-up on scattered feedback gives the canonical example: a feature mentioned by 12 customers across 4 channels looks like 4 separate low-priority requests instead of one high-priority pattern.
The downstream effect is that prioritization runs on corrupted inputs. Loud, recent, well-connected requesters outrank quiet numerous ones — not because anyone decided that, but because recency and proximity are what human memory indexes on. A roadmap built this way isn't wrong at the deciding step; it's wrong at the counting step, which is worse, because the deciders never see the error. We wrote more about the mechanics in feedback aggregation.
The attention cost: triage as interruption
Triage doesn't arrive in a tidy weekly block. Feedback lands all day, and the person responsible either batches it (and lets it rot between batches) or handles it as it comes (and pays the switching tax). The research on interruptions is not kind to the second option: work summarized by Toggl's review of context-switching studies — including Gloria Mark's well-known UC Irvine findings — puts the average elapsed time before returning to an interrupted task at around 23 minutes, and describes the "attention residue" that lingers on the next task even after a brief switch.
For a founder or engineer doing triage between deep-work sessions, each "let me just file that" costs far more than the two minutes it appears to take. This is the cost that makes triage-by-rotation quietly corrosive: it spreads the interruptions across the whole engineering team instead of concentrating them.
The silence cost: the loop that never closes
The last cost is the one customers actually feel. Manual triage almost never records who asked in a durable, queryable way — the quote gets filed, the requester doesn't. So when the fix ships, nobody knows whom to tell, and the message doesn't go out. The customer who reported the bug learns it was fixed by accident, months later, or never.
That silence trains customers to stop reporting, which degrades the input side of the whole system. Closing the loop is cheap when the data supports it and impossible when it doesn't; we've written about that failure mode at length in close the loop.
What the automated version looks like
Every cost above traces to the same root: triage is high-volume mechanical reading, and humans are the wrong instrument for it. The reading, deduplicating, tagging, counting, and routing are exactly what language models handle well now — the judgment about what to build afterward is not, and doesn't need to be.
Disclosure, since this is our subject: we build Modem, which does this triage automatically — capturing feedback across chat, support, and sales channels, deduping and quantifying it with requesters attached, filing issues in Linear, Jira, or GitHub, and matching merged PRs back to the people who asked. The counting distortion above is specifically what its context graph exists to fix — one issue linked across channels, one person across identities — so a theme's count measures demand rather than filing noise. The fair caveat is that automation fixes the pipeline costs, not a judgment vacuum: if nobody on your team is making prioritization calls, clean data just makes the vacuum better organized. And if your feedback volume is genuinely tiny — a handful of items a week — manual triage is fine and you should spend your money elsewhere.
Pricing it for your team
Run the audit honestly. Count the weekly hours across everyone who touches feedback, not just the designated owner. Then ask the two questions the timesheet misses: when did a shipped feature last surprise you with low usage while an unshipped one kept getting requested — that's the counting distortion — and when did you last proactively tell a customer their request shipped — that's the open loop. If either answer is uncomfortable, the real cost of manual triage is already larger than the hours, and the hours were already too many. Which fix to reach for first depends on where it breaks for you; we mapped that in which feedback tool for which bottleneck.
