If you manage a fleet with several models and define the maintenance plan vehicle by vehicle, the work multiplies without adding precision. Fifteen identical pickups end up with fifteen configurations that should be identical and are not, because each one was entered at a different time and with different criteria. The right unit of design is the model: a plan designed once, with the intervals and interventions that correspond to that model, and then applied to the vehicles that share it.
This guide explains why the model is the right unit, what information the Models Master actually provides, how the plan is structured within the Maintenance module and in what order to build it so you do not have to redo it three months later.
The maintenance plan describes the mechanical behavior of the model, not the history of the vehicle. What gets replaced at certain mileages, what gets checked at certain time intervals, which components have their own cycles: all of that is determined by the model’s engineering and the conditions of use, not by the license plate.
Designing it vehicle by vehicle creates three concrete problems. The first is duplicated work: every new vehicle requires repeating a definition that already exists. The second is silent inconsistency, the most expensive of the three, because the plans end up similar but not identical and compliance reports stop being comparable between units of the same model. The third is that the fleet becomes slow to grow: every addition depends on someone with technical judgment sitting down to build the plan from scratch.
When the plan is designed by model, that technical discussion happens only once, and not under the pressure of registering a unit that is already operating.
It is worth being precise here, because this is a common confusion. The Brands Master and the Models Master are master tables: they organize the fleet and store the model’s technical parameters, such as tank capacity and expected fuel efficiency. That is what allows, for example, the Fuel module to detect an invalid fueling when the volume fueled bears no relation to the vehicle’s tank.
What the Models Master does not contain is the maintenance plan. The Maintenance Plan, Service and Task hierarchy lives in the Maintenance module. The masters are the identification base; the plan is an operational definition built separately on top of that base.
The practical consequence is simple: before designing plans, the fleet has to be properly classified. If the fleet has vehicles entered with vague models, the plan by model has nothing to rest on. The granularity must be enough for two vehicles classified the same way to accept the same plan: if two versions have different engines and therefore different intervals, they are two models. This is covered in brands and models masters.
The plan is not a flat list of interventions. It is organized into three levels within the Maintenance module, and each one answers a different question.
The Maintenance Plan is the container. It defines the complete strategy for the model throughout its useful life: what is done, how often and how far the scope of scheduled maintenance goes.
The Service is the grouping of interventions that are carried out together. A service at a given mileage groups the oil change, the brake inspection and the fluid level check because all of that is handled in the same shop visit. The grouping criterion is not mechanical but operational: you group what makes sense to do during the same downtime.
The Task is the concrete intervention the technician performs. Oil and filter change, tire rotation, brake system check. It is the level where the work is described clearly enough for it to be done the same way the first time and the tenth.
The Plan contains Services and the Service contains Tasks, and the same Task can appear in several Services. How to calibrate each level is covered in the Services and Tasks hierarchy.
Building the model’s plan means making four decisions, and it is best to make them explicitly instead of inheriting them from the manual without discussion.
The first is the starting point. The manufacturer’s plan is the technical reference and the floor for the discussion, but it is designed for an average operation that is probably not yours.
The second is the severity adjustment. Rough terrain, constant dust, very frequent stop-and-go cycles or loads close to the maximum justify shorter intervals than the manual’s. It has a direct impact on cost, so it should be documented and not left to one person’s judgment.
The third is the trigger for each Service: mileage, time, or whichever comes first. It is decided per Service and not for the whole plan, and it is covered in maintenance by mileage or by time.
The fourth is the granularity of the Tasks: how much detail adds value and at what point it only adds administrative burden.
A well-defined plan shows in the Calendar. That is where the fleet’s preventive maintenance items (P) and due dates (V) appear, with a green, yellow or red dot depending on urgency, and with the letter T when a ticket is already open for that obligation. That board is what turns the plan into the day’s work.
There is one point to keep in mind from the start: a mileage-based plan depends on the Meter being up to date. In units with integrated GPS, the mileage is updated from telematics and is what triggers preventive maintenance. In those without it, the reading is entered manually, and there the plan is only as good as the recording discipline: if the meter is only updated when the vehicle goes into the shop, the preventive maintenance will always arrive late. For those units, defining who enters the meter reading, how often and at what point in the operation is part of the plan’s design, not an afterthought.
There are always legitimate exceptions: a vehicle assigned to an operation much more demanding than the rest of its model may need shorter intervals. The rule of thumb is that the exception has to remain an exception. If half the vehicles of a model require the same adjustment, the model’s plan is poorly calibrated or they are actually two different models.
There are also situations where operations take precedence over the plan, such as a vehicle that cannot go into the shop because it is covering a demand peak. For those cases there is the option to force the control, a deliberate manual override. When forcing the control stops being exceptional, the problem lies in shop capacity, not in the plan.
The most common mistake is not technical but one of sequence: starting with the Services before the fleet is properly classified. Whoever does it that way ends up redoing everything upon discovering that three different models had been entered as the same one.
The order that works starts with the masters. First you close out Brands and Models, with enough granularity for each model to accept a single plan, and you enter the technical parameters. Only then do you review which interventions are actually being carried out in the fleet, which almost never fully matches the manual, and that gives you the real inventory of Tasks.
With that inventory you build the Tasks, the most reusable piece of the scheme. Then you group them into Services according to the operational criterion of shop visits, and only at the end do you assemble the Plan with the triggers for each Service.
One decision is worth anticipating rather than leaving for the end: how far the plan’s scope goes when part of the maintenance is handled in-house, in your own shop, and part with external shops, because the workload is distributed differently in each case.
