Skip to content
  • There are no suggestions because the search field is empty.

Channel Benchmark Data Mapping Discrepancies in HappySignals

Channel benchmark differences in HappySignals occur because the platform uses a standardized set of channel categories designed for benchmarkable, like‑for‑like comparison. This article explains why some ServiceNow channels may not appear on the Benchmark page and how channel data is handled for benchmarking purposes.

Overview

Customers sometimes notice discrepancies between channel benchmark values and the actual channel distribution shown in HappySignals. A typical symptom is that channel percentages do not add up to 100%, or that only part of the data is included in the benchmark comparison.
This article explains:
  • Why do these discrepancies occur
  • How HappySignals channel benchmarking works
  • What needs to be done in ServiceNow integrations to fix the issue
  • The recommended and alternative implementation options

How Channel Data Is Collected

In a Ticket‑Based HappySignals application, channel information is usually mapped from ServiceNow using Data Properties.
Most commonly:
  • The Channel field in HappySignals is mapped via dot‑walking to the ServiceNow contact_type field
  • The returned value is exactly what exists on the incident or request record
HappySignals does not automatically normalize or transform these values at this stage. Whatever value exists in contact_type it is passed through as‑is.
 

How Channel Benchmarking Works in HappySignals

Only a limited set of channel values is officially benchmarked in HappySignals:
  • Portal
  • Phone
  • Email
  • Chat
  • Walk In
  • Virtual Agent

Note on Virtual Agent
Virtual Agent is supported as a channel value and can be collected in the data mapping. However, it is not currently shown as a visible option on the Benchmark page, as an official benchmark for Virtual Agent has not yet been generated. It was added to the guidance to allow customers to start collecting the data ahead of future benchmark availability.

These values are used to ensure "apples to apples" comparisons across customers.

Any channel value outside this list:
  • Is excluded from the official benchmark calculation
  • Still appears in reporting and experience views
  • Causes channel distributions not to add up to 100%
This behavior is expected and intentional. Even in the benchmark report, channels may not sum to 100% because some channels are not fully comparable to the standardized benchmark categories.
 

Typical Root Cause of Discrepancies

Discrepancies occur when ServiceNow returns channel values that do not match the official benchmark values, for example:
  • Instant Message
  • IM
  • Teams
  • Mobile
  • Walkup Interface
  • Tech Café
Because these values are not benchmarked:
  • Only tickets with benchmark‑compatible channel values are included
  • The benchmark percentage appears lower than the actual channel usage

Screenshot 2026-03-02 at 11.32.19

Example outcome:
  • Benchmark channels cover only 70–80% of tickets
  • Remaining tickets belong to non‑standard channel values


Recommended Solution: Normalize Channels in the Integration

The recommended approach is to standardize channel values at the integration script level, without changing ServiceNow data.
 

How It Works

  1. Keep the existing dot‑walk mapping from contact_type
  2. Extend channel mapping logic in HappyCustomConfig
  3. Convert non‑standard values into benchmark‑compatible values

Example Logic

if (contact_type == 'Mobile') {
contact_type = 'Phone';
}
This ensures that every returned channel value maps to one of the official benchmark categories.
 

Preserving Original Channel Values (Recommended)

If the original ServiceNow channel values are still needed for reporting or analysis, they should be preserved separately while sending a standardized value for benchmarking.

This is done by:

  • Storing the original ServiceNow contact_type value in a separate field (for example conf.org_channel)
  • Sending a benchmark‑compatible value in conf.contact_type

Example implementation

var raw = this.__getFieldValue(obj, 'contact_type');

conf.org_channel = raw;          // original ServiceNow value

conf.contact_type = raw;         // default: same value

if (raw == 'Mobile') {

  conf.contact_type = 'Phone';   // standardized benchmark value

}

Result

  • conf.org_channel contains the original ServiceNow channel value (full data fidelity)
  • conf.contact_type contains a standardized, benchmark‑compatible channel value
  • Only the standardized value is used for channel benchmarking

This approach ensures accurate and comparable benchmark results while preserving the original channel information for reporting and analysis.

 

Alternative Option: Modify ServiceNow Channel Values (Not Recommended)

Another option is to change ServiceNow so that contact_type only contains benchmark values.
 

Risks

  • May impact:
    • Existing reports
    • Flows and automations
    • Integrations
    • Operational processes
  • Requires stronger governance and approvals

Guiding Principle

It is safer to adapt the HappySignals integration to the existing ServiceNow hierarchy than to modify ServiceNow to fit HappySignals requirements.


Summary

Why discrepancies happen
  • HappySignals receives raw contact_type values from ServiceNow
  • Only a fixed set of channel values is benchmarked
What fixes the issue
  • Standardizing channel values at the integration script level
  • Mapping non‑standard values to benchmark categories
Best practice
  • Normalize channels in HappyCustomConfig
  • Preserve original values in a separate field if needed
This approach ensures accurate channel benchmarks while keeping ServiceNow processes unchanged.