Choosing Resource Scheduling Optimization or manual dispatch

What it does

Resource Scheduling Optimization is a paid add-in that batch-schedules requirements to resources on a timer, weighing travel time, utilisation, priority and promise windows against goals you define. The alternative is what most organisations already do: a dispatcher on the schedule board, using the schedule assistant to shortlist resources and dragging bookings by hand. This doc is about which one you commit to in a given implementation, and it's rarely as binary as the sales deck suggests.

Key facts

RSO is a separate paid add-in, priced on the number of resources whose schedules get optimised — not on job volume, not per dispatcher.
It runs against URS tables, so it optimises requirements and bookings, not work orders directly. A work order only enters scope if its requirement does.
A resource is only considered if Optimize Schedule is set on the Resource Scheduling Optimization tab of the Bookable Resource record, and it has work hours defined.
A requirement is only considered if the source work order's Scheduling Method is set to Optimize. That field is the on/off switch per job, and it's the cheapest way to run RSO and manual dispatch side by side.
The moving parts are optimisation scopes (resources and requirements, filtered by views, with a Range Offset and Range Duration), goals (ranked objectives and constraints), and schedules (when a run fires).
Addresses must be geocoded to latitude and longitude. Un-geocoded addresses are effectively invisible to the engine.
Documented run patterns: overnight batch, intraday runs on a roughly half-hourly cadence, emergency handling, single-resource optimisation across days, and simulations that produce results without committing bookings.
SLA dates need mapping to Time From Promised and Time To Promised on the work order — those feed the requirement's start and end and are what the engine treats as the window.
Location-agnostic resources can only take bookings where the requirement is also location-agnostic. RSO treats them as remote workers with no travel.

When to use / skip

RSO earns its money when the routing problem is genuinely hard and the dispatcher is losing. Look for dozens of technicians per territory, high volume of short jobs, real travel between customer sites, and a dispatcher who is visibly the bottleneck. Microsoft is straightforward that RSO is built for onsite work where resources move between customer locations — the case where minimising travel is worth something and no human can hold the board in their head.

Skip it, or defer it, when any of these are true. Small crews — under about a dozen technicians on a board — because a good dispatcher beats the engine and knows things the data doesn't. Work that is mostly remote or desk-based, where there's no travel to save. Long jobs, where each technician does one or two things a day and the routing problem collapses. And anywhere the real constraint is a relationship — named engineer for a key account, the technician the site will let through the gate. You can model some of that with characteristics and resource preferences, but every rule narrows the search space and the results get worse, not better.

The pattern I'd actually recommend on most implementations: go live on manual dispatch, get the data right, and introduce RSO in a later phase with Scheduling Method set to Optimize on one work order type or one territory. That way you're comparing the engine against a working baseline rather than against nothing, and you can point at travel-time numbers when someone asks whether the add-in was worth it.

Configuration decisions

Decide the unit of rollout: territory, work order type, or resource group. Whatever you pick becomes the scope filter and the thing you report against.
Define measurable success criteria before configuring anything — travel time down a stated percentage, no overtime on planned maintenance, SLA compliance above a threshold — and confirm the org can actually produce those numbers.
Rank the goals honestly. Minimise travel, maximise usage, honour priority and schedule as soon as possible pull against each other, and the ranking is a business decision, not a technical one.
Set Range Offset and Range Duration deliberately. A wide range gives better routes and more churn to already-committed bookings; a narrow range protects the near term and gives worse optimisation.
Decide how locked bookings are handled — what the dispatcher pins by hand and what the engine may move overnight. Agree this before the first live run.
Choose whether emergency and same-day work runs through an intraday scope or stays manual. Mixed handling of urgent work is where trust in the engine gets lost.

Gotchas

Bad addresses are the most common cause of disappointing results. Geocode the estate before the POC, not after. Resource count also drives cost, so turning on Optimize Schedule across the whole workforce "to see" has a commercial consequence.
Time zones on Bookable Resource records feed work-hours calculation. One resource with the wrong time zone produces routes that look inexplicably wrong.
You can't optimise into the past, so replaying historical data as a "proof" doesn't work cleanly — shifting dates moves weekdays onto weekends and the comparison falls apart. Use fresh test data.
Time off has to be modelled properly or the engine books people who aren't there, and the dispatcher stops trusting it after two occurrences.
RSO moves bookings that dispatchers thought were settled. Without an agreed locking convention, the first overnight run generates complaints rather than savings.
Adding constraints feels like tightening quality but usually degrades results. If every job has three characteristics and a preferred resource, you've built manual dispatch with extra steps.

Consultant notes

Run the proof of concept as simulations first. Reviewing routes and booking details without committing bookings is the safest way to have the goals argument with the client.
Demo the same day's work under two different goal rankings. Nothing lands the trade-off point faster than showing travel-optimised versus priority-optimised side by side.
Tell the client plainly that RSO is a data quality project wearing an algorithm costume. Addresses, work hours, time off, characteristics and territories are the real deliverable.
Push back on "optimise everything from day one". One territory, one work order type, a measured baseline.
Before go-live, agree who owns goals and scopes operationally. With no business owner the config ossifies and results drift.

Worth another look if the add-in pricing model changes, or once the Scheduling Operations Agent work moves out of preview.