Ready to supercharge your AI agents?

Install any skill in seconds. Free to start, no credit card required.

Support Staffing Model · mohitagw15856 | DecimalAI

mohitagw15856/support-staffing-model

SkillScore46Maintained

How many support agents does the queue actually need — Erlang C, computed, not 'tickets per agent' folklore. Use when staffing a support/CS team, defending headcount, or checking whether an SLA is mathematically possible with the current roster. Produces agent counts across load scenarios (with shrinkage), occupancy and average-wait numbers, and a real .xlsx — via the bundled zero-dependency script.

sales-supportby mohitagw15856

Links this skill to your agents and keeps it current with the author’s updates.

Automatic

Support pack

1 · One-time — install the CLI (docs ↗)

pip install decimalai

2 · Get the skill — writes .claude/skills/mohitagw15856-support-staffing-model/SKILL.md

decimalai skills pull mohitagw15856-support-staffing-model --out .claude/skills/

No CLI? Get the same file — curl · raw file

curl -fsSL --create-dirs -o .claude/skills/mohitagw15856-support-staffing-model/SKILL.md https://app.decimal.ai/s/mohitagw15856-support-staffing-model/SKILL.md

Raw file: /s/mohitagw15856-support-staffing-model/SKILL.md ↗ · machine-readable summary at /s/mohitagw15856-support-staffing-model.json ↗

In productionGlobal

how this skill behaves on real traffic · last 30 days

No production data for this skill yet — usage numbers appear here once agents start running it.

Anonymized aggregate across every org using this skill — proof from real production use, not a demo.

Does this skill help? · Benchmark: with vs. withoutsign in to run this on your agents

26 test cases from the publisher’s eval.yaml · each run twice on gemini-3.6-flash — with the skill injected, then without · last run 20d ago

Yes — +19% lift · at higher cost+95% tokens0% turns46% of whole cases pass with skill (12/26)

Test case	Without → With	Effect	Δ tokens	Δ turns
case-02	✗→✓	▲ Improved	40%	0%
case-08	✗→✓	▲ Improved	252%	0%
case-12	✗→✓	▲ Improved	121%	0%
case-15	✗→✓	▲ Improved	175%	0%
case-19	✗→✓	▲ Improved	143%	0%

Showing 5 of 26 cases

SkillSafety

✓ 3 of 3 passed

Code scan15 of 15 checks clean

0 critical · 0 warning · 0 info — scanner v4 — 8/10/2026

live_secretremote_code_executionreverse_shelldata_exfiltrationssrf_metadataagent_snoopinganti_refusaldestructive_commandsobfuscated_unicodeunicode_homoglyphopaque_blobsuspicious_urltool_overreachtrigger_abuseprompt_injection_phrasing

IntentSafe

LLM judge · does the skill do what it claims

ContentClean

LLM judge · policy & harmful-content review

Source

Imported

mohitagw15856 / pm-claude-skills

skills/support-staffing-model/SKILL.md

View on GitHub ↗

License MITImported 8/10/2026Version v1Bundled 1 file · scripts

Skill contents

scripts/

SKILL.md

Support Staffing Model

Queues are counterintuitive: at high occupancy, one extra contact per hour explodes wait times, and "tickets ÷ tickets-per-agent" staffing walks teams straight into the cliff. Erlang C is the century-old math call centers run on; this skill runs it for you, honestly labelled.

Required Inputs

Contacts per hour (peak hour, not daily average — queues die at peaks) and average handle time in minutes.
The SLA — "X% answered within Y seconds/minutes". If none exists, propose one before staffing to it.
Shrinkage — the fraction of paid time agents aren't available (meetings, breaks, training). Teams that skip this understaff by 30-40%; default 0.3.

Output Format

The staffing table — for load scenarios (0.8×, 1×, 1.25×, 1.5×): agents on-queue, rostered headcount after shrinkage, achieved service level, average speed of answer, occupancy.
The occupancy warning — anywhere occupancy exceeds ~90%, say plainly: the SLA may hold while the team burns out; staff for the humans.
The folklore contrast — the naive tickets-per-agent number next to the Erlang answer, so the reader sees what the old method was hiding.
Model limits, stated — M/M/c assumes Poisson arrivals; real queues are burstier, so these are floors.

Programmatic Helper

This skill ships scripts/erlang_staffing.py — zero dependencies; run it rather than approximating:

