The screen in the meeting room drew blue lines across the city with an alluring neatness. Each vehicle left at a set time, each visit appeared to take a predictable length, and the final stop of the day lay only minutes from the depot. The manager announced that an automatic scheduler would begin proposing routes for the maintenance team in six weeks. Then he asked for questions. Lucía looked at her colleagues. None of them knew whether the program knew about the lift that fails every Thursday, the key that opens only from the inside, or the shop whose owner is available before eight because he works shifts. To the team, these were not anecdotes. They were part of the infrastructure that kept requests resolved. In the meeting, however, they arrived as private memories rather than knowledge needed to design the change.
Automating a schedule is not simply buying a system and learning its controls. It changes who decides the order of work, what time appears available, and whose experience counts when reality departs from the map. A fair transition starts before the deployment date because the important question is not only how many minutes a route will save. It is which forms of knowledge are left out, who will carry the exceptions, and what power staff retain to alter a pilot that causes harm. Treating skilled work as residue that the tool will replace creates a double loss: it devalues the people who sustain the service and makes the system meant to improve it more brittle.
A route contains more than coordinates#
A maintenance route can look like a sequence of addresses, distances, and time slots. In practice it holds signals accumulated over years. The technician who visits a day centre knows that a noisy repair cannot happen during the afternoon rest period. The worker checking water pumps recognises from a brief sound that a different part is needed from the one written on the request. Someone who has covered an area for years has learned that a report described as minor can quickly become a safety problem. This knowledge is not always in a manual because it was formed by observing, asking, making mistakes, and coordinating with people who use those places.
A maintenance route can look like a sequence of addresses, distances, and time slots.
Build a map without extracting knowledge for free#
Before starting the pilot, the service can create a paid map of operational knowledge. This is not a hurried survey designed to feed a vendor, nor a session in which people are asked to hand over everything they know without recognition. It is paid working time, in small groups with facilitation, to describe the circumstances that alter a route, the signs that need human checking, and the agreements with users that should not be broken. The map can record critical routes, access dependencies, safety risks, reasonable buffers, possible substitutions, and questions the system cannot yet answer.
Payment matters because it says something exact about ownership of the process. Skilled knowledge was built while people solved a real service; it is not an extra kindness that can be demanded after a reorganisation has been announced. Paying to document it also allows people without a visible title, or without confidence in a large meeting, to participate. There can be peer interviews, accompanied journeys, shift notes, and tests of exceptional situations. Findings should return to the people who supplied them so they can correct them. Otherwise the map turns experience into extraction and feeds the distrust later described as resistance to change.
A labour table with power to change the design#
Listening before deciding means little if contributions end in a folder with no effect. The design table needs worker representatives chosen by staff, coordinators, safety leads, people who deal with users, and someone able to explain technical limits. Its mandate should be written down: it can alter pilot rules, remove categories of data, require more time for a visit, define suspension conditions, and ask for further testing. If it can only make recommendations, participation comes too late even when it begins before deployment.
That table should address specific situations. Can someone depart from a proposed route when they spot a risk? How is that decision recorded without turning it into a disciplinary mark? Who responds when two apparently short requests coincide and automated priority harms a vulnerable person? What location information is truly needed for coordination, and what would become surveillance? Answering these questions before the first day keeps workers from having to improvise obedience or disobedience in front of an instruction on a screen. It also separates legitimate coordination from disguised individual performance assessment.
A pilot is a reversible test#
The safest way to introduce the scheduler is through a bounded, reversible pilot. It might begin in one area, with a small number of routes and human planning still available as a reference. Reversible means there is an institutional mechanism to stop it, return to the earlier practice, or change its rules without punishing anyone who reports a problem. It does not mean every difficulty defeats the idea. It means the experiment admits that it does not yet know all its effects. The evaluation date, accountable person, and pause conditions should be agreed before the system is switched on.
The pilot should compare more than speed. Journey time, first-time fixes, delays, and fuel use matter, but so do visits needing a second call, safety incidents, unplanned time, coordination burden, and the quality of relationships with the places served. Lucía may show that a route which looked slower prevented a care home from losing water over a weekend. That outcome does not fit a kilometres metric, but it matters more than a tidy line on a map. The labour table must be able to read such effects and decide whether the program should learn, be limited, or be withdrawn.
Agree the transition without hiding the burden#
A fair transition states what will happen to roles, shifts, training, and responsibility before the tool reorganises work. It is not honest to present the scheduler as support and later use its records to accelerate targets, shrink teams, or punish a person who corrects a suggestion. An agreement can explicitly prohibit pilot data from being used for individual disciplinary performance action. It can also establish that the hours spent reviewing routes, documenting exceptions, and training colleagues count as work, rather than as invisible tasks added after the shift.
Training cannot be reduced to pressing buttons either. People need to understand what information the system uses, when a recommendation is weak, how to flag an error, and what rights they have when a tool contributes to a decision. Managers, in turn, need to learn not to treat the dashboard as the only account of what happened. When a technician changes a route, the first question should not be why they failed to obey. It should be what service condition made the proposal inadequate. That question restores value to skill and generates better material for the next cycle.
Maintain the knowledge infrastructure#
There is an important difference between capturing experience and building knowledge infrastructure. Capturing it means copying comments into a system once and declaring the project complete. Building it means maintaining a living record, with owners, reviews, and a way to remove information that is no longer useful. A building gets a new caretaker, an access arrangement changes, or a family no longer needs a particular time slot. If nobody can update those facts, the tool will begin scheduling routes across an imaginary city and the team will correct it at the cost of its own time.
The scheduler’s budget should therefore include update hours, safe channels for alerts, and regular space to examine patterns. If certain exceptions arise every week, they may not be exceptions at all. They may reveal a poorly designed rule, an insufficient resource, or a need unnamed by the work list. Recognising that signal protects people and improves the operation. Ignoring it because it spoils a compliance rate merely moves the harm beyond the screen.
Begin with a question that opens choices#
The next meeting does not need to choose between accepting automation and defending an old route out of nostalgia. It can begin with a more useful question: what makes this service work when the plan is wrong? The answer will identify knowledge that should be mapped and paid for, people who need effective voice, and limits the pilot must respect. Only then can the service decide which parts of planning a tool can take on without impoverishing work or worsening care.
For Lucía, a fair transition will be visible in checkable acts. She will have time to explain why a visit does not last as long as the history says; she can amend a suggestion without fear of penalty; she can see her contribution change a rule; and she knows the experiment can stop if risks outweigh benefits. The scheduler then ceases to arrive as a finished order and becomes a tool under agreed conditions. Skilled knowledge is not left behind by automation. It is the ground on which any reliable route must stand.
