Loan and Trade Between Internal Pools (generic process)

From WFM Labs

Loan and Trade Between Internal Pools (generic process) is the generic process card, GP-404, for the short-horizon transfer of staffed hours between a workforce function's internal supply pools, taken before any external lever is pulled. A loan is a dated transfer of hours from a pool with surplus to a pool with a shortfall, returned when the window closes; a trade is a swap of hours between two pools, equal in hours and settled on the difference in cost. The internal pools are, on one axis, the retained in-market sites and the owned remote centres, two of the three supply types Placement Rules and the Tenure Contract distinguishes (the third, contracted supply, is external and out of scope); on a second axis they are the shared, designated and dedicated pools a client's work is staffed from, as Designated, Shared and Dedicated: What the Words Implement separates the words. The people stay employed and rostered by the lending pool; their hours are placed on the borrowing pool's work in routing and coded in the schedule, and the hours are charged to the pool being helped at that pool's loaded rate. Placement owns the eligibility rule, the finance partner owns the rate, real time owns the execution. It is part of Process Standardization and sits under the work-placement section of the function catalog in Anatomy of a ROC Standard. This card is the concept's definition on this wiki.

A loan is neither a sharing arrangement nor a clearing. A sharing arrangement is a standing routing configuration decided at the gate and governed by Call-Sharing Models and Cost Allocation; a loan is a dated exception beside it, inside the forecast lock, typically days to a few weeks [A]. The monthly clearing of surpluses against shortfalls, the netting The Workforce Broker describes, is upstream and produces hires and placement decisions, not loans. The loan is the lever between them: an estate whose pools cannot lend inside the month pays the pooling penalty of every partition every week and reaches for overtime or a partner before it has used the hours it already pays for. The economies it captures are those of resource sharing in queues, real but bounded: largest when both pools are small, shrinking as either grows.[1][2]

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3). Local values are marked SET LOCALLY.

Field Generic value
Card GP-404 · local card id assigned by the standards committee at deployment
Class real-time, in the catalog's four-class vocabulary (strategic · real-time · both · supporting); its weekly signal feeds the strategic review
Trigger a projected shortfall in one pool inside the lock that the schedule's own flex cannot close, with an eligible surplus elsewhere in the same window
Cadence on demand at the ROC's daily lever review; settlement weekly; the loan report read weekly against a planned band (SET LOCALLY; a reporting reference only, since step 13 fires on recurrence)
Scope in loans and trades between internal pools; eligibility; approval tier; execution in routing and schedule; settlement; the reading of a recurring loan
Scope out external levers (partner overflow above plan, contracted surge, agency hours); overtime and voluntary time off within one pool (Overtime and Voluntary Time Off (VTO) Management); standing sharing arrangements and the sharing-volume signal (Call-Sharing Models and Cost Allocation); the monthly clearing; permanent moves, which are placement decisions through the gate
Inputs the capacity state by pool and interval; the eligibility matrix (skill, language, credential, system access, client contract); the loaded rate by pool with its grade, published by the finance partner; the pre-agreed terms and the day's cap; the lock
Outputs the loan register row; the routing and schedule changes with their reversal; the weekly settlement signed by both pool owners; the weekly loan report against the planned band; a register row when a loan recurs
Upstream the capacity plan and its clearing; the forecast and its lock; the constraint register (which pools may lend to which); the activity-code dictionary; the rate table
Downstream finance (the settlement); the sharing review (a recurring loan); adherence reporting (loaned time coded correctly)
Resources the capacity state; the eligibility matrix; the loan register; the rate table; the routing layer and the schedule. Platforms are named at L3 only
Decision points inside the schedule's own flex; eligible; cheaper than the next lever; which tier; did the hours land; has the loan recurred
Authority tier per the work-placement row of Decision Authority Tiers in Workforce Operations: a loan inside the pre-agreed terms is executed at tier 1 by the real-time analyst with the lending pool's confirmation; a trade between two pools inside the day's cap is executed at tier 2 by the two pools' team leads; a loan outside the terms or the cap goes to tier 3, the ROC duty lead; a loan touching a dedicated pool's client contract or a jurisdiction with a consultation right goes to tier 4, the function head; changing which pools may lend to which is a network-design change for the executive sponsor
Risk and compliance flags idle hours in a dedicated pool are what the client's exclusivity bought, so lending them out is a priced change to that contract; loaned hours stay under the lending site's working-time law; mis-coded loaned time breaks both pools' adherence and the time ledger; a loan across a platform seam the router cannot execute is a loan on paper
Variant-prone steps the approval step where a jurisdiction requires consultation; the eligibility step where a contract forbids outbound lending; the execution step where two pools sit on disjoint routing platforms
Automation candidates nine L2 sub-steps (listed below)

