A senior engineer gets the same share of tier-1 password resets as the new hire, while specialty database tickets sit in a triage queue waiting for someone to manually pluck them out. Round-robin is not assignment — it is load shedding. Skill-based assignment exists in the platform but most teams never get past the configuration cliff.
Skills must be observable, not aspirational
A skill catalog with 200 entries that nobody updates is worse than no catalog. Limit the initial skill set to skills that map to a tangible certification, project history, or queue performance signal. “Oracle DBA” is observable. “General problem-solving” is not. The cmn_skill table should have a definition document for each entry that says how the skill is verified and when it expires.
Skill levels with operational meaning
The default 5-point scale is too granular. Use three levels: 1 (can handle with documentation), 2 (can handle independently), 3 (can mentor others). The router uses level 2 as the threshold for primary assignment and level 1 as the fallback. Level 3 surfaces in the assignment UI so escalations have a known target.
Required skill: Oracle 19c, level 2
Primary candidates: users with skill level >= 2
Fallback: users with skill level >= 1 (notify manager)
Escalation: users with skill level = 3Match against the work, not the queue
The skills required to solve a ticket are properties of the ticket, not the queue. A “Database” assignment group might handle Oracle, Postgres, and MongoDB tickets — distinct skill requirements. Tag tickets with required skills via a categorization rule or an upstream form field, then route within the group based on the match.
// On incident insert, after categorization
var requiredSkills = new TicketSkillRequirementUtil()
.getSkillsForCategory(current.category, current.subcategory);
current.required_skills = requiredSkills.join(',');Capacity is the second dimension
A perfectly skilled fulfiller with 30 open tickets is the wrong assignee. Combine skill match with current workload: open tickets, hours in active timer, scheduled time off. The router scores candidates on (skill_match * 0.6) + ((1 - workload_pct) * 0.4) and assigns to the top score. Tune the weights based on your team’s bottleneck — if quality is the constraint, raise skill weight; if SLA breach is the constraint, raise capacity weight.
Decay and recertification
Skills decay. A certification from 2019 is not the same as one from 2024. Add an expires_on field to user skills and let expired skills drop out of the matching pool with a 60-day grace period. Without decay, the skill matrix gradually loses correlation with reality and the router quietly degrades to round-robin.
On-call and shift awareness
Skill-based assignment that ignores the schedule routes 3 AM tickets to off-shift fulfillers. Combine skill match with the on-call schedule (cmn_rota) and active shift definitions. If no on-shift fulfiller has the required skill, route to the on-shift senior who can triage and hold until the skilled person is available.
Common failure modes
Required-skill fields populated by the user creating the ticket — they will pick wrong. Skills entered only at hire and never updated — automate skill addition from training completion records. A skill catalog maintained by HR but used by IT — give IT operations write access to the IT-relevant skills with a quarterly audit by HR.
Implementation sequence
Pick one assignment group with high diversity of work types. Define five to ten observable skills covering 80% of their tickets. Get the team to self-rate, validate with the manager, enable matching for new tickets only (do not retroactively reassign). Measure mean time to resolve before and after for a month before expanding.
What to do this week: query task_skill for tickets with required skills set but assigned to fulfillers without those skills — that mismatch is your baseline.
