WFM guideData

Wrap code design in contact centres

Q: How many wrap codes should a contact centre have?

The optimal number of wrap codes in a contact centre depends on the breadth of contact types handled, but the practical guidance is: 10–25 contact reason codes for most single-sector operations (e.g. a utility contact centre might have billing query, billing dispute, payment, technical fault, new connection, move home, account closure, complaint — and 2–3 sub-codes per category). Beyond 40–50 codes, consistency of use drops significantly: agents default to the nearest code rather than the accurate one, and the data becomes too noisy to use for forecasting. Separate from reason codes, you need 5–10 outcome codes (resolved, escalated to TL, callback required, complaint logged, referral to specialist, etc.). The acid test: if you ask 10 agents to code the same call description, do 8+ of them select the same code? If not, the code is ambiguous or the scheme is too granular.

Q: How do wrap codes affect WFM forecasting accuracy?

Wrap codes are the primary data source for contact type forecasting and AHT analysis by contact type. If wrap codes are inaccurate or inconsistently applied, several WFM forecasting problems emerge: contact mix assumptions become wrong (if agents misclassify 20% of billing calls as account calls, the billing AHT calculation is deflated and the account AHT inflated — both are wrong); blended AHT calculations hide mix drift (an increase in technically complex contacts is invisible if all are coded as 'general enquiry'); and contact type volume trends cannot be identified, so the operations team cannot distinguish between a real increase in complaint volumes and a reporting artefact. WFM accuracy is bounded by wrap code accuracy. A well-designed wrap code scheme with consistent application is as important to forecast accuracy as having the right forecasting algorithm.

Wrap codes are the foundation of contact type data. Everything downstream depends on them: contact mix forecasting, AHT by contact type, trend identification, failure demand analysis. In most operations, the wrap code scheme was designed once in 2011 and has had codes added to it every quarter since. The result is 200 codes, 25% inconsistency, and forecasting data that nobody trusts.

Contact reason codes vs. outcome codes

Contact reason code

Definition: WHY the customer contacted: what they wanted to discuss or resolve. This is the primary classification and should be selected based on what the customer initiated the contact about, not what happened during the call.

Examples:

• Billing query — unexpected charge
• Technical fault — broadband not working
• Account change — address update
• Payment — set up direct debit
• Complaint — service failure
• New order — product enquiry

Important: Reason should be coded to the primary reason for contact even if the call scope expanded. A customer who calls about a billing query and then mentions a technical issue should be coded to billing query — the primary reason.

Outcome code

Definition: WHAT HAPPENED at the end of the contact: how it was resolved or what action resulted. This is a separate field and should be coded independently of the reason.

Examples:

• Resolved — full resolution in this contact
• Escalated to TL
• Callback required (agent)
• Callback arranged (customer request)
• Complaint logged
• Referral to specialist team

Important: Outcome code feeds FCR calculation — only contacts coded 'Resolved' with no subsequent matching contact in the FCR window count as first-contact resolved. Outcome code must be separated from reason code or FCR data becomes impossible to calculate.

Two-field requirement: Contact reason and outcome must be separate fields in the CRM or ACD. Operations that combine them into a single code ('Billing query — resolved' vs. 'Billing query — escalated') cannot separately analyse contact mix by reason OR FCR by outcome without disaggregating the combined code — which is rarely done in practice. Redesign to two fields before adding new codes.

Granularity: how many codes is the right number?

