Intercom adds custom metrics that calculate across a workspace's full history

Intercom makes local reporting definitions reusable

Intercom's September 23 changelog says teams can now build Custom Metrics in Reports when the built-in metric set does not express a number they need. The release describes two construction paths: apply team-defined filters to a built-in metric, or divide one metric by another while using different filters on each side. Intercom gives examples such as an email-only closure rate and a reopen rate for a specific tag.

Intercom says a custom metric is calculated when a chart loads, so a metric created now can be applied across the workspace's available historical data. Once created, it appears in the metric picker for every chart in the workspace. The release establishes the product capability; it does not establish that a particular metric definition is correct for another team's SLA, performance model or customer-operations policy.

Sources: Intercom changelog, September 23, 2026

A custom ratio needs a metric contract

The operational risk sits in definitions that look familiar but use different populations. A metric called closure rate could count conversations closed during the selected period over conversations created in that period, eligible conversations in a queue, or another denominator entirely. Add channel, team, tag, bot, language or customer-tier filters and two charts can carry the same label while answering different questions.

Before a custom metric becomes part of a weekly operating review, record its business question, numerator, denominator, filters, exclusions, time basis and owner. Give the definition an effective date. If the team later changes a filter or denominator, preserve that change as a new definition version rather than editing the old meaning invisibly. The chart value is the output; the definition is the operating control.

Full-history calculation creates a policy-time distinction

Intercom's full-history behavior is useful for retrospective analysis because a newly created metric can evaluate older conversation data. RevOps should still distinguish event time from policy time. A custom metric calculated over January conversations in September did not necessarily govern the team's January decisions. Historical calculation and historical operating practice are different claims.

For metrics used in performance reviews, incentives, staffing or executive reporting, keep both the definition-created date and the date the organization formally adopted the metric. When comparing periods that cross a definition change, either recalculate all periods under one explicitly chosen definition or show the change boundary. Avoid presenting one continuous trend line if its business meaning changed halfway through.

Validate a small population before trusting the chart

Build a validation set from conversations whose expected inclusion is easy to inspect. Include an email conversation that should count, a different channel that should not, a conversation with the target tag, one without it, a reopened conversation, a bot-handled case if bots are relevant and an item that crosses the selected date boundary. Calculate the numerator and denominator independently for that small set before relying on full-history output.

Record the custom metric name or identifier alongside the validation evidence, checked-at time and owner. Re-run the sample after material changes to filters, tags, queue structure or automation that can alter conversation classification. The goal is not to manually audit every chart load; it is to retain one reproducible reference set that catches a definition drifting away from the operating question.

Keep reporting definitions separate from action authority

A custom metric can be a useful trigger for investigation without automatically authorizing a customer-facing action. A rising reopen rate can justify reviewing a queue, workflow or knowledge gap, but it does not identify the cause by itself. An email-only closure rate can inform staffing without proving individual performance. Derived metrics compress many records into a signal, so the path back to the underlying evidence should remain available.

If a workflow later uses a custom metric to trigger routing, staffing alerts or management escalation, define the threshold, evaluation window, minimum population and fallback when the metric is unavailable. Treat the threshold as separate policy that can change without redefining the metric itself. This keeps the reporting layer explainable even when operations automate decisions around it.

What DailyRevOps would verify before rollout

Create one custom metric that answers a current operating question rather than duplicating a built-in chart. Write its definition before building it, then compare the resulting value with a hand-checked sample. Add it to one existing review surface and record who owns definition changes. Avoid building a library of near-duplicate ratios until the team knows which definitions actually support a recurring decision.

After one operating cycle, inspect disagreements rather than only the metric level. When an operator says a conversation should have counted differently, determine whether the source record, tag, filter, time basis or business definition is wrong. That turns the new flexibility into an auditable reporting layer instead of another set of numbers whose meaning lives only in the person who built the chart.