All case studies
IllustrativeField servicesCase study

Planning field work around priority, capacity and evidence

An illustrative planning layer that turns work orders, skills and location constraints into a reviewable daily plan.

Executive brief

This concept supports dispatch teams by assembling a feasible daily plan from operational constraints. It keeps planners in control while reducing the manual effort required to reconcile urgency, skills, geography and customer commitments.

6planning inputsJoined in one decision layer
3priority bandsWith explicit override rules
Dailyplan refreshPlus event-led exceptions
01

Situation

Field-service planning is a continuous trade-off. Urgent jobs compete with promised appointments, travel time, technical skills, parts availability and working-hour constraints. Spreadsheets can represent each factor but struggle to recalculate the full picture when conditions change.

A useful system must explain its recommendation. Dispatchers need to understand why a job moved and what constraint would change the plan.

02

Diagnostic

The planning model separates hard constraints from preferences. Certification, availability and safety rules cannot be traded away. Travel time, route density and customer preference can be optimised within those boundaries.

Historical data is assessed for missing durations, inconsistent priority labels and postcode quality before it influences future planning.

  • Keep hard constraints explicit
  • Show the reason for each recommendation
  • Record planner overrides as learning evidence
03

Solution design

The planning layer receives approved work orders and resource availability, generates feasible options and scores them against service objectives. The dispatcher reviews conflicts and publishes the plan.

During the day, cancellations and urgent work create exceptions. The system proposes the smallest viable change rather than rebuilding every route without explanation.

04

Learning loop

Actual duration, travel and override reasons feed a weekly review. These observations improve planning assumptions while preserving the distinction between recorded facts and model estimates.

Performance is assessed across service level, travel burden, overtime and plan stability. Optimising only one measure would create hidden cost elsewhere.

05

Expected value

The concept aims to reduce planning effort and unnecessary travel while improving the consistency of priority decisions. A controlled pilot would run recommendations beside the existing plan before dispatchers rely on them.

Operating baseline

From current operating friction to a controlled target state

The diagnostic tests the current state using observable work, then describes the controlled operating state the release is intended to create.

Operating areaCurrent conditionEvidence to collectTarget condition
Work-order qualityDuration, priority, location and parts data varyProfile missing and inconsistent fields by job typeValidated schedulable work order
Constraint visibilityRules and planner knowledge live across spreadsheets and experienceObserve assignment decisions and rejected optionsExplicit hard constraints and scored preferences
Plan stabilityChanges can ripple across the day without clear impactMeasure reassignment and customer disruptionMinimum-change response with visible trade-offs
Learning evidenceActuals and overrides are not consistently codedCompare planned and actual work with reasonsWeekly evidence loop for assumptions and policy
Research context

External evidence sharpens the engagement hypothesis

Findings are paraphrased from the linked original publications. Their scope and populations differ, so they inform the thesis rather than prove a universal outcome.

Lifecycle

NIST risk guidance expects measurement and management throughout operation

Overrides, actual durations and plan failures should feed a continuing review rather than a one-off model assessment.

Source: NIST AI Risk Management Framework
21%

Only a minority of AI-using UK businesses report integration into existing systems

Planning value depends on validated work orders, resource records and dispatch workflow integration, not a standalone recommendation screen.

Source: UK Business Data Survey 2026
Delivery work packages

The engagement is organised around four evidence-producing work packages

Each work package ends with an explicit decision and a tangible output. The sequence keeps delivery connected to operating evidence.

01

Data and constraint diagnostic

Decision
Is available work and resource data schedulable?
Work
Profile jobs, skills, parts, locations, durations and rule sources.
Output
Data readiness and constraint catalogue.
02

Feasible-option engine

Decision
Which assignments satisfy every hard rule?
Work
Encode constraints, validate inputs and explain infeasibility.
Output
Tested feasible plan generator.
03

Balanced planning score

Decision
How should feasible plans trade service, travel, priority and stability?
Work
Agree weights, show trade-offs and preserve dispatcher authority.
Output
Explainable recommendation workspace.
04

Shadow and controlled release

Decision
Does recommendation evidence outperform current planning safely?
Work
Run beside live planning, record overrides and review actuals.
Output
Release decision and calibrated improvement backlog.
Decision architecture

Each operational decision has evidence, control and a measure

DecisionRequired evidenceControlPerformance measure
Is the job schedulable?Scope, location, duration, parts and eligibilityHard constraint validationFailed assignments
Which option is preferred?Service level, priority, travel and stabilityVisible balanced scorePlan objective performance
Should the plan change?New event and impact on committed workMinimum-change policyIn-day plan churn
What should the model learn?Actuals and coded override reasonWeekly operational reviewAssumption error by category
Delivery and operating risk

Risks are designed into the operating model before launch

Risks become manageable when the early signal, control and accountable owner are agreed before release.

RiskEarly signalPrimary controlAccountable owner
Bad duration data creates apparently feasible plansJobs repeatedly overrun by categoryData confidence and buffered assumptionOperations analyst
Optimisation hides an unacceptable trade-offTravel improves while service or stability declinesBalanced scorecard and visible weightsService owner
Frequent replanning disrupts customers and staffIn-day movement exceeds agreed thresholdMinimum-change policy and commitment lockDispatch lead
Planner overrides disappear from learningSystem repeats rejected recommendationsRequired reason code and weekly reviewPlanning owner
Measurement system

Acceptance links the release to observable operating performance

Measures are useful only when their definition is stable and their movement changes a management decision.

OutcomeDefinitionLeading evidenceDecision supported
Feasible assignmentsPublished jobs satisfy skill, availability, safety and parts rulesFailed assignment checksCorrect data or constraint
Balanced plan performanceService, travel, overtime and stability within agreed boundsTrade-off movement by measureChange weight or business policy
Explainable recommendationDispatcher can identify the reason and alternative for each moveUnexplained rejection rateImprove rationale or interface
Improving assumptionsPlanned duration and travel error reduce by categoryOverride and actual captureRecalibrate or exclude weak data
Exhibit 1

A balanced score prevents one objective from dominating

Illustrative decision weight in a daily planning model.

Safety and eligibilityGate
Customer service level30%
Operational priority28%
Travel efficiency24%
Plan stability18%
Source: Quiet Gears illustrative planning model. Weights would be calibrated with operational data.
Exhibit 2

Delivery follows a controlled progression from evidence to operation

01Prepare

Validate work orders, capacity and mandatory constraints.

02Optimise

Generate feasible options against balanced objectives.

03Review

Explain conflicts and capture dispatcher judgement.

04Learn

Compare plan assumptions with completed work.

System blueprint

The optimiser proposes, while dispatch retains authority

01inputs = validate(jobs, people, parts)02feasible = constraints.solve(inputs)03ranked = objectives.score(feasible)04plan = dispatcher.review(ranked.first)05learning.record(plan, actuals, overrides)
01Work orders
02Constraint solver
03Option scoring
04Dispatcher console
05Performance store
Recommended next steps

Move from design to evidence in a bounded release.

  1. Clean six weeks of representative work-order data
  2. Agree hard constraints and balanced measures
  3. Run shadow planning against live operations
  4. Review overrides before enabling recommendations

Where is friction
holding you back?

Talk it through with us