Feature Focus

No One Flags a Job as Late Until It Already Is

Zigaflow28 August 20265 min read
Active Orders41 live
Acme Merchandise - Polo shirtsJB-0441In Production
Promo World - Tote bagsJB-0439Awaiting PO
BlueSky Promos - HoodiesJB-0438On track
Horizon Events - LanyardsJB-0435At risk
Office Fitout Group - MugsJB-0432Ready to Invoice

For most trade and project businesses, job status only surfaces when someone decides to report a problem. By then, downstream commitments have already been made on the assumption everything was on track. Milestone-based project tracking changes the signal from 'no news' to 'stage not confirmed.'

The signal that a job is running behind usually arrives by phone call. A customer asking for an update. A site manager mentioning something in passing. A sub-contractor who didn't show up when they were supposed to. For most trade and project businesses running five or more live jobs at once, the system for knowing where each one stands is informal, inconsistent, and always one step behind where it needs to be.

That gap between what is happening and when you find out about it is not a communication problem. It is a structural one. When job status only travels by exception - when someone decides to report it - the default assumption is that everything is on track until proven otherwise. The problem is that "proven otherwise" usually arrives too late to respond without cost.

How Job Status Actually Gets Communicated

In most small to medium-sized trade and project businesses, job status travels reactively. Nothing is reported unless something goes wrong, and even then the report depends on someone deciding to raise it. That someone is usually managing the problem at the same time as communicating it, which means the update arrives late, compressed, or incomplete.

In practice it looks like this: a job hits a problem on Tuesday. The person on site handles it. By Thursday, someone at the office calls to check in. The answer is "fine, mostly" - which is true now that Tuesday's issue has been dealt with, but misses the fact that the programme has shifted by two days, that a follow-on sub-contractor was due on Wednesday and hasn't been told about the change, and that an invoice milestone tied to stage completion is now due to slip.

None of that is reported, because none of it looks like a problem in isolation. It becomes a problem three weeks later when a customer queries the invoice timing, or when the sub-contractor arrives to a site that isn't ready for them, or when a job that was supposed to close is still running and you're carrying the costs.

When You Find Out Matters as Much as What Happened

The reason late discovery is more expensive than early discovery is not just about fixing the specific problem. It is about the decisions made during the gap - decisions that assumed the job was on track.

A sub-contractor was scheduled based on the original programme. Materials were ordered for a site visit that can no longer happen on the planned date. A customer was given a completion date that the current programme cannot deliver. Each of those downstream commitments costs something to undo. The later the discovery, the more commitments have compounded.

This is where the absence of milestone tracking is most damaging. Without defined checkpoints in a job - stages at which completion of a phase is confirmed, not assumed - there is no mechanism to detect drift until it becomes visible. And it becomes visible when something downstream fails: when a delivery arrives and nobody is there, or when an invoice goes out and the customer disputes it because the work is not done yet.

The FMB and CIOB State of Trade Survey, covering UK small and medium-sized building firms in the second half of 2025, found that nearly half (49%) of respondents reported job delays in that period. Delays are not exceptional. They are routine. The question is not whether your jobs will encounter problems, but whether you will know about them in time to do something useful.

What Milestone-Based Tracking Changes

Zigaflow's project tracking feature works from defined milestones inside a live job. Each job has a set of stages configured to match how that type of work runs, and each stage carries a status updated as work progresses. The difference from informal reporting is that the absence of a confirmed update is itself informative.

With informal tracking, a job that nobody has flagged is assumed to be on track. With milestone-based tracking, a job where a stage is overdue without a confirmed completion shows up as needing attention - not because anyone raised an issue, but because the expected event did not happen when the programme said it would.

This shift from "nothing to report" to "stage not confirmed" changes how you manage a busy week. When seven jobs are running simultaneously, there is not time to check in on all of them equally. Milestone tracking tells you which two or three actually need your attention. That is a different problem to solve than calling around to find out which ones those are.

Set milestones at billing-relevant stages

Aligning milestone completion with invoice triggers - deposit on acceptance, progress payment at a defined stage, final invoice on sign-off - means a missed milestone also flags a delayed billing event. You see the cash flow impact before it materializes.

What This Means for Billing and Sub-contractor Scheduling

The downstream effects of milestone visibility connect to both the finance and operations sides of a project business.

On the finance side, invoice timing is typically tied to job stages. If milestone completion is not tracked, the billing trigger is either missed or chased after the fact. When Zigaflow's project tracking is connected to the invoicing workflow, an overdue stage prompts action before the invoice date passes - rather than weeks after the customer has already noticed the job has not been completed to the stage that was billed.

On the operations side, sub-contractor scheduling depends on an accurate picture of where each job actually stands. A sub-contractor booked three days out based on an outdated status will either arrive to a site that is not ready, or need to be rebooked at short notice. Both outcomes absorb time and, in many cases, cost. Milestone visibility means the schedule can be adjusted with enough notice to avoid the worst of those secondary problems.

Don't wait for the problem to declare itself

The most common point of failure in reactive job management is the assumption that no news is good news. A milestone that has not been confirmed is not evidence that everything is fine - it is evidence that confirmation has not happened. Treat overdue stages as requiring a check, not an assumption.

For a trade business running multiple concurrent projects, the goal is not perfect information across every job at every moment. It is enough visibility to know which jobs need attention before they need rescue. Milestone tracking in Zigaflow is designed around that practical objective - not to create reporting overhead, but to surface the jobs where silence is the signal. See how project tracking works, or explore the job costing glossary term for more on connecting stage completion to financial outcomes.

project trackingjob managementmilestone trackingtrade businessesjob delays

Ready to run your business
on one platform?

Book a free demo and see how Zigaflow fits your team.

Book a free demoView pricing