Findings

A finding is a structured, org-level issue that groups one or more conversations exhibiting the same problem — a recurring script failure, a mispronounced product name, a tool the agent keeps misusing. It is a curated record, created by a person or surfaced by AI, with its own title, description, priority, assignee, tags, and a set of linked calls. Don’t confuse a finding with the per-call analysis_findings produced during conversation analysis. Those are observations on a single call. A finding sits one level up: it is the durable, shareable issue you actually triage and fix, and it draws its evidence from the calls you link to it.

​

Continuous opportunities

Open Findings → Opportunities to compare recurring call problems over time. Select Set up continuous analysis to create a shared monitor with checks for failure type, intent, greeting, transfer path, task outcome, frustration, and supporting evidence. The first boolean stage measures whether an observable problem affected the call; the remaining stages explain it.

1. Select the agents to compare. For a greeting pilot, start with the 3–4 agents considered good and the 3–4 considered poor.
2. Review the instructions and try the monitor on example calls. Validate legitimate transfers, unsuccessful assistance, and ambiguous outcomes with the team before trusting aggregate rates.
3. Save and enable the monitor for ongoing calls. Use the monitor’s existing backfill controls if historical comparison is needed.
4. Return to Opportunities, choose a date range, and narrow by practice, agent, or conversation metadata.

The view ranks issue-and-intent groups with at least two affected calls, first by affected call count, then by rate movement. It shows the previous equal-length period, daily totals, affected agents/practices/versions, and up to three example calls per group. Counts cover the selected population and current monitor version after its analysis start date. Missing and unknown judgments are reported in coverage and excluded from known-outcome rates. Sampling can affect representativeness; rates are not estimates of all unscored calls.

​

Greeting groups and operational context

Send a string in metadata.opportunityContext.greetingGroup to compare named cohorts such as reviewed-good and reviewed-poor. Without it, calls are grouped by the monitor’s observed opening-length classification. Labels are limited to 100 characters in this view. Cohort differences are associations: practices, caller intent, and configuration can explain them. Use them to propose a test, not to infer that the greeting caused the difference. The preset optionally reads these fields under metadata.opportunityContext: Also supply transcripts, tool outcomes, practice attribution, and stable agent version identifiers. Confirm these reach Zelto through the selected ingestion path; a telephony integration alone does not establish that an internally orchestrated workflow supplies this context. See custom call uploads. Transfer paths distinguish required handoffs, immediate human requests, escalation after attempted help, unavailable appointments, tool failures, and unknowns. Appropriate transfers are not counted as successful containment. Multi-action evidence lists requested tasks and their individual outcomes. Suspected explanations remain hypotheses unless operational evidence supports them; the classification is not a root-cause guarantee.

​

From evidence to a change

Owners and admins can Submit finding for review. This creates a candidate with representative call links and the observed volume in its description; those sample links do not represent the entire affected population. Repeating the same submission reuses the candidate. The existing candidate review process publishes accepted findings. New calls update the Opportunities view; they do not automatically rewrite or attach themselves to an already submitted finding. Configure an experiment carries the monitor and suggested name into Experiments. Choose two deployed versions of one agent and review the setup before launching. Zelto measures the outcomes; your platform owns deployment and consistent caller routing. The initial comparison across practices is not a controlled experiment.

​

Anatomy of a finding

Volume is snapshotted when the finding is created: the numerator is the linked conversations inside the analyzed window, and the denominator is all conversations for the same agents over that same window. Later platform-wide uploads don’t auto-link to existing findings, so they can’t dilute the percentage after the fact. Volume is null when there were no agent calls in the window to compare against.

​

Status

​

Priority

Five levels, from lowest to highest: none, low, medium, high, urgent. Priority is independent of status — an open finding can be any priority, and you set it when triaging.

​

Categories

A finding’s category is one of these seven types (or left empty):

• Voicemail not detected
• Bad pronunciation
• Does not follow script
• Bad ASR
• Does not understand the user
• Does not use tooling correctly
• Inconsistent voice

​

Linking conversations

Calls attach to a finding through the finding_conversations join. Linking is idempotent — adding a conversation that’s already linked returns the existing link rather than creating a duplicate. A conversation must belong to the same org as the finding, so you can’t accidentally pull in another tenant’s call. The reverse view holds too: a conversation’s detail page lists every finding it’s linked to, so you can jump from a single call to the broader issue it’s an example of.

​

Annotations and comments

Each linked call carries its own comments, and a comment can be anchored to a slice of the transcript with annotationStartMs and annotationEndMs. That lets you point at the exact moment a call went wrong — “the agent talked over the caller from 0:42 to 0:51” — instead of describing it in prose. Every comment records its author and a type (a plain comment or a transcript annotation).

​

Working a finding

From the finding detail page you can:

• Set priority, assignee, and status. The status button in the top-right advances a finding to its next stage in one click (an open finding → Acknowledge, an acknowledged one → Resolve), with a dropdown for the other transitions.
• Edit the title and the rich description. The description editor supports headings, lists, diagrams, @-mentions, and call examples — type /call to embed one of the finding’s linked calls. The embed plays the recording (with the annotated moments marked on the scrub bar) and shows the annotated transcript excerpt inline, so the writeup points straight at the moment that proves the issue.
• Copy a finding prompt — a packaged summary (title, category, status, description, agents, linked calls) you can hand to an LLM for a deeper look or a draft fix.
• Push to Linear if your org has it connected, turning the finding into a tracked issue. See Linear.

Linked changes can also surface on a finding to track the fix alongside the problem.

​

Programmatic access

Findings are fully scriptable over the REST API: The same operations are exposed as MCP tools — list_findings, get_finding, create_finding, update_finding, add_conversation_to_finding, and annotate_finding_conversation — so an agent can triage findings directly.

​

Related

• Conversations — the calls and transcripts a finding links to.
• Monitors — promote a recurring finding into a continuous check.
• Changes — the agent-scoped fix that addresses a finding.
• Linear — push findings into your issue tracker.
• REST API · MCP — triage findings programmatically.