The situation
Historical service cards record what was done and when, and imply when the next action falls due. That implication is written for a human reader: an interval in the text, a date in a margin, a reference to a procedure that itself specifies the interval.
No field anywhere holds a due date. So planning depends on somebody reading the cards, and planning therefore happens when somebody has time, which is usually after the date has passed.
Why it is hard
The due date is derived, not recorded
It comes from the last action date plus an interval that may be stated on the card, in the referenced procedure, or in a general instruction that applies to a class of equipment.
Intervals are conditional
An interval can depend on hours, cycles, calendar time or whichever comes first. A scheduler that assumes calendar time quietly misses everything driven by usage.
The cards are not uniform
Decades of cards means several formats, several handwriting conventions, and scanned pages of varying quality in the same stack.
How we approach it
Agentix reads the service cards and the procedures they reference, derives the next due action per item, and captures it as an action item with the card it came from attached. Reminders begin 30 days ahead of the due date so the planning conversation happens before the deadline rather than after it.
Where an interval is conditional on usage, the item records the condition rather than flattening it to a calendar date, and is flagged for the data it needs to resolve.
What changes
- Due dates derived from the cards and the procedures they reference
- Action items carry the source card, so a planner can check the derivation
- Reminders start 30 days out rather than on the day
- Conditional intervals recorded as conditions rather than guessed as dates
Next
Is this your problem too?
Bring the version of it you actually have. We will tell you what it would take, including when the answer is that it is not worth doing.
N Catalyst.ai
Book a demo
