Maintenance plan: due date lives on the device
A maintenance deadline is a field on the device, not a row in a spreadsheet. Time-triggered rules check every five minutes and notify the responsible person.
The maintenance schedule lives in an Excel file. One column for the device, one for the last service, one for the next due date. Whether it is the heating system in a managed apartment, the van at the car rental, the machine in the workshop, or the device at the care service: someone enters it when they think of it. The calendar reminds of some things, of others no one. If the heating fails in December or the van is due for its regular inspection, the appointment is missing exactly when you need it.
The due date does not have to live in a table. It can sit on the device itself, as its own field. And the platform can check on its own whether a due date has been reached and notify the person responsible for the device. That is the difference between a list someone has to look at and a due date that reports itself.
Why no Excel template
To be honest, a spreadsheet does something. It collects all devices in one place. It can be sorted and filtered. A formula calculates the next date from an interval. As long as one person maintains the file and everyone else trusts that it is current, it works. For a trade business with a few machines or a property management company with a manageable number of devices, it is a workable way.
The spreadsheet ends where the ongoing work begins:
- No one is notified by the spreadsheet. An overdue row stays overdue until someone looks at it.
- Responsibility stands as a name in a cell, not as a reference. If someone resigns, the old name stays, and the due date runs into the void.
- The next due date only comes into being through manual entry. Anyone who forgets to enter it extends the deadline without noticing.
- Formulas collapse when someone inserts or deletes a row. You only notice at the wrong date.
This is no accusation against Excel. This is the limit of a tool built for accounting, not for ongoing operations.
The due date as a field on the device
In Telesherpa, every device, every machine, every vehicle is an object. "Last service" and "next service" are date fields on that object. They are their own field types, not cells in a row. The due date thus belongs to what makes the device, not to a row that merely mentions the device.
On top of that come calculated display fields. Such a field forms its value from other fields and is only displayed, never typed in. What it should display results from the existing fields. No one has to maintain a due date twice, and there is no second number that drifts apart.
The platform checks on its own
Rules run in three modes: when an object is created, when a field changes, and time-triggered. All three modes are already in operation today. For the maintenance schedule, the time-triggered mode is what counts. It is processed every five minutes. Event-driven rules, for example after a change, run on a one-minute cycle.
The conditions of a rule compare fields: equal or not equal, in a list, greater or smaller, empty or not empty, against a pattern. They can also require that a specific field has changed.
The effect that carries the maintenance schedule is the notification. One concrete sequence: a rule checks on every run whether the due date has been reached and whether the field "Maintenance done" is still empty. Both are the case, so the rule notifies. The message appears in the platform, on request additionally as mail and as push. The recipient is the person entered as responsible on the object.
Two things about this, without sugar-coating. First: if there is no responsible person on the object, no one is notified. The rule then only carries out its remaining work. Entering the responsible person is therefore not a formality. It is the condition for anyone at all to learn that a due date has passed. Second: a time-triggered rule needs a condition that becomes false after it fires. Otherwise it reports again on every run. The field "Maintenance done" solves that: as soon as it is filled in, the rule goes quiet. That is a rule for the design, not a limitation of the platform.
The automation costs no credits. Credits only arise when a user triggers an action. And rules only affect objects in your own area. That is the access control, because the timer runs without a login.
Where the limit lies today
What works today: due dates as fields on the device, calculated displays, a time-triggered check on a five-minute cycle, notifications in the platform as well as by mail and push to the responsible person.
What the next step is: a rule that automatically creates an order from the due date. The effect of creating an object exists in the platform, but is not yet proven in operation. Today you still create the order yourself as soon as the notification arrives. Also planned as a next step: a due-date overview as a report across all devices in an area, so you can see at a glance what is due when, instead of clicking through every device individually.
One further limit this article deliberately does not name: the due date itself. Which maintenance interval applies to a specific device follows the manufacturer's specification and the relevant regulation. The platform checks what you enter. Which interval applies, you decide.
What to do next
Note down the devices, machines and vehicles that need recurring maintenance. Create an object for each, with the fields "last service" and "next service". Enter the responsible person. Set up a time-triggered rule that checks whether the next service is due and whether the service has been done. After each service, fill in the field "Maintenance done".
From then on, the system reports when a due date is reached, and the responsible person learns it in the platform. It is not chance that decides when someone looks into a table, but the due date itself.