A diesel generator is bought for one reason: to run when everything else doesn't. That makes DG service a strange trade — the machine sits idle for weeks, then must start on the first crank at 2 a.m. during a grid failure, and the service provider is judged entirely on that moment. Diesel generator service software has to serve that reality: not a ticket system with "genset" typed into a field, but a system that knows each DG set as a machine — its duty, its hours, its history — and runs the discipline that keeps first-crank confidence honest. On xMatix that discipline is in production use today: every DG set is an asset with a metered life, every AMC generates its own visits, and every visit leaves evidence.
Every DG set, a machine on the record
The fleet starts as records: make, model, rating, serial, site, customer, commissioning date — imported from the AMC register and the engineers' diaries in an afternoon, because the data already exists; it has just never lived in one place. Readings from every visit (hours run, the checks the visit performed), every breakdown and its cause, every part fitted, every contract held. Standby units and prime-duty units live on the same ledger with very different rhythms, and the record holds both honestly — site details riding along too (access instructions, contact, safety notes), so the visit brief carries what the last engineer wished someone had told him. The standby set that ran nine hours all quarter still needs its calendar-based service, while the prime unit at a construction site burns through hour-based intervals in weeks. When the operations head asks which units in the fleet are overdue, the answer is a filter — by customer, site, model or duty — not a phone-around.
AMCs that meter on hours and calendar, whichever bites first
DG maintenance contracts are classically dual-metered — quarterly visits or every 250 running hours, whichever comes first — and that "whichever first" is exactly what registers and spreadsheets fumble. On xMatix the contract meters both: readings captured at each visit update the hours projection, the calendar runs regardless, and the contract raises its preventive job when either threshold approaches, with grace bands for the real world. Entitlements burn down visibly — visits consumed and remaining per contract — so over-servicing a loud customer and under-servicing a quiet one both become visible before they become losses, and the quarter's contract obligations become a schedulable workload instead of a register to be feared. Expiring contracts raise their own renewal leads carrying the unit's history, which is the renewal pitch that actually works.
Preventive visits and the 2 a.m. breakdown, on one queue
The planned PM visit and the emergency breakdown are the same work with different clocks, so they run on one dispatch: preventive jobs generated by contracts fill the schedule ahead; breakdowns arrive against the unit's record — history, site, contract coverage already attached — and are dispatched to the nearest engineer with the right skills, van stock considered. The engineer at the machine works the same way for both: guided checklist for the service performed, readings recorded, parts consumed onto the job, photos of what was found, the customer's signature — all of it captured offline in the basement or the field and synced from the road. The breakdown that interrupts a planned day is dragged into the plan on the dispatch console, not negotiated over six phone calls.
Geography does the rest of the planning work. PM visits due in the same belt cluster into the same engineer's day, sequenced on real roads by the route optimiser, so the month's contract obligations are delivered in sensible loops rather than in the order the register listed them — and the travelled trail afterwards shows the plan met reality. For a DG service business whose costs are substantially diesel and driving, visits-per-engineer-day is the operating metric that moves first.
Parts on the van, parts on the job
First-time fix is a stock question wearing a service costume: the engineer either has the filter, belt and AVR on the van or the machine waits for a second visit. Van stock is a real inventory location — replenished from consumption like any store — and parts issue to the job card as fitted, so consumption reconciles per job and per engineer, and the van that quietly becomes a private warehouse shows up in the numbers. The network-wide parts picture answers the harder question: which branch holds the part for the down machine, and what raising its urgency from the job actually does to the promise date.
Billing that follows the contract, books that follow the billing
Each job line knows its payer before work starts: covered lines consume AMC entitlement, warranty lines route to claims with their evidence, chargeable lines — the top-up service, the part outside scope — invoice with GST split correctly across parts and labour. Collections tie to invoices; everything posts to real books as it happens; and contract profitability (visits and parts consumed against contract price) is a report per contract, which is the number that decides next year's AMC pricing. Multi-site corporate customers get consolidated visibility — every unit, every site, one statement — which tends to be the feature that wins the corporate account in the first place.
The breakdown customer is also the AMC pipeline, worked deliberately: every emergency job on an uncontracted unit ends with the machine's condition on record and a natural next step — the AMC quotation, generated as a lead from the visit itself, priced with the unit's age and state in front of the estimator. Breakdown-to-contract conversion becomes a measured funnel rather than an engineer's occasional suggestion, and the service business shifts, unit by unit, from selling emergencies to selling uptime. The same records make the corporate bid credible: the prospect asking "can you actually service forty sites?" is shown completion rates, response times and covered fleets from the operation's own history rather than a brochure's adjectives.
What this deliberately is not
xMatix does not claim remote monitoring it does not do: there is no telemetry ingestion, no IoT fuel sensing, no auto-diagnosis from the controller. What it does instead is make the human system reliable — metering from captured readings, thresholds that raise jobs, histories that make the next failure predictable to the engineer reading them — which is the part of DG service that actually fails in practice, and the part a service business can fix this quarter with the fleet it already has.
Common questions
What should diesel generator service software track per unit?
The machine's whole life: identity and rating, site and customer, running-hours readings from every visit, services performed, breakdowns and causes, parts fitted, and the contracts covering it — so any unit's state and history is a lookup, fleet-wide, by customer, site or model.
How are dual-metered AMCs (hours or calendar) handled?
The contract meters both clocks: engineer-captured readings drive the hours projection while the calendar runs in parallel, and the preventive job is raised when either threshold approaches, with grace bands. Entitlement consumed and remaining stays a live fact per contract.
Can breakdown calls and preventive visits run on one dispatch?
Yes — contract-generated PM jobs fill the plan ahead, breakdowns arrive against the unit's record with coverage pre-checked, and the console assigns by skill, proximity and availability, re-planning the day by drag when the 2 a.m. call rearranges it.
Does it monitor gensets remotely?
No — and the page says so plainly. There is no telemetry or IoT ingestion. Metering runs from readings engineers capture at the machine; thresholds raise jobs; history informs the humans. For most DG service businesses, that disciplined human loop — reliably executed — is where the availability actually comes from.