Back to Blog
Business Systems

Work Orders: From WhatsApp Messages to a System That Tracks Every Request

Origami TeamEditorial Team
7 min read
Work Orders: From WhatsApp Messages to a System That Tracks Every Request
📚 Make the Most of TechDigitizing Contracting and Maintenance
Part 2 of 7
  1. 1.Where Contracting and Maintenance Companies Lose Their Profit
  2. 2.Work Orders: From WhatsApp Messages to a System That Tracks Every Request (you are here)
  3. 3.Scheduling Field Teams and Dispatching Visits
  4. 4.Coming soon
  5. 5.Coming soon
  6. 6.Coming soon
  7. 7.Coming soon

Work Orders: From WhatsApp Messages to a System That Tracks Every Request

Part one of this series named seven places profit leaks out of contracting and maintenance companies, and said the biggest one was a single item: the request that arrived, got done, and was never logged. It also said the practical order is to close the largest gap first. This part is about exactly that gap.

The problem is not that WhatsApp is bad. It is that a conversation channel is being used as an operating system. A conversation carries information but it holds no state, issues no reference number, warns nobody when a deadline passes, and produces no report. The work order is the alternative: one record created the moment a request arrives, which stays with it all the way to the invoice.

One intake channel before anything else

Most attempts at getting organised fail for a simple reason: the system is added alongside WhatsApp rather than instead of it, so you end up with two sources of truth and crews pick the easier one. The first step is therefore a management decision, not a technical one: every request enters through one place.

This does not mean stopping clients from sending messages. It means whoever receives the message is responsible for turning it into a work order before any technician moves. In practice, the companies that make this stick do three things together:

  • Define one intake point the client actually knows: a single number, a portal, or an inbox.
  • Make one internal rule explicit: no visit without a request number, and no part issued without a request number.
  • Give the client the request number immediately, so they start asking about the number instead of re-explaining the problem from scratch.

The request number: the field everything else hangs on

The number is not paperwork. It is the reference costs are posted against. When a spare part is issued against a request number, technician hours are logged against the same number, and travel and subcontractor costs are charged to it too, you have a calculated cost rather than an estimate. And when those numbers roll up to a contract or a project, you know the margin on that contract, not just on the company as a whole.

The practical purpose: when a maintenance contract comes up for renewal, the difference between negotiating from strength and negotiating from feeling is your ability to say this client consumed a specific number of visits and a specific value of parts over the year. Without a reference number, that conversation is an impression.

Status and owner: who is holding this request right now

What upsets a client is rarely the delay itself; it is not knowing where their request stands. A short status chain is enough: logged, assigned, in progress, waiting on a part, waiting on the client, completed, closed. The two that matter most operationally are waiting on a part and waiting on the client, because they stop the clock against you, put the ball in the right court, and show up in your performance review instead of vanishing inside a generic delay figure.

And every request has one named owner. A request owned by a whole team is owned by nobody. The owner is not necessarily the person doing the work; they are the person who answers when the client asks where things stand.

Response time: a written commitment, not a verbal promise

Maintenance contracts usually specify a response time and a resolution time, and sometimes attach a penalty to them. When that clock is not measured automatically, you find out you breached it from the client's complaint rather than from your own system. The basic requirement is that the clock starts when the request is logged, not when somebody happens to notice it.

Keep two numbers apart: response time, from logging to the technician arriving, and closure time, from logging to the work being finished. The first measures scheduling discipline; the second measures parts availability and whether the right trade was sent. Merging them into one figure hides the real cause of the delay. And when you set priority, tie it to the impact of the fault on the client's operation, not to their tone on the phone.

What gets captured on site: notes, photos, signature

This is the part you pay for months later, not today. Three things are captured on site at the moment of execution:

  • Execution notes: what caused the fault and what was actually done. This is the knowledge part one said walks out the door with the employee. Written against the asset, it stays with the company.
  • Before and after photos: your evidence when a client disputes the condition of the asset before the visit, and your evidence with an insurer or landlord when there is damage.
  • Client or representative signature: an acknowledgement that the work was done and handed over. Without it, the payment application turns into a debate.

