Overview

How Poth works

1
Sources come in

Calls, support tickets, CRM notes, Slack threads, NPS and survey results, in-app chat, internal docs and product analytics are ingested continuously. Nothing is discarded as unstructured — a call transcript and a CRM field are both signal. See Connect your sources.

2
The graph is built

Signals connect to the customers, accounts, segments and features they concern. This is what makes cross-source reasoning possible: a churn reason mentioned on a call links to the account, the account links to its usage pattern, the usage pattern links to the feature. See Knowledge graph.

3
Patterns are extracted

Repeated signals are grouped into themes and ranked by weight and segment, not by recency. You get "onboarding friction, 847 mentions, SMB under 50 seats" rather than a wall of quotes. See Pattern extraction.

4
Hypotheses are tested

For each pattern, agents form competing explanations and score them against product, operational and behavioural data. Weak ones are rejected with their confidence shown, so you can see what was ruled out and why. See Hypothesis engine.

5
Gaps are collected

When no existing data separates two surviving hypotheses, Poth generates the specific questions that would, and sends them as targeted follow-ups. Each question tests one explanation. See Adaptive surveys.

What an answer contains#

Part What it tells you
Insight The pattern, stated as a finding rather than a quote
Evidence Counts, sources and the trail behind the claim
Segment Who this actually applies to
Confidence How strongly the data supports it
Recommended action The lever with the largest expected effect

Why rejected hypotheses are shown#

A finding is easier to trust when you can see what it beat. If cleanliness was rejected at 18 percent confidence because morning cleaning was logged as completed, you know the obvious explanation was tested rather than skipped.

Next#

Updated