← All white papersWhite Paper · September 2026

You don’t have an integration problem

Tools add up and connections multiply. The way out is not a better connector. It is one floor under the business, on the stack you are already paying for.

12 min read·Published by AI Pathway

Used by

  • Business Owner
  • Operations Manager
  • Office Manager
  • Business Systems Analyst

A client rings on Tuesday about the house at 42 Wattle Street. You open the estimating system for the contract sum, the accounting file for what has been invoiced, the shared drive for the latest set of drawings, somebody’s phone for the photo of the framing, and the spreadsheet for the items still open with the tiler. Five places. Two of them have the address spelled differently. One is a version from a fortnight ago and you cannot tell which.

In short

The problem
You are not missing a system. You have too many, and the only thing joining them is you. Every one of them holds its own copy of the truth, so the cost of keeping them in step grows faster than the number of tools does.
Why another integration does not fix it
You own neither end of any connection you buy. A field that is not in a vendor's interface is not in yours either, at any price, and their roadmap quietly becomes your roadmap.
What to build instead
One floor, holding the record, the gate, the argument and the identity. Specialist systems keep the specialist jobs and start reporting into it. You build the part that is specific to how you run your business.
The first step
Move the one spreadsheet that would stop work if it were deleted tonight. Put a job number on every row, and give it one rule it can enforce that the file could not.
What stays with a person
The price. The signature on a variation. The accounting ledger and anything with a statutory clock on it. And the live phone call, which is the one row that never goes to zero.

Take the spec to Claude, ChatGPT or Copilot. The sentence to paste is one click away.

Want the whole thing by email?

This paper, plus the rest of the library. One click to stop them.

1. The arithmetic nobody does at purchase time

Every tool in your business was bought to fix one real problem, by someone sensible, on a day when it was the right call. That is why this creeps up on you. Nothing here was a mistake.

The trouble is that tools add up and connections multiply. Two systems have one possible join. Four have six. Ten have forty-five. Nobody sits down and works that out, because you never buy ten at once. You buy the second and it is fine, and the third, and by the sixth the office manager has become a translation layer and the business has quietly hired a person to retype addresses.

Look at where the work actually goes. Not the work of building, the work of telling the business what the building work did. The site supervisor tells the office, the office tells accounts, accounts tells the client, and somewhere in that chain a number gets read off one screen and typed into another. Every one of those handoffs is a place where the business loses track of itself, and none of them appears on a job cost report.

Six caravans in a paddock joined by extension cords is not a house. It keeps the rain off for a while, every caravan is perfectly good, and you still cannot add a room.

2. Why another integration never finishes it

The instinct is to join them better. A connector, an automation tool, a developer for a fortnight. Sometimes that helps. It never finishes, and the reason is worth understanding before you spend the fortnight.

You own neither end of any connection you buy. Both ends belong to vendors solving their own problems on their own timetable. So three things are always true. A field that is not in their interface is not available to you at any price, and you find that out after you have designed around it. A change on their side is a change to your business, made without asking. And a connection can be repriced or retired by somebody who has never heard of you.

Here is the part that matters. Each of those systems holds its own copy of the truth. Its own customer list, its own idea of what a job is, its own version of the address. When you integrate, you are not resolving that. You are agreeing to keep several copies in step forever, and that agreement never expires. It is a subscription you pay in somebody’s afternoons.

A floor inverts it. One place holds the truth and everything else reads from it. At that point you are not integrating at all. You are reading and writing your own data, which is a different kind of problem, and a much smaller one.

3. What a floor actually is

Four things, and every one of them is boring, which is the point.

  • A record. One place where a job is a job, a client is a client, and each has a number issued by you. Not by the estimating system. Not by the accounting file. By you.
  • A gate. Something that can refuse. This is what separates a floor from a shared drive. A spreadsheet lets anybody type anything, which is why the spreadsheet is always a bit wrong and everybody knows it. A gate says no: this cannot be marked complete while that is open, this date cannot be typed because it is set by the step that earns it.
  • An argument. A report that reads the record directly and refreshes without anybody reformatting a file. The moment a number has to be prepared by a person before a meeting, the meeting is about the preparation.
  • An identity. Who is allowed to see and do what, taken from the accounts your business already administers rather than from a list of names typed into a report.

Record, gate, argument, identity. That is the whole idea. Every system you have ever bought is those four things wrapped around one job, sold at a monthly price, with its own login. Once you hold the four yourself, you stop needing a fresh set of them every time a new job needs organising.

4. The stack already under your feet

If you run Microsoft 365, you are paying for all four already.

