Chat Concurrency and Handle Time

Chat Concurrency and Handle Time is the measurement model for a channel in which one agent serves several customer sessions at the same time, so that the time a session lasts and the time an agent spends on it are different quantities. It matters because every synchronous staffing calculation assumes one agent and one contact: handle time is agent time, offered load is arrivals multiplied by handle time, and occupancy is handle time over productive time. Under concurrency each identity breaks unless the function states which clock it is reading, and a chat plan built on session time where agent time was needed asks for more agents than it needs, while one built on a concurrency target where measured concurrency was needed asks for fewer. The page is part of the Workforce Data Definitions Framework. Average Handle Time and Occupancy keep their definitions on their own pages, and the first already distinguishes contact handle time from agent handle time; Multi-Channel and Blended Operations carries the operating choices around the concurrency rule.

The peer-reviewed treatment of chat is more developed than that of email. Chat agents serving several customers are modelled as processor-sharing servers with a concurrency limit, with fluid approximations used for staffing and control; staffing with impatient customers has been solved asymptotically by linear programmes for routing and staffing; and the choice of how many sessions an agent should hold, with abandonment during service, has been analysed with conditions under which a least-busy or most-busy assignment rule is optimal. Those results are established. The shortcut by which a planner converts them into an Erlang-style load, described below, is the practitioner model, not yet validated in the literature.

Two clocks per session

Quantity	Whose clock	Definition	Instrument	Where it lands
Session elapsed time	the customer's	assignment to an agent until the session ends, by resolution, abandonment or time-out	the platform's session log, start and end stamps; measured [M]	the in-service delay the Service Level goal is read against; never the ledger
Agent focus time	the agent's	the minutes of the agent's attention attributed to the session, reading, composing and sending, under a published attribution rule	derived from message-level stamps in the session log; measured [M] under the rule, estimated [E] otherwise	the in-work tier of the Agent Time Accounting Model; the numerator of occupancy

The sum of elapsed time over an agent's sessions in an hour can exceed sixty minutes, because sessions overlap. The sum of focus time cannot, because focus is a partition of the agent's clock. That asymmetry is the whole of the measurement problem: elapsed time is a property of the session, focus time is a property of the agent, and only the second is a unit of agent capacity. The difference between them is time the customer spent typing or reading and time the agent spent on other sessions, and the two are not separable from the elapsed stamp alone.

Effective handle time

The effective handle time of a session, for staffing, is the agent time it consumed: focus time s_f. Where focus time is not measured, a planner estimates it as elapsed time divided by realised concurrency, s_elapsed ÷ k, and this yields agent in-session time per session, an upper bound on focus time, and is consistent only when k is computed on the same basis as the elapsed time; the estimate is inferred from the processor-sharing model and has no peer-reviewed validation as a general rule. Offered load in agent-Erlangs is then arrivals multiplied by focus time, and the Erlang formulas, or Erlang-A where abandonment matters, are applied to that load and validated by simulation (Simulation Methods in Workforce Management). The AHT page's contact AHT and agent AHT are exactly the two clocks, and AHT-01, the register's handle-time row for session channels, names which one it holds for chat.

Capacity under concurrency

Two quantities are both called capacity and are kept apart:

realised throughput = productive minutes × realised concurrency ÷ elapsed minutes per session

capacity ceiling = productive minutes ÷ focus minutes per session

The first is what the agent did serve in the interval: sessions per productive hour at the concurrency and pace actually observed. The second is what the agent could serve if every productive minute were focus time, a ceiling at 100 percent focus. They differ even when every input is measured consistently, because productive minutes contain idle time and in-session minutes contain customer-side time in which the agent attends to nothing; the worked example below gives 8.0 against 11. Staffing plans against the realised figure and reads the ceiling as headroom. Neither is capacity = concurrency limit × 60 ÷ elapsed time, which is the calculation a planner makes when the routing platform's maximum simultaneous sessions is taken as the agent's throughput. That fails because realised concurrency at ordinary load is below the limit, and because per-session pace falls as concurrency rises, so elapsed time and concurrency are not independent inputs; the dependence is what the processor-sharing model exists to represent. Field evidence from server logs, transcripts and surveys at a large service firm found that agent multitasking lengthened customers' in-service delays and lowered resolution rates, so a capacity computed at a high concurrency may be unreachable at the quality the function requires.

Occupancy under concurrency

On the ledger, in-work time for chat is the sum of focus time, so occupancy on the register's definition is Σ focus time ÷ productive time and cannot exceed one. A second ratio, Σ elapsed time ÷ productive time, is sometimes reported under the same name and can exceed one; the Occupancy page notes the artefact. That ratio is realised concurrency, not occupancy, and this page proposes, through Definitions and Source-of-Truth Change Control (generic process), that OCC-01's concurrency rule name focus time as the numerator, so that chat occupancy and voice occupancy are the same kind of number. A third ratio, Σ elapsed time ÷ (concurrency limit × productive time), is the utilisation of session slots; it is useful to the routing owner, labelled as slot utilisation, and kept out of the occupancy row.

Concurrency is a measured parameter, not a target

Realised concurrency in an interval is

k = Σ session elapsed minutes falling in the interval ÷ agent productive minutes in the interval

computed per agent and per interval from the session log, then averaged time-weighted; it is register entry CCY-01, sourced from ST-012, the platform session log. The concurrency limit is a routing setting the function chooses: the maximum simultaneous sessions the platform will assign. Realised concurrency is what the function measures, and staffing reads the measured figure, for five reasons.

