Wiki:Packs/Content Delivery Under Capacity Constraint

A pack is a deployable set for a Claude project. This one supports a question that gets asked constantly and answered badly: how do we get this in front of the whole workforce without wrecking service level?

The content might be a leadership update, a policy change, a compliance module or a training refresher. The default answer everywhere is the same — schedule people offline in blocks, pick a time, absorb the cost. That is usually the most expensive option available and almost never the only one.

This pack treats content delivery as a capacity allocation problem rather than a communications problem, and it is deliberately written for the person who owns the content as much as for the person who owns the staffing.

When to use it

Use it when:

• An all-hands, town hall, training rollout or compliance push needs to reach a large frontline population
• Someone has proposed taking a fixed percentage of the workforce offline simultaneously
• Offline activity is being scheduled by several functions independently — communications, HR, training, quality — with no shared view of what it costs
• An operation has real-time automation in some places and not others, and delivery is inconsistent as a result
• A delivery window is being negotiated and nobody can say what it would cost to shorten it

Do not use it to design the content itself, to choose a production format, or as a substitute for Shrinkage Planning and Optimization in the annual plan. It assumes that material and does not repeat it.

The central finding

Idle time aggregates but does not concatenate. An agent idle 30% of the day does not have two and a half usable hours — they have that time arriving as short gaps between contacts, and whether a gap can carry the content depends on handle time and occupancy rather than on the idle percentage itself.

For a pool at occupancy ρ with average handle time AHT, mean gap length is AHT × (1 − ρ) / ρ, gaps arrive at 60ρ / AHT per agent-hour, and the probability a gap reaches length L decays as exp(−L / mean gap). Harvest opportunities per agent-hour, with AHT at 25 minutes:

Occupancy	Mean gap	3 min	5 min	10 min	20 min	30 min
60%	16.7 min	1.20	1.07	0.79	0.43	0.24
70%	10.7 min	1.27	1.05	0.66	0.26	0.10
75%	8.3 min	1.26	0.99	0.54	0.16	0.05
85%	4.4 min	1.03	0.66	0.21	0.02	0.002

At 85% occupancy, five-minute content is roughly 290 times more harvestable than thirty-minute content. At 70% the same swap is worth about tenfold. The decay is exponential in length and steepens as occupancy rises, so the tighter an operation is run, the more completely content length dominates every other variable — including the idle rate that most people reach for first.

Put as a window: at 85% occupancy, five-minute content needs about 1.5 hours of exposure per person and lands inside a day. Thirty-minute content needs roughly 440 — about eleven working weeks. It is not expensive to harvest; it is impossible, and any plan assuming otherwise silently falls back to scheduling.

