Maintenance management software holds what a factory does to keep its machines running. It covers preventive maintenance schedules and completion, breakdown logs with causes and repair time, downtime reasons captured at the machine, spares consumption and stock, critical spares identified by consequence rather than usage, contractor and AMC records, and the maintenance history of each machine. Pentoggle is an AI platform that generates production-ready software from a plain English description, which means a factory can build maintenance around its own equipment and shift reality instead of adapting to a system built for a large plant with a dedicated engineering department.
Most manufacturers in India already run Tally for accounting, some run Busy or Marg, and larger businesses may run SAP Business One. Those systems handle purchase, sales, GST and accounting well. This is not a proposal to replace them. Pentoggle builds the maintenance application around them, covering the workflows they were never designed for.
Key takeaways
- Preventive maintenance is skipped when the machine is busy, which is exactly when the consequence of skipping it is highest.
- Downtime is only analysable if the reason is captured at the machine, and reasons recorded at the end of a shift are largely fiction.
- Critical spares should be stocked according to what happens if you do not have them, not according to how often you use them.
- Maintenance history per machine is what turns a repair into evidence, and most of it evaporates because it lives in a fitter's memory.
- The number that matters in maintenance is the share of preventive work completed on schedule.
Why maintenance in most factories is reactive
Almost every Indian factory has a preventive maintenance schedule. It exists as a chart, it was drawn up carefully, and it is followed as far as production allows.
The problem is that maintenance and production compete for the same machine, and production wins nearly every time. A machine running an urgent order does not stop for a scheduled service. The service is deferred, then deferred again, and eventually the schedule is a document rather than a practice. When the machine fails, the failure looks like bad luck rather than the accumulation of six skipped services.
This is not a discipline problem, it is a visibility problem. Nobody deciding to defer a service is looking at how many times it has already been deferred, or at what the last few breakdowns on that machine cost in lost hours. The decision to defer feels small each time, and it is the accumulation that matters.
Packaged maintenance modules exist in most ERP systems and are among the least used. They tend to require an asset register, standard task lists and a discipline of work orders that a factory with two maintenance fitters is not going to sustain.
What maintenance management software holds
Machine register
Every machine with its identification, location, criticality, purchase and installation details, and any warranty or AMC.
Preventive schedules
Tasks with their frequency, defined by calendar or by running hours, with due dates and assignment.
Completion records
What was done, by whom, when, and what was observed, along with deferrals and the reason for them.
Breakdown log
Failure, cause where established, repair action, downtime duration and the production lost.
Downtime reasons
Captured at the machine as it happens, categorised in terms the operators actually use.
Spares stock and consumption
What is held, what was consumed against which machine and which job, and the cost.
Critical spares list
Items identified by the consequence of not having them, with stocking rules to match.
Contractor and AMC records
External service providers, contract coverage, visit history and costs.
Machine history
Everything above assembled per machine, which is what makes a replacement decision defensible.
The service that gets skipped is the one that mattered
A machine running well is the easiest machine to defer maintenance on, because stopping it costs visible output today while servicing it prevents an invisible failure later. Every deferral is individually rational and the sequence is not.
What changes the decision is showing the accumulation at the moment of deferral. This service has now been postponed three times. The last service was two hundred running hours past its interval. This machine has had four unplanned stoppages in six months, costing this many hours. None of that is available when the schedule is a chart on a wall and the history is in a fitter's head.
Recording deferrals as deliberately as completions is what makes this possible, and most systems do not. A deferred service simply stays pending, indistinguishable from one that is not yet due. Recording it as a decision, with a reason and a person, turns a drift into a visible choice.
The same records answer the question every factory owner eventually asks about an ageing machine, which is whether to keep repairing it. That question can only be answered with a history of what has already been spent and how much production has already been lost, and in most plants neither figure exists.
Downtime reasons collected later are not data
Downtime analysis is only as good as the reason attached to each stoppage, and reasons are usually assigned at the end of a shift by a supervisor reconstructing the day. What gets written is plausible rather than accurate, and the plausible reason is disproportionately the one that is easiest to write.
The result is a downtime report where a large share of the hours sit in general categories, and the improvement discussion runs on impressions.
Capturing the reason at the machine when the stoppage happens produces different data. It needs to be a short list of categories in the words operators use, entered in seconds on a phone, and it needs to distinguish the things that are actually different: waiting for material, waiting for an operator, tool or die change, mechanical failure, electrical failure, quality hold, and no work.
The distinction that matters most is between machine failure and everything else. A plant that discovers most of its downtime is waiting for material has a planning problem rather than a maintenance problem, and would have spent the next year improving maintenance.
Stock spares by consequence, not by usage
Ordinary inventory logic sets stock levels from consumption rate and lead time. Applied to spares, it produces exactly the wrong answer for the items that matter.
A bearing consumed every month is stocked because it moves. A control card used once in four years is not stocked because it does not. But if that card fails, the machine is down for the weeks it takes to import a replacement, and everything that machine was making stops with it.
Spares stocking should be driven by the consequence of absence: how long the machine would be down, what that machine is a constraint for, and how long the item takes to obtain. Items with a severe consequence and a long lead time are stocked regardless of how rarely they are used. Items with a short lead time and an easy substitute are not stocked at all, even if they move often.
Identifying critical spares this way is a one-time exercise per machine, usually done with the maintenance head in an afternoon, and it is one of the highest-return pieces of thinking available in a factory. Holding the list in the application, with the reasoning attached, keeps it from decaying when the person who made it leaves.
Why building this is now practical
Maintenance software has historically been bought by plants large enough to have a maintenance department that would use it. A factory with two fitters and a maintenance head who also handles projects has never had an option that fit.
With Pentoggle you describe your machines, your schedules, how your fitters actually work, what you want captured at the machine and what your spares situation is, and get a working application. When you add a machine, change a service interval, or decide to start tracking contractor visits, you describe the change and the application updates. Most factories start with the machine register, the preventive schedule and downtime capture, because those three produce the history everything else depends on.
Where maintenance looks different by industry
- Injection Moulding Software, where mould maintenance runs on shot counts rather than calendar dates.
- CNC and Machine Shop Software, where machine availability directly limits saleable hours.
- Plastic Manufacturing Software, where a continuous line stopping is a material loss as well as a time loss.
- Food Processing Software, where maintenance and hygiene requirements intersect.
- Pharmaceutical Manufacturing Software, where equipment inside the qualified scope stays in your validated system.
Why manufacturers choose Pentoggle for maintenance
Built for a small maintenance team
Not a work order system that assumes a department.
Deferrals recorded, not just completions
So the accumulation is visible when the next deferral is decided.
Reasons captured at the machine
In seconds, in the words operators use.
Spares by consequence
Critical items identified by what happens without them.
Changes in days
A new machine or a revised interval does not become a three month project.
The one number that runs maintenance
Preventive maintenance completed on schedule, as a share of what was due.
Breakdown hours and machine availability are outcomes, and they move slowly and for many reasons. Schedule compliance is an input, it is entirely within your control, and it moves first. A plant whose compliance falls this quarter will see breakdowns rise in the next two.
Track it monthly per machine, with deferrals and their reasons visible alongside. The machines that consistently miss their schedules are usually the ones production cannot spare, which is the same reason their failure will be the most expensive.
Ready to build maintenance management software?
The service you skipped is never the one you were thinking about.