Digitising work orders: from paper to app for production and field service

A technician finishes a job, fills in a paper work order, has the customer sign it and puts the carbon copy in the folder in his van. On Friday that folder lands on the administration desk. On Monday the order is retyped into the ERP. On Wednesday the invoice goes out. Provided the order was legible, and provided it did not stay behind in the folder.

For most manufacturing companies and field service teams, digitising work orders is the project with the fastest payback, precisely because the paper version has so many hidden costs. This article covers what those costs are, what a digital work order needs to do, when a standard app is enough and how to make the switch without turning your technicians against you.

What a paper work order really costs

The work order itself costs nothing. Everything around it does.

Days between the job and the invoice. Between the job and the moment the order is in the system, there are on average three to ten days. That is cash flow in transit, and every day of delay makes it easier for the customer to dispute details.

Retyping, and the errors that come with it. Every work order is retyped at least once. A 7 that looks like a 1, a missing item number, a forgotten hour. Every error costs a phone call or a credit note.

Lost orders. Every company working with paper knows that orders go missing. Nobody knows how many, because that is exactly the problem. Every lost order is work that is never invoiced.

Materials that are not charged. The technician used another fitting from the van, forgets to write it down, and it disappears from stock without a trace. Over a year that is rarely a small amount.

No view of what is happening. Which jobs were completed today? How many hours were worked this week per customer? Which machine needs a striking amount of maintenance? With paper you only know once the administration has finished retyping, if you know at all.

Administration as the bottleneck. One or two people processing work orders set the pace of your invoicing. If they are out, cash flow stalls.

What a digital work order needs to do

A photo of a paper order is not a digital work order. The difference is in the structure: every line on the order becomes a piece of data you can forward, add up and look up. These are the functions that matter.

Linked to the job

The technician picks the customer, the installation or the machine not from memory but from a list that comes from your planning or ERP. No typos in customer names, no order without a reference number.

Hours, materials and travel, structured

Start and end time with one tap. Materials from an item list, with quantities. Kilometres or travel time according to the agreements with that customer. Everything you later want to invoice or analyse is captured on the spot.

Photos and signature

Photo of the situation before and after, photo of the type plate, customer signature on the screen. The customer immediately receives a PDF by email. Discussions afterwards largely disappear.

Working offline

Basements, construction sites, production halls with thick walls: your technicians often work without coverage. The app must be able to fill in completely offline and synchronise as soon as there is a connection again. An app that cannot do that is no longer used after a week.

Checklists and mandatory fields

A maintenance visit has fixed steps. An inspection has mandatory measurements. The app guides the technician through those steps and does not let the order close if something is missing. That makes quality enforceable instead of dependent on who is on the road that day.

Straight to invoicing and planning

This is where the gain is. A closed work order appears in your ERP or accounting package as lines to invoice, and in your planning as a completed task. Nobody retypes anything anymore.

Standard app or custom work order?

There are solid standard apps for work orders and field service. For a technical team with a classic flow (job, hours, materials, signature, invoice) they are a good and fast choice. Look at two things above all: does the app really work offline, and does it integrate with your ERP or accounting package, not just the three big names in the brochure?

Custom software comes into the picture when:

• your flow deviates. An inspection report with specific measurements, a work order that generates a certificate, a process with approval by a site manager before the order may go to invoicing.
• the integration is the stumbling block. Your ERP is less common, you work with your own item codes or customer agreements, and the standard app cannot get that data in or out. Then you are back to retyping. See our article on custom software versus an off-the-shelf package for that trade-off.
• the work order is part of a bigger whole. Planning, time tracking, stock in the van, maintenance history per machine. If you want all of that in one system, you are better off building one mobile application that fits you than tying five separate tools together.
• you see the number of users growing. Twenty technicians times a monthly licence, year after year, is in the long run often more expensive than an app that is yours.

The honest caveat: start by looking at the standard apps. If one fits, including integration and offline use, that is faster and cheaper. If after that exercise you have written down three "yes, buts", you know custom software is worth it.

How such a project runs

The technology is rarely the difficulty. Adoption on the shop floor is. This is how we approach it.

1. Shadow for a day. Before a single screen is drawn, we spend a day with a technician and half a day with the administration. What is really on the order? Which information is always missing? Where does it go wrong between van and invoice?

2. Build the order around the work, not around the administration. The app has to be faster than paper for the technician. If that fails, it will not be used and the rest is irrelevant. That means: few taps, big buttons, offline, and never asking for anything the app already knows.

3. Start with one team. Two or three technicians, one type of job, two weeks. What they report gets adjusted before rolling out to the rest. That way you get ambassadors instead of resistance.

4. Integrate with what is already there. Only once the order itself works do we connect it to ERP, invoicing and planning through an API integration. In that order, because an integration on an order nobody fills in delivers nothing.

5. Extend based on use. Checklists, stock in the van, maintenance history per machine, a customer portal where customers find their orders. All logical next steps, but only after the basics are used daily.

What that delivers

For ML-TECH we built a platform that lets planners manage construction sites, tasks and materials, and lets workers on site check in, tick off tasks and see the status of their project through a mobile app. All in real time, also on sites with limited connectivity. The company saves around fifteen hours a week with it.

At Samoco the gain was in the chain behind it: hours of employees and subcontractors are recorded digitally, approved by a manager and automatically forwarded to payroll or purchase orders. Seven working days per month of administration that no longer needs doing.

In both cases the real gain was not in the screen on the phone, but in everything that no longer had to be done by hand afterwards.

Where to start this week

1. Take ten random work orders from last month and trace them: when carried out, when in the system, when invoiced. The average number of days is your first figure.
2. Ask the administration which information is most often missing on an order. That is your list of mandatory fields.
3. Ask two technicians what annoys them most about the paper order. That is your list of what the app has to do better.

With those three lists you can evaluate both a standard app and a custom software partner with focus. And if you want to look at it together, we are happy to show you what is possible, with no strings attached, even if the answer turns out to be a standard app.