Elevate Core blog

How to automate data entry between the systems you already use

Mon, 14 Sep 2026 00:00:00 GMT

You automate data entry between systems by letting the information travel on its own. Once a customer's details, a job, a reading or an address exists in one place, software can carry it into the next place, check it on the way, and flag anything that does not add up. You keep the systems you already use: the diary, the quoting tool, the accounts package, the spreadsheet, the trade software you have run for years. What changes is that a person types each fact once instead of six times. In our experience that single change removes most of the typing an office does, and most of its typing errors with it.

Where does double entry actually happen?

Wherever one system ends and another begins. A customer rings, and their name and address go into the diary. The job is quoted, so they go into the quoting tool. The job is done, so they go onto the job sheet, then the invoice, then the accounts package, then the letter that goes out with the certificate. Same customer, six times, by hand. Firms rarely notice, because each retype takes a minute and belongs to a different person. Try the retyping test: pick one customer from last month and count how many times their name was typed between the first call and the paid invoice. The number surprises most people. Each one of those retypes is a place where software can take over.

What does it look like when it works?

We built this for an international shipping company whose staff retyped customer names and addresses into shipping paperwork by hand, for hundreds of parcels a day. Every typo risked a delayed parcel, a customs query or a return. Now the paperwork fills itself in from the records the company already holds, and each address is checked against the formats both countries expect before anything ships. Processing the address details for one parcel went from 3 minutes to under 40 seconds. Across more than 50,000 shipments, that has saved the company thousands of hours. Nothing about the paperwork changed, and the staff kept the systems they knew. What changed was who did the typing and who did the checking. The same shape applies to a job sheet becoming an invoice, or a meter reading becoming a certificate.

Why is checking as important as copying?

Because the moment a fact moves between systems is the best moment to check it. When software carries an address from one place to another, it can confirm that the postcode exists, that the invoice total matches the quote, that the certificate number follows the right pattern, that a required field is not blank. A person retyping at the end of a long day does none of that reliably, and the errors that slip through are the expensive kind: the ones nobody notices until the customer rings, the payment bounces or the inspector asks. With the check built into the transfer, the mistake is caught before the document goes out rather than after.

Do you have to replace your systems to do this?

No, and you usually should not. Most of the tools a firm already runs can be connected: the accounts package, the diary, the spreadsheet, the trade-specific software. There are a handful of ways to make a connection, and the right one depends on what you run and what each system allows. Choosing and building that connection is the work we do. Deciding that the retyping should stop is the part you do. What you should not do is buy a large new platform in the hope that it covers everything, because then you will find yourself retyping into that as well.

How do you start?

With the retyping test above, and with the one pair of systems where the same fact travels most often. Write down what gets typed, from where, into what, and what ought to be checked on the way. That is enough for us to tell you whether the two can be connected and how long it would take.

Frequently asked questions

Does this work with our accounts package?

Almost always. The widely used packages are built to be connected to, and older ones can usually export and import. The answer for your particular package takes us minutes to give.

What if one of the systems is a spreadsheet?

A spreadsheet can be read from and written to like any other system. Whether it should stay a spreadsheet is a different question, which we covered in turning your spreadsheet into an app.

If your office types the same details into more than one system, tell us which systems on our contact page. We will tell you which retypes can go and what it would take.

Is it safe to give a developer access to your customer data?

Fri, 11 Sep 2026 00:00:00 GMT

Yes, if three things are true. The developer sees only what the job needs, usually far less than you think. The obligations are written down before anything is shared, in a data processing agreement, which the law requires anyway. And you know where the data will live once the system is built, and who can reach it. A firm with those three in place can hand over its records with a clear conscience. A firm that skips them is trusting to luck, however honest the developer.

What does a developer actually need to see?

Much less than the whole database. To build a job-tracking system, an invoicing tool or a booking app, a developer needs the shape of your data: which fields exist, what format they take, which awkward cases turn up. They do not need the names and addresses. A few dozen sample records with the real details replaced do most of the work. Real data is needed at two moments only: when your existing records are moved into the new system, and when a fault appears that only real data reproduces. Both are short and supervised, not standing access. That is how we work. We build on sample data wherever the job allows, and once a system is handed over we need nothing further from it.

What should be written down before you share anything?

