Maintenance Scheduling & Planning

Six maintenance types, one register, one generation engine — that is the operating model behind AssetAI's scheduling module, and it is worth understanding the mechanics before you configure a single schedule.

How the Schedule Engine Decides What to Generate

Every schedule declares a basis — time, meter or condition — and that basis determines whether the engine acts on its own. Time and usage/meter schedules are self-driving: a daily 06:00 job checks every tenant's due schedules and raises work orders automatically, and the "Generate due" button gives planners a manual trigger for the same logic mid-shift. Predictive and condition-based entries, by contrast, never fire on their own — they exist in the register for consistency and reporting, but someone has to convert the signal into a work order.

This matters for how you sequence a rollout:

• Get preventive, calibration, statutory and lubrication schedules into the time or meter basis first, since these are the ones that will actually populate your work order queue without manual intervention.
• Treat predictive/condition entries as a watch-list layer on top, not a replacement for the automated core.
• Remember that lead time is a pull-forward window, not a grace period — a 5-day lead time on a 30-day PM means the work order appears 25 days after the last one closed, not 30.

Editing a schedule's interval or start date only re-anchors the next due date if the schedule has never generated a work order — once it has run, the due-date chain is already live and edits apply going forward, not retroactively. This is a deliberate constraint that keeps historical due dates auditable, which matters for anyone benchmarking their program against ISO maintenance-management guidance or building toward TPM discipline on the floor.

Putting the Week Together on the Planner

The Weekly Planner is intentionally a grid, not a Gantt chart: technicians run down one axis, the seven days run across the other, and every cell shows the open work orders scheduled for that technician on that date. Clicking a cell reassigns technician and date in one action — there is no drag-and-drop layer to manage, which keeps the interface predictable for planners moving between shifts.

Two things sit alongside the grid that make it useful for actual planning conversations, not just a calendar view:

• An unscheduled backlog list, so nothing due gets buried once it drops off the current week.
• PM due-markers for the week, placed beside real jobs so a planner can see at a glance which technician has room to absorb a preventive task versus one already carrying breakdown work.

Filters for due and overdue, each with a live count, sit above the grid so a planner can triage before touching a single cell. None of this checks technician hours against job estimates — capacity levelling is a manual judgment call the planner still makes — but the visibility is enough to plan a realistic week for a plant standardising its CMMS practice for the first time.

Staying Ahead of Slippage

A daily sweep runs independently of the generation job and watches two conditions: PMs overdue beyond a per-company threshold (three days by default) and assets breaching a repeat-failure pattern (three breakdowns in 30 days, by default). Both thresholds are configurable per company, which matters across industries with different duty cycles and risk tolerances. From there, PM compliance — the share of PM work orders completed on or before their scheduled date — becomes the single number planners and plant managers track over time, and it sits alongside the rest of AssetAI's reporting in /features.

A schedule register only earns its keep if it matches how your plant actually works — cramming six maintenance types into one form is useful only if you respect what each basis can and cannot do on its own. That distinction should shape both how you configure AssetAI and what you expect from it once schedules start running.

What Belongs in One Schedule — and What Doesn't

Every AssetAI schedule points at exactly one asset. There is no route or round type that lets a single ticket cover ten lubrication points or a bank of similar machines, and there is no Gantt chart or dependency logic sitting behind the Planner — it is a click-to-place grid, not a project timeline. Knowing this before you design your register saves rework later:

• If your lubrication rounds currently live on a single paper sheet covering many machines, plan on one schedule per asset in AssetAI rather than trying to replicate the round as one entry.
• If you're coming from a spreadsheet with cross-task dependencies ("do B only after A closes"), that logic has to stay a manual judgment call — the engine won't enforce sequencing.
• If you need labour-hours-versus-availability planning, treat the Planner as a placement tool, not a capacity model; it shows who has what, not who has room for more.

None of this is a gap so much as a scope decision — the module is built for plants standardising PM, calibration, statutory inspection and lubrication into one clean register, not for teams that need dependency or crew-levelling logic. If you're unsure which category your rollout falls into, the use-case and industries pages break down how different plant types typically structure their registers.

Numbering, Editing and the Audit Trail

Every schedule and the work orders it spawns carry a sequential number — MNT-000001 by default, with a prefix you can configure per company, unique within that company. That numbering, combined with the fact that generated work orders stay permanently linked back to their parent schedule, is what makes the register defensible when an auditor or ISO assessor asks for evidence of a calibration or statutory inspection history — a concern covered in more depth on the ISO & standards page and in ISO's own standards library.

Two mechanics worth knowing before you edit a live schedule:

• Changing the interval or start date re-anchors the next due date only if that schedule has never generated a work order yet — once it's live, edits don't retroactively shift history.
• Checklist tasks are typed one per line in the form but stored as a JSON array; they land as bullet lines in the generated work order's description, so what your technician sees on the floor matches what was configured months earlier.

This is the same discipline that underpins broader reliability practice — the kind of structured, recurring task discipline described under TPM — applied at the level of a single schedule record rather than a plant-wide program.

Fitting the Module to an Indian Manufacturing Floor

Plants across India's manufacturing base — a sector profiled in ongoing coverage from IBEF — run mixed fleets where calibration deadlines, statutory inspections and everyday lubrication compete for the same technicians' time. A single register with consistent numbering and a lead-time pull-forward mechanism is a deliberate fit for that mix, not a generic add-on. If your current setup still splits these into separate spreadsheets or paper logs, it's worth reading what a CMMS actually does before comparing modules, checking the full feature list, and then booking a walkthrough against your own asset register rather than a generic demo script.