Field Service Software Problems for Plumbing and Electrical Contractors: The 7 That Cost Real Money, and How to Avoid Them

Why does the tech app end up as an afterthought?

The biggest scope failure in trades software is designing the office first. It happens naturally. The people commissioning the build sit in the office, the demonstrations happen on a laptop, and the dispatch board is the screen everyone can picture. The mobile app gets described as a companion, which is exactly backwards.

Every fact in the system originates in a truck. Arrival time, what was found, what was fitted, the photo of the panel, the customer signature, the payment. If capture in the field is awkward, slow or unreliable, everything downstream is estimated rather than recorded, and your job costing, your utilisation and your margin reporting are all describing a fiction politely.

The symptoms are recognisable. Techs complete work and phone the office to have someone type it up. Photos live in a camera roll and never reach the property record. Invoices go out days later because the job was closed from memory. And the dispatch board that looked so good in the demonstration slowly fills with stale statuses nobody trusts.

The fix is a sequencing decision. Design and test the field application first, on a real phone with a cracked screen, in a basement, with a tech who is not enthusiastic about technology. Build the office screens around what the field can reliably produce. Any developer who wants to show you the dashboard before they have watched a tech work has the priority backwards, and their build will reflect it.

What goes wrong when you migrate customers, properties and pricebooks?

Trades data has a specific shape that migrations get wrong, and the errors surface months later in the least convenient way.

The first is that your records are customer shaped when the work is property shaped. A landlord with nine units, a homeowner who moved, a commercial account with four sites: if history attaches to a person rather than to an address and the equipment at it, then a tech arriving at a repeat callback cannot see that the same water heater was serviced twice last year by two different techs. Deduplicating on phone number or name merges households that should be separate and separates accounts that should be joined.

The second is the flat rate pricebook. Everyone assumes it exports and imports. In practice it contains task descriptions written for customers, labour assumptions, material lists and margin rules that were tuned by hand over years, and half of it is out of date because supplier costs moved. Importing it unchanged simply relocates stale pricing into a new system where it will now be applied faster.

Practical fixes. Model property and installed equipment as first class records with serial numbers and service history, and attach customers to them rather than the other way round. Treat the pricebook as a rebuild, not a transfer, and use the migration as the moment to reprice against current supplier costs. Migrate open jobs, active service agreements and two to three years of history, and scan older paperwork as attachments on the property instead of re keying it.

Why do the accounting and payment integrations break after launch?

Because they are quoted as connectors and delivered as reconciliation problems.

The accounting sync is the usual offender. Pushing invoices into your accounting system is straightforward. Making a month close cleanly is not, and that is where the fiddly work lives: deposits and progress payments, partial refunds, warranty callbacks that should not be revenue, material costs landing against the right job, sales tax rules by jurisdiction, and credit memos. Everything looks fine for weeks because the office is still working, and then the bookkeeper cannot tie the month and quietly starts keeping a parallel spreadsheet.

Payments break differently. Taking a card in the driveway is a real improvement to your working capital, and it also puts you in scope for the Payment Card Industry Data Security Standard. Any design that stores card numbers in your own database rather than holding processor tokens is an expensive mistake, and it is one that is easy to make when a developer is trying to be helpful about card on file.

Supplier catalogue feeds fail through drift. Prices move, part numbers get superseded, and a pricebook wired to a stale feed prices jobs at last year's costs on today's work.

The fixes: define acceptance for the accounting integration as a period that closes and ties, not as invoices appearing. Insist on tokenised payments with no card data in your systems. And make catalogue updates a visible event with a review step, so nobody discovers a price change by losing money on it.

What happens when job costing and compliance are not properly covered?

Two gaps do most of the invisible damage in trades builds.

The first is job costing that only counts the first visit. Real jobs have second truck rolls, a helper for two hours, a part collected from the supplier on the way, and sometimes a warranty callback three weeks later. If those do not attach to the original job, your margin report is not wrong by a little, it is systematically flattering, and you will keep selling the work that loses the most money because it looks fine on paper. Warranty callbacks in particular need to be visible as a cost against the original job and as a quality signal against the tech and the part.

