Measuring whether a digital tool improved your productivity

Most builders can tell you what they pay for software. Very few can tell you what it returned. That gap is not laziness; it is that measuring productivity on a construction job is genuinely awkward. The work is not repetitive, the inputs change weekly, and the person who would do the measuring is the same person who is already flat out running the job.

The result is that tool decisions get made on feel. A builder signs up to a site management platform, uses it for a season, and keeps paying because cancelling feels like admitting the decision was wrong. Or the opposite: a tool that quietly saved two hours a week gets cancelled in a slow month because nobody could point to the saving.

This article is about the measurement itself — how to set up a test that can prove or reject a tool’s value, and how to run it without turning your week into an administration exercise. If you are still working out what you are paying for in the first place, the guide to auditing a builder’s tool stack covers that separately.

Why “I feel more organised” is not a measurement

Feeling more organised is real, but it is not a result you can act on. It cannot tell you whether to renew a subscription, whether to roll the tool out to the second crew, or whether to spend the same money on something else. Worse, it is biased: once you have paid for a tool and spent a fortnight learning it, you are invested in it having worked.

Measurement exists to break that bias. It does not need to be scientific. It needs to be specific enough that the answer could come back negative. If every possible outcome of your trial leads to “keep it”, you have not measured anything.

The practical test is this: could you write down, in advance, what result would make you cancel? If not, you are not measuring, you are justifying.

Start with the commercial problem, not the tool

Tools do not improve productivity in the abstract. They improve a specific step in a specific process. Before you measure anything, name the problem the tool was supposed to fix. Common ones on residential jobs in NSW:

• Variations agreed on site that never make it into a written instruction, and therefore never get paid.
• Rework caused by a drawing revision that reached one trade and not another.
• Time lost waiting on a decision from the client, the certifier or the engineer.
• Hours spent each week re-entering the same information into quotes, schedules and invoices.
• Disputes at the end of a job where the record of what was agreed is thin.

Each of those has a different measure. A tool that speeds up quoting will not fix variations going missing, and a document platform will not fix a scheduling problem. Pick one problem, and measure that one. If you try to measure everything, you will measure nothing.

This is also where the record keeping side matters. The Australian Taxation Office is clear that business records need to be kept and be retrievable, and a digital tool often becomes part of that record set. Whatever you measure, do not let the measurement process leave gaps in records you are obliged to keep.

The baseline is the whole exercise

A baseline is simply a record of how the work performs before the tool arrives. Without one, you have nothing to compare against, and memory will quietly rewrite the past in favour of the present. Builders who skip the baseline almost always conclude the new tool helped, because the old method has been reduced to a vague impression of chaos.

You do not need months of data. A few weeks on live jobs is enough, provided you record the same things the same way. The key discipline is to fix the measures before you start, in writing, so that you cannot adjust them once you see the results.

Keep the baseline crude but honest. “Three variations missed on the last four jobs” is a usable baseline. “Admin felt heavy” is not.

Choosing measures that survive contact with a real job

There are two broad families of measure, and they fail in different ways. Time-based measures ask how long something took. Outcome-based measures ask how often something produced the right result. Neither is reliable on its own.

Time-based measures are easy to record but noisy. If a task took longer because a supplier went quiet or it rained for three days, the tool gets blamed for something it did not cause. Outcome-based measures are closer to what the client actually pays for, but they need a clear definition of a “right result” and someone willing to count exceptions.

The practical approach is to pick one of each. Time how long it takes to issue a revised drawing to all affected trades, and count how many trades received it before they started work on the superseded version. Together, those two numbers tell you something a feeling cannot.

Run the trial as a comparison, not a launch

The most common measurement mistake is to roll a tool out across every job and then try to work out whether things improved. Once the old method is gone, you have no control group. The comparison becomes a memory exercise, and memory is exactly what you were trying to avoid.

Better: run the tool on two or three comparable jobs while the remaining jobs continue on the existing method. Keep the measures identical on both. This is not a clinical trial and it does not need to be statistically pure — it just needs to give you two sets of numbers gathered the same way.

Comparable matters. Two jobs of similar size, similar stage and similar client type will tell you far more than one large job and one small renovation. If you cannot find comparable jobs, say so in your notes and treat the result as indicative rather than conclusive.

Distinguish adoption time from steady-state time

Every tool is slower in the first weeks. Someone has to learn it, set it up, import contacts, and fix the mistakes made while learning. If you measure from day one, you will conclude the tool is a failure even when it is fine.

Set a settling period and exclude it from the comparison, or record it separately so you can see the curve. Then measure the steady state: what the tool does once the crew stops thinking about it. The same logic applies in reverse when you cancel something — there is a cost to unwinding a tool, and it should be part of the decision.

