Wiki:Packs/Time and Production Accounting Audit

From WFM Labs
Pack
ID CP-WFM-024
Name Time and Production Accounting Audit
Domain WFM
Blocks 1 instruction + 5 reference
Version 1.0
Source Time and Production Accounting Audit (generic process) · Production Accounting for Blended Agents · Capacity Standards Workshop for Time Accounting · Service Level Mathematics for Voice, Chat and Email · Multichannel Capacity Model Assembly · Reconciliation Tests for Time Accounting · Agent Time Accounting Model

A deployable Claude project setup for running the time and production accounting audit (GP-605) on a workforce function, preparing the capacity standards workshop that turns its signed gap register into definitions, sources and a requirement model, and specifying the service-level model per channel from inputs the registers can source. The pack produces four files: the capture-point inventory per channel and system, the gap register in three classes with the blended-agent test results beside it, the workshop pack (agenda, participants by seat, inputs, the five decisions W-01 to W-05, the annex), and the model specification per channel with every input traced to its ledger row and source row. Copy Block 1 into a project's custom instructions; save Blocks 2–6 as Markdown files and upload them as project knowledge. See Wiki:Packs for how packs work.

When to use it

Use this pack when a function is adopting the Workforce Data Definitions Framework and needs its first full audit pass, when a trigger (a platform change, a channel launch, a cohort migration, a reconciliation test failing twice running) calls for a channel-scoped pass, or when a signed gap register exists and the workshop that consumes it needs preparing. It pairs with Wiki:Packs/Data Definitions and Source of Truth (CP-WFM-023), which drafts the definition card, source row, ledger placement and tests for any single number a user brings; this pack runs the audit and the workshop that produce those objects in bulk, and specifies the model each channel's requirement is computed on. It is not for adopting a definition or a source, which only the workshop and GP-606 do; for reconfiguring a platform; for the derivations of Erlang C, Erlang-A or the simulation methods, which their own pages carry; or for localizing GP-605 as a card into a function's standard, which Wiki:Packs/Cross-Cutting Governance Processes (CP-OPS-014) does.

How to deploy

  1. Create a project in Claude named for the work, not the method: "Time accounting audit for the function", not "Data audit".
  2. Paste Block 1 into the project's custom instructions.
  3. Save each remaining block as the filename in its heading and upload it as project knowledge.
  4. Start a conversation with the channels, the system classes, the blended cohorts and the sample period in scope, and the configuration export of the first platform instance; have the data and analytics lead present for the classification steps.

Block 1 — Project instructions

You are running the time and production accounting audit (GP-605) for the
user's workforce function, preparing the capacity standards workshop that
turns its gap register into signed definitions, source rows and a
requirement model per channel. The audit starts from what the capacity
model consumes and works back to the instruments, never the other way.

Routing:

| Task | File |
|---|---|
| Run or scope an audit pass; classify a gap; draft a remedy | `audit-protocol.md` |
| Build or fill the channel × system grid | `capture-point-inventory.md` |
| A multi-channel cohort: detection tests, separation methods, reporting both ways | `blended-agent-tests.md` |
| Sessions, seats, inputs, W-01 to W-05, what the room may not decide, the annex | `workshop-agenda.md` |
| Specify a channel's model; set a blended pool's reserve | `sl-math-reference.md` |

In this order:

1. Fix scope: channels, systems as classes, cohorts, sample period. Build
   the inventory from the user's configuration exports, one row per state,
   timer, counter or timestamp; never from memory.
2. Map each row to its ledger bucket and RG entry; grade it; test coverage
   per bucket per channel. Run T-01 to T-06 on the sample period, then the
   blended-agent tests on every multi-channel cohort.
3. Classify each gap (not collected · partially collected · collected but
   misallocated) with its evidence; trace it to the models that consume
   the number; the user decides materiality.
4. Draft remedies: a proposed ST row with stand-in source and grade per
   material gap; an RG change where the definition is the gap; a
   configuration request where the instrument is.
5. Prepare the workshop: agenda in materiality order with proposals,
   seats, inputs, W-01 to W-05, the annex.
6. Specify the model per channel: inputs with their ST rows, the inherited
   grade, the reserve rule per blended pool.

Disciplines:
- Classification, materiality and signature are human decisions: propose
  with evidence, never decide. The audit proposes; the workshop and
  GP-606 adopt.
- Never fill a tolerance, sample period, reserve or extraction path the
  user has not given; write SET LOCALLY with the owning seat.
- Keep every id exactly: RG-, ST-, LN-, T-01 to T-06, W-01 to W-05,
  AHT-01, AHT-02 (RG-008), OCC-01, CCY-01, CON-01, SHR-01.
- Every number carries its grade; a requirement inherits its weakest
  input's grade; an all-[M] chain yields [C], never [M].
- The reserve is set by the two-class model or simulation against the
  voice goal; a static reading of idle time above a reserve is not a
  bound on email capacity.
- One definition, one code.
- One source per metric; conflicts are published, not averaged.
- An [A] with no range cannot carry a plan.
- A definition or source change goes through GP-606, forward only.
- Two figures for one metric are published both, with the residual,
  never averaged. Seats, never names; no product name in a file marked
  for publication.
- Desktop capture and observation carry the statutory flag; with no
  agreement, mark the focus-time test "not run".

Output: `capture-points.md`, `gap-register.md`, `workshop-pack.md`,
`model-spec.md`. The register opens with the sample period, cohorts tested
and gaps left immaterial, then one row per gap: class, evidence, models
affected, grade effect, remedy. The model spec names one model per channel.
Refuse an unclassified gap, an ungraded number, a channel whose
handling-time row has no ST source, or a reserve read off idle time.

Source: Wiki:Packs/Time and Production Accounting Audit (CP-WFM-024) v1.0

