Job Management Systems in New Zealand

Where the money leaks

In most service businesses the loss is not dramatic. It is a job quoted in a notebook and never followed up. Hours written on a docket that never made it onto an invoice. Materials fitted and never charged. A callback that was warranty for one customer and billable for another, and nobody can now remember which.

Add those up over a year and the number is usually larger than the software. Before talking to anyone, take one month and count: quotes sent versus quotes followed up, hours recorded versus hours invoiced, materials issued versus materials charged. That is the business case, and it is more persuasive than any feature list.

Try a product first. Seriously.

ServiceM8, Fergus, Tradify, simPRO and others are mature, well supported, and cost a fraction of a build. A large share of businesses that ask about custom software should be using one of them, and a good developer will say so.

Custom earns its place in three situations:

• Your quoting is the advantage. If the way you price work is why you win jobs — complex takeoffs, unusual materials logic, rates that vary by contract — a product will flatten that into something generic.
• You have hit a ceiling. The product does 85% and the remaining 15% is handled by a spreadsheet somebody maintains at night.
• Per-user pricing has turned. At forty field staff, $50 per user per month is $24,000 a year. Ownership starts to look different.

If none of those describes you, the honest answer is to buy something.

The field app is the whole risk

Office software gets used because people are at desks. Field software gets used only if it is faster than the paper it replaces, on a cracked phone, in the rain, with gloves on, by someone who did not ask for it.

Offline is not optional here. New Zealand and Australia have plenty of sites with no signal — rural jobs, basements, plant rooms, half the Coromandel. An app that spins when there is no reception gets abandoned inside a fortnight, and you will not get a second chance at adoption.

Offline roughly doubles the complexity of the app, because reconnecting means resolving changes made in two places. That has to be in the brief from the beginning. Retrofitting it is close to a rewrite.

Ask every developer whether they have shipped an offline-capable field app, and what happens when two people edited the same job. The answers will be noticeably uneven.

Scheduling is harder than a calendar

Dispatch looks like a drag-and-drop calendar and behaves like a constraint problem. The crew member must be certified for that equipment. The job needs two people and a specific vehicle. Travel between sites is not free. This client will only accept mornings. And when the 8am job runs three hours over, everything after it has to move.

Be honest about how much of this you need. Full optimisation is expensive and often less useful than a clear board that a competent dispatcher can reshuffle quickly. Many businesses are better served by good visibility than by an algorithm.

Connect it to accounting on day one

The largest single time saving in most of these projects is invoices raised from completed jobs flowing into Xero or MYOB without anyone typing them again. It is also where the money leak closes, because an invoice generated from recorded time and materials cannot forget the materials.

Ask what flows back the other way — paid status, customers, credit terms — and what the system does when the accounting platform is unavailable. It should queue and retry, never drop.

Roll out to one crew

Field software meets reality fast. Give it to one crew, ideally one that will tell you honestly what is wrong, and watch for two weeks. You will learn that a button is in the wrong place, that a screen needs to work one-handed, and that something you thought essential is never used.

Fixing that before the other thirty people see it is the difference between software the crew defends and software they work around.

Comparing quotes

• Offline experience. Shipped, not theoretical.
• Accounting integration. Which platform, which direction, what happens on failure.
• Phase one. Anyone proposing the core flow before the scheduling engine is showing judgement.
• Product honesty. Which off-the-shelf options they considered and why a build wins here.
• A reference in your trade. Ask to speak to a business still running their software.

Describe how a job moves through your business today, and where it falls over. Developers who build for trades and service businesses will tell you what it takes — and whether a $60-a-month product would do it instead.