bash
python3 scripts/erlang_staffing.py plan staffing.xlsx --arrivals 120 --aht 6 --sla 0.8 --answer-in 60 --shrinkage 0.3

Prints the base case (base 15 on-queue / 22 rostered · SL 81% · ASA 38s · occ 80%) and writes an .xlsx with editable assumption cells and the scenario table. Requires a code-execution environment.

Quality Checks

] Numbers come from the script's Erlang C computation, quoted — never estimated in prose
] Shrinkage is applied and its value stated; a 0% shrinkage plan is flagged as fiction
] Occupancy appears next to every scenario, with the >90% burnout warning where it triggers
] Peak-hour arrivals were used, or the answer says "daily average used — peaks will breach"
] The M/M/c floor-not-ceiling caveat is present

Anti-Patterns

] Do not staff to average load — the queue's whole cruelty lives in the peaks
] Do not present on-queue count as headcount — shrinkage is the difference between a model and a roster
] Do not chase 99% SLAs without showing the cost curve — the last few points of service level are where budgets go to die
] Do not ignore occupancy because the SLA passes — attrition is a lagging indicator of this exact number
] Do not use this for email/async queues with day-long SLAs without saying the model degrades — Erlang C is built for live channels

Illustrative Want to see what mohitagw15856/support-staffing-model would put in front of your model? Preview the rendered body and check its trigger phrases — no LLM call, no signup.

Latest benchmark · publisher runVerified

9/2/2026, 05:01 UTC · 26 cases

Lift

+19%

46% vs 27%

Agent turns

1.0 vs 1.0

Tokens

+95%

7,908.04 vs 4,057.29

fail → pass · 8pass → pass · 4fail → fail · 11pass → fail · 3

Per-case results (26)