1. Per-session speed falls as concurrency rises, so the gain from a higher limit is partly eaten by longer sessions; treating the limit as realised throughput counts the gain twice.
2. Customers abandon while waiting and during service, and abandonment during service reduces the benefit of holding more sessions; Erlang C sees neither.
3. Multitasking degrades resolution and satisfaction, so the limit that maximises throughput is not the one that meets the quality goal.
4. Service and patience distributions materially change routing, staffing and performance, so one mean concurrency across mixed session types misstates the load.
5. Realised concurrency varies by interval and by agent; one daily figure understates the peaks the interval model is sized for.

A target is a number the function wants; a parameter is a number the function has. Concurrency enters the capacity model as the second. Where a function changes the limit, realised concurrency, focus time and elapsed time are re-measured after the change, because all three move together; diffusion-based staffing for multitasking systems is one analytical treatment of that joint movement, and simulation is the fallback when concurrency interacts with routing or in-service abandonment.

Measurement from platform session logs

A chat platform's session log typically holds, per session, the queue entry, the assignment to an agent, each message with its author and time stamp, and the end with a reason. Four quantities are derived, and the derivation rules are published on the channel's definition card.

• Elapsed time = end − assignment. [M].
• Focus time under an attribution rule, for example: the span from a customer message to the agent's reply is attributed to that session when no other session's reply intervenes; where the agent replies in two sessions within one span, the span is split by the rule the card states. The rule is a choice, is stated, and is applied the same way every extract. [M] under the rule.
• Realised concurrency per interval as above; where the platform exposes a concurrent-session count per time stamp, that series is the direct instrument. [M].
• Abandonment before assignment and during service, from the end reason, kept separate because they enter the models differently. [M].

Where the platform holds only session start and end, focus time is estimated as elapsed ÷ k and graded [E] as an upper bound, and the shortcut's bias is reported rather than hidden.

Worked example

The numbers are synthetic and graded [E]; everything computed is [C] on [E] inputs. One hour, five chat agents, each with 55 productive minutes [E], 275 agent-minutes in all. Forty sessions are handled [E]; mean elapsed time is 12.0 minutes [E]; mean focus time under the attribution rule is 5.0 minutes [E]; agents are inside at least one session for 230 of the 275 minutes [E]; the routing platform's concurrency limit is three [E].

Σ elapsed = 480 session-minutes; Σ focus = 200 agent-minutes [C]. Realised concurrency on productive minutes is 480 ÷ 275 = 1.75 [C]; on in-session minutes it is 480 ÷ 230 = 2.09 [C]. Occupancy on the ledger is 200 ÷ 275 = 72.7 percent [C]; the elapsed-based ratio is 480 ÷ 275 = 175 percent [C], the artefact. Realised throughput is 55 × 1.75 ÷ 12.0 = 8.0 sessions per agent-hour [C], which is also 40 sessions ÷ 5 agents; the capacity ceiling is 55 ÷ 5.0 = 11 sessions per agent-hour [C], computed rather than measured, and reachable only at 100 percent focus. Offered load in agent-Erlangs is 40 × 5.0 ÷ 60 = 3.33 [C]; computed on elapsed time it would be 8.0 [C], and an Erlang calculation fed the second figure asks for roughly twice the agents [A].

Two checks follow. The shortcut elapsed ÷ k gives 12.0 ÷ 1.75 = 6.9 minutes on the productive basis, which is simply productive minutes per session (275 ÷ 40) and includes the 45 idle minutes, and 12.0 ÷ 2.09 = 5.75 minutes on the in-session basis, which is in-session minutes per session (230 ÷ 40) [C]. The shortcut therefore yields in-session agent time, an upper bound on focus time, against the 5.0 minutes measured; the measured figure is used. And had the concurrency limit of three been used as a target, capacity would read 3 × 60 ÷ 12.0 = 15 sessions per agent-hour [C], against a realised throughput of 8.0 and a ceiling of 11: planning on 15 understaffs by about 27 percent against the ceiling and by nearly half against what the agents delivered [C], before any quality effect is counted.

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 function at Level 2 holds elapsed time and session counts from the platform, states a concurrency it has measured rather than set, and grades its focus time [E] as elapsed ÷ k. Level 3 derives focus time from message stamps under a published attribution rule, computes realised concurrency per interval, and holds chat occupancy on the same numerator class as voice; that is the precondition for the automation layer to adjust the concurrency limit intraday on measured rather than nominal load. At Level 4 the channel is sized by simulation with abandonment during service and mixed session types, and the limit is a control the routing engine moves against a quality constraint.

See Also

• Workforce Data Definitions Framework — the hub this page belongs to
• Agent Time Accounting Model — the in-work tier focus time lands in
• Email Handle Time Measurement — the sister problem for asynchronous work
• Multichannel Capacity Model Assembly — where the chat requirement meets the others
• Reconciliation Tests for Time Accounting — test T-04, the cross-system double count across overlapping sessions
• Average Handle Time — contact AHT against agent AHT
• Occupancy — the definition and the over-100-percent artefact
• Multi-Channel and Blended Operations — the concurrency rule as an operating choice
• Erlang-A — the delay model with abandonment the effective load is fed to
• Simulation Methods in Workforce Management — the validation and the fallback