Why automating job sheets in construction is different from automating invoices
A purchase invoice has a fixed structure: supplier, date, amount, VAT code. A job sheet has some of that structure, but the rest comes from the field. A technician notes on a paper form: 'extra pipework basement, 2 hours, materials included.' That is not a standardised field. It is context that only someone familiar with the file will understand. On top of that, the format varies by client: one customer sends their own job sheet template, another uses an app, and a third calls in the order while the technician writes something down themselves. That variation is the first obstacle. Any system that only works with fixed templates per client will fail here immediately.
The change-order problem: the line that holds everything up
The concrete lesson that keeps coming up at installation and construction companies is this: change orders are recorded late and loosely. At the end of the day, the technician quickly adds a few lines, sometimes on the back of the form, sometimes in a separate notes field. Those lines are critical for the invoice amount, but they are the hardest to read and the least structured. Automation that processes these lines blindly will produce errors that cost more than the savings. That is not an argument against automating, but it is an argument for choosing human-in-the-loop as your model. Let the system handle the structured parts: the order code, the operative, the date, the materials list. Flag the change-order lines as 'requires review'. An office employee approves those specific fields, not the entire form. That is a different division of work than retyping everything, but also a different one than blind automation.
When does digitising and automating job sheets pay off?
The rule of thumb is simple: automation pays off when volume is high enough and when a recognisable portion of the form arrives in a structured format. At a company with dozens of technicians submitting forms every day, retyping order codes, addresses and hours is pure wasted time. That part is something a system like dottle can take over, without requiring you to set up a template for each client. dottle reads varying formats and extracts the recognisable fields. What it does not do is decide on its own what a handwritten change-order line means for the invoice. That decision belongs to a person. Compare this to the approach at Cabooter Group, where 85% of documents are processed fully automatically and the remaining 15% receive human review. Exactly the same principle applies to job sheets: the structured portion automatically, the exceptions to a flagged queue.
When does automating job sheets not make sense?
There are situations where automation is better avoided, or where something else needs to be fixed first. If forms are structurally illegible because of an internal process problem, for example technicians who have never been told what the back office needs, automation will not solve that. The first step there is a digital job sheet app in the field so that input is already structured. Only once that step has been taken does adding a processing layer deliver value. If volume is low, say fewer than a handful of forms per day, the business case is thin. Setup takes time, and the payback period becomes long. And if project administration is so complex that every form requires unique manual handling, automation is not a substitute for a project controller.
How does job sheet processing work in practice?
In practice, a working approach looks like this: the technician submits the form, digitally or as a photo of a paper document. The system reads the form, recognises the structured fields and prepares them in the ERP or accounting package. Fields that are uncertain or require a decision, such as the change order, an unrecognised materials code, or a missing signature, are flagged. The back-office employee opens the task, sees only what needs attention, approves or adjusts, and sends it on. Retyping the standard fields is gone. Control over the exceptions remains. That is the essence of human-in-the-loop working, and it is precisely why this model also works in construction: not because it handles everything automatically, but because it puts the right person in the right place.