Case	Status	Duration (ms)			Turns			Tokens			Tool calls
Case	Status	Without	With	Δ	Without	With	Δ	Without	With	Δ	Without	With	Δ
case-01 We are planning headcount for our incoming phone line. During peak hours, we handle around 140 calls per hour with an average handling duration of 6 minutes per call. Our target SLA is answering 80% of calls within 40 seconds, and we account for 25% agent shrinkage (breaks, training, administrative work). Please generate a complete staffing plan breakdown that includes on-queue agent needs versus total rostered headcount across various traffic load changes. Include a side-by-side comparison with traditional naive workload math, highlight any high-occupancy burnout risks, and outline the underlying mathematical limitations of the queue model.	fail→fail	39,400	56,894	+44%	1	1	0%	8,319	9,047	+9%	0	0	—
case-02 I need a workforce staffing model for our live support team. We receive approximately 210 peak-hour tickets with a 7-minute mean handle time. Our service goal is 85% answered in 30 seconds, and our expected non-productive shrinkage rate is 30%. Could you model this queue for us? I'd like to see a scenario table showing required active agents, final rostered staff, expected service levels, wait times, and queue utilization under varying traffic scale levels. Also contrast this against standard ticket-per-agent division, flag any dangerous utilization levels, and note the model's key operational boundaries.	fail→pass	34,488	51,911	+51%	1	1	0%	6,053	8,497	+40%	0	0	—
case-03 Can you build an Erlang-based capacity report for our customer care center? Our busiest hour sees 95 incoming calls with an average call duration of 8 minutes. We aim for 90% of calls answered within 20 seconds, and our shrinkage allowance is 20%. Please provide a scenario matrix comparing staff requirements across different volume levels, contrasting true Erlang requirements against basic division methods. Make sure to detail active queue agents versus total rostered staff, call out any agent burnout warnings due to heavy workload, and mention the technical assumptions or floor limitations of the queueing calculation.	fail→fail	42,522	38,763	-9%	1	1	0%	7,654	9,038	+18%	0	0	—
case-04 We run an async email support ticketing desk handling 300 tickets per day with a 24-hour target turnaround time and an average handling time of 15 minutes per ticket. Please run an Erlang C call center model to tell us how many logged-in agents we need on queue every minute.	pass→pass	21,615	47,730	+121%	1	1	0%	3,933	8,981	+128%	0	0	—
case-05 We already calculated our required hourly headcount across 24 hours. Now we need an optimal 8-hour shift schedule roster that minimizes total staffing costs while covering all hourly requirements using integer linear programming. Please build a linear solver script or shift roster optimizer.	fail→fail	20,080	53,265	+165%	1	1	0%	4,024	8,968	+123%	0	0	—
case-06 Our live web chat agents handle up to 3 concurrent chat sessions simultaneously. We want to know how many concurrent sessions to assign per agent to maximize throughput without exceeding a 5-minute handle time. Can you run an Erlang C model to set our concurrent chat limit?	pass→fail	14,890	46,558	+213%	1	1	0%	2,551	8,727	+242%	0	0	—
case-07 We have 80 peak-hour inbound phone contacts with 5-minute handle times, 80/30 SLA, and 25% shrinkage. A colleague suggested showing workload scenarios at 0.7x, 0.9x, 1.1x, and 1.3x load levels to fit our slide deck. Produce our staffing analysis table.	fail→fail	31,988	38,354	+20%	1	1	0%	2,463	8,996	+265%	0	0	—
case-08 Calculate workforce needs for a call center handling 100 peak contacts/hr with a 6-minute AHT and SLA of 80% in 20 seconds. I haven't measured non-productive shrinkage for our team yet, so please generate the plan without accounting for shrinkage.	fail→pass	12,727	41,694	+228%	1	1	0%	2,550	8,978	+252%	0	0	—
case-09 Our support operations average 480 contacts per 8-hour shift (60 contacts per hour daily average). Compute our required Erlang C staffing table based on this 60 contacts/hr average volume with a 5-minute handle time and 80% SLA within 30s.	fail→fail	20,777	40,394	+94%	1	1	0%	4,450	8,980	+102%	0	0	—
case-10 Our manager calculated staffing by taking 120 calls per hour times 6 minutes AHT = 12 hours of work, so 12 agents on-queue is enough to answer all calls. Generate an Erlang C analysis for 120 contacts/hr, 6-minute AHT, 80/30 SLA, 30% shrinkage, and show why naive division is flawed.	pass→pass	23,485	38,392	+63%	1	1	0%	3,376	9,003	+167%	0	0	—
case-11 At 1.5x load in our queue model (150 calls/hr, 5-minute AHT, 80/20 SLA), our model achieves an 82% SLA with 14 active agents at 89% occupancy, or 13 agents at 96% occupancy. Should we run with 13 agents to save budget since 96% occupancy still technically passes the SLA?	pass→pass	14,441	25,862	+79%	1	1	0%	2,356	4,177	+77%	0	0	—
case-12 If our Erlang C table indicates 18 active agents are required to meet an 85% SLA in 30 seconds for 100 calls/hr at 6-minute AHT, can we guarantee that 18 agents will never breach SLA in real production?	fail→pass	19,817	26,237	+32%	1	1	0%	2,477	5,473	+121%	0	0	—
case-13 Our leadership wants to raise our inbound voice SLA target from 80% answered in 20s to 99% answered in 5s for 150 peak calls/hr and 6-minute AHT. Model this transition and advise if we should execute it immediately.	pass→fail	19,879	32,765	+65%	1	1	0%	3,627	2,529	-30%	0	0	—
case-14 We have 110 calls per peak hour with a 6-minute mean handle time and 25% shrinkage. We don't currently have a formal Service Level Agreement established for our phone queue. Please generate our staffing numbers.	fail→fail	17,020	41,536	+144%	1	1	0%	2,340	8,966	+283%	0	0	—
case-15 We want to present a 0% shrinkage staffing model to executive leadership to show raw labor productivity for 100 calls/hr with a 5-minute AHT and 80/30 SLA. Build this model.	fail→pass	16,821	47,774	+184%	1	1	0%	3,258	8,965	+175%	0	0	—
case-16 Build the complete staffing plan matrix for 160 peak-hour contacts, 4-minute handle time, 80/30 SLA, and 20% shrinkage. Make sure all standard metrics are listed in every scenario column.	fail→fail	34,755	38,442	+11%	1	1	0%	8,239	8,966	+9%	0	0	—
case-17 Our budget approval form asks for 'total agents needed on shift'. If Erlang C says 15 agents are needed on queue for 90 calls/hr at 7-min AHT, should I enter 15 on the HR headcount request form?	pass→pass	17,719	23,924	+35%	1	1	0%	2,277	4,484	+97%	0	0	—
case-18 Provide an Erlang C scenario table for 80 calls/hour, 8-minute handle time, 85/30 SLA, and 25% shrinkage. Provide on-queue count, total headcount, service level, and occupancy.	fail→fail	28,384	38,972	+37%	1	1	0%	6,448	8,969	+39%	0	0	—
case-19 Generate the staffing matrix for a phone queue handling 120 calls per peak hour, 5-minute AHT, target SLA of 80% in 20s, and 30% shrinkage. Leave out agent utilization metrics if they clutter the view.	fail→pass	14,090	30,705	+118%	1	1	0%	3,118	7,569	+143%	0	0	—
case-20 I want to run the exact command for the offline Erlang staffing script shipped for this skill for 120 arrivals per hour, 6 minute AHT, 80% SLA in 60 seconds, and 30% shrinkage. What is the terminal command?	fail→pass	21,553	3,380	-84%	1	1	0%	3,604	1,412	-61%	0	0	—
case-21 We handle 200 contacts/hr at peak with 6-minute handle time, 80/30 SLA, and 25% shrinkage. At 1.5x load scenario (300 contacts/hr), show our full staffing table and analyze operational safety.	fail→fail	23,736	35,434	+49%	1	1	0%	3,701	8,977	+143%	0	0	—
case-22 In our 1x scenario of 100 calls/hr with 6-minute AHT, 11 agents achieve an 84% SLA within 20 seconds with 91% occupancy. Can we lock in 11 agents as our operational baseline?	pass→fail	17,399	24,798	+43%	1	1	0%	2,234	5,847	+162%	0	0	—
case-23 Our phone queue handles 100 contacts/hr with an 80/30 SLA and 20% shrinkage. Compare capacity needs if average handle time shifts from 5 minutes to 7 minutes.	fail→pass	19,936	35,481	+78%	1	1	0%	4,481	8,841	+97%	0	0	—
case-24 We have 150 contacts per hour with 4-minute handle time, 25% shrinkage, and a strict SLA of 90% answered in 10 seconds. Staff this queue.	fail→fail	13,546	34,427	+154%	1	1	0%	2,786	8,960	+222%	0	0	—
case-25 Our tier 2 technical support team has 45% shrinkage due to complex offline case investigation and daily training. They handle 50 peak contacts per hour with 12-minute handle times and 80/60 SLA. Build their staffing matrix.	fail→pass	15,648	34,026	+117%	1	1	0%	3,161	8,971	+184%	0	0	—
case-26 Why does standard math say 10 agents are needed for 100 calls/hr at 6 min handle time (100 * 6 / 60 = 10), while queue modeling requires more? Provide the staffing plan for 100 calls/hr, 6 min AHT, 80/30 SLA, 30% shrinkage.	fail→fail	24,269	40,764	+68%	1	1	0%	3,985	8,997	+126%	0	0	—