The four allocation models and the loan

A loan executes under whichever of the four allocation models the borrowing pool's work runs on, as Call-Sharing Models and Cost Allocation names them. Under percentage allocation the loaned posts are added to the borrowing node's share for the window; under overflow they are placed behind the borrowing pool's threshold as secondary capacity; under skills-based pooling they are made eligible for the borrowing pool's work for the window, which makes loans cheap to execute and easy to forget to reverse; under value with capacity state the loan is the capacity-state change the router already reads, and the process reduces to recording and settling it. The pooling benefit a loan captures is overstated by exactly the double count Multi-Skill Pooling and the Double-Counting Trap names.

The cost rule is the sharing rule and is not restated: hours are charged at the loaded rate of the pool being helped, published by the finance partner with its grade (a rate at [E] is charged as a range and trued up at [M]), and the price is re-read on the resolved case beside the hourly figure before the loan is judged, because hours are not comparable across pools and resolved cases are. A transfer price set by a rule both parties knew before the hours moved is the form the transfer-pricing literature finds fair.[3] A trade nets to zero in hours and settles on the difference in cost between the two pools' rates.

L1 flow

Thirteen steps, five decisions. Owners are seats.

  1. Raise the request: body of work, hours per interval, window, eligibility required, cause — borrowing pool lead.
  2. Is the shortfall inside the schedule's own flex (break and activity resequencing, shift extension within rules)? — real-time analyst. Yes → schedule lever, close; no → 3.
  3. Identify candidate lending pools from the capacity state: surplus hours in the same window — real-time analyst.
  4. Are the candidate hours eligible for the work (skill, language, credential, system access, client contract)? — real-time analyst. Yes → 5; no → next candidate, or the external-lever path.
  5. Price the loan: hours at the borrowing pool's loaded rate with its grade, re-read on resolved cases; compare against the next lever in the published order (SET LOCALLY) — real-time analyst.
  6. Confirm the surplus is releasable: not training, not a deferred backlog, not already lent — lending pool lead.
  7. Which approval tier? A loan inside the pre-agreed terms → tier 1, the real-time analyst executes on the lender's confirmation; a trade inside the day's cap → tier 2, the two team leads; outside the terms or the cap → tier 3, the ROC duty lead; touching a dedicated pool's contract or a jurisdiction with a consultation right → tier 4, the function head.
  8. Record the loan register row: pools, hours, window, rate and grade, approver, return date; for a trade, the two blocks and the difference — real-time analyst.
  9. Execute in routing: eligibility or share for the window, with the reversal scheduled at the same time — routing administrator.
  10. Execute in schedule: loaned time coded to the loan activity so both pools' adherence and requirement close — scheduling analyst.
  11. Did the loaned hours land on the borrowing pool's work? — real-time analyst, during the window. Yes → continue; no → idle loaned hours are a pricing error and the loan is shortened.
  12. Return and settle: routing reversed at the window's end and verified; weekly settlement at the rate, re-read on resolved cases, signed by both pool owners; an extension is a new request — real-time analyst; finance partner.
  13. Has the same loan, between the same pools in the same window, recurred for consecutive weeks (count SET LOCALLY)? — placement lead, weekly. Yes → open a register row and hand it to the sharing review on Call-Sharing Models and Cost Allocation, which carries the reading of sustained sharing (three candidate causes, the threshold not moved); no → the loan is working.