Code count	Signal quality	Consistency risk	Forecasting suitability
1–5 codes (too few)	No useful segmentation — all contacts lumped into 3-5 buckets. AHT is meaningless blended average. No trend analysis by contact type.	High consistency (no choice) but the data is not useful.	Cannot forecast by contact type. Volume trend is the only usable output. WFM forecasting is blind to mix changes.
10–25 codes (optimal)	Sufficient segmentation to identify trending contact types, AHT variation, seasonal patterns. Forecasting can be done at code level.	High if codes are clearly labelled and mutually exclusive. Calibration sessions identify coding drift early.	Forecasting at code level is feasible and informative. Mix drift is visible.
26–50 codes (marginal)	Some useful segmentation but data quality begins to decline. Rare codes have too few observations for reliable trending.	Medium — agents begin selecting 'nearest available' for ambiguous contacts. 5–10% miscoding expected.	Forecasting possible at aggregate category level but less reliable at individual code level.
51–100 codes (too many)	Rare codes produce noisy data. Category-level analysis requires collapsing codes anyway. Net signal gain vs. 25 codes is minimal.	Low — agents choose familiar codes for convenience. Inconsistency makes individual code trends unreliable.	Code-level forecasting is unreliable. Must collapse to 15–25 effective categories. The overhead has produced no net benefit over starting with 25 codes.
100+ codes (broken)	Minimal — only aggregates are usable. Individual code data is noise. Operations do not trust the data.	Very low — miscoding is the majority pattern, not the exception.	WFM forecasting must use contact handle time and total volume only. The code scheme is operationally redundant.

Five wrap code scheme failure modes

Code proliferation without review

Symptom: New codes are added whenever a new contact type is identified, but old codes are never removed. The scheme grows to 100+ codes over 5 years. Nobody reviews the full list — agents use the first 20 codes they learned.

Fix: Annual code review. Remove codes with <0.5% usage over 12 months. Archive rather than delete — data history is preserved, the code is just not offered to agents going forward.

Ambiguous code labels

Symptom: Multiple codes describe overlapping situations: 'account query', 'account change', 'account management' are all valid for the same contact. Agents pick randomly. Inter-rater reliability on coding tests is <60%.

Fix: Code labels must be specific and mutually exclusive. Rewrite labels with decision rules: 'account change — address/phone/name update (not payment details)'. Run a coding consistency test before deployment: 10 agents, 10 contact descriptions, target 80%+ agreement.

Reason and outcome combined in one code

Symptom: The scheme requires agents to select 'Billing — resolved', 'Billing — escalated', 'Technical — resolved', 'Technical — callback', etc. The proliferation of code combinations is unmanageable. FCR analysis requires code disaggregation.

Fix: Separate into two fields: contact reason (why did they call) and outcome (what happened). This reduces the number of codes required and enables independent analysis.

'Other' as the largest code

Symptom: 'General enquiry' or 'Other' represents 20%+ of contacts. This means the coding scheme does not capture the actual contact mix — a significant portion of demand is invisible to forecasting.

Fix: Analyse the 'Other' bucket using speech analytics or manual call review. Identify the top 3–5 contact types currently absorbed by 'Other' and create specific codes for them.

No agent training on code application

Symptom: Codes were configured by the WFM or IT team without agent input. Agents learned on the job which code to use based on what colleagues do. Consistency is anecdotal, not calibrated.

Fix: Coding training as part of onboarding. Wrap code calibration exercise quarterly (same call, 10 agents, review consistency). Include wrap code accuracy in QA framework.

Wrap code questions

How many wrap codes should a contact centre have?

10–25 contact reason codes is optimal for most single-sector operations. Beyond 40–50, consistency drops significantly — agents default to the nearest code, and data becomes too noisy for forecasting. The acid test: if you ask 10 agents to code the same call, do 8+ select the same code? If not, the scheme is ambiguous or over-granular. Separate reason codes (why they called) from outcome codes (what happened) — these should be two separate fields, not combined.

How do wrap codes affect WFM forecasting accuracy?

Wrap codes are the primary source for contact type forecasting and AHT analysis by contact type. If codes are inaccurate, contact mix assumptions become wrong, blended AHT calculations hide mix drift, and trend identification is impossible. WFM accuracy is bounded by wrap code accuracy. A well-designed scheme with consistent application is as important to forecast accuracy as having the right forecasting algorithm.