Two documents. A confidentiality agreement covers what the developer learns about your business. A data processing agreement covers your customers' personal data, and this one is not optional. Under UK GDPR your firm is the controller, meaning the one who decides why and how the data is used, and a developer who handles it on your behalf is a processor. The ICO's guidance is plain: "whenever a controller uses a processor, there must be a written contract", and the law sets out what it must say. The developer acts only on your instructions, keeps the data confidential and secure, tells you before bringing in anyone else, helps you if there is a breach or a request from a customer, and deletes or returns the data when the work ends. The same rules apply word for word under the EU's GDPR, and most countries have an equivalent. A developer who is happy to sign this agreement, and knows what belongs in it, is telling you something about how they work.

Where will the data live once the system is built?

Ask this before the build starts, because the answer shapes the design. There are two options. The system runs on your own machines or your own accounts, so nobody outside the firm can reach the data without you. Or the developer hosts it, running the database on your behalf. We usually advise the first where the job allows, because it keeps you in control and takes us out of the picture once the system is delivered. Some systems need a hosted database, for instance where staff in the field and the office share live records, and then the questions become who holds the keys, where the server is, and what happens if the arrangement ends. Those answers belong in writing too. We are on both sides of this question: our own platform, FireRecord, holds our customers' records under exactly these obligations.

What should you ask a developer before handing over data?

Five questions, and the answers tell you most of what you need to know.

What do you need to see, and can you work from a sample with the real details removed?
Will you sign a data processing agreement before we share anything?
Who on your side will have access, and when does it end?
Where will the data live once the system is built, and can we run it ourselves?
What happens to our data, and to your access, if we stop working together?

A developer who answers all five without hesitation is safe to work with. One who waves them away is not, however good the portfolio looks.

Frequently asked questions

Do we need a data processing agreement with a freelancer as well as with a company?

Yes. The law looks at what is done with the data, not at the size of whoever does it.

Who owns the data in the new system?

You do, always, and you should be able to export it at any time. Who owns the code is a separate question with its own answer, and we will cover it in a later article.

If you are weighing up whether to let a developer near your customer records, describe the system you want and the data it involves on our contact page. We will tell you what we would need to see, and what we would not.

How to get your business on ChatGPT

Tue, 08 Sep 2026 00:00:00 GMT

You cannot register a business with ChatGPT. There is no form, no directory and no fee. When a customer asks it for a plumber in Leeds, an accountant in Bristol or a letting agent in Glasgow, ChatGPT searches the web, reads the pages it finds and writes an answer from them. Getting your business on ChatGPT means making sure those pages exist, describe you clearly and agree with each other. The same is true of Copilot, Gemini and the AI answers at the top of Google.

Is there a way to register a business with ChatGPT?

No, and anyone selling you a ChatGPT listing is selling something that does not exist. OpenAI's guidance for website owners explains that ChatGPT finds websites the way a search engine does, by reading them, and that a site which blocks its reader "will not be shown in ChatGPT search answers". There is nowhere to submit your details. People typing "register my business on ChatGPT" are really asking how ChatGPT decides which firms to name. That has an answer.

How does ChatGPT decide which firms to name?

It reads four kinds of page and trusts what they agree on. First, your own website: what you do, where, and what qualifies you. Second, your business listings on Bing and Google, where it takes your address and phone number from. Third, the places other organisations describe you: any professional register or trade body you belong to, and the review sites. Fourth, what other people say about you, in a trade magazine, on a supplier's or partner's website, or in a forum thread. When Yext analysed 6.8 million AI citations for questions about local businesses, 86 per cent of what the assistants relied on came from the first two: the firm's own site and its listings. A firm missing from any of the four, or described differently in each, is passed over for one that is not.

Why does ChatGPT recommend your competitor instead of you?

Usually because the web says more about them than about you. ChatGPT is cautious in the way a new customer is cautious: it prefers a firm that several independent sources describe over one that only describes itself. Your competitor may have claimed a listing you never did, kept a register entry current, collected thirty reviews to your six, and been mentioned in the local paper two years ago. None of that is clever. It is the ordinary evidence that a firm exists, does what it says and is trusted, gathered in places a search can reach. If you have all of it and ChatGPT still names someone else, the usual cause is that your details disagree with each other: an old phone number here, a former address there.

What can you do about it?

