Feedback summaries can tell you what customers are saying. The expensive question is why.
The dashboard is not the deliverable. The dashboard is the beginning of an argument you haven't finished having.
Theme clustering, sentiment tagging, and summaries can tell you what customers are saying. The harder question is why it is happening, and that gap is where expensive mistakes live. We built Poth on that distinction: a summary of feedback is not an explanation, and acting on the summary alone can point a team at the wrong cause.
Themes are not causes
Feedback tools have been clustering tickets and sentiment-tagging transcripts since well before the current AI wave. Feed them your call transcripts, Slack threads, support tickets, and survey responses, and they'll hand back a clean thematic breakdown: 40% of complaints mention onboarding, sentiment on mobile is trending down, the word "confusing" appeared 200 times this quarter.
That output is genuinely useful. It can also become the stopping point. "Customers mention onboarding" doesn't tell you whether the real problem is a broken signup flow, a missing integration nobody flagged directly, or a pricing page that sets the wrong expectation before onboarding even starts. A theme dashboard describes the symptoms; the diagnosis still needs evidence.
Where the money actually gets lost
Here's the scenario that makes the distinction concrete. A B2B SaaS company sees a churn spike in a cohort. The dashboard shows a cluster of complaints about price. The obvious move is to adjust pricing or offer a discount to the accounts most likely to leave.
But if the real driver is that this cohort never got through onboarding, and "too expensive" is just the socially acceptable reason people give when canceling a subscription they never got value from, the pricing fix does nothing. Worse, it teaches the team the wrong lesson: next quarter, when churn ticks up again, pricing is the first place they'll look, because that's what "worked" last time. Misattribution doesn't just waste one fix cycle. It corrupts the team's model of its own customers, and that model compounds.
No amount of re-summarizing the complaints gets you from symptom to cause. You need a mechanism that actively tests candidate explanations against evidence, not a nicer chart of the same input.
What a hypothesis engine does that a dashboard can't
Poth starts by building a persistent customer knowledge layer: it connects the places customer evidence already lives — call transcripts, Slack threads, support tickets, CRM notes, surveys, in-app chat, docs, product analytics — into one model your team can actually reason over.
The hypothesis engine sits on top of that. For a given problem, it generates specific candidate explanations rather than one summary — onboarding friction, a missing integration, a cadence mismatch — and assigns each a confidence score. Then it goes beyond theme reporting: it tries to validate or reject each hypothesis against the connected evidence. And where the existing evidence doesn't settle it, it generates a targeted follow-up question or survey designed to close exactly that gap.
That last step is the actual product. A feedback tool that only shows what has already been said still leaves the missing-evidence problem to the team. A system that can identify its own evidence gap and go collect the missing data point is doing something much closer to an analyst's work than a dashboard's. It's an active loop, not a passive report: generate candidates, check them against what you know, and when you don't know enough, go find out instead of guessing.
Who's doing the guessing right now
The gap between aggregation and attribution doesn't belong to one size of company. What differs is who's currently doing the guessing.
At a small startup, this work often falls to a founder or product lead synthesizing support tickets and call notes from memory, in spare time. Without a dedicated research function, root-cause analysis can easily lose out to more immediate work.
At a larger company, the evidence is often split by function: CX owns the surveys, insights owns the interviews, analytics owns the behavioral data, and support owns the tickets. Connecting those slices into one tested explanation can become a cross-team project, so a theme on a dashboard may stand in for a fully tested cause.
Poth fits those two situations differently: the full platform for teams that have no research function yet, and a synthesis and hypothesis layer for enterprises that plugs into the stack they already run rather than replacing it. But the mechanism is the same in both, because the failure it prevents is the same — acting on a theme instead of a tested cause.
The honest limit
A hypothesis engine can only test explanations against evidence that exists. If a conversation was never recorded and a complaint never made it into any system, there's nothing to connect. Scattered isn't the problem — scattered-but-captured is exactly the situation a customer knowledge layer is built for. Never-captured is the real limit.
That's why Poth is built to say "we don't know yet" instead of papering over a gap. When the evidence isn't there, it tells you which hypothesis is untested and generates the question that would test it. If your company is starting from very little captured feedback, expect the first stretch to be more collecting than mining. We'd rather tell you that up front than pretend any model can conjure evidence that was never written down.
The question to ask any vendor — including us
Many dashboard demos now share the same opening moves: clustering, sentiment, and theme extraction. What separates tools in this category is what happens after the summary. Does it generate specific, falsifiable explanations for a problem? Does it check them against evidence you already have before asking anyone anything new? And when the evidence genuinely isn't there, does it know how to go get it, rather than leaving that step to you?
Aggregation answers "what are people saying." That was never the expensive question. The expensive question is which of the three plausible explanations for a metric moving is the real one — and whether your team is currently guessing at the answer or actually testing it.