Step 13 is the loan-specific reading and the rule the card exists to state: a loan that recurs is hours that belong in the borrowing pool's plan, so sustained high loan volume is a forecasting or placement failure, never a success. A rising loan count reported as flexibility is a pool planned wrong every week.

L2 step table

The pre-agreed terms, the day's cap, the lever order, the band and platform names are L3 values and read SET LOCALLY.

Step Sub-step Owner (seat) Inputs Outputs Duration Automation candidate Documentation join key
1 1.1 Write the request borrowing pool lead projected shortfall by interval request minutes N L3-404-01
2 2.1 Test the shortfall against the schedule's own flex real-time analyst schedule; the rules closed, or carried to 3 minutes Y (check) L3-404-02
3 3.1 Read surplus hours by pool for the window from the capacity state real-time analyst capacity state candidate list minutes Y (lookup) L3-404-03
4 4.1 Check each candidate against the eligibility matrix and the contract column real-time analyst eligibility matrix; constraint register eligible candidates minutes Y (matching) L3-404-04
5 5.1 Price at the borrowing pool's rate; re-read on resolved cases; compare to the next lever real-time analyst rate table; case count; lever order priced loan minutes Y (arithmetic) L3-404-05
6 6.1 Confirm releasable surplus lending pool lead candidate list; the pool's plan confirmation same shift N — never L3-404-06
7 7.1 Read the terms and the cap; execute at tier 1 or 2, or refer to tier 3 real-time analyst; team leads; ROC duty lead priced loan; terms; cap execution or referral same shift N — never L3-404-07
7 7.2 Where a dedicated pool's contract or a jurisdiction is touched, obtain tier 4 approval and any consultation function head; works-council liaison the loan; the register entry approval with conditions SET LOCALLY N — never L3-404-07
8 8.1 Open the register row real-time analyst approval loan row minutes Y (filing) L3-404-08
9 9.1 Configure routing for the window; schedule the reversal routing administrator loan row routing change and reversal record same shift N L3-404-09
10 10.1 Code loaned time in both schedules scheduling analyst loan row; activity-code dictionary schedule update same shift Y (coding) L3-404-10
11 11.1 Compare handled work by the loaned posts against the loan real-time analyst routing data landed or idle finding each interval Y (comparison) L3-404-11
12 12.1 Verify the reversal at the window's end real-time analyst routing configuration reversal confirmed minutes Y (check) L3-404-09
12 12.2 Compute the weekly settlement on hours and resolved cases; obtain both signatures finance partner; pool owners loan rows; rate table; case count signed settlement weekly N — never (the signature) L3-404-12
13 13.1 Count recurrences; compare the week's loans to the planned band as a reporting reference placement lead loan register weekly loan report weekly Y (comparison) L3-404-13
13 13.2 Open the register row on a recurrence; hand to the sharing review placement lead loan report register row same week N L3-404-13

Variants

The known variant classes, recorded per Standard and Variant in Process Documentation:

  • Statutory. A lending site where a works council holds a co-determination right over the distribution of working time inserts a consultation step before step 9 when a loan changes the lent posts' hours or duties; the liaison owns it and the function head approves the variant. A loan that changes neither needs no step.
  • Contractual. A dedicated pool whose client contract forbids or prices outbound lending is a constraint-register entry read at step 4; the step is parameterized by the register, so the entry is SET LOCALLY and takes no variant row.
  • Structural. Two pools on disjoint routing platforms cannot execute step 9 as a configuration; the step is varied to a manual transfer of posts, reviewed each quarter until the seam closes.
  • Transitional. A pool from a predecessor organization with a different activity-code dictionary codes loaned time under a mapped code, under a variant row expiring at the dictionary cut-over; see Activity-Code Consistency.

L3 register

Names only; the terms and cap per tier, the lever order, the band and the recurrence count are SET LOCALLY in the L2 rows.

