What principle should you use to assign jobs to field technicians?

First rule out the impossible options with hard constraints: qualification and clearance, the customer's time window, the employee's roster, service area and vehicle capacity. Then, among the remaining options, choose by criteria — proximity to the current location, current workload in minutes, job priority. That order works equally well for manual and automated assignment.

Which is better: fixed territories or workload-based allocation?

Fixed territories give you minimal mileage and local knowledge, but cope badly with uneven demand. Workload-based allocation is fair to the team but ignores geography. In practice the two are combined: territory as a preference, workload as a constraint, and the final pick goes to whichever option fits the time windows.

How do you handle urgent jobs that come in during the day?

Agree the rules in advance: up to what hour an urgent job goes into the current day, what share of the shift is kept in reserve, and what gets bumped in a conflict. When one arrives, it goes to the nearest suitable person, and only the unfinished part of the plan is recalculated — not the entire day.

Do you need automation if you only have five technicians?

At that size manual assignment still copes, provided the jobs have no tight time windows and the day doesn't fall apart daily. The signals that it's time to change approach: the morning plan takes more than an hour, staff call the dispatcher about every change, and in the evening nobody can name the reasons for failures from data.

How do you measure whether allocation has improved?

Take four metrics before and after: jobs completed per person per day, share closed on the first visit, share completed within the agreed window, and total mileage per job. You have to record them up front — otherwise there's nothing to compare against and the assessment comes down to the dispatcher's gut feeling.

Assigning jobs to field technicians: how to set it up

Assigning a job to a technician takes a dispatcher a few seconds — and the whole shift pays for it: extra mileage, some people idle while others work overtime, missed deadlines and return visits. Let's look at the data you need to make a considered assignment, the dispatching models that exist in practice, how to turn priorities into rules anyone can follow, and what to do when the day falls apart by eleven in the morning.

Why assignment is the most expensive decision of the day

In field service, delivery and distribution the cost of a bad assignment isn't visible right away. The job went to someone who was free — formally, nothing is wrong. But "free" and "suitable" are two different things: that person may be on the other side of town, without the right tool, or without clearance for the site. You only see the result in the evening, when one crew closed four addresses instead of seven and the other spent half the day driving.

Three key operational metrics are decided at the assignment stage. The first is first-time fix rate: if an engineer arrives without the right qualification or parts, the visit has to be repeated — double the cost for zero revenue. The second is meeting deadlines: the window you promised the customer is either built into the plan or broken. The third is workload balance, because a skew between people hits both your cost base and morale at once — "lucky" and "unlucky" routes quickly become a source of friction inside the team.

Dispatching, then, isn't the mechanical handing out of tasks. It is a daily optimisation problem with constraints. And the more urgent work flows through your day, the more its quality depends on the assignment logic being written down rather than living in one person's head.

The data you can't assign without

Any allocation model works only as well as the input data behind it. Before arguing about algorithms, check that you actually know what you need to know about every job and every person.

For the job you need:

An exact address with coordinates — "5 High Street" with no building or entrance number costs twenty lost minutes on site.
The type of work and the skills it requires — installation, repair, survey and scheduled maintenance need different people and different kit.
The time window and the deadline — the slot agreed with the customer and the contractual due date are two separate constraints.
Planned duration — a standard per work type, not an average "about an hour for everything".
Parts and equipment needed — whatever has to be in the van to close the visit first time.
Priority — emergency, warranty case or routine work.

For the technician you need: skills and certifications, working hours and current workload in minutes, service area and start point, vehicle and capacity, and their actual position through the day. That last item is what turns dispatching from blind planning into managing the situation as it unfolds — without it, the dispatcher rings round the crews just to find out who is closest.

Duration standards deserve a line of their own. If planned times are invented, every workload calculation becomes fiction: the system lays the day out neatly, and reality falls apart by lunchtime.

Five allocation models and when each one fits

In practice you see a handful of stable patterns. They aren't direct competitors — each has its own range of applicability.

