Work order app for an electrical company instead of paper

FUR Dorian is an electrical company with several crews working in the field - service, installations and support at client sites. People drive out to jobs in several service vehicles, and every visit ends with a work order.

The work order was a paper form. After finishing a job, someone on the crew filled it in with a pen: who they visited, which vehicle, who was on the crew, start and finish times, what materials were used. Two of those fields were not really fields but lists - the crew and the materials could each take up half a page.

The slips came back to the office whenever they came back. Sometimes after a single route, sometimes at the end of the month, as one big stack. Only then would someone retype them into the systems the company uses to bill labour and materials. The problem was not the paper itself, but that in the meantime, the office had no idea what had actually happened on a job.

Where we started

With the paper form, not with screens. We went through the form field by field and for each one asked who reads that piece of information and what they do with it afterwards.

Two things came out of it that were not in the original brief:

• Most fields were simple data that could be picked instead of typed - client, vehicle, date. All the real work was hiding in the two list fields: the crew and the materials used. Those were what decided whether a work order got filled in on the spot or ended up as “I’ll finish it later”.
• The office did not need another billing system. It needed the data from a work order to be easy to feed into the systems the company already had.

The second observation decided the scope - and in the opposite direction from where projects like this usually head.

What we built

A browser panel, no app to install. After finishing a job, an employee logs in from their phone and fills in the work order on the spot, before getting back in the van. The administrator sees it the same moment - and can approve it, correct it, or send it back with a question.

Access is split by role: an employee works with their own work orders, while the administrator sees the whole company and manages users, vehicles and the client database. Login is protected by a second factor - a code from an authenticator app. This is a panel holding client business data, opened from any browser on any phone, so a password alone was not enough.

A client typed in by hand, or picked from the database

The biggest risk with a form like this is simple: an employee is standing at the site, the client is not in the database, and the form will not let them through. That is when a work order ends up “for later” - which is exactly where the paper used to end up.

So the client field works two ways. If the company is already in the database, typing the first few letters of its name is enough to pick it from a suggestion list - the job links to that profile and enters its history. If it is not there, the employee types the name by hand and moves on, and the office links it to a proper profile later. The form is never a reason not to fill in the work order.

CSV export instead of an integration

The client did not want to wire the panel directly into their systems, and had a good reason: an integration costs both sides money and locks everyone into one setup for years. They settled on a compromise - the office approves work orders in the panel and exports them to a CSV file, which goes into the company’s systems the same way as any other import.

Nobody sold this as the final solution. It is cheaper, it was ready immediately, and it does not close off anything: if the company ever decides on a direct connection, the data is already sitting in one place and one format.

How the rollout went

The first working version was ready in a week, and the client got to look at it before paying anything. A screen is easier to judge than a scope written out in sentences, especially with someone who has never ordered software before.

The following two weeks went into tying everything together and testing it on real jobs. In just under three weeks, the crews were filling in work orders in the panel, and the paper form stayed in the binder.

What changed after launch

To be honest about measurement: the company did not keep statistics before the rollout. So there is no “it used to take this long, now it takes that long” comparison here, and the numbers below describe the state after launch, not savings calculated from the client’s own data.

The change that cannot be written as a number is this: a work order stopped being a document that reached the office late. The office sees it the same day and can ask about a detail while someone still remembers the job, instead of three weeks later over a pile of slips.

The scope grew along the way. Once the panel went live, it turned out the administrator also needed to manage users and vehicles inside it - which was never part of the original agreement, because things like that simply do not exist on a paper form. We added it at no extra charge, reasoning that a panel without its own administration would have come back to us the moment the crew changed anyway.

The lesson for next time: a paper form shows what an employee writes down, but says nothing about who manages all of it. Reference data, roles and access levels have to go into the scope from day one, even if nobody mentions them up front.