Why your software doesn't talk to your other software

Most firms I look at have plenty of software. The enquiries arrive in an inbox, the jobs live in a job record, the prices live in a rate card, the templates live in a folder, the photos live on somebody’s phone. All of it works. None of it talks to the rest, so a person reads one thing and retypes it into another. That person is the join. Finding the few joins worth building is usually worth more than buying anything new.

Schematic drawing. Six boxes on the left, numbered 01 to 06, show where a firm's facts already live: the inbox holds scope, attachments and sender; the job record holds the site address and order number; the rate card holds rates, thresholds and uplift rules; the templates hold the clause library and approved version; the phone holds site photos and timestamps; the spreadsheet holds the column nobody documented. All six feed into a single block in the middle marked BY HAND, where a person reads it all and retypes it. Three lines leave that block to a quote, a job pack and a report. The caption reads: the join is a person. It works. It is also the slowest part of the week.

Why does information get retyped when we already have systems?

Because the systems were bought one at a time, for good reasons, years apart.

The accounts package came first. The job management tool came when the jobs got too many for a diary. The templates were built by whoever was doing the work at the time. Nobody sat down and planned how it would all fit together. Each purchase solved the problem in front of it, and each one stored its information in its own place.

That is not a failure. It is what growing looks like. The cost only shows up later, in the hour someone spends copying a site address out of an email and into a method statement that already exists in a folder.

How common is this?

Here is what the published figures say, and how far to trust them.

The government’s UK Business Data Survey 2026 asked businesses using AI tools whether those tools were joined up with the systems they already ran. In construction, 14% said they were. Across information and communication firms the figure was 39%, and in manufacturing 12%. That is a survey about AI tools only, so read it narrowly. It still points at the same thing. Buying a tool and joining it up are different jobs, and among the construction firms using these tools, the second one mostly is not happening.

On how many tools a firm is running, I found no British count. The nearest is Autodesk’s State of Digital Adoption in the Construction Industry 2026, which Deloitte Access Economics ran across 954 construction and engineering businesses. Those were in Australia, Hong Kong, India, Japan, Singapore and Vietnam, not the UK. The count of tools it is often quoted for is not on the report’s public page, so I have left it out.

Everything else I read on this was supplier marketing with no sample size attached, including some confident pound figures for what disconnected software costs a small business. I have left those out. If a number does not say who was asked and how many, it is not evidence.

From my own work: in some of the systems we have running right now, the thing that took the time was not the writing. It was moving facts from one place to another.

What is a join, exactly?

Four steps, and only four.

Something arrives or changes. Your rule says what it means. A fact gets written somewhere else. A person checks the result before it goes anywhere.

Schematic drawing titled The joins. The same six boxes on the left, numbered 01 to 06, showing where a firm's facts already live. All six feed into a tall panel in the middle marked ON YOUR RULES: the system, built on your own rules, which checks what arrived against your list, drafts from your templates and rules, and assembles the numbers into your format. One line leaves the panel into a highlighted block: a person signs it off, every time. Three lines leave that block to a quote, a job pack and a report. The caption reads: nothing is issued without a named sign-off.

A join is not a new platform and it is not a rip-and-replace. Your existing tools stay where they are. The join reads from one, applies a rule you wrote down, and writes to another, where a person checks it before it goes anywhere.

The rule part is the bit that takes the time, and it is the bit worth doing properly. Pricing off your rate card is a rule. Knowing which client walks away above a certain figure is judgement, and judgement stays with your person. We write the rules down with you before anything is built, you read them and sign them, and the system applies them the same way every time.

Which joins are worth building?

Start by finding where the retyping happens, not where the software is.

For a week, note every time somebody reads a fact in one place and types it into another. Site address out of an email and into a job pack. Order number off a PDF and into the accounts package. A figure off a subcontractor’s text and into the monthly report. You will get a list, and a few will come up every single day.

Three joins are worth checking first.

The intake join. Work arrives without the drawing, the address or the order number, and somebody spends a long time chasing it. The fix is a check against your own list of what must be present. It drafts a request for the rest in your wording, for you to check and send. It is usually the cheapest thing on the list to build and the fastest to pay back. It is also easy to miss, because it does not feel like paperwork. It is covered properly in how to pick the one document to automate first.

The job record to document join. The address, the scope and the access arrangements are already recorded. The method statement or job pack needs all three. Nobody should be typing them twice.

The document to report join. Last, always. A report is assembled from data, and the data has to exist and be clean first. Build this one early and the early weeks go on fixing job sheets.

What should not be joined?

Plenty.

If it does not happen more than once a month, leave it. The build costs more than the problem, and you will have spent the budget that should have gone on the thing happening many times a week.

If the fact only exists in somebody’s head, or in a phone call that never got written down, there is nothing to read. Fix that first, or accept that a person keeps doing it.

And if two people disagree about what the rule is, that is not a software problem. It is a rule problem, and it needs settling on paper before anything applies it automatically. We find this on nearly every build. It is better found in a document than in a live system.

Where does the person stay?

Everywhere it matters.

Nothing is fully automated where a mistake costs money or safety. That is a permanent rule at Fenwick Automation, not a stage we grow out of. A quote gets a human check. A method statement for a live site gets a named person’s signature, recorded, every time. What goes away is the typing, not the deciding.

The honest version of the pitch is small: the draft is waiting for your person when they sit down, instead of hours away. They read it, fix the one thing only they would spot, and send it.

What to do this week

Take a notepad and write down every retype for a normal working week. Do not change anything, do not tidy anything up, just record it. At the end of the week, count which ones happened most.

If you have already worked out what your paperwork costs you a year, put the two lists side by side. The join worth building is usually where the biggest cost and the most frequent retype overlap.

If you would rather talk it through, book the 10-minute call. Describe the document that eats the most time in your week and where its facts get copied from. I’ll tell you whether it fits and give you a rough estimate: a range for the first route. If it’s not worth doing, I’ll say so.

Sources

Blake Fenwick, founder of Fenwick Automation

Some of the systems we've built, running right now. More about Blake Fenwick and how we work.

Blake Fenwick on LinkedIn

Find out whether it's worth doing.

10 minutes. You tell me the document that eats your evenings. You leave knowing whether it fits and roughly what it would cost.

Book the 10-minute call

Work out what it costs