Three things, in this order. Make your website answer the questions a customer asks before ringing: what you do, where you cover, and what qualifies you. Claim the free business listings from Microsoft and Google, and make sure every listing, register and page carries the same name, address and phone number, word for word. Then give people reasons to mention you: ask for a review after every job, and keep any register or directory entry current. Where the work becomes technical is in how the pages are written and structured so that a search matches them to the questions your customers actually ask. That part is what we do for service businesses of every kind. The three steps above are the part every firm can do for itself.

How do you check whether ChatGPT knows your business?

Ask it what a customer would ask, once a month, and write the answer down. Type what you do and where, for example "electrician in Leeds" or "accountant in Bristol", into ChatGPT and into Copilot, and note whether you are named and who is. Then ask "what does [your company] do?" and check the description, the address and the phone number. Where a detail is wrong, it came from a page somewhere that is wrong, and the fix is to correct that page, not to argue with ChatGPT. Where you are absent, look at the four sources above and ask which one is missing you.

Frequently asked questions

Can you pay to be listed on ChatGPT?

No. There is no paid listing and no directory.

Does it help to put "find us on ChatGPT" on the website?

No. ChatGPT reads your site for your services, your areas and your contact details, not for mentions of itself.

If you would like to know how your business shows up in ChatGPT, Copilot and Google's AI answers today, tell us what you do and where on our contact page. We will run the checks and tell you what we find.

Turning your spreadsheet into an app: when it is time and what changes

Sat, 05 Sep 2026 00:00:00 GMT

It is time to turn a spreadsheet into an app when the spreadsheet has become the system your business runs on: several people edit it, it feeds the documents you send to clients, and a mistake in it costs money or a compliance failure. What changes is not the logic. The spreadsheet already describes that, often in more detail than anyone realises. What changes is where the information lives and what protects it. An app, meaning here a private web application with a database behind it, keeps one record of each job, checks entries as they are made, controls who can change what, and produces your documents from the data instead of by retyping. Your spreadsheet is the specification. You have already written it.

How do you know the spreadsheet is no longer enough?

The signs are familiar to anyone who has lived with one. More than one person needs to edit it at the same time. There is a file called final, and another called final v7. A formula exists that nobody dares touch because the person who wrote it has left. Cell colours mean something: yellow is waiting, green is invoiced, and everyone just knows. Values are copied out of it into Word, into certificates, into invoices, by hand. Nobody can say who changed a figure or when. It travels by email, so two versions exist by lunchtime.

The clearest test is this: if the spreadsheet were unavailable for a day, would work stop? If the answer is yes, it is not a spreadsheet any more. It is your business system, running on a tool built for calculations. In 2020 Public Health England lost track of nearly 16,000 positive test results because the spreadsheet format used to collect them could not hold more rows, as the BBC reported. The lesson is not that spreadsheets are bad. It is that they have limits nobody sees until the day they matter.

What does an app actually mean here?

It does not mean something in an app store. When an owner asks whether the business needs a mobile app, the honest answer is usually no. What most firms need is a private web application: software that runs in a browser, on a phone in the field and a laptop in the office, with a database behind it. A database is simply a store where each piece of information is kept once, in its own labelled place, so it can be found, checked and combined without being retyped.

A web application does not need to be installed, does not go through an app store, and is updated once for everyone. It can work without a signal and catch up when the connection returns, which is how we built FireRecord to behave on site. A native phone app makes sense when you need something only the phone can do, such as particular hardware. For a job list, a checklist, a certificate or a report, the browser is enough, and it costs a fraction of building for two app stores.

What carries over from the spreadsheet?

Almost everything, and that is the point. The columns become fields. The tabs become record types: jobs, properties, clients, engineers. The formulas become rules that the app applies automatically. The colours and comments become proper statuses and notes that can be filtered and reported on. The lookups between tabs become links between records, so a job knows its property and its client without anyone typing the address again.

Most valuable of all is the knowledge that has accumulated in the sheet over the years: the exceptions, the special cases, the column added in 2019 because a particular client needs a particular reference. A spreadsheet that has run a business for a decade is the most complete description of that business anyone will ever write. Nobody sat down to write a specification, but there it is. Turning it into an app starts with reading it properly, with the people who use it, and asking what each column is really for.

What gets better?