The second is the compliance layer around the trade. Licence and certification expiry by tech, permit status on jobs that need one, and insurance certificates for commercial accounts are all things a business is expected to control and most systems leave as a spreadsheet. A dispatch board that will happily assign an unlicensed tech to a job requiring a licence has created a liability rather than removing one.

The fix is to make these constraints rather than reports. Costs attach to the job whatever visit they arrived on, callbacks link to their parent job, and scheduling checks certification before it offers a tech. None of this is difficult, but it has to be specified, because no developer will invent it for you.

Should you build custom or configure what you already own?

Most contractors under roughly forty techs should not build, and this deserves saying plainly. ServiceTitan, Housecall Pro, FieldPulse and Jobber exist because the common trades workflow is genuinely well understood, and a packaged product gets you live in weeks for a monthly fee. A five truck shop that needs dispatch and invoicing does not need a bespoke platform, it needs to finish setting up the one it has.

Before pricing custom work, audit the configuration you already pay for. The recurring finding is a shop using perhaps a third of its product: good, better and best options never built, service agreements tracked in a spreadsheet because nobody set up recurring job generation, review requests never automated, and a pricebook half populated so techs quote from memory.

The build case sharpens on three signals. Per tech pricing has become a five figure annual line that grows every time you hire. Your workflow genuinely does not fit the box, usually an unusual service agreement model or a job costing method the product forces you to abandon. Or you need to own the roadmap because a supplier feed, a customer portal or a warranty system matters to you and will never be a vendor priority. A middle path exists and is often the right one: keep the accounting and the payment processor, and build only the dispatch and estimating engine the packaged tools get wrong for your trade.

How do hidden costs get into the quote?

Trades quotes go wrong in a consistent set of places, and none of them are the screens buyers look at.

• Offline reliability. Real engineering with queued updates, conflict handling and photo sync, not a checkbox, and the first thing cheap builds cut.
• Accounting reconciliation. Priced as a connector, delivered as a close that has to tie every month.
• Pricebook build. Rarely a transfer, usually a rebuild with repricing, and it consumes your team's time as well as the developer's.
• Rollout and training. Getting thirty techs onto a new tool is a programme, not a launch email, and it is the difference between software and shelfware.
• Multi branch roles and reporting. Cheap to imagine, expensive to retrofit once the data model assumed one location.

Digital Heroes delivery bands for this category put a first release covering scheduling, the mobile job app, basic invoicing and one payment integration at $40,000 to $70,000 over 3 to 4 months, a full platform with dispatch, flat rate estimates, job costing, accounting sync and payments at $70,000 to $130,000 over 4 to 7 months, and multi branch systems above $130,000. A quote materially below that band has usually cut the offline work or the accounting sync, which are precisely the two things that fail in the field.

What separates a build that works from one that fails here?

Working builds are proven on the worst day, not the best one. Pilot with one crew running live jobs while the office keeps the old process as a backup, and choose your least technical tech as the test rather than your most enthusiastic. If they can complete a job, take payment and close it out in a crawl space with no signal, the build is real. If the pilot only ever runs in good conditions, you have tested nothing.

They are built by people who watched the work. A developer who insists on riding along or shadowing dispatch before writing code will build something techs use. One who skips that step builds a beautiful demonstration that falls apart on the third truck roll of a Monday.

They measure the right thing after launch. Not logins, but the share of jobs invoiced the same day, the share of jobs with photos attached, and the number of jobs still being closed by phone call to the office. Those numbers tell you within a fortnight whether adoption happened.

And they leave you holding the keys. Repository, cloud infrastructure and payment processor accounts in your name, with a named support arrangement for month four when the day one bug list has aged into a maintenance list. A contractor who traded per seat fees for a dependency on one development firm has swapped a predictable cost for an unpredictable one.