In many fleets, maintenance lives as a flat list: change the oil, inspect the brakes, check the lights. That list works as long as the team is small and everyone remembers the same things. It stops working as soon as the fleet grows or diversifies, because a flat list does not distinguish between what is decided once, what is coordinated with the workshop and what the technician actually does. Those are three different things and they need three different levels.
That three-level structure is the Maintenance Plan, Service and Task hierarchy, and it lives in the Maintenance module. This guide explains what each level solves, where most implementations go wrong and in what order to build it.
Without a hierarchy, each intervention exists on its own and without context, and that produces four effects that show up in operations before they show up in reports.
The first is duplication. The same intervention is defined again for each vehicle, with slightly different wording, and it ends up being impossible to tell whether two records describe the same job.
The second is lost efficiency in the workshop. If nobody defined what should be done together, the vehicle comes in for one intervention, leaves, and comes back two weeks later for another that could have been handled in the same stop. Every extra visit is downtime that could have been avoided, a problem we cover in how to reduce downtime.
The third is that cost analysis loses its unit of comparison. Without a stable grouping, there is nothing to compare spending against.
The fourth is more subtle: technical knowledge stays in the head of whoever coordinates, and when that person is absent, the fleet improvises.
The Plan is the governance level. It defines the complete scheduled maintenance strategy for a model throughout its service life: what is done, how often and how far the scope of scheduled work extends.
It is the level where decisions are made that should not be debated every week. The base interval, the adjustment for operating severity, what falls within planned maintenance and what is handled as corrective work when it comes up. Those definitions are made once, with technical criteria, and then executed without reopening them case by case.
The Plan is designed by model, not by vehicle, because the intervals depend on the model’s mechanics and operating conditions, not on the license plate. That criterion is fully developed in maintenance plans by model.
A poorly defined Plan is not noticed right away. It is noticed months later, when the fleet piles up correctives for things the plan should have anticipated.
The Service is the coordination level, and it is the one with the greatest impact on daily operations. It groups the interventions that are best performed together in a single workshop visit.
The key words are “best performed”. The grouping criterion is not mechanical but operational: what can be done during the same downtime, with the same work crew, in a reasonable time window. A service at a given mileage groups the oil change, brake inspection and fluid level check because all of that fits in one stop. An annual safety service groups what follows calendar logic.
In practice, the Service is the unit to think in when dealing with the workshop. When work reaches the workshop as a coherent package instead of as loose tasks, the quote is more comparable, the estimated time is more realistic and there is less back-and-forth.
That is why designing Services is not an administrative chore: it is the decision that determines how many times a year each vehicle will be out of service.
The Task is the execution level: what the technician actually does. Oil and filter change, tire rotation, brake system inspection, light check.
The value of this level lies in repeatability. A well-described Task ensures the work is done the same way the first time and the twentieth, regardless of who does it or whether it is handled in an in-house workshop, through self-managed maintenance, or at an external workshop.
Tasks are also the most reusable piece of the scheme. The same Task appears in several Services of the same Plan and often also in Plans for different models. Defining them once and referencing them is what keeps the fleet from ending up with eight versions of “light check” that are actually the same thing.
Each level answers a question the others cannot. The Plan answers what strategy this model follows. The Service answers how the work is organized over time and in the workshop. The Task answers what exactly is done.
When the three levels are mixed, none of the three questions gets a good answer. A flat list forces the coordinator to answer all three at once, every time, from memory. With the levels separated, each one can be adjusted without touching the others: you change the grouping of a Service without rewriting the Tasks, or you adjust a Plan interval without reorganizing the workshop.
That independence is what allows the scheme to evolve. A plan that can only be changed by rebuilding it from scratch, in practice, never gets changed.
Almost all the problems with these hierarchies are granularity problems, not conceptual ones.
Services that are too large. A Service that bundles twenty-five interventions keeps the vehicle out of service too long and is hard to coordinate. If the workshop never completes it in one go, the Service is poorly sized.
Tasks that are too granular. Describing every mechanical step turns execution into administrative work and nobody completes it. The Task should go as far as a competent technician needs instruction, and no further.
Duplicated Tasks without criteria. The same intervention defined several times under different names. It is the mistake that clutters the history the most, because it hides the fact that something is recurring.
Services defined by manual logic rather than workshop logic. The manual groups by mechanical system; operations group by downtime. When the Service copies the manual’s logic, the vehicle goes into the workshop more often than necessary.
A plan without an explicit grouping criterion. If nobody can explain why those Tasks are together, the grouping falls apart on its own in practice.
The order matters more than it seems, and the intuitive sequence is the wrong one. Almost everyone starts with the Plan, because it is the most abstract level and the easiest to discuss in a meeting. Then they move down to Services, then to Tasks, and halfway through they discover that the real Tasks do not fit into the Services they already defined.
The sequence that works starts at the bottom, with the inventory. Before defining anything, review which interventions are actually being performed in the fleet, looking at the work history and not just the manufacturer’s manual. That list, cleaned of duplicates, is the real catalog of Tasks.
With the Tasks defined, group them by operational criteria: what fits into a single workshop stop, with what reasonable total duration. That is the Services layer, and it is worth validating it with whoever coordinates the workshop before entering it, because it is the one that will collide with reality.
Only at the end do you assemble the Plan, assigning each Service its trigger, which can be mileage, time or whichever comes first depending on the component. That criterion is developed in mileage-based or time-based maintenance.
Two warnings. It is best to start with the model that has the most units rather than the most complex one, because it leaves better criteria for the rest. And the Task catalog should be reviewed after the first few months: the corrective history shows what should be in the preventive plan and is not. That loop between what fails and what is prevented is the difference between a living preventive plan and a decorative one.