Manual assignment. The dispatcher decides who gets the job. Maximum flexibility and room for informal nuance, complete dependence on one person. Works while you have a couple of dozen jobs a day and one dispatcher on duty.
Fixed territories. The city is split into areas, each with an assigned person or crew. Mileage is minimal and staff know the patch and its sites. The weak spot is imbalance: one area is swamped while the next one idles, and you can't shift the load without stepping in by hand.
Round robin and workload-based. The job goes to whoever has the fewest booked minutes in the shift. Fair and transparent for the team, but geography is ignored: equal workload is easily bought with extra kilometres.
By skill and priority. First you filter down to the people who can actually do the work — skills, certification, equipment — and only then pick the nearest or least loaded among them. This one is mandatory wherever complex equipment and site clearances are involved.
Algorithmic optimisation. The whole day is laid out at once, taking geography, time windows, skills and vehicle limits into account, and the visiting order is built together with the assignment. That is a routing problem, and it can't be solved by hand: the combinatorics explode.

A mature process usually blends these. Hard limits act as a filter, skills as an admission test, and geography and workload as the criteria for choosing inside whatever set of options remains.

Turning the dispatcher's judgement into rules

The real risk in manual dispatching isn't that people make mistakes — it's that the logic is written down nowhere. While it lives in someone's head, you can't audit it, hand it over to the next shift or improve it. Formalising it starts by splitting your conditions into three levels.

Hard constraints. Never to be broken: qualification and clearance, the customer's time window, the employee's roster and days off, access zone, payload and volume.
Priorities. What wins in a conflict: an emergency call bumps routine work, a contractual deadline beats convenient geography, a repeat visit to the same customer stays with the same engineer.
Optimisation criteria. What you improve among the acceptable options: total mileage, jobs per person, evenness of minutes, share completed on time.

A useful exercise: write down your last ten contentious assignments and explain each with a single rule. Usually it turns out there are five to seven real rules, and the rest are exceptions — which are also worth saying out loud: "only Smith handles this customer", "the site with a permit goes to whoever holds one".

That rulebook is valuable in itself, even before any automation. It removes half the evening arguments and makes a new dispatcher predictable from day one. And once the rules are written, moving them into a system is a matter of configuration rather than reinventing the process.

Changes during the day: replanning instead of firefighting

The morning plan survives until the first deviation. The customer doesn't answer the door, the work takes twice as long, an emergency call lands, someone falls ill or sits in traffic. The question isn't whether this happens, but how long it takes to rebuild the rest of the day.

What gets you through such moments without ringing everyone up:

Slack in the schedule. Loading a shift to a hundred per cent guarantees failure: any deviation immediately pushes the last addresses past the end of the working day.
A clear cut-off point. Decide in advance up to what hour an urgent job goes into today, and after which it moves to tomorrow with the customer notified.
Live status on the map. The dispatcher sees who is where and what is already done, and gives the urgent job to the nearest suitable person rather than the first one to pick up the phone.
Recalculate the remainder, not the whole plan. Only the unfinished part changes; closed visits stay untouched.
Logged reasons for deviations. No answer, no access to the site, missing parts, previous job overran. A month later that is a ready-made list of what to fix in the process rather than in the people.

Here's a good maturity test: how many minutes does it take to move three jobs from one person to another? If it's more than ten, your process rests on phone calls, and on peak days it will predictably collapse.

Moving from phone and spreadsheet to a system

Make the move gradually. Start by putting the data in order: normalised addresses with coordinates, realistic duration standards, a skills and certifications matrix for your staff, written priority rules. Then record where you stand today — jobs per person per day, mileage, share closed first time and on time. Without that baseline you won't know what changed after automation. Next, launch on part of the flow: one team, one city, two weeks running alongside the usual process.

What changes as a result. Jobs are accepted and allocated in a single screen instead of messages and calls; routes are visible on a live map; the visiting order is calculated by an OR-Tools optimisation engine that respects windows and constraints; the technician works in a mobile web interface with photo reports and checklists, with no app to install; completion is confirmed on the spot, and the customer sees statuses in their own portal. For more on how this is set up for field teams, see Field service management.

You don't have to retype the data either: itlogist exchanges with 1C, AmoCRM, Bitrix24 and Excel, so jobs reach the field from the sources you already use. Rollout takes 7 days, with no long-term contracts, and the product is built for teams of 5 to 100 field staff. In other words, you can test a new allocation scheme on live work rather than on paper — and compare it with your recorded baseline a month later.

Assigning jobs to field technicians: models, rules and common mistakes