AI for scheduling in utilities: Work Orders, Crew Authorisations and the Day the Plan Breaks
At ten past seven the day plan is already wrong. A two person team sits outside a substation waiting on a switching programme the control room cannot run until a generation constraint clears. A jointer has driven forty minutes to a service alteration and found nobody home and the meter box locked. A fault has come in, and the nearest crew holding the right authorisation is halfway through a pole change that will now not finish today.
None of that is a failure of scheduling software. The schedule published last night was a set of reasonable promises made against a network, a workforce and a set of third parties, all of which moved overnight.
The work does not arrive as work orders
Four streams feed the same finite pool of qualified people, each with its own cadence and its own idea of urgency. Outage management produces fault work, raised by customer calls, protection operations and last gasp messages from metering, prioritised by customers off supply and by a restoration clock. Asset inspection programmes produce cyclical volume, overhead line inspections, pressure regulator checks, hydrant surveys, plus the defects they raise, each with a remedial window set by severity. Planned maintenance comes out of asset policy and condition data, and most of it needs a network outage to execute. Customer requested work covers new connections, service alterations, meter exchanges and third party damage.
It arrives as incidents in the outage system, work orders in the asset system, an email from a local authority, a spreadsheet, a call from a site manager. Before any of it can be scheduled it has to become the same comparable object: what work, on which asset, needing which authorisations and crew composition, for how long, in what network state, with what access, inside which date window, against which clock. That normalisation is the first honest job for an agent.
A crew is not a resource unit
Competency is a hard constraint and finer grained than most scheduling data models admit. A person authorised to operate at one voltage is not automatically authorised at the next one up. Gas operative competence is held by category and pressure tier, by mains or services. Add confined space entry, water hygiene certification for potable work, street works accreditation for whoever supervises the excavation, and first aid cover.
Certificates expire, medicals expire, and agency labour arrives with paperwork that has to be verified rather than assumed. Some tasks need a crew composition held at the same moment, one person to work and another competent to rescue, so a single absence does not slow the job, it cancels it. Treat any of that as a preference and the plan looks better and cannot be executed.
Keeping that picture true is real agent work: reconciling training records, authorisation registers, medical review dates and subcontractor documentation, then flagging every expiry landing inside the planning horizon while there is time to book the reassessment.
The network has to be in the right state first
A job on a circuit usually needs an outage. The outage needs a switching and isolation programme, and that programme needs approval and a sanctioned window agreed with control that depends on demand, generation, weather and whatever else is booked against that circuit. So jobs get bundled into one outage, which makes every job in the bundle dependent on every other. One slip and the outage is wasted and requeues weeks out.
Then there is access, a set of calendars owned by other people. Wayleave notice periods. A farmer who will not have vehicles on that field during lambing or harvest. A street works permit with fixed dates and a charge for overrunning them. An agent is well suited to chasing these and raising the alarm when a permit date and a crew date have drifted apart, which nobody notices until the morning of.
Plant belongs in the same picture and rarely is. An excavator, a jointing van or an elevated work platform with a current inspection certificate and a licensed driver is booked in a different system from labour at most utilities, which is why crews arrive at digs with no machine.
The customer end of the appointment
Some jobs are a network task and some are an appointment with a household, and the second kind carries obligations the first does not. A window has been promised, and in many markets a missed one carries a guaranteed standard and a compensation payment. Customers on a priority services register may have a medical dependency on supply, need longer notice, an interpreter, or contact through a relative.
Those commitments have to survive rescheduling, and that is where they fail. The original appointment respects the flag because the booking process checked it. The replacement, made by a dispatcher at four in the afternoon, does not. Any agent touching rebooking must carry the customer's constraints into the new slot as a gate, not a note.
Regulatory response clocks sit above all of it: gas escape attendance targets, supply interruption limits, restoration obligations. A scheduler who cannot see which jobs run against a clock will trade one away to save three.
Weather, storm mode and the way back
Weather does two things at once. It changes what work is permitted, since wind above a threshold stops work at height and ground conditions rule out certain jointing and pressure activity. And it changes how much work exists. When a storm lands the plan inverts: planned work is stood down, crews are reassigned to restoration, and mutual aid arrives from another region needing briefing, mapping and an authorisation check.
The underrated part is the way back. Hundreds of stood down jobs, each with its own permit, outage dependency and appointment, all needing rebooking in order against constraints that shifted while nobody was watching. Reconstructing what was cancelled, what each customer was told, which permits lapsed and which outages must be re-requested, then proposing a re-entry sequence, is slow clerical work and entirely tractable.
Where the optimiser ends and the agent begins
An optimiser answers a well posed question: given jobs with durations, locations, time windows and skill requirements, and crews with shifts and start points, produce an assignment that respects the constraints and minimises travel. Good solvers exist. Keep yours.
The trouble is that the question is almost never well posed. Durations come from a task library that knows nothing about this site. An access restriction sits in an email. A permit status was never updated. A competency lapsed last week. Plant is booked out in a system the scheduler cannot see.
So an agent belongs upstream and downstream of the optimiser rather than in place of it. Upstream it assembles a schedulable job: reading the incident, the defect, the survey notes and the correspondence, resolving the asset reference, deriving the authorisation and crew composition required, finding the access clause in the wayleave, checking permit and outage status, and estimating duration from your own completion history rather than the book figure.
Downstream it handles the exceptions: deciding what moves, telling affected customers, renegotiating access, rebooking inside the customer's recorded needs, and writing all of it back into the work management system and the mobile workforce app. That last step is underestimated. A rescheduling decision that never reaches the crew's device is not a decision, it is a rumour.
Write the commit boundary down before go live. An agent may propose assignments, book inside published windows where every constraint is satisfied, send confirmations from approved templates and write status back. Without a named person it may not alter network state, vary a switching decision, relax an authorisation requirement, dispatch to a job whose safety documentation is incomplete, or move a job on a regulatory clock.
The day-of reality
Jobs run over. The excavation hits an unrecorded service, the joint fails a pressure test, the fault is not where the indication said. Watching live status against planned duration lets the knock-on be modelled at eleven in the morning rather than discovered when the crew rings in at four.
There is no access at site. Nobody home, gate locked, a vehicle over the chamber, a landowner who has changed his mind. The travel is already spent, so the value sits in the next hour: reach the customer while the crew is still there, offer a slot that honours their original constraints, and find nearby work to fill the gap.
An emergency callout lands. A reported gas escape pulls the nearest qualified crew off whatever they were doing. That reassignment is correct and it wrecks the rest of their day. The useful work is what a dispatcher has no time for: identifying every displaced job, telling every affected customer before they ring in, and rechecking standby cover.
Where AI fails here
It cannot create capacity. If you are short of authorised jointers, better scheduling shows that shortage in sharper detail and does not fix it. Nor can it negotiate with a landowner who has decided today is not the day, or make a permit authority answer the phone.
Asset and network model quality is the ceiling on everything. Wrong locations, wrong connectivity, unrecorded services and duplicate asset records produce plans that are fluent, specific and wrong.
Duration prediction is genuinely hard and heavy tailed, fault work most of all, where diagnosis dominates and is not predictable from the incident record. An estimate good on average is badly wrong on the job that ruins the day.
Safety judgement is not a scheduling input. Whether conditions at a site allow work belongs to the competent person standing there, and a tight plan quietly argues for pressing on.
Then the failure that reads like success: a message citing a slot already promised elsewhere, written confidently because the booking moved after the draft was composed. Bind every time in a customer message to a value read at the moment of sending.
Where to start
Begin with intake enrichment. It is high volume, checkable against what a planner would have done, and it reaches no customer. Follow with no access recovery and appointment rebooking, both pure exception handling with a verifiable right answer. Leave outage bundling, storm re-entry planning and any form of dispatch authority until the first two have been trusted through a bad week. Measure jobs completed on first visit, appointments kept and clocks met, not jobs scheduled.
If your plan is assembled from an asset system, an outage system, a permit inbox and a spreadsheet everyone quietly trusts more than the software, describe it to Adopt AI Partners and we will say plainly which parts an agent should carry and which it should not.