Skip to main content

Conversation audits

Conversation Audits configures the hourly root-cause analysis (RCA) job that samples your conversations, works out what went wrong, and files each finding under a category and tag. Use this page to control how much the audit reviews, which conversations it picks up, the root-cause categories it sorts findings into, and the tag vocabulary it uses. The audit's results are read in Insights → Conversation Audits.

Edits are staged. A sticky Save / Discard bar appears at the bottom whenever the current configuration differs from what's saved. Two buttons at the top act immediately, without going through Save:

  • Run once — queues an audit run right now instead of waiting for the hourly schedule.
  • Reset to defaults — restores the platform-default triggers and analysis groups (asks for confirmation first).

General​

Coverage window and per-run limits for the audit job.

  • Config name — a label for this audit configuration.
  • Lookback days — how many days back the audit considers when selecting conversations (minimum 1).
  • Max interactions per run — the maximum number of conversations audited in a single run (minimum 1). Caps cost and runtime.

An Enabled / Disabled tag next to this section shows whether the audit configuration is currently active. (Whether audits run at all for the account is a super-admin toggle — see Super Admin Tools.)

Triggers​

Triggers are the conditions that cause a conversation to be picked up for audit. Each trigger has:

  • An enable toggle — turn the trigger on or off.
  • A label and description — what the trigger looks for.
  • Condition tags — a read-only summary of what the trigger matches: channels, customer moods, and/or CSAT ratings (shown as stars).
  • Focus instructions — free text telling the auditor what to pay attention to for conversations caught by this trigger.

A conversation matching any enabled trigger becomes eligible for the audit.

Analysis groups​

Analysis groups are the root-cause categories the audit sorts findings into, each with its own tag taxonomy. Groups are shown in a collapsible list; each header shows the group's name, an Enabled / Disabled tag, and its tag count. Inside each group:

  • Enabled — a toggle for whether this category is used.
  • Default stream — where findings in this group are routed by default: Platform fix, Business insight, AI quality (internal), or Let planner decide.
  • Instructions — free text guidance for how the auditor should categorise into this group.
  • Tags — the closed vocabulary of tags available in this group. Remove a tag with its close (×) button, or type a label and press Add (or Enter) to create one. New tag labels are automatically converted to a normalised key.

Suggested tags​

A read-only feed of tags the audit job has proposed from recent findings that aren't yet in your taxonomy (looking back 30 days). Each row shows the suggested tag, the group it belongs to, and how many times it was seen. Click Add tag to fold a suggestion into that group's tag list (it then appears under Save like any other edit). Suggestions already present in your taxonomy are hidden, and the section shows "No new suggested tags right now" when there's nothing to review.

How it works​

On its hourly schedule (or when you click Run once), the audit selects up to Max interactions per run conversations from the last Lookback days that match any enabled trigger. For each one it performs a root-cause analysis, assigns it to an enabled analysis group, and tags the finding from that group's tag list — routing it to the group's default stream. Over time the job proposes new tags it keeps encountering, which surface under Suggested tags for you to accept into the taxonomy. The findings themselves are reviewed in Insights → Conversation Audits.

Audit all conversations​

When Audit All Conversations is enabled in Super Admin Tools, each scheduled or ordinary Run once audit selects conversations from yesterday only, from midnight inclusive to today's midnight exclusive in the business timezone (default Asia/Kolkata). For example, a run on September 8 audits September 7. This includes yesterday's late-night conversations even if they are less than 24 hours old or their tickets are still open.

The previous day's window is fixed when the run starts. Conversations within it are processed oldest first. Previously audited conversations are normally excluded, so repeated runs on the same day continue through that day's remaining conversations. Re-audit rules, such as new email messages, still apply inside the window. Stored scan cursors do not pull older backlog into these runs; when the calendar day changes, the window moves forward even if older work remains.

Each account gets its own Max processed/run budget (default 500, configurable from 1 to 2,000). Skipped or failed conversations do not consume it. The job fetches additional pages within yesterday until it completes the configured number of AI analyses or exhausts eligible conversations. The operational CONVERSATION_AUDIT_MAX_INTERACTIONS_PER_RUN ceiling (default 2,000) applies per account. Explicit manual-run limits bound processed conversations for broad audits and selected conversations for trigger-only audits.

Historical passive-email recovery remains available only through an explicit account-scoped Run once API request with passiveEmailBackfillDays (1–30). This intentionally uses the requested historical range instead of yesterday and does not move the scheduled cursor.

Passive email accounts​

When email Passive analysis is enabled, the audit reviews the external email exchange. It reconstructs replies from supported quoted and forwarded email formats, including conversations contained in a single stored email. Internal ticket statuses, assignments, and AI task events are excluded because they do not establish what the external support team did.

Enable Agent response audit to check contradictions, unnecessary repeated requests, and material spelling or grammar errors, including errors in support templates. When a support reply has a clear personal signature, the audit extracts the name and attributes that reply's findings to the signing agent. The Agents view shows each name's finding counts, severity and issue-type distribution, and findings per 100 audited conversations. Replies without a clear signature appear as External support — agent unknown. Names come from signatures, so people using identical signing names are grouped together; initials and full names are not automatically combined. Quoted sender identities and dates are unverified; findings should be reviewed against the original email.

The audit can only assess messages received by the platform, directly or in quoted history. It cannot establish that an external reply or action never happened just because it is absent. Within the scan window and run limits, previously processed or skipped email conversations become eligible again when a new email arrives or reconstruction changes.