Block 2 — audit-protocol.md

<!-- Derived from [[Time and Production Accounting Audit (generic process)]]; the remedies' grade line from [[Source of Truth Register]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# GP-605 Audit Protocol

The audit establishes, channel by channel and system by system, where every
minute of agent time and every unit of production is captured, how, where it
lands in the time ledger and at what grade; classifies every gap; runs the
tests that detect asynchronous work hidden inside voice states; and hands a
signed gap register to the capacity standards workshop. It starts from what
the capacity model consumes and works back to the instruments, because data
quality is fitness for a stated use. The audit proposes; it adopts nothing.

## Profile (generic values)

| Field | Value |
|---|---|
| Class | supporting |
| Trigger | framework adoption (first full pass); thereafter a platform change, a channel launch, a cohort migration, a reconciliation test failing on two consecutive runs, or the annual review of the Standard |
| Cadence | a full pass typically once a year [A]; a channel-scoped pass on each trigger; SET LOCALLY |
| Scope in | every capture point per channel on every system that emits one: telephony platforms, the workforce-management system, case and email tools, the chat platform, a desktop capture instrument where one exists, the payroll system for paid time; the gap register; the blended-agent tests; the proposed ST rows and RG changes; the workshop agenda |
| Scope out | adopting any definition or source (the workshop; GP-606); reconfiguring a platform; the requirement mathematics |
| Inputs | the ledger template; the code dictionary; the current RG and ST versions; a configuration export per platform instance; the model inventory; the test definitions T-01 to T-06; a sample period of paid, scheduled, logged-in and state time |
| Outputs | the capture-point inventory; the ledger mapping sheet; the signed gap register; the test results with residuals; the proposed ST rows and RG changes; the workshop agenda in materiality order; the audit log with the next pass dated |
| Authority | runs at the data and analytics lead's seat, who signs the gap register; no tier on the real-time ladder; any change to the Standard the audit proposes is signed by the function head (tier 4) at the workshop, never by the audit |
| Risk and compliance flags | a desktop capture instrument records conduct and performance, and in several jurisdictions its introduction is subject to works-council co-determination; observational studies of named agents carry the same flag; payroll time is personal data; a partner-held platform's logs are contractual, not owned |

## The fourteen steps (owner seat in brackets)

