Five Systems, One Picture: How Small Businesses Actually Make Decisions From Data

Ask a small business owner how last month actually went and you will usually get a feeling, not a figure. Not because the numbers don't exist — they do, scattered across five different systems — but because no single screen shows them together. This post is about that gap: why it exists, what it does to decision quality, and the practical order of operations for closing it.

The Spreadsheet of Truth

Almost every service business we talk to has one. A spreadsheet, maintained by hand, where someone — usually the owner or the office manager — exports jobs from one system, copies payments from another, eyeballs the ad spend from a third, and tries to reconcile the lot on a Sunday night.

The spreadsheet of truth has four structural problems:

• It's stale the moment it's saved. By the time you're looking at it, the numbers have moved.
• Manual keying introduces errors. A transposed digit in a payment amount, a job pasted into the wrong month, a customer counted twice under two spellings of their name.
• One person understands it. The formulas, the colour coding, the reason column Q exists. When that person is on leave, the business is flying blind.
• It can only answer the questions someone thought to add columns for. New question, new export, new hour of copy-paste.

None of this is a criticism of the person maintaining it. The spreadsheet exists because it's the only place the whole business is visible at once. That's the real finding: the demand for a single picture is so strong that people will do hours of manual work every week to fake one.

The Five Systems Every Service Business Already Runs

Look at a typical Australian service business — a trades company, an inspection service, an allied health clinic — and you'll find the same five layers, whatever the specific brand names:

Each of these tools is good at its own job. The jobs system knows the work. The payment platform knows the money movement. The accounting package knows the true position. The CRM knows the people. The ad platforms know what you paid for attention.

The problem is that no business question worth acting on lives inside a single layer.

The Answers Already Exist. Nothing Joins Them.

Here's the uncomfortable structure of it: every decision-grade question spans at least two systems.

• What does a booked job actually cost me to acquire? — advertising plus CRM plus jobs.
• Which service line makes money after labour and materials? — jobs plus accounting.
• Which past customers are due to come back and haven't? — jobs plus contacts.

Each system's built-in reports only tell you its own side of the story. Your ad platform will happily report a cost per conversion — but its idea of a "conversion" is a click on a call button or a form submission, not a booked, completed, paid job. Your accounting package knows revenue to the cent but has no idea which ad channel produced it.

And the joins are genuinely ugly at the data level, which is why "just export both and VLOOKUP it" dies quietly. This is log-reading work:

• One system stores the phone number as +61 4xx, the other keeps the leading zero. A naive match finds nothing; matching on the last nine digits finds the customer.
• Payment references rarely carry the invoice number cleanly, so a payment and its invoice have to be matched on amount, date window and customer — and two jobs for the same customer on the same day will collide unless the matching logic is built to handle it.
• Timestamps arrive in UTC while your ledger thinks in Sydney time. A payment taken on Friday night lands in Saturday's books unless the join applies the offset — and around daylight saving the offset changes.
• The same customer is "Jo-Anne" in the CRM, "Joanne" in the jobs system and "J Smith" on the bank statement.

None of these problems are exotic. They're the standard failure points, and an integration is only trustworthy when it's built to handle them deliberately — with a verification layer that catches the mismatches instead of silently dropping them.

What Becomes Answerable Once Systems Share Data

When the five layers feed one database, a specific set of questions moves from "gut feel" to "look it up". Three examples that matter most for service businesses:

Cost per lead — and cost per booked job — by channel. Join ad spend to enquiries, enquiries to quotes, quotes to booked jobs. Now you can see that one channel produces cheap enquiries that rarely book, while another produces fewer enquiries that convert at a much higher rate. Every budget decision changes once you can see past the click.

Margin by service line. The jobs system knows the service type and the hours. The accounting layer knows the materials and the labour cost. Joined, you can see which service lines carry the business and which ones are busywork priced too low. Most owners have a hunch about this; the joined data regularly disagrees with the hunch.

