Agent State Taxonomy and Activity Codes
Agent State Taxonomy and Activity Codes is the classification of the states a service agent can be in, as three separate systems record them: the telephony platform's real-time states, the workforce-management system's scheduled activities, and the work-item states of a case, email or ticketing tool. The page sets out what each system can and cannot see, the mapping table that joins the three to the buckets of the Agent Time Accounting Model, and the rule of one code, one meaning. It is part of the Workforce Data Definitions Framework. The method for keeping codes identical in attributes across nodes and platform instances, the dictionary, the mapping of inherited codes with an expiry, and the check before any cross-node report, is on Activity-Code Consistency and is not restated here; this page supplies the taxonomy that the dictionary classes.
The distinction between a real-time state and a scheduled activity is as old as schedule adherence, which compares the two,[1] and the operations literature on call centers describes the agent's cycle through available, busy and after-call-work states as the basis of every utilization and staffing calculation.[2] The third system is newer: asynchronous work has a state model held by the tool that holds the item, not the agent, and a function that leaves it out of the taxonomy records that work as something else.
Three state systems
Each system answers a different question, so each records a different thing about the same minute.
| System | Exists to | Typical states | Who changes the state | What it cannot see |
|---|---|---|---|---|
| Telephony real-time states | route contacts to agents who can take them | logged out · available (ready) · on contact (talk, hold, conference) · after-contact work · auxiliary, with reason codes (break, training, meeting, coaching, system, other) · outbound | the platform for contact states; the agent for auxiliary and ready; the system by timer for after-contact work | work done on another platform; what an agent in available is actually doing; anything an agent with no queue assignment does |
| Scheduled activities | plan and adhere: say what each agent should be doing in each interval | shift · open or queue time · break · lunch · training · coaching · meeting · one-to-one · off-queue work · time off · absence | the scheduler before the day; the real-time analyst intraday by exception | what actually happened; it is a plan until an adherence feed compares it to a state |
| Work-item states | track a unit of asynchronous work to closure | new or unassigned · assigned · open (in progress) · pending (waiting on customer, third party or system) · resolved · closed · reopened | the agent on open, pending and resolved; the system on arrival, assignment, auto-close and reopen | how long the agent was actually working the item while it was open; which agent's minutes the item consumed when it changed hands |
A telephony state is a statement about an agent; a work-item state is a statement about an item. Neither alone says that this agent spent these minutes on this item, the tier-6 fact the capacity model needs for asynchronous channels. Workload Model for Asynchronous Channels carries the item lifecycle; Email Handle Time Measurement carries the instruments that produce the per-item minutes.
The mapping table
The mapping table joins the three systems to the ledger buckets. Each row answers: given this combination of states, which bucket does the minute land in, and which system's record is primary when they disagree.
| Ledger bucket | Telephony state | Scheduled activity | Work-item state (for that agent) | Primary system |
|---|---|---|---|---|
| In-work, voice | on contact or after-contact work | open or queue time | any | telephony |
| In-work, chat | in session (focus time per Chat Concurrency and Handle Time) | open or queue time | any | chat platform's session log |
| In-work, asynchronous | a dedicated work state, or available where no work state exists | off-queue work, or open time at a blended seat | open, with a running touch timer | work-item tool |
| Available-idle | available | open or queue time | none open, or open with no touch running | telephony; corrected by the work-item tool |
| Planned shrinkage, by class | auxiliary with the matching reason | break, lunch, training, coaching, meeting, one-to-one | any | scheduled activity for the class; telephony for the minutes |
| Unplanned shrinkage, by class | auxiliary with a system, outage or unscheduled reason | open or queue time | any | telephony |
| Scheduled-not-logged (absence, no-show, late start, early finish) | logged out | any working activity | any | workforce system against the session log; the absence feed for the reason |
| Off-schedule paid | logged out | time off, paid absence, no shift | any | payroll against the schedule |
| Residual | a state not in the dictionary; or logged with no state | any | any | none; published |
Scheduled-not-logged is a bucket of its own, as on Agent Time Accounting Model: a no-show lands there and nowhere else, and the bucket is reported as a class of unplanned shrinkage, never added to the auxiliary classes a second time.
The primary system column is the precedence rule the ledger applies when two systems claim one minute. Telephony is primary for voice in-work because it stamps the contact; the work-item tool is primary for asynchronous in-work because it stamps the item; the scheduled activity is primary for the shrinkage class because the class is a planning attribute, while the minutes come from the state log. A row with no primary system is a residual by construction. The precedence rule is written once, in this table, and cited by every reconciliation on Reconciliation Tests for Time Accounting; a report that resolves a double count differently from the table has created a private definition.
One code, one meaning
A code enters the dictionary when it maps to exactly one ledger bucket. Three corollaries follow.
A code that could mean two things is a defect, not a convention. An available state in which agents also answer email means two buckets, available-idle and in-work asynchronous, and the share of each is unknown; the fix is a dedicated work state or a work-item timer, never a planning factor that splits the state by assumption. Production Accounting for Blended Agents carries the detection tests and the separation methods.
A catch-all code is a residual with a name. Auxiliary reasons such as other, project or admin are, in practice, buckets whose class nobody set; the dictionary either classes them or retires them, and until it does their minutes are reported in the residual line, not in shrinkage.
A code's meaning is its attributes, not its label. Two instances can both carry a code labelled training that differ in whether it is paid, whether it counts as available and which register entry it rolls up to; Activity-Code Consistency fixes the seven attributes a code must carry and the check that catches a difference. In data-management terms the dictionary is a conformed dimension, defined once and shared identically so that facts computed against it are comparable,[3] and the metadata-registry standard supplies the rule for the definition itself: one concept, one identifier, one definition, independent of the system that stores it.[4]
How codes land in ledger buckets
The path from a raw state record to a ledger bucket has four steps, and each is a place a function can lose minutes.
- Read. Each system's log is extracted at native resolution: state-change events, interval activities, timestamped status changes. Aggregating before mapping loses the overlap the next step needs.
- Translate. Each code is looked up in the dictionary, or in the mapping table of inherited codes with its treatment and expiry. A code found in neither is residual.
- Resolve. Where more than one system claims a minute, the primary system in the mapping table wins and the secondary claim is logged as a double-count event, which the cross-system test on Reconciliation Tests for Time Accounting counts.
- Post. The minute is written to one bucket with the dictionary version, the mapping-table version and the primary system recorded, so that a Data Lineage Card for Planning Models can cite them.
Step 3 is the one most estates skip. Each system's report is internally consistent and sums its own minutes; the ledger is the only place the three are forced to agree on the same minute, which is why the Source of Truth Register points at it for every time-based metric.
Real-time state against scheduled activity
Adherence is the comparison of the first system to the second, minute by minute, and is defined on Adherence and Conformance. The taxonomy's contribution is that adherence is computable only for codes whose scheduled or state attribute reads both: a scheduled activity with no corresponding real-time state (an off-queue block at a seat whose platform has no off-queue state) is exempt from adherence by construction and is reported as such, not as out of adherence. The same gap is why asynchronous work at a blended seat is invisible: the schedule says open time, the telephony state says available, and adherence reports a perfectly adherent agent who appears idle.
Maturity Model Position
Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a Level 2 function has the first two systems and an adherence feed between them. Level 3 adds the third system to the taxonomy, with a mapping table, a precedence rule and a residual line, and it is through that dictionary that the automation layer reads real-time states. At Level 4 the mapping runs on every extract, and intraday rules and the capacity model read one dictionary, so that an intraday rule and a monthly plan cannot disagree about what a state means.
See Also
- Workforce Data Definitions Framework — the hub this taxonomy belongs to
- Agent Time Accounting Model — the buckets the codes land in
- Activity-Code Consistency — the dictionary, the inherited-code mapping with expiry, and the check
- Adherence and Conformance — the comparison of real-time state to scheduled activity
- Production Accounting for Blended Agents — work done inside an available state
- WFM Data Models and Schemas — the activity dimension and the adherence event as data objects
- The Definitions Register — the entries each code rolls up to
References
- ↑ Cleveland, B. (2012). Call Center Management on Fast Forward: Succeeding in the New Era of Customer Relationships, 3rd ed. ICMI Press, chapter on real-time management and adherence to schedule.
- ↑ Gans, N., Koole, G., & Mandelbaum, A. (2003). "Telephone Call Centers: Tutorial, Review, and Research Prospects". Manufacturing & Service Operations Management 5(2), 79–141.
- ↑ Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd ed. Wiley, chapter 4 (conformed dimensions and the bus architecture).
- ↑ International Organization for Standardization / International Electrotechnical Commission. ISO/IEC 11179-4: Information technology — Metadata registries (MDR) — Part 4: Formulation of data definitions.