The conclusion is therefore not "find more idle time." It is "change the shape of the content." That is a decision held by the content owner, not the workforce planner, which is why [[#Block 5 — content-shaping.md|Block 5]] is addressed to them.

A second ratio governs whether a pool can afford any release at all: an agent is indivisible, so one person is 8% of a twelve-agent pool and 0.2% of a five-hundred-agent one. Percentage-of-headcount release rules are meaningless below roughly 40 agents; surplus over required staffing is the only valid rule there.

How to deploy

1. Create a project in Claude. Name it for the work, not the method
2. Copy Block 1 into the project's custom instructions
3. Save Blocks 2–6 under the filenames in their headings and upload as project knowledge
4. Start a conversation

Block 1 — Project instructions

# Content Delivery Under Capacity Constraint

You help people get content in front of a contact centre workforce — leadership
updates, policy changes, training, compliance material, announcements — without
buying it out of service level.

The default approach everywhere is to schedule agents offline in blocks: pick a
time, book N people, absorb the cost. That is usually the most expensive option
available and almost never the only one. Your job is to establish what fraction of
the content genuinely requires everybody present at the same moment, and to route
everything else into time the operation is already paying for.

The person you are working with is often a communications, HR, training or
leadership stakeholder rather than a workforce planner. Do not assume workforce
management vocabulary. Explain occupancy, shrinkage and service level when they
first appear.

## Routing

| When the task is | Open |
|---|---|
| Deciding how much of a session must be live at all | `synchronicity-audit.md` |
| Working out whether content of a given length can be delivered in a given window | `harvest-feasibility.md` |
| Understanding when slack appears and which kind it is | `slack-structure.md` |
| Advising the content owner on how to shape material so it is cheap to deliver | `content-shaping.md` |
| Planning across sites with uneven automation coverage | `mixed-estate-delivery.md` |

## Disciplines

- Idle time and harvestable time are different quantities. Never treat one as the other.
- Never quote a harvest volume without stating the assumed occupancy and handle time it rests on.
- Content length is usually the binding variable, not idle rate. Check it first.
- Treat the intraday trough map as something to measure. Never assume the textbook morning-peak curve.
- A percentage-of-headcount release rule is meaningless below roughly 40 agents. Use surplus over requirement.
- Distinguish a reversible release from an irreversible commitment, and say which one is being proposed.
- If the content owner can change the length, that is a bigger lever than anything the planner can do.
- State when a delivery approach depends on automation the estate may not have everywhere.
- Where a figure is judgment rather than measurement, mark it `[estimated]`.

## Output

Lead with whether the request is feasible in the window asked for, then what would
make it feasible. Give the arithmetic, not just the verdict — the assumed
occupancy, handle time, content length and population, so any of them can be
challenged.

When a request cannot be met without scheduling, say so plainly and quantify what
scheduling would cost in service level terms rather than in currency. The cost of
this work is almost never material in money; it is material in availability.

Refuse to produce a delivery plan that assumes a uniform release percentage across
pools of different sizes, and refuse to assume an intraday shape that has not been
measured. Both produce plans that look sound and fail locally.

Source: Wiki:Packs/Content Delivery Under Capacity Constraint (CP-WFM-004) v1.0

Block 2 — synchronicity-audit.md

# Synchronicity Audit

Figures marked `[estimated]` are judgment, not measurement.

## Purpose

Establish what fraction of a proposed session genuinely requires every participant
present at the same moment. That fraction, and only that fraction, has to be
scheduled. Everything else can be delivered by other means at a fraction of the
cost.

Most sessions fail this audit badly. A common structure — five minutes of
introduction, twenty minutes of pre-recorded video, five minutes of live questions
— is 17% synchronous and 83% broadcast, yet the whole thirty minutes is scheduled
as though all of it were live.

## The three categories

| Category | Definition | Test | Deliverable by harvest? |
|---|---|---|---|
| **Synchronous** | Requires live interaction in both directions | Would it be materially worse if the participant watched it later? | No |
| **Broadcast** | One-way transmission | Does anything the audience does change what is delivered? | Yes |
| **Async-interactive** | Requires a response, but not a simultaneous one | Must the response arrive during the session, or merely by a deadline? | Yes |

The critical misclassification is **broadcast presented as synchronous**. It happens
because the event feels live to the person delivering it, and because attendance is
easier to evidence when everyone is in a room at once. Neither is a reason to pay
for simultaneity.

## Running the audit

Take the session's agenda and assign every minute to one of the three categories.
Then ask two questions of anything marked synchronous:

1. **Does the interaction go both ways?** A leader answering questions is
   synchronous. A leader speaking while an audience listens is broadcast, whether
   or not it is happening live.
2. **Does the audience have to be the whole population?** Live interaction usually
   needs a representative group, not a complete one. A question answered in front
   of 200 people is answered for all 18,000 once it is recorded.

What survives both questions is the synchronous core. It is usually between 10% and
20% of the original duration `[estimated]`.

## What to do with each part

**The synchronous core** is scheduled, and because it is now small, it can be
scheduled well — into a genuine trough, for a subset of the population, with the
rest opting in. A five-minute live element for a self-selecting audience is a
different capacity event from a thirty-minute mandatory one for everybody.

**The broadcast portion** is recorded once and delivered against operational
conditions rather than a calendar. See `harvest-feasibility.md` for whether it fits
the window required.

**The async-interactive portion** is given a deadline rather than a slot.
Acknowledgements, comprehension checks and surveys all work this way, and doing so
converts them from scheduled shrinkage into harvestable work.

## The reversibility argument

This is the strongest reason to prefer harvest over scheduling, and it does not
depend on the cost being large.

A scheduled block is an **irreversible commitment made against a forecast**. It is
placed weeks ahead on predicted volume. If the queue turns on the day, there is no
move available — the participants are already in the session.

A harvested release is a **reversible decision made against actuals**. It fires only
when current conditions permit, and the participant can be recalled within seconds
if conditions change.

An organisation that would never commit capital irreversibly on a forecast routinely
commits capacity that way, because the calendar makes it feel like an administrative
act rather than an operational one.

## Where this analysis does not apply

- **Content whose value decays within hours.** A safety notice or a live incident
  briefing has to reach people now, and scheduling is the correct answer. Pay the
  cost knowingly.
- **Sessions whose purpose is the gathering itself.** Some events exist to create
  shared experience. That is a legitimate objective and it is genuinely
  synchronous — but it should be named as the objective rather than smuggled in
  behind an information-transfer rationale.
- **Regulated training with attendance requirements** that specify live
  participation. Check whether the regulation actually requires simultaneity or
  merely evidence of completion; it is more often the latter.

## Common objection and the answer

*"People will not watch it if it is not scheduled."*

Often true, and it is a completion-tracking problem rather than an argument for
scheduling. Harvested delivery produces better attendance data than a live session
does, because completion is recorded per person rather than inferred from a
connection count. Set a completion deadline, report against it, and escalate the
tail — which will be a small fraction of the population, and can be scheduled
directly at negligible cost.

Block 3 — harvest-feasibility.md

# Harvest Feasibility

Figures marked `[estimated]` are judgment, not measurement. The arithmetic below is
a planning approximation, not a substitute for simulation.

## The question this answers

Can content of length *L* reach a population of size *P* within a window of *W*
hours, without scheduling anyone offline?

Two ratios decide it. Idle percentage, which is what most people reach for first,
barely enters into the answer.

## Ratio 1 — content length against handle time

Idle time aggregates but does not concatenate. An agent idle 30% of the day does not
have two and a half usable hours; they have that time arriving as short gaps between
contacts. Whether a gap is long enough to carry the content is what matters, and gap
length is governed by handle time and occupancy, not by the idle percentage itself.

For a pool at occupancy ρ with average handle time *AHT*:

```
mean gap length      m = AHT × (1 − ρ) / ρ
gaps per agent-hour  g = 60ρ / AHT
P(gap ≥ L)             = exp(−L / m)

harvest opportunities per agent-hour  =  g × exp(−L / m)
```

**Assumptions:** Poisson arrivals, single-skill pool, longest-idle-first routing,
gap lengths approximately exponential, wrap included in AHT. It degrades where
arrivals are strongly scheduled (callbacks, appointments) or where routing is not
idle-balanced — see *Routing discipline* below.

### Worked table — AHT 25 minutes

Harvest opportunities per agent per hour, by content length:

| Occupancy | Mean gap | Gaps/hr | 3 min | 5 min | 10 min | 20 min | 30 min |
|---|---|---|---|---|---|---|---|
| 60% | 16.7 min | 1.44 | 1.20 | 1.07 | 0.79 | 0.43 | 0.24 |
| 70% | 10.7 min | 1.68 | 1.27 | 1.05 | 0.66 | 0.26 | 0.10 |
| 75% | 8.3 min | 1.80 | 1.26 | 0.99 | 0.54 | 0.16 | 0.05 |
| 85% | 4.4 min | 2.04 | 1.03 | 0.66 | 0.21 | 0.02 | **0.002** |

### The finding

**At 85% occupancy, five-minute content is roughly 290 times more harvestable than
thirty-minute content. At 70% occupancy the same swap is worth about 10 times.**

The decay is exponential in *L* and steepens as occupancy rises. So the tighter an
operation is run, the more completely content length dominates every other variable
— which is the opposite of the intuition that a busy operation simply has less time
available. It has less time *and* that time arrives in smaller pieces, and the second
effect is far larger than the first.

### Converting to a window

Exposure needed per person = 1 ÷ (opportunities per agent-hour).

| Scenario | Opportunities/agent-hr | Exposure needed |
|---|---|---|
| 85% occupancy, 5-minute content | 0.66 | **1.5 hours** |
| 70% occupancy, 20-minute content | 0.26 | **3.8 hours** |
| 60% occupancy, 30-minute content | 0.24 | **4.2 hours** |
| 85% occupancy, 30-minute content | 0.002 | **440 hours** — roughly eleven working weeks |

The last row is the point. Thirty-minute content in a tightly-run operation is not
expensive to harvest; it is effectively impossible, and any plan that assumes
otherwise will quietly fall back to scheduling.

Apply an acceptance factor for agents who are in an ineligible state — on a break,
in a coaching session, not logged in. A factor of 0.5 to 0.7 is a reasonable
starting assumption `[estimated]` until measured.

## Ratio 2 — one agent against pool size

The first ratio says whether a usable gap exists. The second says whether the pool
can afford to give it up.

An agent is indivisible. In a pool of 12, releasing one person removes 8% of the
pool. In a pool of 500, it removes 0.2%. The release quantum is the same; its
consequence is not.

```
releasable now = scheduled on duty − required staffing for the interval
```

Required staffing comes from the interval's own Erlang calculation, not from a
headcount percentage. This matters because **a percentage-of-headcount release rule
is meaningless in small pools**: 50% of a 12-agent pool is six people, which is a
service failure, while 50% of a 500-agent pool is 250, which is also a service
failure but for entirely different reasons. Neither number was ever derived from a
staffing model.

Below roughly 40 agents, treat surplus as the only valid release rule `[estimated]`.
Above a few hundred, percentage rules become approximately safe because the quantum
is small relative to the pool.

## Why idle time and harvestable time diverge

Small pools run structurally lower occupancy than large pools at the same service
level — that is standard pooling theory. It is tempting to read this as small pools
being rich harvest targets. They are not, for two reasons that both bite hardest
exactly there:

- Their gaps are shorter and less predictable relative to the content.
- Their release quantum is a large fraction of the pool, so each release is chunky
  and risky.

**Idle time and harvestable time move in opposite directions as pools shrink.** Large
pools have less idle in percentage terms and far more of it is usable.

This has a consequence for consolidation business cases, which typically count only
the occupancy gain from pooling. Pooling also converts unusable idle into deliverable
capacity. That benefit is real, recurring across every offline activity in the year,
and almost never counted.

## Routing discipline as a lever

Gap length distribution is partly a routing choice, and this is the least-known lever
available.

**Longest-idle-first routing** — the fairness default on most platforms — spreads
idle evenly across the pool. It produces many short gaps and very few long ones,
which is the worst possible distribution for harvesting.

**Fixed-order or top-down routing** concentrates work on the top of the list and
idle at the bottom, manufacturing long contiguous gaps for agents low in the order.

Switching discipline can create harvestable blocks without adding a single minute of
idle time. It carries real costs — perceived fairness, uneven occupancy exposure,
skill decay for agents who are consistently at the bottom — and should be a
deliberate, temporary and monitored change rather than a standing configuration. But
where long-form content genuinely must be harvested, it is the only lever that
changes the shape of the distribution rather than waiting for the tail.

## Where this breaks

- **Scheduled arrival work** — callbacks, appointments, booked consultations. Gaps
  are deterministic, not exponential, and this model does not apply.
- **Blended and multi-skill environments.** Secondary-skill idle is not the same as
  true idle, and the formula overstates availability. Model per skill.
- **Back office and asynchronous work**, where there is no queue-driven interrupt and
  the constraint is a completion deadline rather than an arrival. Harvest is easier
  there and this arithmetic is unnecessarily pessimistic.
- **Very small pools** under about 8 agents, where the exponential approximation and
  the surplus rule both break down and only direct observation is reliable.

Block 4 — slack-structure.md

# The Structure of Slack

Figures marked `[estimated]` are judgment, not measurement.

## Two kinds of slack, and why the distinction decides the delivery method

Available capacity arrives in two forms that behave nothing alike. Treating them as
one is the most common planning error in this area, because it leads to a single
delivery mechanism being applied to content that needs two.

| | Structural slack | Stochastic slack |
|---|---|---|
| **Source** | The shape of demand across the day, week and year | Randomness in arrival timing |
| **Predictable?** | Yes — it is in the forecast | No — visible only in the moment |
| **Extent** | Interval-wide: the whole period is soft | Momentary: gaps between contacts |
| **Supports** | Long-form content, in pools large enough to release someone | Short chunks, in any pool |
| **Mechanism** | Planned placement | Automated conditional release |
| **Failure mode** | Forecast is wrong and the trough does not appear | None material — it fires only on actual conditions |

**Structural slack** is the afternoon softening, the mid-week dip, the post-peak
shoulder, the seasonal trough. When a pool is genuinely in one, the entire interval
is below requirement, not merely the gaps between contacts. That is the only
condition under which a small pool can release a person for a long block without
harm.

**Stochastic slack** is what remains: the gaps that exist because the next contact
has not yet arrived. It is present all day, in every pool including the smallest,
and it can only ever carry short content — see `harvest-feasibility.md` for the
arithmetic on how short.

## The two delivery lanes

**Lane A — planned placement into forecast troughs.** For content that cannot be
chunked below the gap threshold. Carries forecast risk: the release is committed in
advance and the trough may not materialise. Mitigate by placing it in the deepest
part of the trough rather than the edges, by keeping the block as small as the
content allows, and by retaining the ability to cancel the release on the day.

**Lane B — automated conditional harvest.** For everything else. The release is
conditioned on live state and can be reversed within seconds. Requires real-time
automation and queue-state awareness; without those, it degrades to Lane A with
smaller blocks.

Most organisations operate only Lane A, and operate it badly — placing sessions
against a calendar rather than against a trough. That is why every offline activity
appears to cost service level: the only mechanism in use is the expensive one, aimed
without reference to demand.

## Release conditions for Lane B

The release decision should test all four. Passing three is not sufficient.

1. **Current staffing exceeds required staffing** for the live interval.
2. **Queue depth and longest wait are below threshold** right now.
3. **The next interval is forecast soft**, so the release does not create a problem
   one interval later.
4. **The agent can be recalled immediately** and the content resumed without loss.

Condition four is what makes conditional harvest safe. It permits the release
decision to be wrong, because being wrong is recoverable. Without resumable content
the release becomes a commitment and the mechanism loses its principal advantage.

## Mapping the trough — measure, never assume

The single input the entire method rests on is the intraday shape, and it is the one
most often assumed rather than measured.

The textbook curve — morning peak, afternoon decline — is a generalisation that
holds for some queues and not others. Shape varies enormously by segment, channel,
customer geography and business model. Assuming the standard curve is how delivery
windows end up placed into peak.

Derive it directly:

- Pull at least eight weeks of interval-level offered volume and required staffing.
- Compute surplus, not volume. **The trough is where staffing exceeds requirement,
  which is not the same as where volume is lowest** — staffing curves are lumpy and
  a low-volume interval can still be tightly staffed.
- Segment it. Aggregate curves hide the pools that never trough at all.
- Separate day-of-week from time-of-day. Monday's shape is frequently not Thursday's.
- Note the variance, not just the mean. A trough that appears on average but fails
  one week in four is not a trough you can plan a release into.

## Global estates smooth, local ones do not

Peak is local. Every region's trough sits at a different absolute time, so the
aggregate harvest capacity across a multi-region footprint is far smoother and more
continuously available than any single site's.

The practical consequence: **set a window, not a time.** A global delivery window
measured in days will pass through every region's trough. Within a single region on
a single day it will not, and forcing a common absolute time forces most of the
population outside their own trough.

This is specific to genuinely multi-region operations. Most published guidance
assumes single-site or single-region working, where the effect does not exist and
common scheduling looks more reasonable than it is.

## What structural slack is worth

Structural slack is finite and contested. Training, coaching, quality feedback,
engagement activity and communications all want the same troughs, and each is
usually planned by a different function without visibility of the others. The result
is a trough that is oversubscribed several times over while the rest of the day goes
unharvested.

Where more than one function schedules offline activity, the useful first step is
simply to plot all of it against the same trough map. The overlap is typically
severe and nobody has previously seen it in one view `[estimated]`.

Block 5 — content-shaping.md

# Content Shaping — for the person who owns the material

Figures marked `[estimated]` are judgment, not measurement.

This block is written for the requester — communications, HR, training, a leader —
rather than for the workforce planner. It exists because the largest lever over
delivery cost is held by the content owner, not by the planner, and almost nobody
tells them so.

## The one thing to know

**How long your content runs matters more than how busy the operation is.**

In a tightly-run contact centre, cutting a single item from thirty minutes to five
can increase the number of opportunities to deliver it by two orders of magnitude.
No amount of planning skill produces a comparable gain. The planner is working with
the distribution they are given; you decide its shape.

The reason is that agent idle time arrives in short gaps between contacts, not in
blocks. A long item needs a long uninterrupted gap, and long gaps are rare in a way
that is not intuitive — their frequency falls off exponentially as the item gets
longer, and falls off faster the busier the operation is.

## Four rules

**1. Chunk to well below average handle time.**

If typical contacts run twenty-five minutes, target segments of three to five
minutes. Each segment should stand alone: its own opening, its own point, its own
close. A twenty-five-minute item cut into five arbitrary five-minute slices is not
chunked — it is interrupted, and people will not reassemble it.

Ask of each segment: if someone watched only this one, would they have gained
something whole?

**2. Make it resumable.**

Delivery may be interrupted mid-segment when the queue turns. Content that must be
watched start to finish, or that loses its meaning when resumed, forces the planner
to guarantee an uninterrupted window — which is the expensive thing you were trying
to avoid. Resumable content lets the release decision be reversible, and
reversibility is what makes it cheap.

**3. Separate the part that must be live from the part that must not be.**

Live interaction is valuable and expensive. Recorded transmission is cheap and, done
well, often better — the message is consistent, contributors can join from anywhere,
and it can be produced properly rather than delivered cold.

Almost every session mixes the two and then prices the whole thing at the live rate.
Split them. Keep the live element small, genuinely interactive, and open to a
self-selecting audience rather than mandatory for everyone. A question answered in
front of two hundred people is answered for the whole population the moment it is
recorded.

**4. Ask for a window, not a time.**

"Everyone by Thursday" is cheap. "Everyone at 2pm Tuesday" is expensive, and the
difference is often an order of magnitude. A window lets delivery flow into whatever
capacity appears; a time forces the operation to manufacture capacity that does not
naturally exist at that moment.

The wider the window, the cheaper the delivery — and across a multi-region
operation, a window of two or three days will pass through every region's natural
quiet period, which no single common time can do.

## What to bring to the planner

Answering these five before the conversation converts it from a negotiation into an
arithmetic problem:

| | |
|---|---|
| **Total runtime** | How many minutes of material in total |
| **Longest indivisible segment** | The single longest piece that cannot be split — this is the binding constraint |
| **Genuinely live portion** | Minutes requiring two-way interaction, and with whom |
| **Completion window** | The deadline, and what actually happens if it slips |
| **Audience** | Everybody, or a defined subset — and whether "everybody" was examined or assumed |

The second row is the one that decides feasibility. If the longest indivisible
segment is short, almost anything is possible. If it is thirty minutes, the answer
in a tightly-run operation will be that it cannot be harvested at all and must be
scheduled — with the service level cost that implies.

## What you get back

Delivery that costs the operation nothing measurable, reaches more people than a
live session does, and produces better completion data — because completion is
recorded per person rather than inferred from a connection count.

You also get the tail: a small residual who were never available inside the window.
That group is small enough to schedule directly at negligible cost, which is the
correct use of scheduling — for the exception, not the population.

## The trade you are making

Harvested delivery gives up control of *when* an individual receives the material.
You choose the window; the operation chooses the moment within it.

For most content that is no loss at all. Where it is a real loss — an embargo, a
market-sensitive announcement, a coordinated launch — say so explicitly, because
that is a legitimate reason to schedule and the cost should then be accepted
knowingly rather than argued about later.

Block 6 — mixed-estate-delivery.md

# Delivering Across a Mixed Estate

Figures marked `[estimated]` are judgment, not measurement.

## The problem

Conditional harvest needs real-time automation: something watching queue state and
pushing content to eligible agents within seconds. Almost no estate has that
everywhere. Coverage is typically uneven across sites, business units, acquired
entities and outsourced partners, and the gaps are rarely documented in one place.

The result is a two-tier delivery experience that nobody designed and few people can
see. Covered populations receive content invisibly, in their own quiet moments.
Uncovered populations receive it as a scheduled interruption, or at an unsociable
hour, or not at all.

## Establish coverage before designing delivery

The map is usually absent, and building it is worth doing once because it is
reusable across every offline activity in the year.

For each delivery unit — site, business unit, partner, queue group — record:

| Field | Why it matters |
|---|---|
| Real-time automation present | Determines whether Lane B is available at all |
| Queue-state visibility latency | Multi-minute latency makes conditional release unsafe |
| Ability to recall an agent mid-activity | Without it, releases are commitments, not experiments |
| Content platform reachable from the agent desktop | A harvest trigger with nowhere to send the agent is useless |
| Completion tracking | Determines whether a window can be managed or only hoped for |
| Typical pool sizes | Governs whether a percentage rule is even meaningful |
| Governing contract, where outsourced | Offline time may be chargeable or contractually constrained |

The last row is frequently the binding one and is usually discovered late. Where
delivery is outsourced, the commercial construct decides whether harvested time is
free, billable, or prohibited — and it often differs between partners for reasons of
deal vintage rather than design.

## The fallback where automation is absent

Degrade to scheduled release, but not to the pattern that is usually reached for.

- **Small blocks, not large ones.** Release a few percent of a pool at a time rather
  than a large share. The aggregate offline minutes are identical; the service level
  impact is not remotely so.
- **Placed against a measured trough**, not a calendar slot. This is the difference
  between scheduling and planning.
- **Surplus over requirement as the rule**, never a percentage of headcount —
  particularly in small pools, where one agent already represents a large share.
- **Cancellable on the day.** Retain the ability to abandon the release if the
  interval turns. This recovers part of the reversibility that automation would have
  given.
- **Spread across a wider window** to compensate for the smaller blocks. Where
  automation would deliver in hours, expect days.

Delivered this way, an uncovered population is materially more expensive than a
covered one but not catastrophically so. Delivered the usual way — a large
simultaneous block placed by calendar — it is expensive enough to be visible in the
day's service level.

## Say the gap out loud

Present the coverage map with the plan rather than after it. A delivery design that
appears uniform and turns out to have holes damages trust in every subsequent plan;
one that names its own limits does not.

The honest framing is that a mixed estate produces a mixed experience, that this is
a consequence of tooling coverage rather than intent, and that the affected
population is identifiable in advance.

## The gap has a cumulative number attached

This is the part worth capturing while it is visible, because it is otherwise
invisible.

The cost of missing automation is not one event. It recurs across every offline
activity in the year — training, coaching, quality feedback, engagement, compliance,
communications. Each one is individually small enough to absorb without comment,
which is precisely why the aggregate is never assembled.

To size it:

```
annual exposure = (offline hours per agent per year requiring delivery)
                × (uncovered headcount)
                × (marginal service-level cost of scheduled vs harvested delivery)
```

The third term is the one to establish carefully and the one most likely to be
challenged. Express it in service level and abandonment terms rather than in
currency; the currency figure is usually small enough to dismiss, while the
availability figure is not.

## Where this sits in a maturity assessment

Uneven coverage is a **consistency** failure rather than a capability failure. The
practice exists somewhere in the estate; it does not hold across it.

In staged maturity models this is the characteristic barrier between a level where
individual relationships or sites are run well in isolation and a level where the
same practice holds everywhere. It caps the overall placement regardless of how
advanced the best-run site is, and closing it has an unusually good economic profile
— it means generalising something that already works rather than buying anything new.

A delivery event that exposes the gap concretely, with named populations and a
measurable difference in experience, is more persuasive evidence than an audit
finding, and it costs nothing extra to capture.

Usage notes

Sizing. The instruction block is about 450 words and loads with every message inside the project. The five reference blocks total roughly 5,500 words and load only when retrieved.

The arithmetic is a planning approximation. The gap-length model assumes Poisson arrivals, a single-skill pool, longest-idle-first routing and roughly exponential gap lengths. It does not apply to scheduled-arrival work such as callbacks and appointments, understates the constraint in blended and multi-skill environments, and is unnecessarily pessimistic for back-office work where there is no queue-driven interrupt. Below about eight agents per pool it should not be used at all. It is a way to size a question quickly, not a substitute for simulation.

Two inputs must be measured rather than assumed. The intraday trough map is the foundation of the whole method, and the textbook morning-peak curve is a generalisation that holds for some queues and not others. The automation coverage map decides which delivery lane is even available. Both are commonly assumed, and both are cheap to establish.

Scope. The pack is deliberately silent on production format — live, recorded, in-person or hybrid. The harvest model holds whichever way that decision goes, and including it would make the pack an opinion about someone else's craft.

Article debt. Blocks 2, 5 and 6 have no canonical article home on this wiki yet. The synchronicity audit, content shaping for the requester, and mixed-estate delivery are original to this pack. Blocks 3 and 4 derive from the pages named in the infobox. Until the missing articles are written, those three blocks are the canonical version of that material, which is the reverse of the intended dependency and should be corrected.

Change history

Version	Date	Change
1.0	2026-08-10	Initial publication. One instruction block, five reference blocks.

See also

• Intraday Management — the cycle this delivery model plugs into
• Occupancy — including the team size effect that drives the second ratio
• The Occupancy Trap — why high occupancy is not the goal
• Pooling Theory — the structural reason small pools behave differently
• Shrinkage and Shrinkage Planning and Optimization — where scheduled offline time lands in the plan
• Wiki:Packs — the full pack inventory