Rebooking gaps. Any business with a repeating service — annual inspections, termite checks, aircon servicing, six-monthly cleans — is sitting on a list of customers who are due back and haven't booked. That list is a join between job history and contacts, filtered by date. It's the cheapest lead source most businesses own, and without the join it doesn't exist as a list at all.

Beyond the big three: quote-to-book conversion by tech, enquiry response times against outcomes, revenue by suburb against where the ad spend actually goes. Once the data is joined, each new question is a query, not a project.

A Worked Example: Pink Slips NSW

Pink Slips NSW is a vehicle inspection business we operate ourselves, which makes it the place we prove this approach before we sell it to anyone else.

The build runs sixteen integrations in one codebase — bookings, payments, messaging, advertising and analytics all feeding the same picture. The operational result is full automation of the admin layer: hundreds of payments a year reconcile themselves, and the weekly admin load on the business is zero hours.

The decision-making result is the part relevant to this post. With ad platforms joined to actual bookings, spend could be steered by cost per booked job rather than cost per click — and cost per lead dropped 80%. That improvement came from the join itself: with bookings tied to spend, budget was steered by cost per booked job instead of cost per click, and moved to the channels that were actually producing jobs.

The full breakdown of what's connected and how is in the Pink Slips NSW case study.

The Ladder: Set Up, Connect, Troubleshoot, Audit, Analyse

There's a right order to this work, and skipping rungs is how businesses end up with expensive dashboards displaying wrong numbers.

1. Set up. Each system has to be configured properly on its own before joining anything. Conversion tracking that fires once per enquiry, not three times. Invoice references that carry through to payments. A CRM that captures the enquiry source instead of "Direct" for everything. We can set up and configure this layer across the common stack — including Xero and HubSpot where they're the accounting and CRM layers.

2. Connect. The joins themselves: webhooks where the platform supports them, API pulls where it doesn't, nightly syncs into one database. This is delivery work we do constantly — Stripe payment events, Google and Meta ad spend via their APIs, GA4 and Search Console data, SMS and email via Twilio and SendGrid. We've built a ServiceM8 sync for a Sydney trades company that mirrors jobs and payment status into a single database, so the office sees the pipeline in one place instead of tab-hopping.

3. Troubleshoot. Most businesses don't arrive with a blank slate — they arrive with a half-built Zapier chain, a webhook that stopped firing months ago, or an integration a previous developer left undocumented. Repairing these is its own discipline: read the logs, find where the data stops, fix the join, then prove it with real records end to end. If that's the situation you're in, our integration rescue service exists for exactly this.

4. Audit. Before anyone makes a decision off the joined data, verify it against source of truth. Do the payment totals match the bank? Does the booked-jobs count match the jobs system? The verification layer is built to catch double-counted conversions, dropped records and timezone drift — because a dashboard that's confidently wrong is worse than no dashboard.

5. Analyse. Only now do dashboards and reports earn their place. With verified joined data underneath, the analysis layer is the easy part.

Notice that "buy a dashboard tool" isn't rung one. Dashboards are rung five. Feeding a reporting tool from unverified, unjoined systems just gives the spreadsheet of truth a nicer interface.

Start With the Audit, Not the Dashboard

If this describes your business, the first step isn't a big build. It's an audit of what you already have:

• What does each of your five systems actually hold?
• Which joins already exist, and do they still work? (A recurring audit finding: an integration that stopped syncing quietly at some point, with nobody noticing.)
• Where are the data-quality landmines — duplicate contacts, missing sources, references that don't carry through?
• Which single question, answered first, would most change a decision you're currently making on gut feel?

That last one matters. The businesses that get value from this don't connect everything at once — they pick the one join that answers their most expensive open question, build it, verify it, and then extend from there.

We do this as a defined engagement: audit first, then a recommended build order, then the connection work itself. The full scope of what we connect and how the process runs is on our integrations service page. Tell us what your five systems are and which question you can't currently answer, and we'll reply within 1 business day.