Skills CX operations
Support team topology
Growing support teams default to splitting by whatever annoyed someone last quarter — a new product launch, a loud enterprise customer, a channel that backed up. Each split adds coordination cost: handoffs, duplicate policy, uneven load, and managers who no longer see the whole picture. The topology question is not "how do we organise people" but "where should boundaries sit so ownership is clear and handoffs are rar
npx rulebase-skills install cx-team-topologyWhen to use it
Reach for this when someone says any of these — they are the phrases the skill itself triggers on:
- “team topology”
- “how should we split the team”
- “organise support by product or queue”
- “when to create pods”
- “support team structure”
How it works
The method, in the order the skill runs it. The full procedure — tables, worked examples and the edge cases — is in the skill itself.
Step 1: map the split dimensions
Common axes.
Step 2: measure coordination tax
Before adding a boundary, estimate: Internal transfer rate between candidate teams, Repeat contact after transfer, Dual-ticket workflows, Manager span, Policy forks.
Step 3: queues vs pods
Shared queue model — agents pull from pooled work; skills route by rules.
Step 4: growth triggers — when to split
Split when at least two hold: Span of control, Skill surface area, Calibration drift, Hiring profile differs.
Step 5: design the boundary artefacts
Any split needs: Routing rules, Escalation map, Shared calibration, Knowledge ownership, Metrics, Customer identity.
Step 6: plan reversibility
Try soft splits before hard ones: Skill-based routing with dedicated supervisor, Named pod on same queue technology, Time-boxed pilot with transfer and CSAT/QA comparison.
Related skills
Free and open source, and vendor-neutral — it reads the conversations from whichever helpdesk you already run. Browse all 149 skills · connect your helpdesk over MCP · source on GitHub
