Design KPI scorecards that reflect your support team’s responsibilities

A useful KPI scorecard expresses what good support means for a particular team. Supportbench lets you select supported measures, define thresholds and weights, and refine organization defaults for Divisions and teams. This matters in B2B operations because a frontline response team and a specialist handling long engineering dependencies may need different performance expectations. Design the scorecard around the team’s responsibilities, then use the result to investigate and improve work.

Define the decisions before choosing metrics  ·  Agree scope, access and a baseline  ·  Understand scope and inheritance  ·  Create or revise a scorecard  ·  Choose among the supported metric groups  ·  Choose thresholds in the correct direction  ·  Balance weights and understand the overall score  ·  Verify the processed report and history  ·  Worked example: frontline and specialist support  ·  Troubleshoot scorecard configuration and interpretation

Define the decisions before choosing metrics

Custom scorecards select and configure the supported metric catalog. This is not a free-form formula editor where every imagined measure or arbitrary field can become a KPI. Use a suitable data view or report for questions the scorecard catalog does not answer.

Agree scope, access and a baseline

1. Confirm you have permission to edit KPI scorecards and access to the corresponding settings section. Viewing reports and editing the scorecard definition are different capabilities.
2. Identify the organization, Division or team whose responsibilities the definition should describe. Review existing configurations before adding another.
3. Choose a representative baseline period and inspect the underlying data. Include normal workload, meaningful samples and known exceptions.
4. Agree which measures the team can reasonably influence and which depend heavily on customers, vendors or other departments.
5. Write down the purpose of each proposed target and the action a warning should prompt. A threshold with no response plan adds noise.
6. Decide who owns future configuration changes and how reviewers will know when definitions change.

Understand scope and inheritance

The configuration follows organization defaults, with more specific Division and team overrides. A team without its own custom configuration can use the applicable Division definition, and agent reporting uses the applicable primary-team context. The current editor creates Division and Team overrides; it does not offer an Agent scope. Check the effective configuration before comparing people or teams.

A new custom card starts with Division scope and Active scorecard enabled. Review both deliberately before saving. Do not assume a new form is an inactive sandbox. If you need to prepare a definition without activating it, use the available inactive state and verify that choice before saving.

Create or revise a scorecard

1. Open Settings → Organization → KPI scorecards. Inspect the existing definitions.
2. Choose New Scorecard, or select the intended existing card. Confirm whether you are editing the organization default or a custom override.
3. In Settings, enter a descriptive Name. Choose the available Scope and the corresponding Division or Team.
4. Review Active scorecard. Decide whether this definition is ready to participate in report processing.
5. Open KPI Metrics. Use Search KPI metrics to locate a supported measure or browse its group.
6. For each intended measure, turn on Use and set its Weight, Fail, Warning and Success values as applicable. Read its description and unit.
7. For time metrics, use the days/hours/minutes helper when helpful, then verify the resulting minutes. Do not enter hours into a field that expects minutes.
8. Review enabled metrics, threshold direction and total weighting as a set. Remove measures that do not support the agreed review.
9. Save using the settings toolbar and read the outcome. Reopen the definition to confirm the persisted scope, active state and metric values.
10. After the relevant report processing, verify the result in Reporting using the procedure below.

Example values displayed as placeholders in empty metric inputs are not saved defaults or recommended targets. Enter and verify your intended values. A visible example such as a weight of 20 does not prove that the definition has that weight.

Choose among the supported metric groups

The configuration reference provides the full field and metric list. The operational interpretation guide explains date bases and calculations, such as the difference between surveys sent in a period and responses received in it. Keep those definitions with the report when presenting results.

Choose thresholds in the correct direction

Some metrics improve as the number increases; others improve as it decreases. Time, reopen, escalation, de-escalation and effort measures have lower-is-better definitions in the applicable catalog entries. Do not apply one direction to every metric merely because the inputs share the same layout.

The scoring logic generally requires a target and failure boundary to make a comparison, with metric-specific exceptions. Intermediate or incomplete results can be indeterminate. A Warning input should not be interpreted as a promise that every metric uses an identical three-band formula. Review the resulting score behavior using the metric definition and actual report.

Balance weights and understand the overall score

Weights express the relative contribution of included measures. They do not change the raw response time, survey answer or Case history. A metric meeting its target earns its full weight, a true failure earns zero, and an included indeterminate result earns half its weight. The overall result is the rounded percentage of earned weight out of the included total.

For example, with included weights of 50, 30 and 20, a success, failure and indeterminate result respectively earn 50 + 0 + 10. The overall score is 60%. This illustrates the calculation; it is not a suggested scorecard design.

1. Avoid giving nearly all weight to speed if the team must also deliver technically correct, complete answers.
2. Check whether closely related measures unintentionally count the same behavior several times.
3. Review the sample size and actual scoring behavior. Current Core scoring treats a numeric zero as success before normal threshold comparison for every calculated metric. An indeterminate Chat CSAT result is excluded from the overall denominator; other included indeterminate results receive half weight. These rules are not a user-selectable empty-value policy in this editor. A favorable score therefore needs its underlying observations checked.
4. Record target and weight changes with the effective review period. A revised overall score is not directly comparable without that context.
5. Explain the configuration to the people using the scorecard so they understand the intended operational decisions.

Verify the processed report and history

1. Reopen the saved configuration and confirm the exact active scope, enabled measures, thresholds and weights.
2. Allow the normal report process to calculate the applicable results. Active configuration is used by the nightly KPI reporting process; saving a card is not a live recomputation of every displayed report.
3. Open Reporting → KPI Scorecards and choose the appropriate agent, team, Division or organization report.
4. Select the intended period and confirm the scope. Check the effective inherited or overridden definition.
5. Inspect the enabled metric rows and available targets. Compare representative values with the relevant underlying reports or Case evidence using the same calculation basis.
6. Check how success, failure, indeterminate and missing values affect the result. Do not treat an empty measure as evidence of good performance.
7. Open supported trends when historical data is available. A missing history snapshot is different from a current value of zero.
8. Record the verified definition and period with any shared export or review notes.

Scorecard history is calculated and stored by report processing. Opening the report or its trend retrieves the available results; it does not mean every Case has just been recalculated under the current form values. Investigate processing and history separately when a saved configuration does not yet appear in the expected report.

Worked example: frontline and specialist support

A frontline team primarily owns initial triage and timely customer responses. A specialist team handles complex integration failures with engineering dependencies. The operations owner keeps shared definitions where they remain useful, then evaluates a scoped override for the specialist team instead of copying the same close-time target without context.

1. Review representative Cases from each team and confirm what each team controls.
2. Choose a balanced set of supported response, resolution and quality/feedback measures.
3. Set documented targets and weights from the agreed service model and baseline.
4. Verify the effective inheritance and processed report for both teams.
5. Use the scorecard to identify a review question, then inspect the actual work before deciding on a change.
6. Revisit the design when responsibilities or service commitments change.

A useful review might reveal that the specialist team’s customer updates need improvement even though the engineering resolution time is largely outside its control. That leads to a concrete communication action rather than an unexplained ranking.

Troubleshoot scorecard configuration and interpretation

Continue learning

• Reference every KPI scorecard setting and metric
• Interpret scorecard results and weighted scoring
• Review KPI trends and history
• Choose the right report for your operational question
• Review stored AI Insights for an individual Case