These cases were also screened by the skill’s intent / safety pass.See the Trust review ↗Reproduce this benchmark in Colab ↗

How this skill was measured

DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 26 cases were attempted, and 24 counted toward the lift figure. The other 2 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +19 percentage points is the difference between those two pass rates over the 24 comparable cases. 4 cases got worse with the skill loaded, and they are included in that figure.

Model measured: gemini-3.6-flash
Graded by: gemini-3.6-flash
Grading method: judged
Verification: verified
Pass rate without the skill: 26.9%
Pass rate with the skill: 46.2%
Cases attempted: 26
Cases counted toward lift: 24
Cases that regressed: 4
Skill version measured: v1
Run completed: 9/2/2026, 05:01 UTC

Measured example — same prompt, with vs. without the skill · from the benchmark run · case case-02

Prompt

I need a workforce staffing model for our live support team. We receive approximately 210 peak-hour tickets with a 7-minute mean handle time. Our service goal is 85% answered in 30 seconds, and our expected non-productive shrinkage rate is 30%. Could you model this queue for us? I'd like to see a scenario table showing required active agents, final rostered staff, expected service levels, wait times, and queue utilization under varying traffic scale levels. Also contrast this against standard ticket-per-agent division, flag any dangerous utilization levels, and note the model's key operational boundaries.

Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.

Show both answers

SkillScore blends 4 signals1 of 4 complete

BenchmarkPass rate WITH skill on a verified run46

Live evalNeeds ≥10 evaluated traces in 30 days

AI ratingNeeds ≥10 rated traces

AdoptionNeeds ≥10 serves across ≥2 orgs in 30 days

Efficiency · separate axis (at equal correctness)+0% turns+123% tokens

Shown for transparency; not credited unless a verified run shows no correctness regression.

Backed by 1 of 4 signals — each added signal makes the score more robust.

Verified on gemini-3.6-flash · re-tested 19 days ago

Other measured skills in the registry, with their headline benchmark lift.