signals-scout-conversations

Query the $conversation_message_sent event daily, dividing countIf(sla_breached) by countIf(sla_active) over a 21-day window. Compare recent days against the trailing baseline and skip days with fewer than roughly 15 active-SLA replies to avoid noise.

Join the first $conversation_message_received per ticket with the first $conversation_message_sent, then compute p50 and p90 minute differences grouped by day. Also compute the never-answered share separately, since unanswered tickets never appear in the percentiles.

No. The emission pipeline files per-ticket product-feedback signals from message content, while this scout watches aggregate operational metrics like SLA rates and backlog. It explicitly defers all per-ticket content findings to the emission pipeline.

The plural $conversations_* events are UI and widget telemetry, not ticket-lifecycle data. Mixing them into operational metrics would corrupt breach, latency, and backlog calculations, so only singular $conversation_ticket_* and $conversation_message_* events are used.

The scout runs a 30-day execute-sql probe for any $conversation_ticket or $conversation_message events. If none exist, it writes a not-in-use scratchpad key and closes out empty rather than filing a report.

When a live inbox report already tracks the same dimension, such as an ongoing SLA breach, the scout appends fresh daily rate-versus-baseline evidence to it. A persistent regression stays one report across runs instead of a new report per tick.