Five things, and each one removes a category of error or work.

One record per thing. A job, a property, a client exists once. Every document and every list draws from that record, so a corrected address is corrected everywhere.
Checking at entry. A date has to be a date. A certificate number has to match the pattern. A required field cannot be left blank. Mistakes are caught when they are typed, not when a client rings.
Permissions. An engineer sees their jobs. The office sees everything. Only certain people can approve, delete or change a price.
Documents from data. Quotes, certificates, reports and invoices are generated from the record, in your own templates, instead of being retyped from the sheet.
History. Every change is recorded with who made it and when. That is the question an auditor, an inspector or an insurer asks first, and a spreadsheet cannot answer it.

Several people can work at once without overwriting each other, from any device, and the file that used to travel by email no longer exists.

What do you lose, and how do you keep some of it?

You lose some freedom, and it is worth being honest about it. In a spreadsheet you can add a column on a whim, try a quick calculation, or reorganise everything on a Friday afternoon. An app is more deliberate. Adding a new type of information means changing the app, and that should be a decision rather than an accident.

There are three ways to keep the flexibility that matters. First, insist on export: your data should come out as a spreadsheet at any time, because it is yours. Second, design the app so the office can manage its own lists, such as job types, statuses and standard wording, without calling a developer. Third, keep using spreadsheets for what they are good at, which is analysis. Pull the data out, chart it, and explore it. Just do not make the spreadsheet the record again. And if a process is still changing every week, wait. Build the app when the process has settled enough to be worth protecting.

Is our process too particular for an app?

No, and the spreadsheet is the proof. Every firm believes its way of working is unusual, and in the details it usually is. Those details are exactly why off-the-shelf products never quite fit: the extra reference, the two-stage approval, the certificate that needs a different layout for one type of client. An app built around your spreadsheet keeps the details, because they are already written down in it.

Twenty years of doing something by hand is not a reason it cannot be automated. It is an asset. The exceptions are known, the edge cases have all happened at least once, and the people who handle them can explain them. The processes that resist automation are the ones nobody can describe. Yours has a description, with formulas.

To start, take the spreadsheet, remove anything confidential, and write down three things: what goes into it, what comes out of it, and who touches it between the two. That is enough for a developer to tell you whether it should become an app and what the first version should contain.

Frequently asked questions

Do we lose our data when we move away from the spreadsheet?

No. The existing rows are imported once, cleaned along the way, and the app becomes the record from that point. You should be able to export everything back to a spreadsheet at any time.

Do we need a phone app as well as the web app?

Usually not. A web application works on a phone, a tablet and a laptop, and it can be built to work without a signal. A separate phone app only earns its cost when you need something the browser cannot do.

Can we keep using the spreadsheet while the app is being built?

Yes, and you should. The usual approach is to run both for a short period, compare the results, and switch when the team trusts the app. Nothing is lost in the meantime.

If you have a spreadsheet the business could not run without, describe what goes in, what comes out and who touches it on our contact page. We will tell you whether it should become an app and what that would involve.

How to automate report writing for inspections and site visits

Wed, 02 Sep 2026 00:00:00 GMT

You automate report writing by splitting the job in two. The findings are captured once, on site, in a structured form. The document is then assembled from those findings by software, using your own template. The person keeps the judgement: what was observed, how serious it is, what should happen next, and the signature at the bottom. In our experience of building report tools for surveyors, energy assessors, fire risk assessors and inspection firms, most of the time after a visit goes on retyping and formatting rather than on thinking. That is the part software removes.

What part of a site report can be automated?

Everything that is copying, arranging or repeating can be automated. That includes typing up notes, placing photographs, numbering findings, filling in the standard wording, building the action table, applying the layout and exporting the finished file. It also includes the parts that are the same every time: the property description block, the methodology section, the definitions, the rating scale.

What cannot be automated is the assessment itself. Deciding whether damp in a wall is significant, whether a consumer unit needs replacing or whether a fire door is adequate is professional judgement, and in regulated work it is the judgement the law relies on. Software can put the decision into the right section, in the right words, with the right photograph attached. It cannot make the decision, and a tool that claims to should worry you.

A useful test: if two competent people would write the same thing, it can be automated. If they might disagree, it is judgement.

Where does the time go after a site visit?