SharePoint lists are the record. Power Automate is the gate, and it is the good kind, because a person cannot type past a flow. Power BI is the argument. Entra is the identity, already administered by whoever set up your email. The document libraries holding your drawings and certificates are already there, already backed up, already inside the security posture your clients and your insurer ask about.

You do not have to like Microsoft for this to be the practical answer. The argument is not that it is the best software. It is that the floor is already poured, already paid for, already backed up, and already survives someone leaving.

Two honest notes. Some of this steps up in cost the moment you need the premium tier of connectors, or Dataverse instead of lists, and that is worth pricing before you design around it rather than after. The build plans on this site carry that question job by job, and the short version is that a first build usually does not need it and a mature one usually does.

If you are on Google Workspace, the same four pieces exist under different names and there is a page here for that. If you are on neither, there is a page for free tiers. The argument is about the shape, not the brand.

5. Delete the step, do not automate it

This is the part most people get wrong, and it is where the real gain is.

Once there is a floor, the temptation is to take the current process and automate it step by step. Resist that. Automating a step preserves it. You want it gone.

Walk through the week and find every step whose only purpose is moving information from one place to another. Somebody reading a figure off one screen and typing it into another. Somebody emailing a spreadsheet so two people can look at the same rows. Somebody retyping an address. Somebody ringing the site supervisor for an update the supervisor already recorded somewhere else.

None of those should be automated. They should not exist. They exist only because the information was in the wrong place, and once it is in the right place the step has no job left. Automate it instead and you have built a machine to perform a task that did not need doing, which is worse than the spreadsheet was, because now it is load-bearing and nobody remembers why.

The same goes for the reports. A good share of the reporting in a building company exists to reassemble information the software split up. Put it back together at the source and most of those reports stop being written, not because you gave up on them but because the question they answered is now visible without asking.

This is the rare project where the right move is not to replicate what you do today. Use that. It is the only chance you get to delete process rather than add it.

6. What you build, and what you never build

Build what is yours. How your jobs actually move. Your registers: variations, outstanding items, defects, site instructions, stage invoices, subcontractor documents. Your checklists and the rules that hold them. Your handoffs. Your reporting. These are the parts where every builder is different, where off-the-shelf has always felt like wearing somebody else’s boots, and where the difference between you and the builder down the road actually lives. Nobody can sell you this well, because to sell it to you they would have to sell the same thing to your competitor.

Never build the regulated speciality. The accounting ledger stays the accounting ledger. Payroll stays payroll. Estimating and takeoff stay where they are. Anything with a statutory clock on it keeps the system built to respect that clock. These are not hard because of the software. They are hard because being wrong has consequences somebody has to carry, and that is not a licence you can generate.

Never replace something that is working. A floor adds a layer. It does not require you to remove a tool. The specialist systems keep doing the specialist job and start reporting into one place instead of being the place.

One rule settles most arguments about where a thing belongs: organise by the question, not by the software. Not “what does the estimating system hold”, but “what do I need to answer on a Tuesday morning”. A register per question. The software that used to hold the answer becomes a source, not a location.

7. The smallest version that is still a system

A first version here is not an app. It is one key, one register that runs on it, and one gate that can say no.

  • The key. Two lists, jobs and contacts, where the job number is issued by you and every other system’s reference is a column on the row. That is the entire long game, and it costs an afternoon now or a migration later.
  • One register. It should be the one that hurts. For most builders that is outstanding items across live jobs, because today it is a spreadsheet plus somebody’s memory and a missed row costs real money.
  • One gate. A job cannot reach a closed state with an open item against it. It has to block, not warn.
  • Money in one direction only. A nightly read of invoice state from the accounting file into a list, read-only, never written back. Two-way sync is where these projects die and you do not need it to get the screen.
  • One report. It reads the lists, and the test is that it refreshes without anybody touching a file.

Deliberately not in it: no mobile app, no offline, no two-way writeback, no scheduling or programme, no price book, no document migration, and no agent yet. The field app is what everyone starts with and what kills the project, because you end up with a lovely form writing into nothing.

The test, and you can stage it in a minute from your own data

Take a live job with an open item and try to close it. The system refuses. Then ask what is outstanding across every job right now and get it on one screen without opening a second system. Fail either and there is no floor yet, whatever got built.

8. Where this goes, once agents have a floor

This is why the idea is worth acting on now rather than in 2019, when the same four pieces already existed.

An agent with six logins is a worse employee than a person. It has to guess which system is right, it cannot see the whole job, and every answer needs checking against the others. That is why so many attempts at this feel like a party trick. The problem was never the model. There was nothing coherent to point it at.