Job aid Anchored to Form
L3-404-01 The loan request form step 1 work instruction
L3-404-02 The schedule-flex checklist step 2 work instruction
L3-404-03 The capacity-state surplus read step 3 work instruction
L3-404-04 The eligibility matrix and its contract column step 4 work instruction
L3-404-05 The rate table, the resolved-case re-read and the lever order step 5 work instruction; rule on Call-Sharing Models and Cost Allocation
L3-404-06 The releasable-surplus test step 6 work instruction
L3-404-07 The pre-agreed terms, the day's cap and the referral note per tier step 7 work instruction
L3-404-08 The loan register layout (LN-nnn) step 8 work instruction
L3-404-09 The routing configuration and reversal sheet per platform steps 9 and 12 work instruction
L3-404-10 The loan activity code and its mapping step 10 work instruction
L3-404-11 The landed-or-idle check step 11 work instruction
L3-404-12 The weekly settlement sheet and signature record step 12 work instruction
L3-404-13 The weekly loan report and the recurrence hand-off step 13 playbook
L3-404-14 The loan during an incident: emergency path, logging, ratification at the next sitting steps 7 to 9 runbook

Automation candidates

Flagged at L2 per Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades, never on a maturity label. The list is ranked by how easy a catch rate is to publish: the nine L2 rows marked Y, in order.

  1. The eligibility match (4.1): a deterministic comparison against the matrix and the contract column; every error is a countable mismatch.
  2. The surplus read (3.1): after the match, because the capacity state it reads is a projection with a grade.
  3. The reversal check (12.1): after the read, because a missed reversal is caught against routing data a shift later.
  4. The landed-or-idle comparison (11.1): after the reversal check, because attributing handled work to loaned posts adds an error class; it is also where the loan's benefit is measured rather than asserted.
  5. The pricing (5.1): after the landed check, because the rate's grade and the resolved-case re-read are inputs the arithmetic cannot verify.
  6. The schedule-flex check (2.1): after the pricing, because the rules it tests are local and change, so its catch rate is republished when they do.
  7. The schedule coding (10.1): after the flex check, because a coding error is silent until adherence reporting reads it.
  8. The register filing (8.1): after the coding, because it is assembled from an approval given by hand.
  9. The weekly band comparison (13.1): last, because the row it opens stays human and the band is set from a quarter of hand-kept reports.

Three steps are never candidates. The releasable-surplus confirmation (6.1) is the lending pool lead's statement about a plan a rule cannot read: whether the hours shown as surplus are in fact free. The tier decision (7.1, 7.2) is the execution authority itself. The settlement signature (12.2) is the transfer-price acknowledgement by both pool owners. Under skills-based pooling, where a loan is a one-line configuration, what the card adds is the record, the reversal and the settlement the configuration does not produce; the routing mechanics themselves are standard.[4]

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 loan by telephone call between supervisors, unrecorded and unsettled, is Level 1; a loan logged per predecessor organization and priced by whoever arranged it is Level 2; the process above, rule-priced, settled weekly on the resolved case, with the eligibility matrix, the tier terms, the coded time and the landed check, is the Level 3 process this card defines, where Call-Sharing Models and Cost Allocation also places rule-priced sharing reviewed weekly; a router that proposes the loan with its price for the duty lead to approve, with the first three candidates released on a published catch rate, is Level 4.

See Also

References

  1. ↑ Smith, D. R., & Whitt, W. (1981). "Resource Sharing for Efficiency in Traffic Systems". Bell System Technical Journal 60(1), 39–55. doi:10.1002/j.1538-7305.1981.tb00221.x.
  2. ↑ Mandelbaum, A., & Reiman, M. I. (1998). "On Pooling in Queueing Networks". Management Science 44(7), 971–981. doi:10.1287/mnsc.44.7.971.
  3. ↑ Eccles, R. G. (1983). "Control with Fairness in Transfer Pricing". Harvard Business Review 61(6), 149–161.
  4. ↑ Koole, G. (2013). Call Center Optimization. MG Books. Chapters on skill-based routing and multi-skill staffing.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Loan_and_Trade_Between_Internal_Pools_(generic_process)&oldid=5500"