Write the settling period into your plan before you start. If you decide it afterwards, you will be tempted to extend it every time the numbers look bad.

Measure the cost of the tool, not just the saving

A tool’s return is the saving minus the total cost of running it. The subscription is the visible part. The hidden parts are the setup hours, the ongoing administration, the time your subbies spend on it, the training each new starter needs, and the cost of the data you put in if you ever leave.

For a small builder, the administration load often decides the outcome. A platform that saves an hour a week in document control but costs two hours a week in data entry is a net loss, and it will show up in the measures if you are counting both sides.

This is also where the automation question sits. Automating a process that should not exist just makes the wrong process faster. Before measuring a tool’s speed, confirm the process it supports is one you actually want. The article on automating a small builder’s office works through that distinction.

Where recovered time actually goes

Here is the part most measurement plans miss. Productivity gains do not usually appear as spare time. They appear as more work absorbed into the same week. A builder who saves several hours a week on administration rarely goes home earlier; they take on another job, or answer more client calls, or finally get to the quoting backlog.

That is not a failure, but it means “hours saved” is an incomplete measure. The honest question is what the recovered capacity was used for, and whether that use was worth more than the tool cost. Decide this in advance. If the answer is “more jobs without more office hours”, measure jobs per office hour. If the answer is “fewer disputes at handover”, measure disputes.

Without that decision, recovered time gets absorbed invisibly and the tool looks like it did nothing.

Worked example: a builder in western Sydney

A builder running a small residential business in western Sydney was losing money on variations. The pattern was familiar: a change was agreed verbally on site, the client accepted it, the work was done, and the paperwork caught up weeks later or not at all. The builder bought a site management tool with variation tracking and wanted to know whether it worked.

Before rollout, over four jobs, they recorded a simple baseline: how many variations were agreed on site, how many were written up within a set number of days, and how many were ultimately invoiced. The gap between the first and last number was the cost of the problem.

They then ran the tool on the next two jobs while the remaining work continued as before. The settling period was excluded. At the end, they compared the proportion of agreed variations that were written up and invoiced.

The result was not uniform. On one job the tool clearly closed the gap, because the site supervisor logged changes from his phone before leaving site. On the other, the gap barely moved, because the supervisor was the same person who had always been too busy to write things up, and the tool had not changed that. That is a useful finding: the problem was not the paperwork system, it was who was doing it and when.

The builder kept the tool but changed the process around it, making the site supervisor log the variation before the trade left site. That is the kind of conclusion measurement produces and feelings do not.

Keeping the records straight while you measure

Measurement creates its own records: notes, counts, screenshots, spreadsheets. Those sit alongside the business records the tool itself produces. Keep them together and keep them retrievable, and do not let the trial create a parallel set of numbers that nobody can reconcile later.

The Australian Signals Directorate’s guidance for small business is a useful reference point here, because the more of your business runs through digital tools, the more your records depend on those tools staying available and secure. A measurement process that ignores access and backup will eventually produce a confident answer based on incomplete data. The getting your team to use the software you paid for covers the selection side in more detail.

Safe Work Australia’s material on digital technologies and AI is worth reading for a related reason: introducing a digital tool changes how work is done and who is accountable for what. If a tool is meant to improve a safety-related process, such as recording site inductions or plant checks, measure that process specifically rather than assuming general productivity gains cover it.

The decision rule you write down first

Before the trial starts, write the decision rule. Something like: if variations written up within the agreed window improve on the comparison jobs, keep the tool; if not, cancel it or change the process around it. Name the date you will decide.

A written rule does two things. It stops the decision drifting indefinitely, and it makes the result admissible in your own head. Builders are practical people; most will accept a negative result if it was defined fairly in advance. What they will not accept is a number that appears to have been invented after the fact.

Three outcomes are possible, and all are legitimate: keep the tool, change the process it sits inside, or cancel it. A measurement that cannot produce the third outcome is not a measurement.

What to do with the answer

If the tool wins, roll it out deliberately and re-measure once, later, to confirm the gain held. Gains often shrink after the novelty fades and the person who championed the tool moves to another job.

If the tool loses, cancel it and note why. That note is valuable, because it stops you buying the same category of tool again in two years with the same expectation. If the tool is neutral, the decision comes down to cost and risk — neutral tools that add administration are usually not worth keeping.

Whatever the outcome, the measurement habit is the asset. Builders who routinely baseline a process before changing it make better technology decisions across the board, because they stop confusing activity with improvement. If you want to build that discipline alongside your formal training, the guide to how NSW builder CPD works explains how the requirements fit together, and the course catalogue lists what is available.

Questions builders ask

• Business
• Productivity
• Technology

Published 14 August 2026. General information for builders, not legal, financial or engineering advice for a specific job. Check current requirements with the relevant regulator or standard before relying on them.