One field note that decides adoption: an app that needs a strong signal will not be used. A technician in a basement, a plant room or a building under construction needs to photograph, write and collect a signature offline, then have everything sync automatically when the signal returns. That is an adoption requirement, not a nice-to-have.

Variations: document them before you do them

The third leak in part one was extra work done with no change order. The work order is the natural place to catch it: when a client asks for something outside the original scope, an additional line is opened inside the request or as a linked request, and signed off there and then. The difference between a two-minute signature on site and trying to extract one a month later is the difference between money collected and money written off.

From work order to invoice and payment application

This is where the return shows up. The payment application or invoice is not built from memory at month end; it is assembled from closed work orders, each carrying its own proof: date, description, hours, parts, photos and a signature. Submission turns from a research project into an assembly job, and disputing it gets harder because every line has a document behind it.

On the compliance side, e-invoicing in Saudi Arabia requires you to issue an electronic invoice tied to a real transaction and integrated with the Zakat, Tax and Customs Authority platform. When the source of your invoice lines is closed, documented work orders, compliance becomes a by-product of how you operate rather than extra work at the end of the month.

The Origami view

When we roll out work orders for a contracting or maintenance client, the most common mistake we see is starting with a huge form carrying twenty mandatory fields. The result is predictable: crews fill fields with junk values just to close the screen, and you end up with data that is worse than none.

What works in practice: start with six mandatory fields only — client, site, description, priority, owner, status — plus a photo and a signature at closure. Run that for a full month until it becomes a habit, then add one field at a time, each only when a real decision depends on it. The rule we use: any field that does not change a decision, settle a dispute, or end up on an invoice is a field that slows the technician down for nothing.

And the metric we watch in month one is not how many reports the system produces, but the share of requests that entered the system compared with what actually reached the supervisors. If requests keep coming in through the back door, the problem is managerial and no system will fix it.

Coming next

Now that every request has a number, an owner and a clock, the next question is who goes, when, and in what order. Part three covers scheduling field teams and dispatching visits: matching the trade, sequencing visits geographically, checking part availability before dispatch, and tracking attendance and location in a way that complies with the Personal Data Protection Law.

Sources

#Make the Most of Tech#Contracting and Maintenance#Work Orders#Operations Management

Frequently Asked Questions

What is the minimum set of fields a work order needs to be useful?+

Six are enough to start: client, site, fault description, priority, owner and status, plus a photo and a signature at closure. Long forms push crews to enter junk values, which corrupts your data. The practical rule is that any field which does not change a decision, settle a client dispute, or end up on an invoice can wait.

How do I stop requests from still arriving through WhatsApp?+

With a management decision, not a tool. Make the rule explicit: no visit without a request number, and no spare part issued without one. Let clients message you however they like, but whoever receives the message must convert it into a work order before any technician moves, and give the client the request number immediately so they get used to referencing it.

What is the difference between response time and closure time, and why separate them?+

Response time runs from logging the request to the technician arriving on site and reflects scheduling discipline. Closure time runs to the work being finished and reflects parts availability and whether the right trade was dispatched. Merging them into one figure hides the real cause of a delay and stops you from fixing it.

Why do site photos and a client signature matter on a work order?+

They are the evidence that settles the argument later. Before and after photos establish the condition of the asset at the time of the visit and protect you in a damage dispute, and the signature is an acknowledgement that the work was handed over. When those documents are attached to the work order, the payment application becomes an assembly of ready data instead of a debate based on memory.

Rate this article

Related Articles

Weekly newsletter

The latest articles that matter to business owners, once a week. Just your email.

Looking for a software solution for your business?

At Origami we build custom systems, websites, and stores tailored to how your business works. Get in touch and we'll show you how we can help.

One session. Twenty minutes. No commitments.