The specific asset
Not the site or the facility: the machine. It answers "how many times has this failed?", the question that gives value to everything else.
Guide
Not when it's signed: at that point everyone still remembers what happened. A work order pays off much later, which is why it should be designed with whoever reads it without context in mind.
It's the document that records a maintenance job: what was requested, on which piece of equipment, who did it, what they did, how long it took, what it consumed, and what it was signed off as. It's called a work order, job sheet or ticket depending on where you are. Its purpose isn't to report that something got done — a message would do for that — it's to leave enough of a record that someone who wasn't there can understand what happened, and so that all of them together can say something about the equipment.
With the question each one answers.
Not the site or the facility: the machine. It answers "how many times has this failed?", the question that gives value to everything else.
What was requested, in the words of whoever reported it. Useful later to see whether the report was what it appeared to be.
With its readings when there's a measurement involved. "Checked and correct" proves nothing at all.
What was done and why it had happened. The cause is the field most often skipped, and the one that lets a corrective fix prevent the next one.
Travel and work, kept separate. Without this there's no cost per job and no margin per contract.
With its reference and quantity, charged to the warehouse. It's the other half of the cost.
Before and after photos and sign-off from whoever receives the work. It's what gets shown when someone disputes the job.
By name, not "the team". If three people share a login, this field — and everything calculated from it — stops meaning anything.
Almost never out of carelessness. A work order gets filled in badly when it's filled in late — at the end of the day, once the details have already blurred — when it asks for fields that don't apply to that job and something has to be made up, or when whoever fills it in doesn't see the point of what they're writing. All three problems have a design fix: fill it in where the work happens, make the work order type depend on the asset type instead of using one generic form for everything, and let the technician see the history they're building themselves, because then they start writing for their future self.
A one-size-fits-all work order forces half of it to go unused on every job, and what goes unused gets ignored until what matters starts getting ignored too. What works is having templates by job type and by asset family, each with its own checks and fields: servicing a fire extinguisher doesn't ask for the same things as servicing a chiller, and an electrical fault doesn't ask for the same things as a leak. Linking the template to the asset family or model means every order arrives with the right one without anyone having to choose it, which is the only way this holds up across hundreds of assets.
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
The customer's signature at the bottom of a work order is such an ingrained habit that hardly anyone asks what it actually proves. It proves that someone from that site was present and signed off on what the document says, which isn't nothing, but it doesn't prove that what the document says is complete. That's why what really backs up a claim isn't the signature but what's above it: the real date and time, the specific piece of equipment, what was found, what was done and with what material. A signature on a work order that just says "checked" doesn't add anything the day there's a dispute. And there's a practical wrinkle worth solving before it comes up: when the person in charge isn't on site the day of the job, the alternative to signing a piece of paper nobody will ever go looking for is having them confirm it afterwards from their own account, which provides the same sign-off with a better trail.
A work order template gets designed backwards from the end: what questions will you want answered two years from now. If you're going to want to know how many times a specific part failed, there has to be a field for the part, not free text where everyone calls it something different. If you're going to want to compare times, start and end time have to be required. And if you're never going to look at a field, that field shouldn't be there, because every box that goes unused is one more excuse not to fill in the rest of the order. The usual mistake goes the other way: designing it from the start by adding everything that might conceivably be interesting, and ending up with a form the technician fills in halfway, with only three fields ever actually used.
The specific asset, the problem as it was described, what was checked item by item, the fix and the cause, real times with travel kept separate, material used, evidence with a signature, and who did the work, by name.
We don't publish paper templates, because a paper work order carries all the problems of a paper work order: it arrives late, it has to be transcribed, and it can't be analyzed. What we do instead is build your template in the system, starting from whatever you use today.
Because they're filled in late, because they ask for fields that don't apply, and because whoever fills them in doesn't see the point. All three get fixed with design: recording it on the spot, templates by asset type, and a visible history for the technician.
Yes, and it's what separates a system that gets used from one that gets filled in halfway. The template is linked to the asset family or model, and every order arrives with the right one without anyone having to choose it.
In the demo we turn it into a digital template and run it from the phone, so you can see what changes compared to paper.
Accessibility
Saved in this browser. Light or dark theme is set from the footer.