It goes on moving information between places. Handwritten or phone notes are typed into a document. Photographs are downloaded, renamed, resized and dropped into position. Findings are numbered by hand, then renumbered when one is added. Standard paragraphs are copied from the last report and checked for the previous client's name. The action plan is rebuilt as a table from findings written three pages earlier. Then the whole thing is read again for formatting mistakes.

None of this is assessment. The assessors and surveyors we have built for told us the write-up took as long as the visit, and sometimes longer. That is not surprising once you look at the documents. An electrical installation condition report follows the model forms in BS 7671, with schedules of inspection and test results to complete. A residential survey follows the RICS Home Survey Standard, with a set structure and a condition rating for every element. A fire risk assessment or an energy compliance report has its own fixed sections in the same way. Different trades, same shape: a structured document, filled by hand.

How does capturing findings on site remove the typing?

The typing disappears when a finding is recorded once, in its final structure, at the moment it is observed. Instead of a notebook and a camera roll, the assessor works through a checklist that mirrors the sections of the report. Each observation is entered against its section, with the photograph attached to that observation rather than sitting in a folder. Where it suits the work, the observation is spoken rather than typed: the tool transcribes the speech into text and files it in the right place.

We built this workflow into FireRecord, our own platform for fire risk assessors: observations spoken or typed on site are sorted into the sections of the report and the document assembles itself, with every version kept. The approach is not specific to fire safety. Any inspection that follows a fixed structure, from a condition report to a building survey, can be captured the same way.

How does a template become a report generator?

Your existing Word template already describes the document: the headings, the order, the tables, the wording that never changes. A report generator keeps that layout and replaces the manual filling with placeholders. The facts about the job live as structured records, meaning each piece of information is stored in its own labelled field rather than inside a paragraph. When you ask for the report, the generator fills the placeholders from those records, numbers the findings, builds the tables, places the photographs and exports the result to Word or PDF.

We built this for an energy assessor who was producing compliance reports by retyping values from certificate files into a Word template. The tool reads the certificate data directly, including the modelling information most software ignores, and produces a draft in the assessor's own template, ready for professional review. Hours of retyping per report became minutes. The template did not change, only who was doing the typing.

What does the person still have to do?

The person does the part the report exists for. They inspect, they decide what is significant, they rate it, they recommend the action and they put their name to it. In regulated work the report is also a record with legal weight: a fire risk assessment must be recorded in full, a condition report is issued in a prescribed form, a survey carries the surveyor's professional liability. A generator makes that record consistent and complete. The competent person makes it correct.

There is also a review step that should never be skipped. A generated draft is a draft. It should be read the way you would read a colleague's work: does the severity match the photograph, is the recommended action proportionate, has anything been filed under the wrong heading. In practice this review takes a fraction of the time the old write-up took, because you are checking rather than producing. The same holds in any country. The legal reference changes, the division of labour does not.

How do you start automating your own reports?

Start with one report type, the one you produce most often. Take a finished example and mark every piece of text as one of three things: a fact captured on site, a judgement, or wording that is the same every time. The facts and the fixed wording are the automation. The judgements stay with the person.

Then write down the steps between the site visit and the sent report, including the ones that feel too small to mention: renaming photographs, renumbering, copying the address into three places. Those steps are the time you will get back. With that list you can judge whether an existing product covers your document, or whether the structure of your report is particular enough that a tool built around your template is the honest answer. Firms with twenty years of the same process usually assume the second option is out of reach. In our experience it rarely is. The process that seems too particular to automate has already been described, in detail, by the people doing it.

Frequently asked questions

Does this work with our existing Word template?

Yes. The template becomes the layout the generator fills, so the reports your clients receive look the same as before. Changes to the template are made once and apply to every report after that.

Do we have to dictate on site?

No. Speaking observations is faster for some people and awkward for others. Structured capture works with typing, with dictation, or with a mix, and the report assembles the same way. What matters is that each finding is recorded once, against its section.

Will the reports still follow the standard?

The structure follows the standard, because the checklist and the template are built from it. Whether the content meets the standard depends on the assessment, which is why the competent person reviews and signs every report. If the standard is revised, the template is updated once.

If your firm produces the same report over and over and the write-up takes longer than the visit, we can tell you what could be automated and what should not be. Describe the report and the steps on our contact page and we will give you an honest answer.