If dispatchers override the optimizer, the policy is wrong.

A work rule is a hard filter. It rejects any service resource that violates it, and rules are always applied before objectives — they produce the list of candidates who are allowed to take the job. A service objective is a weighted score applied only to the candidates that survived the rules, and it decides which of them is chosen. The practical difference is diagnostic: if an appointment will not schedule at all, look at your work rules; if it schedules to the wrong person, look at your objective weightings.

Fewer than most orgs end up with. A policy per genuinely different scheduling behaviour is right — typically one for routine planned work, one for emergency or SLA-driven work where speed outranks travel, and sometimes one for installations or multi-day jobs. A policy per work type, per region and per customer tier is how orgs end up with twenty policies nobody can reason about. If two policies differ only in one objective weighting, they usually should have been one.

A work rule rejected every candidate. The usual causes are an over-strict skill requirement where a skill level is set higher than anyone actually holds, a territory with no members available in the appointment window, an operating hours or absence configuration that removes the people you expected, or a required resource preference that only one person satisfies and they are already booked. The fix is almost always to relax the constraint — often by converting a hard skill requirement into a preference so it becomes an objective rather than a filter.

Global optimization belongs outside working hours, typically overnight, scoped per territory — running it mid-morning rearranges days that technicians have already started, which destroys trust faster than a bad schedule does. In-day optimization is what handles disruption during the working day, and it should be constrained so it only moves work that has not been started. Resource schedule optimization is the narrowest and is useful both for a single disrupted technician and as a safe way to test a policy change before applying it broadly.

Yes. Service crews let you schedule a group of resources as a unit with defined roles, and multi-day work can be modelled so a single job spans several appointments across days. Both need deliberate design rather than default configuration — crew membership has to be maintained as people move, and multi-day work needs rules about whether the same crew must return. Orgs that skip this design usually end up scheduling installations manually outside the system, which then distorts every utilization and capacity report they produce.

Substantially less than an implementation, because the platform is already live and the work is configuration rather than build. The audit and override analysis need enough historical scheduling data to see real patterns, so the constraint is usually how much clean data exists rather than consultant time. Tuning then runs as cycles — change, simulate, roll out to one territory, measure — and it is deliberately iterative, because a policy that is reweighted once and never re-examined drifts again as territories, skills and job mix change.