Your Scheduler Has No Hands

1. The Plan Is Wrong the Moment Reality Moves

If you run SimPRO, ServiceM8, AroFlo or Tradify, the hard part is already solved. The plan lives in one place. Every job has an owner and a state. Nobody has to ring the office to find out what was agreed. At representing the work, this software is good, and it has been good for years. Nothing below argues otherwise.

What it cannot do is stay true. The plan is wrong the moment reality moves, and in trades reality moves constantly. Jobs run over. Parts do not arrive. A technician calls in sick at six. A customer is not home. None of that changes the record by itself.

We went looking for evidence of that gap in an odd place: job advertisements. Between 18 and 20 August 2026 we read 41 contactable ads posted on Seek by Australian trades businesses hiring office and administrative staff. That is a small sample over a narrow window, so read what follows as a description of what those 41 ads say rather than a survey of the industry. It is stated up front because the honesty is most of the credibility.

Of the 41, 35 describe scheduling work. More usefully, 14 of the 41 name a job management system outright. Those 14 are the interesting ones. They are not businesses shopping for a scheduler. They bought one. They are hiring a person to work it.

2. Every Change Has Three Parts, and the Software Does One

Keeping a record true is a continuous editing job, and every edit has the same three parts.

1. 1

   Input: learning that reality changed

   A customer rings. A technician texts from the van. A supplier emails a revised delivery date.

2. 2

   Mutation: changing the record

   Opening the job and typing it in, so the plan matches the world again.

3. 3

   Output: telling the humans it affects

   The customer waiting at home, the technician whose next job just moved, the supervisor who committed to a date.

Your job management system does the second one. It has no ears and no mouth. A person sits between the world and the database, and that person’s day is the first and the third.

The ads describe this almost literally. These are published duty lines, quoted as written and attributed to nobody:

Three of those four describe mutation. The fourth describes output. None of them describe deciding what the schedule should be, and that is the tell. Of the 41 ads, 26 titles said administrator and 8 said scheduler. Setting the schedule is generally the owner’s job or a supervisor’s. The role being advertised is absorbing change on behalf of a schedule somebody else set.

Narrowing to the 14 ads whose businesses already name a system, the shape of the day comes through:

• 13 of 14 ask the person to talk to customers.
• 9 of 14 ask them to chase something.
• 7 of 14 involve quoting or converting.
• 6 of 14 ask them to move data between systems.
• 6 of 14 involve variations or contract disputes.
• 3 of 14 mention confirming or rescheduling.
• 2 of 14 mention asking where the technician is.

The base is stated on every line on purpose. A percentage on a base of 14 would read as precision this sample cannot carry.

3. Two Consequences, and the First Is Counterintuitive

The first of those explains the apparent contradiction in section 1 on its own. The second is worth checking against your own week before you read further. If your work is mostly booked installs weeks out and the schedule rarely moves after Monday, much of what follows will not apply to you, and it is better to find that out here than three sections later.

4. The Input Step Is Not Listening, It Is Noticing

The obvious reading of section 2 is that the missing piece is a pair of ears and a mouth: something to take the calls and make the calls. That is the wrong first move, and the ads say so. Confirming and rescheduling appears in 3 of 14. Asking where the technician is appears in 2 of 14. Chasing appears in 9 of 14 and moving data between systems in 6 of 14. The volume is not in the conversation.

Most changes are already visible inside the system you own, and they are visible as an absence:

None of that needs a phone call to detect. It needs the system polled against an expectation of what should have happened by when.

5. What Closing the Loop Takes

Six components, in this order. The order matters more than any single piece, because each one is only worth building once the one above it exists.

1. 1

   An expectation model

   For every job, purchase order, invoice and certificate: what should have happened by when. Almost all of it is derivable from data you already hold, which is why this step is cheaper than it sounds.

2. 2

   A divergence engine

   Poll, compare, raise typed exceptions. This is the component that converts a person's memory into a queue, and it carries most of the value.

3. 3

   An action policy per exception type, tiered by cost of error

   Cheap ones act. Expensive ones propose and stop. Nothing gets a blanket permission.

4. 4

   Propose versus commit

   Status updates, notes and notifications commit automatically. Schedule changes arrive as a one-tap proposal. This is how authority is handed over incrementally rather than demanded up front.

5. 5

   Write-back with an audit trail

   Every action attributable and reversible. If you cannot see what it did and undo it, you will not let it do anything worth doing.

6. 6

   An explicit never-automate list

   Quoting a non-standard job. A variation. A complaint. Anything touching a payment dispute. Written down before you start, not discovered afterwards.

6. What You Could Measure Yourself, and What Would Prove This Wrong

The other papers in this library carry a return on investment section. This one does not, and the reason is worth stating plainly: we would have to invent the numbers. There is no customer behind this paper and no measured saving. Job ads tell you the work exists. They tell you nothing about what it costs to do, or what it would cost to stop.

Here is what you can measure for yourself in a fortnight, without buying anything. Pick one week. Every time somebody in the office learns that a job moved, log two things: how you found out, and how long the gap was between the change happening and the record showing it. Nothing else.

Then read it back. There are three honest outcomes.

• 1.Mostly “somebody rang us”. The input problem is real and it is external. Harder to close, and the place where a conversation layer eventually earns its keep.
• 2.Mostly “somebody went looking”. The input problem is real and it is internal, which is the tractable one. Everything in section 5 applies, and the expectation model largely writes itself from the rows you just logged.
• 3.The gaps are minutes, not hours. Your process is already tight, nothing here will pay for itself, and you should spend the money elsewhere.

That third outcome is a real result rather than a failed experiment, and we would much rather you found it in a fortnight for nothing than after buying something.

7. Where to Start

Not at the top of section 5. Start at step two, on its own.

A divergence engine needs read access and nothing else. No change to how your team works, no new app for technicians to ignore, no authority handed to anything. It produces a single artefact: a list of what diverged from plan last week that nobody was told about.

That list answers the question for you. If it is uncomfortable reading, the rest of section 5 is worth building, and you already know which exception types to build first, because they will be the ones filling the list. If you recognised every line on it, the noticing is not your problem, and we will say so rather than sell you the next five steps.