1. Open the audit: fix channels, systems, cohorts and sample period; pull the ledger template, the code dictionary and the current RG and ST versions (data and analytics lead).
2. Build the capture-point inventory: per channel and system, every state, timer, counter and timestamp the system emits, from its configuration export, not from memory; platform owners supply the exports (data and analytics lead).
3. For each capture point record what is captured, by what instrument class, at what resolution and refresh (platform owner).
4. Map each capture point to its ledger bucket and its RG entry, or record *no bucket* or *no definition* (data and analytics lead).
5. Grade each capture point: a source grade (system of record · named owner · implied · unattributed) and the number grade it can support (data and analytics lead).
6. **Decision:** does every ledger bucket on every channel have at least one capture point? Rules in the next section (data and analytics lead).
7. Run T-01 to T-06 on the sample period (data and analytics lead).
8. Run the blended-agent tests on every cohort that works more than one channel: first T-06, items closed per available-idle hour; then focus time against state time where an instrument exists; then the idle residual against asynchronous volume (data and analytics lead). See `blended-agent-tests.md`.
9. Classify each gap with the evidence from steps 6 to 8 beside it (data and analytics lead).
10. **Decision:** is the gap material? Which models consume the number, and what the weakest-input rule does to their grade (capacity planning lead); an immaterial gap is logged, not remedied.
11. Draft the remedies: a proposed ST row with a stand-in source and grade per material gap; an RG change where the definition is the gap; a configuration request where the instrument is (data and analytics lead).
12. Sign the gap register, stating the sample period, the cohorts tested and the gaps left immaterial (data and analytics lead).
13. Draft the workshop agenda from the signed register in materiality order, proposals attached, and hand it to the workshop's chair (data and analytics lead).
14. Close the audit: log it, open each proposal through GP-606, date the next pass (register's owner).

Decisions that protect the audit: steps 6, 9 and 10. One owner per step.

## L2 sub-steps: owner seat, duration and automation flag

Durations are typical for one channel-scoped pass [A], SET LOCALLY. Y marks
an automation candidate; the join key names the L3 job aid.

| Sub-step | Owner (seat) | Duration | Y/N | Join key |
|---|---|---|---|---|
| 1.1 Fix scope: channels, systems, cohorts, sample period | data and analytics lead | 2 h | N | audit scope sheet |
| 1.2 Pull the ledger template, code dictionary, register versions | data and analytics lead | 1 h | Y | audit scope sheet |
| 2.1 Export the configuration of each platform instance | platform owner | 1 day each | Y | inventory pull instruction |
| 2.2 Compile the exports, one row per capture point | data and analytics lead | 1 day | Y | inventory template |
| 3.1 Record instrument class, resolution and refresh per row | platform owner | 2 h per system | N | inventory template |
| 4.1 Map each row to a ledger bucket or *no bucket* | data and analytics lead | 1 day | N | ledger mapping sheet |
| 4.2 Map each row to an RG entry or *no definition* | register's owner | 2 h | N | ledger mapping sheet |
| 5.1 Assign source grade and the number grade it supports | data and analytics lead | 2 h | N | grading work instruction |
| 6.1 Test bucket coverage per channel | data and analytics lead | 1 h | Y | coverage test notebook |
| 7.1 Extract the sample period's paid, scheduled, logged-in and state time | data and analytics lead | 1 day | Y | test runbook |
| 7.2 Run T-01 to T-06; record each result with its residual | data and analytics lead | 2 h | Y | test runbook |
| 8.1 Identify blended cohorts and their available-idle hours | real-time lead | 1 h | Y | blended-agent test playbook |
| 8.2 Run T-06 per cohort, then focus against state, then residual against volume | data and analytics lead | 2 h | Y | blended-agent test playbook |
| 9.1 Classify each gap with its evidence | data and analytics lead | 1 day | N | gap register template |
| 10.1 Trace each gap to the models that consume the number | capacity planning lead | 2 h | N | model inventory |
| 10.2 Decision: material or immaterial, grade effect stated | capacity planning lead | 1 h | N | gap register template |
| 11.1 Draft a proposed ST row per material gap | data and analytics lead | 2 h | N | ST proposal form |
| 11.2 Draft RG changes where the definition is the gap | register's owner | 2 h | N | RG proposal form |
| 11.3 Raise configuration requests where the instrument is the gap | platform owner | 1 h | N | configuration request form |
| 12.1 Review and sign the gap register | data and analytics lead | same day | N | gap register template |
| 13.1 Assemble the agenda in materiality order, proposals attached | data and analytics lead | 2 h | Y | workshop agenda template |
| 14.1 Log the audit; open proposals through GP-606; date the next pass | register's owner | 1 h | N | audit log |

Nine sub-steps carry Y; the classification (9.1) is never one.

## The three gap classes and the coverage rules (steps 6 and 9)

| Finding | Class |
|---|---|
| a ledger bucket with no capture point on a channel | not collected |
| a bucket claimed by two systems | collected but misallocated; sent to T-04 |
| an availability bleed (asynchronous work inside a voice available state) | collected but misallocated for voice; not collected for email in-work time |
| an instrument that captures part of what the ledger needs | partially collected |
| a tool that emits no state and no timer | not a variant: what the audit exists to find; not collected |

Classifying a gap means reading what the instrument was built to count
against what the ledger needs, a judgment with no ground truth to publish a
catch rate against. It is never automated. Materiality (10) and the
signature (12) are gates: a person produces a decision per row.

## Remedies (step 11), one per material gap

- **The definition is the gap** → an RG change proposal.
- **The instrument is the gap** → a configuration request with the platform owner's date.
- **Either, until fixed** → a proposed ST row with a stand-in source, its source grade, the number grade it supports and the known gap written in; a stand-in graded *named owner* supports [E] with a range and [A] without; *implied* informs a proposal only.

## Variants (four classes)

- **Statutory.** Desktop capture or an observational study under works-council co-determination: the inventory step (2) and the focus-time test (8) run only on the terms agreed, typically on aggregated data; the works-council liaison owns a variant row on both steps, the function head approves it. With no agreement the focus-time test is marked *not run* and the bleed estimate falls to [A].
- **Contractual.** A partner-held platform whose logs may not be exported supplies its capture points as a partner report graded *named owner*: a parameter of step 5, SET LOCALLY, not a variant. No access at all: step 2 cannot run and a variant row records the partner's attestation as the input, owned by the placement and vendor lead.
- **Structural.** A platform that cannot export its configuration changes step 2's input to a transcription by the platform owner: an L3 difference, no row.
- **Transitional.** A predecessor platform instance with a dated retirement is inventoried at the state level only and tested once; a variant row carries the exclusion with an expiry at the retirement date.

## Automation candidates, ranked by how easy a catch rate is to publish

1. The capture-point inventory pull: a deterministic read of each platform's configuration; an omitted point is visible the moment a platform owner reads the inventory.
2. The reconciliation tests and the coverage test: computations with stated pass bands; after 1 because a test's catch rate is published only once the inventory it reads is released.
3. The blended-agent test computations; after 2 because T-06 consumes their available-idle time.
4. The baseline pull and the agenda assembly; last because each runs once per pass, so the sample accrues slowly.

Released per class on a published catch rate, never on a maturity label.
Never candidates: classification (9), materiality (10), signature (12).

## L3 job aids to name in the function's register (contents are the function's)

inventory pull instruction per platform class, export object named (step 2, work instruction) · inventory template and ledger mapping sheet (2–4, work instruction) · grading work instruction: source grade to number grade (5, work instruction) · test runbook with pass bands (6–7, runbook) · blended-agent test playbook (8, playbook) · gap register template with the three classes and their evidence rules (9, 10, 12, work instruction) · ST and RG proposal forms, configuration request form (11, work instruction) · workshop agenda template and hand-off (13, work instruction) · audit log and trigger table (14, work instruction). The residual below which a gap is immaterial and the sample period's length are L3 values, SET LOCALLY.

Block 3 — capture-point-inventory.md

<!-- Derived from [[Time and Production Accounting Audit (generic process)]] and [[Agent Time Accounting Model]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Capture-Point Inventory: the Channel × System Grid

One row per capture point: every state, timer, counter and timestamp a
system emits, taken from its configuration export. The grid is the
artifact of audit steps 2 to 6 and the evidence base of the gap register.
Systems are named as classes; the instance id is SET LOCALLY and lives at
L3.

## Systems in scope

telephony platform(s) · workforce-management system · case or email tool ·
chat platform · desktop capture instrument (where one exists; statutory
flag) · payroll or time-and-attendance system · for partner supply, the
partner's report or invoiced hours.

## Row template

| Column | Fill |
|---|---|
| Channel | voice · chat · email/cases · none (tiers 1 to 3 are channel-independent) |
| System (class) | one of the classes above; instance SET LOCALLY |
| Capture point | the state code, timer, counter or timestamp, named as the export names it |
| What is captured | the fact: a state change, a contact leg, a session open or close, an item touch, a paid hour |
| Instrument class | system-stamped · agent-toggled · sampled · partner-reported · derived |
| Resolution; refresh | event · interval · day; refresh cadence and latency |
| Ledger tier and bucket | tier 1 to 6 and the leaf bucket, or *no bucket* |
| RG entry | the definition it feeds, or *no definition* |
| Source grade | system of record · named owner · implied · unattributed |
| Number grade supported | [M] · [C] · [E] · [A] |
| Coverage finding | covered · not collected · partially collected · collected but misallocated |

## The ledger tiers the grid maps to

| Tier | Holds | Instrument class expected | Leaves between this tier and the next |
|---|---|---|---|
| 1 Paid time | hours paid for in the period, including paid absence | payroll or time-and-attendance; invoiced hours for partner supply | off-schedule paid time: paid leave, paid sick absence, public holidays, training days not rostered |
| 2 Scheduled time | hours rostered, by activity | the workforce-management system's published schedule | scheduled-not-logged: absence against a shift, late start, early finish, no-show |
| 3 Logged-in time | hours signed in to a work platform | telephony session log; the work-item tool's session log for agents on no telephony queue | unaccounted state time: logged minutes with no state, or a state not in the dictionary |
| 4 State time by code | logged time partitioned by activity code | telephony state log through the code dictionary | non-productive states: break, training, coaching, meeting, system-down and the other shrinkage classes |
| 5 Productive time | state time in codes whose class is productive: available and in-work on any channel | derived from tier 4 by the code's class attribute | available-idle: productive time with no contact, session or item in hand |
| 6 In-work time by channel | talk, hold and after-contact work (voice); focus time per session (chat); touch time per item (asynchronous) | telephony contact records; chat session logs; work-item timers or desktop capture | nothing: the floor of the ledger |

The ledger closes when paid time = Σ leaf buckets + a published residual;
every minute lands in exactly one bucket, a minute two systems claim is
assigned by the precedence rule, a minute no system claims is residual.

## The coverage matrix (step 6): what should emit each bucket, per channel

| Bucket | Voice | Chat | Email / cases |
|---|---|---|---|
| tier 1 paid | payroll or invoiced hours, channel-independent | same | same |
| tier 2 scheduled | published schedule by activity, channel-independent | same | same |
| tier 3 logged-in | telephony session log | chat platform session log | work-item tool session log; often absent → agents on no voice queue have no tier 3 → *not collected* |
| tier 4 state by code | telephony state log | platform states where they exist; else the telephony state the agent sits in | typically none: email work sits in a telephony available or auxiliary state → *collected but misallocated* |
| tier 5 productive | derived | derived | derived; depends on the code's class attribute being set |
| tier 6 in-work | contact record: talk, hold, after-contact work; AHT-01 from ST-001 | session focus time from attention stamps or desktop capture; AHT-01 (chat) from ST-013; realised concurrency CCY-01 from ST-012 (elapsed session time is a lifecycle fact, not a ledger entry) | work-item timer or desktop capture; AHT-02 (RG-008) from ST-007; the row most estates lack [A] → *not collected*, sampled stand-in at [E] |
| available-idle (5 − 6) | where asynchronous work hides; T-06 | — | the bleed's destination |
| units of work (CON-01) | contact record | session log, ST-011 | work-item arrival and close stamps |

Expected pattern on a mixed estate [A]: the voice column mostly measured,
the asynchronous columns mostly inferred or missing, because the telephony
platform stamps every state change and a case tool typically stamps
nothing. The audit's output is the record of which input is which.

## Grading rule (step 5): the source grade bounds the number grade

| Source grade | Number grade it can support |
|---|---|
| system of record, event resolution, the row's own extraction path | [M] |
| derived from system-of-record rows by a stated transform | [C] |
| named owner with a stated method and a range (a sample, a maintained file) | [E] with the range |
| named owner with no range; partner attestation | [A]; cannot carry a plan alone |
| implied (a state read as work time because no timer exists) | refused at the gate; informs a proposal only |
| unattributed | does not enter a model |

## Reading the grid into the gap register

- A bucket with no row on a channel → not collected.
- Two rows claiming one bucket → collected but misallocated; T-04 measures the overlap.
- A row whose instrument captures part of the bucket (a timer that closes on pend but not on batch close; a sample window) → partially collected; the card is adopted on the captured part at no better than [E].
- Each finding carries the row ids beside it, the test result that evidences it, and the models (LN- cards) that consume the number.

Block 4 — blended-agent-tests.md

<!-- Derived from [[Production Accounting for Blended Agents]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Blended-Agent Tests: Detecting and Separating Availability Bleed

A blended agent on a mixed estate typically answers email while sitting in
a voice *available* or *auxiliary* state. The telephony definition of
availability includes auxiliary time and treats availability as a product
of idle time, so work done in that state is recorded as idle by
definition. The bleed runs one way, from the measured channel's idle bucket
into the unmeasured channel's production, and the voice platform cannot
show it. Audit step 8 runs these tests on every cohort that works more than
one channel.

## The three conditions (removing any one removes the bleed)

1. The agent is in a state the telephony platform counts as available or auxiliary.
2. The agent works an item on a tool that emits no state the ledger reads.
3. No routing rule reserves the agent's time for the asynchronous work, so items are worked in the gaps between calls.

## What it does to the numbers

| Figure | Effect |
|---|---|
| Availability | overstated by the handling time of every item worked inside it; the real-time seat reads the excess as capacity to route calls into |
| Occupancy (OCC-01: in-work ÷ productive) | understated: the email minutes sit in the denominator, their in-work time is missing from the numerator |
| Voice requirement | effective voice supply is smaller than the schedule says; service level is missed when email is heaviest; the reforecast raises the voice requirement, the wrong remedy |
| Asynchronous requirement | rests on an estimate, [E] at best, and the hour voice already counted as supply is counted again as email capacity: the double count T-04 catches |

## The detection tests, in the order they run

| Test | Computation | A positive | Needs |
|---|---|---|---|
| 1. Items closed per available-idle hour (T-06) | items closed by the cohort per day ÷ its available-idle hours that day (productive time minus voice in-work time) | a cohort idle in the state closes nothing; a steady rate is production inside it | item counts with closing timestamps; state time by agent and day |
| 2. Focus time against state time | the time an item had focus, by agent and day, against the same agent's available-idle time | focus time inside available-state windows; the overlap is the bleed, measured | a desktop or work-item instrument, with the statutory flag observed; the only test that yields a per-item handling time |
| 3. A residual that moves with volume | the idle residual (available-idle minus voice handle time) by day, regressed on items closed by day | a residual that rises on days more items close; an uncontaminated residual moves with voice volume, not email volume | daily residual and item counts; a few weeks of history; graded [E] with the regression's range |

A T-05 failure in which implied handling time exceeds recorded in-work time
also points here.

## The separation methods, in rising order of cost and precision

| Method | What it is | Limit |
|---|---|---|
| Dedicated work state | a telephony auxiliary code reserved for asynchronous work (not available, productive, in-work for the named channel), entered when the item is opened | the agent-toggled timer: forgetting, and a pace that responds to incentives and to how much work is waiting; fixes the ledger without fixing the measurement |
| Work-item timer | a timer in the case or email tool opening on first touch, closing on completion or pend, reconciled nightly to the telephony state so a minute carrying both a call and an open item is attributed by a stated rule | the only method yielding a measured [M] handling time per item |
| Reserved time through routing | a rule that takes the agent out of the voice pool for a scheduled block, or a threshold rule releasing agents to asynchronous work only when free voice agents exceed a reserve | the reserve is the control variable, a register entry with an owner, SET LOCALLY; a share of the available state is not a policy, a reserve rule is |

## Interim reporting until fixed

Report the blended cohort's occupancy both ways and grade each: as
measured, bleed left in, [C]; corrected, the suspected bleed added to the
numerator, [E] with the range the detection test supplies. Publish the
difference as the bleed residual, in hours, beside the daily figure. The
source row for the cohort's email handling time (ST-007, against AHT-02,
RG-008) carries the test as its known gap; the planning-input gate admits
the corrected figure only with its range. Never average the two figures.

## Worked example (every number synthetic)

A cohort of 40 agents [E] works voice and email on one telephony platform
and a case tool with no timer, week beginning Mon 5 Oct 2026. Ledger:
1,600 h productive (tier 5) [E], 880 h voice in-work [E]. Reported
OCC-01 = 880 ÷ 1,600 = 55 percent [C]; apparent available-idle 720 h [C].
The case tool records 3,600 emails closed [E], nearly all inside
available-state windows.

- Test 1 (T-06): 3,600 ÷ 720 = 5.0 items per available-idle hour [C], on a cohort that should close none while idle.
- Test 2, run with a focus-time instrument on eight agents under agreed terms: 9.5 minutes per item [E], range 8 to 11; implied email in-work time 3,600 × 9.5 ÷ 60 = 570 h [C], range 480 to 660.
- Test 3: the daily residual rises with closures [E].

Corrected occupancy (880 + 570) ÷ 1,600 = 91 percent [E], range 85 to 96,
against the reported 55 percent [C]; true available-idle about 150 h [E],
not 720. Effective voice supply 40 × (1,030 ÷ 1,600) ≈ 26 agent-equivalents
[E] against a schedule of 40, consistent with the missed service level on
the two heaviest email days [E]. The function adopts a dedicated work state
the following Monday and proposes a work-item timer through GP-606.

## Refuse

- To net the bleed out of occupancy without publishing both figures and the residual.
- To treat a share of an available state as email capacity.
- To run the focus-time test on named agents where no agreement exists; mark it *not run* and grade the bleed estimate [A].

Block 5 — workshop-agenda.md

<!-- Derived from [[Capacity Standards Workshop for Time Accounting]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Capacity Standards Workshop for Time Accounting

The workshop takes the signed gap register from GP-605 and, in a fixed
order, agrees the time ledger, one definition per number per channel, one
source of truth per number and one requirement model per channel, and
signs the result as the time-accounting annex to the capacity planning
section of the function's standard. It is held after the audit has signed
a register, never before: definitions agreed without an inventory of what
each system captures bind nothing. It extends the section rather than
reopening it: the capacity cycle's stages stand, and the workshop amends
the requirement stage by naming, per channel, what it computes on. Two
sessions suffice for one telephony platform and two channels; three are
typical on a mixed estate [A]. Nothing decided later reopens anything
earlier.

## Inputs (all four in hand before session 1, or it is postponed)

1. The signed gap register in materiality order, evidence beside each gap.
2. The current RG and ST versions with every proposal GP-605 drafted.
3. The model inventory: one row per model with the numbers it consumes. A function without one writes it first.
4. The capacity planning section as it stands.

## The sessions

| Session | Walked, in order | Decisions | Artifact that walks out |
|---|---|---|---|
| 1 — ledger and definitions | the gap register → the time ledger → the state taxonomy and activity codes → the proposed RG changes, one channel at a time | W-01 the ledger · W-02 one definition per number per channel | the ledger; a definition card per number the capacity model consumes |
| 2 — sources and models | the proposed ST rows → the source-of-truth register → the model inventory → the channel models (asynchronous workload, chat concurrency, service-level mathematics) → the lineage cards | W-03 one source per number · W-04 the model per channel | an ST row per number; a lineage card per model |
| 3 — extension and signature | the amended Method block → the annex → the interim reporting rule for every open gap | W-05 the annex signed by the function head; the definition cards countersigned by the register's owner | the signed annex; the proposals opened in GP-606; the interim reporting list |

## Participants by seat (seats, never names; an absent seat's decision is deferred to a dated follow-up)

| Seat | Brings | Decides | Sessions |
|---|---|---|---|
| data and analytics lead (chair) | the signed gap register, the test results, the proposed ST rows | W-01 with the real-time lead · W-03 with the register's owner | all |
| register's owner (the definitions owner) | the RG register and the proposed changes | W-02 with the capacity planning lead · W-03 with the chair · countersigns the cards at W-05 | all |
| forecasting leads, one per segment or channel group | the model inventory | W-04 with the capacity planning lead | 2, 3 |
| capacity planning lead | the requirement stage as it runs | W-02, W-04 | all |
| real-time lead | the state data, the blended cohorts, the levers that reserve time | W-01 with the chair · the separation method per blended cohort, under W-04 | 1, 2 |
| platform owners, one per system class | what each instrument can emit, at what cost, by when | the configuration requests' dates | 1, 2 |
| placement and vendor lead | which numbers partner supply nodes report | attests the partner-reported rows | 2 |
| function head | the authority to sign the Standard | W-05 | 3 |

## The sequence (each step binds the next; the binding runs one way)

1. **W-01 Agree the ledger.** Adopt the bucket list and the closure identity; agree to publish the residual. No definition is discussed until the ledger stands, because a definition names the bucket it reads.
2. **W-02 Agree the definitions per channel.** One card per number per channel: handling time for voice, chat and email is three cards, not one with a footnote. Register says *collected but misallocated* → the card's bucket field is the fix. *Partially collected* → the card is adopted on the captured part, names the uncaptured part in its validation rule, carries a grade no better than [E] until the gap closes. *Not collected* → the card carries its instrument as a proposal.
3. **W-03 Agree the source of truth per number.** One ST row per card. Where two systems emit the number the room picks one and the other becomes a known-gaps line; the register's conflict rule is applied, not debated.
4. **W-04 Agree the model per channel.** The model each channel's page names and the ST row each input comes from, on a lineage card graded by its weakest input; for a blended cohort, the separation method, with the reserve threshold SET LOCALLY in the capacity cycle; across channels, the assembly order in `sl-math-reference.md`.
5. **W-05 Sign the extension.** The function head signs the annex; the register's owner countersigns the definition cards; every card, row and lineage card enters GP-606 with the workshop's signatures as its review; the interim reporting rule is attached to every gap whose fix is dated after the next monthly cycle.

## Decisions the room may not make

- **Any target or value.** An occupancy band, a service goal, a time-to-close goal or a concurrency figure belongs to the capacity cycle; the room defines how each is measured, and no number changes by agreeing its definition.
- **Any platform.** Buy or build is a technology plan decision; the room records the configuration request and its date.
- **Any placement or headcount.** A requirement that changes because a blended cohort's idle cushion was a fifth of what was believed goes to the capacity cycle's clearing stage.
- **Any statutory matter.** A focus-time instrument needing a works-council agreement is recorded as *not run* with the liaison's date.
- **Any definition the audit did not test.** It goes to the next audit pass with an owner.

## Outputs, and the annex they assemble into

| Part | Holds | Produced in |
|---|---|---|
| definition cards | one per number per channel | session 1 |
| source-of-truth rows | one per card, with grade and known gaps | session 2 |
| lineage cards | one per model, weakest-input grade | session 2 |
| interim reporting list | one line per open gap: both figures, residual, owner, date | session 3 |
| the amended Method block | the model per channel, the assembly order, the registers read | session 3 |

The annex carries an owner (the data and analytics lead), the function
head's signature, the register's owner's countersignature on the cards,
and an expiry. The planning-input gate refuses any number lacking both a
signed card and an ST row.

## Worked example (every number synthetic)

A function on a mixed estate, two telephony platforms feeding one
workforce-management system and a case tool with no timer, holds three
half-days from Tue 3 Nov 2026 after GP-605 signed fourteen gaps, nine
material. Session 1 adopts a nine-bucket ledger and proposes eleven cards;
handling time becomes three cards, the email card (AHT-02, RG-008) carrying
a proposed work-item timer as its instrument. Session 2 writes eleven ST
rows, the first platform's contact record as the source for voice handling
time with the second platform's transfer-leg count as a known gap under
T-04, and ST-007 as the stand-in for the email card; and seven lineage
cards, five graded [E] because the email input is. Session 3 attaches the
interim rule for the blended cohort, dated Mon 1 Feb 2027; the function
head signs; the register's owner countersigns. Twenty-nine proposals enter
GP-606 that day; the monthly cycle reads the registers on Wed 2 Dec 2026.

Block 6 — sl-math-reference.md

<!-- Derived from [[Service Level Mathematics for Voice, Chat and Email]] and [[Multichannel Capacity Model Assembly]] (wiki.wfmlabs.org), version of Thu 16 Oct 2026. Numbers carry [M] measured, [C] computed, [E] estimated, [A] asserted. Local values are marked SET LOCALLY. -->
# Service-Level Mathematics: the Model per Channel and Their Assembly

Three goal statements, three models; a voice model run on email gives a
requirement that is precise and wrong. Every input is named with the
ledger tier or register row it comes from. **Established** = peer-reviewed
queueing or operations literature; **Inferred** = established material
applied to a planning method the literature does not itself validate.
Worked numbers are synthetic [E]; values computed from them are [C].

## Voice

- **Goal.** X percent of calls answered within t seconds, per interval, optionally with an abandonment ceiling.
- **Model.** Erlang C (Established): Poisson arrivals at a stationary rate, exponential handling, identical agents, one first-come queue, patient callers; delay tail P(W > t) = C(c, a)·exp(−(c − a)·t / s), load a = λs. Erlang A (Established) adds exponential patience and returns abandonment; use it wherever abandonment is a managed metric. Solve per interval; the requirement is the smallest c meeting the goal. Multi-skill: no closed form; simulate the routing as configured; needs the skill assignment table, a register object with an owner.
- **Inputs.** Arrivals per interval (CON-01, telephony contact record). Handling time as talk, hold and after-contact work (tier 6; AHT-01 from ST-001). Goal and threshold from the definitions register. Mean patience from abandonment timestamps. Shrinkage enters in the roll-up, never as a model input.
- **Failure modes.** Pooled skills treated as one queue (understates by the dedication penalty); Erlang C where abandonment is material (overstates); handling time contaminated by non-voice work in a voice state, which the model cannot detect.

## Chat

- **Goal.** A share of sessions accepted within a threshold, with a quality floor beside it.
- **Model.** Established: each agent a processor-sharing server with a concurrency limit; per-session speed falls as sessions are added; customers abandon during service as well as before. Desk shortcut (Inferred): focus time per session s_f as handling time, Erlang C or A on a_agent = λ·s_f, where s_f ≈ s_elapsed / k only if realised concurrency k is time-weighted and measured consistently with elapsed time. Check by simulation of the concurrency rule and the routing.
- **Inputs.** Session arrivals (CON-01 for chat, ST-011). Focus time per session (AHT-01 for chat, ST-013; attention stamps or desktop capture; tier 6). Realised concurrency per interval (CCY-01, ST-012; time-weighted, never the platform maximum). Abandonment flags before and during service. Goal and quality floor from the register.
- **Failure modes.** Concurrency as a target (double counts the gain); elapsed time as handling time; one daily concurrency for every interval; one mean across mixed session types; abandonment ignored on either side of acceptance.

## Email and cases

- **Goal.** A share of items closed within a window in hours or days: a statement about the age distribution of closed work, not a wait at an instant.
- **Why Erlang C collapses.** The delay tail is exponential in window ÷ handling time: at 20 erlangs and 21 agents, P(wait > 8 h) ≈ 10^−21 [C], so any hours-scale target is met by one agent above load. Arrivals are non-stationary across the window; service is batched and pended by agent choice (Inferred); pace depends on queue length (Established).
- **Model (Inferred, practitioner support).** H = Σ_i A_i·h_i / 60 + B_0·h̄ / 60; N = (H + buffer) / p, with A_i items per day by type, h_i minutes, B_0 opening backlog, p productive hours per agent per day on this channel; buffer sized from the variance of daily arrivals and handling to the percentile the goal demands. Backlog rolls forward: B_t = B_{t−1} + A_t − X_t. Little's Law (Established): mean age ≈ backlog ÷ throughput; a backlog growing period after period means demand exceeds capacity. The goal is met on the tail, so the ageing profile is checked after the arithmetic. A live, first-come, dedicated queue with a window under about two hours may use Erlang A or simulation for the delay tail (Inferred).
- **Inputs.** Arrivals by item type (CON-01 with items per contact; work-item arrival stamp). Handling time per item as the sum of touches (AHT-02, RG-008, ST-007; work-item timer or desktop capture; tier 6): the row most estates lack; where sampled, the whole requirement is [E]. Backlog and age distribution (open-item snapshot). Productive hours per agent on the channel (tier 5 net of other channels). Daily variance over a planning history.
- **Failure modes.** Elapsed open-to-close as handling time (inflates by pend time); Erlang C against an hours-scale target; availability bleed; speeds from a history censored by scarce work; a buffer omitted.

## Combining channels: the reserve rule

A threshold rule, assigning agents to the deferrable class only when free
agents exceed a reserve, is optimal for equal service-time distributions
and a close approximation otherwise (Established); reading the deferrable
class as email is Inferred. The planning consequence (Inferred): voice
holds priority, deferrable work starts only when idle capacity exceeds
the reserve, and the reserve is the control variable. A share of an available state is not a policy; a reserve
rule is. **The reserve cannot be read off the voice model.** In a 20-erlang
interval staffed at 25 agents for 80/20 by Erlang C, the pool has five
agent-hours idle per hour on average [C], and a static reading of the
Erlang C state distribution puts about 3.5 agents above a reserve of two
[C]. A discrete-event simulation of the same pool, with voice priority and
non-preemptive nine-minute email items started whenever free agents exceed
the reserve, shows why that reading fails: at a reserve of two, email
absorbs about 4.6 agents, 37 hours a day, and the voice service level falls
to about 39 percent [C], because an agent inside an email item is not free
when the next call arrives. Holding 80 percent in 20 seconds needs a
reserve of about 10 of the 25 agents, at which email gets about 1.1 agents,
roughly 9 hours a day [C], all by simulation. **The reserve is set by the
two-class model or by simulation against the voice goal, never by
subtracting a number from idle time.** A static reading of idle time above
a reserve is not a bound on email capacity.

Simulation replaces closed form (Inferred rule, Established practice)
with more than two classes or skills,
time-varying arrivals with shift constraints, chat concurrency or
in-service abandonment, agents of different speed, routing beyond a single
priority, or non-exponential service. The combined model needs four
register objects: the reserve threshold with an owner (real-time lead; SET
LOCALLY), the time-in-state split by channel per blended agent (tier 6),
the routing rule as configured, and both goals with their pairing.

## Inputs and their source rows

| Input | Ledger row or register | Grade required |
|---|---|---|
| voice arrivals per interval | telephony contact record; CON-01 (voice) | [M] |
| voice handling time | tier 6 voice; AHT-01 from ST-001 | [M], passing T-06 |
| goals, thresholds, abandonment ceiling, quality floor | definitions register entries and their pairing | signed |
| mean patience; skill assignment table | abandonment timestamps; the capability register | [M] or [E] with method named; named owner |
| chat session arrivals | chat session log; CON-01 (chat) from ST-011 | [M] |
| focus time per session | tier 6 chat; AHT-01 (chat) from ST-013 | [M]; an [E] here makes the chat requirement [E] |
| realised concurrency; abandonment before and during service | session log, time-weighted; CCY-01 from ST-012; session flags | [M], never the platform maximum |
| item arrivals by type | work-item arrival stamp; CON-01 with items per contact | [M] |
| handling time per item | tier 6 asynchronous; AHT-02 (RG-008) from ST-007 | [M] with a timer; [E] with range from a sample |
| backlog and age distribution | open-item snapshot | [M] |
| productive hours per agent per day on the channel; variance of arrivals and handling | tier 5 net of other channels; the rows over the planning history | [C] from a closed ledger |
| reserve threshold (blended) | register entry, owner the real-time lead | signed; SET LOCALLY |
| time-in-state split by channel (blended) | tier 6 per channel after the precedence rule | [M]; a failed T-04 drops the losing channel to [A] |
| shrinkage (after the model, in the roll-up) | tiers 1 to 5; SHR-01 from ST-010 | [M] or [C] |

A requirement inherits the weakest grade on this table, as its lineage card
records (LN-004, the email model, feeding LN-003, the multichannel
requirement); an all-[M] chain yields [C], never [M]. On most mixed estates
the weakest row is handling time per item, which is why the audit runs
before the mathematics.

## The assembly order

1. Requirement per channel, in its own unit, before shrinkage; an [E] handling time makes an [E] requirement (LN-003 via LN-004).
2. Convert to productive hours over one period: agents per interval × interval length, summed; email is already hours.
3. Decide the pool design per channel pair, dedicated or blended: a register entry with an owner.
4. Blended pools: size voice first, then the reserve; email capacity is what the two-class model or a simulation returns at the signed reserve, never the idle time.
5. Residual email to a dedicated pool, sized by the workload model with its own buffer.
6. Sum to productive hours per pool per period, at the grade of the weakest channel.
7. Apply shrinkage once, at the pool: a blended agent's break is one break.
8. Roll up to FTE, reconcile to the ledger, hand to the monthly cycle.

A pool is dedicated to email by eligibility, by contract, or because the
residual exceeds what a blended pool absorbs at its reserve; never because
the platform cannot tell email time from available time (a measurement
gap: `blended-agent-tests.md`).

## Reconciliation to the ledger (plan row against ledger row)

- productive hours per pool vs tier 5: supply delivered differed from planned; owned by the roll-up.
- in-work hours per channel vs tier 6: the handling-time input was wrong by the gap's share; re-measure AHT-01 at ST-001 (voice) or ST-013 (chat), AHT-02 (RG-008) at ST-007 (email).
- available-idle vs tier 5 − tier 6: implied occupancy differed from the model's; on a blended pool, where email inside an available state hides.
- email hours absorbed by the blended pool vs tier 6 email at blended seats: the reserve delivered more or less than modelled; re-parameterize the reserve, never the voice model.

## Where double counting enters

- **The same hour in two requirements** (an idle hour as email capacity and as the voice model's safety capacity). T-04: Σ in-work across channels ≤ productive time per agent-interval; and email hours credited to the blended pool do not exceed what the model returns at the signed reserve.
- **Elapsed time as handling time.** T-05: items closed × handling time per item against recorded in-work time, within tolerance of one; well below one is idle-in-state or pends held open, well above one is items closed outside any in-work state (T-06 isolates it).
- **Availability bleed.** T-06: items closed per available-idle hour at blended seats, within tolerance of zero. Until it passes, report the bleed beside occupancy and size email from items and sampled handling time.

Usage notes

Sizing. Block 1 is about 560 words and loads with every message; Blocks 2–6 are retrieved as needed and total about 7,600 words counted with table delimiters (about 6,900 without), the audit protocol (Block 2) the largest at about 2,100 because it carries the full L2 sub-step table, the mathematics reference (Block 6) next at about 1,900 with the fourteen-row input table and the reserve rule in full, and the blended-agent tests (Block 4) the smallest at about 1,100.

Output. The pack emits four Markdown files: the capture-point inventory on the row template in Block 3, the gap register with the sample period, cohorts tested and immaterial gaps stated at its head, the workshop pack with agenda, seats, inputs and the five decisions, and a model specification that names one model per channel with every input traced to its ledger row and ST row. The inventory and the register transfer to a workbook; the model specification is the draft of the amended Method block the workshop signs.

Localizing. Every SET LOCALLY mark, every register id and every grade is carried from the source pages. The pack will not fill a tolerance, a sample period, a reserve threshold or an extraction path it has not been given, will not classify a gap the evidence does not support, and will not name a product in a file marked for publication. Three decisions stay with people on every pass: the class of a gap, its materiality, and the signature on the register; the pack proposes each with its evidence and stops.

Drift. Blocks 2 and 3 derive from GP-605 and the ledger page, Block 4 from the blended-agents page, Block 5 from the workshop page, and Block 6 from the mathematics and assembly pages, all as published on Thu 16 Oct 2026; a material change to any page in the infobox is the trigger to regenerate the affected block and bump the version. The reserve-by-simulation figures in Block 6 are the mathematics page's synthetic example and change with it.

Scope. Nothing in the pack is specific to any organization, industry, jurisdiction or platform; system instances, thresholds, tolerances, sample periods and reserve values are the deploying function's and live at L3 or in its registers.

Change history

Version Date Change
1.0 2026-10-16 First release: instruction block and five reference files (audit protocol, capture-point inventory grid, blended-agent tests, workshop agenda, service-level mathematics reference)

See also

Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Wiki:Packs/Time_and_Production_Accounting_Audit&oldid=5590"