Field Service & Trades// definition

What a skill matrix has to know before it can pick a technician

In short

A skill matrix is dispatchable only when it separates 2 kinds of fact: hard constraints that remove a technician from the candidate list — a licence the work requires, a supervision rule, a part not on the van — and soft preferences that only re-order who is left. Every constraint needs a validity date tested against the job's scheduled day.

Key takeaways

  • Constraints filter the candidate list; preferences only re-order it. Tags lose that distinction.
  • Validity is evaluated at the job's scheduled date, not at the moment the board is built.
  • Familiarity with a make and model is a preference. It shows up in duration, not eligibility.
  • Supervision is a property of a pair, so it consumes 2 technician-days for 1 job.
  • Truck stock belongs in the matrix: an eligible technician without the part is no candidate.

A skill matrix is the data a scheduler consults before it may send anyone. Most operators hold it as names with 3 or 4 tags — gas, commercial, senior — which reads well and dispatches nothing, because a tag cannot say whether missing it makes the assignment illegal or merely slower.

That is the whole design question. A hard constraint removes a technician from the candidate list: a licence the work legally requires, a check the site demands, an apprentice who may not attend alone, a part not on the van. A soft preference re-orders whoever is left — this technician installed the unit, speaks the customer's language, saw the fault last year. Encode both the same way and the scheduler cannot tell a rule from a nicety.

One filters the list, the other only sorts it

  • A constraint returns a candidate set, possibly empty. An empty set is information: the job cannot run today and should surface immediately, rather than becoming one of the jobs sitting unassigned until someone notices.
  • A preference returns a ranking, never an exclusion. A dispatcher may override it without an argument, which is the practical test of whether you classified it correctly.
  • Preferences show up in duration, not eligibility. A technician who has never worked that make finishes later — a scheduling input, not a permission, feeding the recalibration in the first call being on time and everything after it sliding.
  • Emergencies shrink the eligible pool to 1 or 2 names, which is why the reserved-capacity argument in one emergency and the afternoon board is gone has to be made per skill, not per technician-day.

The fields a dispatchable technician record carries

FieldKindHow it has to be storedWhat breaks without it
Licence or registration the work requiresHardIssuing body, identifier, scope covered, valid-from and valid-toThe board offers a technician who legally may not do the job
Site or sector clearanceHardCheck type, the body that ran it, expiry, site classes unlockedA technician is turned away at reception and the slot is lost
Equipment class competenceHardA system class the operator defines: split system, 3-phase, sealed unitEverything is 1 bucket called technician and anyone gets sent
Make and model familiaritySoftManufacturer, model family, last date worked, jobs completedNothing legally, but durations diverge silently by technician
Truck stockHard, volatileLive part counts per van, refreshed on consumption not nightlyThe right technician arrives without the part and the visit is wasted
Customer and site historySoftPrior visits to the site, outcome, whether the customer asked againContinuity is lost and callbacks get sent to strangers
Supervision statusHard, pairedLevel, plus the rule naming who must be present or sign offAn apprentice is dispatched alone to work they may not sign off
Working zone and start locationSoft, usuallyHome or depot start, preferred zone, willingness to cross itOptimisers produce routes nobody will drive
The 8 fields, and what the scheduler loses without each

Truck stock is the row most often left out, and it turns a correct assignment into a wasted visit more reliably than any skill gap. It is also the only 1 of the 8 that changes several times a day, making it an integration problem rather than a records problem.

Expiry is a field, and it has to be checked against the job's date

Credentials lapse without anyone touching the record, which makes them the only constraint that changes while the system sits idle. 3 rules follow, and all 3 are routinely got wrong.

  1. Evaluate validity at the scheduled date of the job, not when the board is built. A booking taken in March for July work must test the credential against July, or the day arrives and the assignment is void.
  2. Treat the near-expiry window as a scheduling input. A credential expiring in 30 days is still valid and already a planning problem, particularly for agreements booked months ahead.
  3. Fail closed on a missing date. A credential with no expiry recorded is unverified, not permanent, so exclude it and raise it rather than assume.

The record structure that makes this enforceable — issuing body, scope, evidence, renewal state — is set out in what a licence record needs to enforce an expiry. The matrix only consumes it.

Supervision is a property of a pair, not of a person

An apprentice's constraint is not on them, it is on the pair: may attend if a named person is present, may attend alone and not sign off, or may not attend this work at all. A scheduler storing supervision on 1 technician cannot express any of the 3, so it books the apprentice and the day fails at the door.

Modelled properly, a supervised job consumes 2 technician-days and produces 1 completion — a capacity fact the board must show. Getting it into the data is ordinary internal tools and operations work: an eligibility table beside the platform you run. It sits with dispatch, scheduling and route sequencing, inside our field service and trades work.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

What is skill-based dispatch?

It is assignment that first filters technicians by what the job requires, then ranks whoever remains. The filter uses hard constraints — licences and registrations, site clearances, equipment class competence, supervision rules, parts on the van — and the ranking uses preferences such as familiarity with the model or prior visits. Without the filter, a scheduler is optimising travel across people who cannot legally do the work.

How should technician certifications be stored for scheduling?

As structured records with an issuing body, an identifier, the scope of work covered and explicit valid-from and valid-to dates — not as tags on a profile. The scheduler has to test validity against the date the job is scheduled for, which a tag cannot answer. A credential with no recorded expiry should be treated as unverified rather than assumed valid.

Should familiarity with a manufacturer be a hard requirement?

Only where the manufacturer or a warranty term genuinely requires it, which is a commercial constraint the operator can name. Otherwise it is a preference: an unfamiliar technician is slower, not ineligible. Make it hard and jobs strand in the unassigned queue for a reason nobody can defend when the customer asks why nobody came.

  • dispatch
  • skills
  • eligibility
  • scheduling
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation