Custom workshop software development for heavy equipment

The work order is the core, from report to invoice

It rarely starts neatly. A driver calls from the roadside, a fleet manager emails a list, a contractor sends a photo of a leak. The system's first job is to tie that report to an asset: registration, chassis or serial number, with the odometer reading alongside it. Without that anchor, the repair ends up in a customer record instead of the machine's history, and it becomes impossible to trace later what happened to this particular unit.

A few questions at intake shape everything that follows. Who is reporting, and are they authorised to place an order? Where is the vehicle: on your premises, at the customer's site or by the roadside? Is it still driveable, or does it need transport? Does this fall under an existing contract, under warranty, or under neither? If those answers stay on the phone, the planner has to work them out again before anything can be scheduled. An intake screen that makes these fields mandatory saves the rest of the chain from a series of follow-up calls.

Next comes diagnosis, and two things should be kept separate: what the customer reported and what the technician found. The customer says the machine is vibrating; the technician reads a fault code and finds a worn bearing. That separation between complaint, cause and work performed is not academic. Manufacturers ask for it explicitly on warranty claims, and it is the only way to see which faults keep coming back.

That diagnosis also generates a pile of data that comes from nowhere else. Diagnostic software differs by make and produces fault codes in its own structure. The technician measures play, pressure or wear and records values on which a later judgement rests. He photographs the finding, because a cracked bracket in a photo carries more weight than three lines of text. If those findings end up in loose folders and messaging apps, they still exist, but not when someone needs them. If they hang off the work order line, they travel with it to the approval, the invoice and any claim that follows.

Then comes approval, execution and invoicing. These streams overlap: part falls under manufacturer warranty, part under a maintenance contract, part is for the customer's account. A system with only one invoice destination per work order forces your administration to split things by hand.

The additional work moment

The technician is under a trailer preparing it for inspection and sees that the brake discs are worn. That was not in the order. Carrying on without approval creates a line the customer can refuse; waiting leaves the lift occupied and a technician standing idle. Usually it is settled with a phone call that nobody records, and the argument then moves to the invoice. What the software needs to do here is small and concrete: the technician creates an additional work line with a photo, a description and the expected hours and parts; the customer approves or declines it; and the system records who gave approval and when. Only then does the line flow through to scheduling and invoicing.

The difficulty lies in the waiting. The customer is in a meeting, the fleet manager is on leave, the owner wants to come and look for themselves first. Meanwhile the vehicle sits on a lift you needed that day. A system that takes additional work seriously therefore gives the work order a waiting status that is visible in the schedule, so the workshop planner can see that this bay is not moving. Many businesses also agree with regular customers that the technician may carry on with minor findings as long as they are recorded. Such an agreement belongs in the system, per customer or per contract, not in the head of the workshop supervisor.

What the customer sees during the repair

Customer communication is not a side issue in repair work; it is where you can set yourself apart. The customer is not standing next to the lift. He only knows that his machine is with you and that he cannot use it. Every hour without an update, he fills in the gaps himself, usually unfavourably, and at some point he rings. That call takes time from your front desk and rarely gives him more than a status the system already knows.

The approach that works is simple. When the technician finds a fault, he takes a photo with a brief note; that goes to the customer as a proposal. The customer approves or declines digitally, and his name, the time and the exact lines he signed off are recorded. In addition, he sees a status for each vehicle that updates as work progresses: received, in diagnosis, awaiting your approval, awaiting a part, in progress, ready. This is the same information your planning board already tracks, just made visible outside. For a fleet manager with vehicles at several workshops, that is the difference between phoning and checking.

Two things deserve attention here. The first is access: a manager sees all vehicles belonging to his company, a driver sees only his own, and a machine that has been sold disappears from the previous owner's view. The second is that the status is tied to a real event, such as the goods-receipt booking for the part, rather than to a field someone has to update by hand.

The invoice that falls apart

At the end of a repair on heavy equipment, there is rarely a single invoice with one recipient. Some of the work falls under manufacturer warranty and goes to the importer. Some falls under a maintenance or repair contract and is charged according to the framework agreement. Some is damage and goes through an insurer, sometimes with an assessment firm in between and an excess that stays with the customer. And some is simply for the customer themselves. That split only becomes clear while the work is under way, because when the technician opens the order he does not yet know what cause he will find.

That places a firm requirement on the data model: the recipient belongs to the line, not to the order. Every labour line and every parts line carries its own recipient, so a work order can be split across several documents without double entry. If a claim is later rejected, that line must be able to switch recipient, with a record of who decided it. For insurance work, the supporting evidence attaches to those same lines: photographs of the damage, the damage claim form and the expert's report.

Parts, the service van and the engineer without signal

Your stock sits in more places than the warehouse. Every service van is its own location, stocked with filters, hoses, oil and wear parts. The technician picks up a filter set on the way, fits it and drives on. If that issue isn't linked to a work order line, the part never reaches the invoice, the van isn't restocked and the count stops adding up. Scanning from the van, linked to the open order, is therefore the foundation.

That sounds obvious and isn't, because the van is a workplace where scanning competes with dirty hands, rain and time pressure. A solution that only works on paper won't be used. What does work: a short list of what should be in this van, issuing in two taps on the phone, and restocking that starts on its own as soon as stock drops below the agreed level. Stocktaking then becomes a check rather than a reconstruction.

The parts flow also has its own quirks. There are special-order parts that are reserved for a particular work order and aren't freely available, even though they're on the shelf. There are exchange and reconditioned units, where the old part must come back before the credit is settled, so they need their own status and location. There are part numbers that fit several machines but differ by build year, with all the risk of ordering the wrong part. More on this at spare parts software.

When the part isn't there

The interesting moment isn't the issue but the absence. The part isn't in the van and isn't in the warehouse, and there are four routes: it's with a colleague in another van, it's at the other branch, it can come from the importer, or it takes longer and the machine has to do something in the meantime. Whoever doesn't have those routes in view picks the most expensive one: ordering and waiting.

Software helps by making stock visible across all locations at once, vans included, and by linking the order to the work order rather than a standalone purchase document. That way everyone knows why this job is on hold and when it can continue. Just as important is what happens to the vehicle while it waits. If it's set aside, someone needs to record that it's been taken apart and which loose parts belong with it. Right now that information lives in a technician's head and disappears the moment they take a week off.

Integrating with manufacturer and supplier catalogues

A workshop for heavy equipment rarely works with a handful of suppliers. There's the importer with its own catalogue and part numbers, there are universal suppliers for filters, brake parts and lighting, and there are specialists for hydraulics or electrics. Each party provides availability and replacement numbers in its own format, from a neatly structured file to a portal where someone searches by hand.

The value of an integration lies less in ordering than in looking up. A technician who opens the correct catalogue for this chassis number straight from the work order is less likely to pick the wrong number than someone working from memory or an old invoice. Replacement numbers are only useful if they arrive automatically; hand-maintained lists fall behind. If you build it yourself, the question of how to handle varying integrations needs to be settled early, because every supplier will change its format sooner or later.

Working without signal

Then there's the engineer working out in the field. On a building site behind a dyke or at a contractor's yard out in the polder, the signal drops out. An app that sends every action straight to the server grinds to a halt, and the engineer falls back on paper that gets retyped later. If the app works locally, they can complete the work order, take photos, log hours and parts and get the customer to sign, then everything syncs once connectivity returns. The tricky part is what happens next if the planner has changed the same order in the meantime. See also building a field service app.

Working offline is therefore not a switch you flip on, but a decision that affects the entire architecture of the app. The data the technician needs has to be on the device beforehand: his orders for today, the related asset records, and the stock on his own van. And when syncing, there needs to be a rule everyone understands: hours and parts the technician logged win, because he was there, while changes to scheduling and customer details come from the office. Anything outside that should land on a list someone reviews, rather than quietly disappearing.

• Every service van as its own stock location with its own minimum stock level
• Issue always against a work order line, in two steps
• Stock across all locations and vans in a single search
• Ordered parts reserved against the order they are for
• Returns flow and status for exchange and refurbished units
• Catalogue and replacement numbers taken from the source, not entered by hand
• Work orders, photos, hours and parts work offline
• An explainable rule for conflicts during synchronisation

Related services