An agent with one floor can do real work. Ask what is at risk of missing a stage invoice date this month and it reads one shape of data and answers. Ask which items have been open longer than a fortnight with no owner and it can tell you, because owner and clock are columns rather than conventions.

Three stages, and the first is already true.

  • It builds the thing. Your office manager describes the register they have always wanted and has a working list, a form and a gate the same afternoon. This is not a forecast. It is what changed, and it is the reason to pour the floor now.
  • It maintains the thing. The agent reads the floor, notices where reality has drifted from the design, and proposes the change. A register nobody has updated in six weeks. A gate people have found a way around. A field that is always blank, which means the process it described is not the process being run.
  • The org chart stops being a map of your software. Today work is organised around which system holds what, and people’s jobs are shaped by the gaps between them. On a floor, the running around is done by agents against one record, and what is left for people are the questions that carry consequence: what we charge, what we commit to, who we send, what we tell the client. You stop asking which system this lives in and start asking who is accountable for this outcome.

That is the end state, and nobody sells it. It is a consequence of having a floor.

9. The discipline that has to arrive with it

Here is the trap, and it is the mirror image of the opportunity.

If an agent can regenerate the whole thing from a prompt, you do not have a system. You have a slot machine. Ask again and it comes back different, and every check you did last month has to be done again from scratch, because nothing is the same shape any more. People are finding this out the expensive way with self-built tools: the second version is not an improvement on the first, it is a replacement, and it has to be reviewed like a stranger.

Yes, you can just ask an assistant to do all of this, in the same way you can run a building company out of a spreadsheet and a good memory. Both work until the day they do not, and that day is usually the day somebody asks you to prove what happened. The build, buy or have it built paper works through that decision properly.

So the floor carries the parts that do not regenerate.

  • The objects and their keys. A job is a job, with one number, forever. Agents can write the screens, propose the flows and draft the reports. They do not get to rename the job.
  • Gates that refuse rather than warn. A warning is a suggestion. Half the team reads past it on a Friday afternoon, and they are right to, because it was only a suggestion.
  • A log. Who did what, when, and what the state was before. Not for suspicion. For the day a client asks why, and the answer needs to be a record rather than a recollection.
  • A named owner on every queue, and a clock. The fastest way to tell a real system from a demo: point at any open item and ask whose it is and when it goes overdue. If the answer is in somebody’s head, it is not a system yet.

Get those four right and the agents can be as creative as they like above them, because they cannot break the shape. Get them wrong and the more capable the agent, the faster the mess arrives.

10. The first step, and what stays with a person

One spreadsheet, moved.

Pick the file that would stop work tomorrow if it were deleted tonight. Everyone in the office knows which one within two seconds. Put it on the floor with the same columns and the same person maintaining it, add a job number to every row, and give it one rule it can enforce that the file could not.

It pays the same day. Two people can work in it at once, nobody asks who has it open, and nothing gets overwritten on a Thursday. And the first time the list refuses a row somebody wanted to close, you will have felt the difference between a file and a system, which is worth more than being told about it.

Then stop. Do not build a second register until people have stopped emailing the old file around. The failure here is never technical, it is two registers running in parallel for three months. Two weeks later the measure is simple: nobody has asked for the spreadsheet back, and at least one row got refused.

What stays with a person. The price, always. A variation is chased for a signature and never agreed on a phone call. The accounting ledger, and anything with a statutory clock on it. Safety, and anything implying a licence. What you commit to a client.

And the one thing no floor can give you: the live phone call. A register can tell you that nobody has rung the client at 42 Wattle Street in nine days. It cannot make the call. That needs a number, a carrier, calling hours, the disclosure spoken at the top, a Do Not Call check before the dial, and a recording and transcript kept where somebody can read them later. That is not a feature you generate. It is the one row in the whole build that never goes to zero, and it is the part we run: a voice agent on your number, in your business name, writing what happened back into your own records.

Everything else on this page you can build yourself, and now you can build it in an afternoon. That is the honest shape of it, and it is why the standards on this site are published rather than sold.

The part we run: the calls

Get Paid, $199 a month, rings every open quote for a decision and every stage invoice for a payment date, against your Xero, and writes the date back. Booked After Hours, $119 a month, answers the enquiry call you could not take, on your own number. Flat monthly, no call caps, and nothing on your floor has to move for either.

Technical? The build standard is open. Take it.

Related reading

Published by AI Pathway · https://aipathway.com.au

Read the full interactive version at https://aipathway.com.au/explore-ai/integration-problem-builders