How do we stop typing the same data into three different systems?

Why does the same data end up typed more than once?

Because every system arrived on its own. The website form came with the website. The CRM came when sales got busy. The accounts package came from the accountant, and the job tracker came from whoever was most annoyed at the time. Each one solved a real problem, and nobody planned how they would share a customer's name, address and order between them.

So a person does it. An enquiry lands by email, someone types it into the CRM, then into the job sheet, then into the accounts when the invoice goes out. Three copies of one fact, each typed by hand, each a chance to get it slightly wrong.

It rarely looks like a problem from the outside. It looks like someone being busy.

What does it actually cost?

Time is the obvious cost, and the least interesting one. The bigger cost is that the copies drift apart.

A customer changes their email address. Sales updates the CRM. Nobody tells accounts, so the next invoice goes to the old address and gets paid late. A postcode gets mistyped in the job tracker and the engineer goes to the wrong street. A company name is spelled three ways, so the report that counts customers counts the same customer three times.

None of these is dramatic. They are small and constant, they add up, and they land on the people who then spend an afternoon working out which version is true.

There is a legal edge too, where the data is about people. The ICO's guidance on the accuracy principle expects all reasonable steps to keep personal data accurate, so that it is not "incorrect or misleading as to any matter of fact". Its checklist includes having processes to check the accuracy of the data you collect, and recording the source of that data. The ICO also notes that this guidance is under review following the Data (Use and Access) Act, so check the current version before relying on it.

Hand typing the same details into three places works against both. When the CRM and the accounts disagree about a customer's address, which one is the source? Usually nobody can say.

What is the fix, in plain terms?

Type it once, at the point it enters the business, and let the systems pass it along from there.

That one sentence covers most of the work. The detail is deciding where "once" happens and how each system then gets its copy.

Approach	How data moves	Good for	Watch out for
Typing it again	A person reads one screen and types into another	Nothing, long term	Errors, delay, nobody owns the true version
Export and import	A file goes out of one system and into the next	Weekly or monthly batches	Someone still has to remember to do it
Linked form and sheet	The form writes straight into a spreadsheet	Enquiries, bookings, simple requests	Sharing settings on the sheet
Script or API	Software sends the data across when something happens	Anything frequent or time sensitive	Needs building, testing and an owner

What do the tools you already pay for do?

Often more than you think. If you run on Google Workspace, start with forms.

Google's guide to form responses explains how to send responses to a new or existing linked Google Sheet. That is the useful option. Every enquiry, booking or request arrives as a new row with nobody copying it. The website or the team fills in the form, and the sheet becomes the place the data was typed once.

One catch from the same page. When you create a new response spreadsheet, form collaborators get access to it automatically, but later changes to the form's permissions do not carry across to the sheet. If someone leaves, remove them from both.

The next step is getting that row somewhere else without a person in the middle. Apps Script's installable triggers include one that runs when someone responds to a form. That is the moment a short script can tidy the data, check it and pass it on.

Passing it on is where APIs come in. An API is a door a system leaves open so other software can read from it or write to it, with permission. Google's guide to external APIs says Apps Script can work with APIs from all over the web, using its UrlFetch service to make the requests. Many CRMs, accounts packages and job systems offer one, so check what yours provides before assuming it cannot be connected. Where they do, the new enquiry can create the contact in the CRM and the customer in the accounts package, from the same row, with the same spelling.

Copy and paste is not an integration. It is a person doing the integration's job.

We build this kind of link as process automation, and in Google's own tools through our Apps Script service.

How do you find where the double entry happens?

Follow one piece of data through the business, end to end. Pick something common, such as a new customer, and write down every screen it gets typed into, by whom, and what they copy it from.

Do it with the people who actually do the typing, not from the org chart. They know the workarounds. They know about the spreadsheet that sits between the CRM and the accounts because the two never quite agreed.

You usually end up with a short list that looks like this.

Data	Typed into	Typed by	Copied from
Customer name and address	CRM, job tracker, accounts	Sales, office, accounts	The enquiry email
Order details	Job tracker, accounts	Office, accounts	The quote
Contact changes	Wherever the person remembered	Whoever took the call	A phone call

Then decide, for each row, which system owns the truth. The others should read from it, not hold their own hand typed copy. That decision matters more than any tool, and it is the step people skip.

Where do people get this wrong?

The common mistake is buying another system to fix it. A new platform that promises to do everything becomes a fourth place to type the customer's name, and the old three do not go away because something still depends on them.

The second mistake is linking everything to everything. Five systems each syncing with the other four means nobody knows which way a change flows, and a typo made in one place spreads to all of them before lunch. Data should flow one way, from the system that owns it, to the systems that need it.

The third is building the link and walking away. Connections break. A password changes, a field gets renamed, a provider changes how its API behaves. Installable Apps Script triggers run under the account of whoever set them up, so build them on an account the business controls, not one person's login. If nobody is told when any of this happens, the business goes back to double entry without noticing, because someone quietly starts typing again to keep things moving.

When is this not the answer?

When the volume is tiny. If three new customers a month get typed twice, the honest fix might be a checklist and a careful person. The link has to cost less to build and look after than the typing it replaces.

When the systems are about to change anyway. Linking an accounts package you are leaving in the spring is money spent twice. Decide the future setup first, then join it up.

When the real problem is that nobody agrees on the data. If sales and accounts disagree about what counts as a customer, automating the transfer just moves the argument faster. That needs a conversation and a decision before it needs a script.

When the data is sensitive and you do not know where it is going. Personal data moving between systems should be mapped and understood, not just connected. If you are not sure what your obligations are, the ICO's guidance is the place to start, and a data protection adviser is the next step.

Where do you start?

Pick one piece of data, follow it for a week, and count the times it gets typed. That list is the brief.

If you have the list and want to know what joining it up would take, tell us what's stuck and we'll map the quickest fix. We will tell you straight which links a form and a short script can handle, which need a proper integration, and which are not worth building at all. Time to talk yet?