Integration
Systems integration, so nothing gets typed out twice
Most small businesses do not need new software. They need the software they already pay for to talk to itself. The website, the accounts package, the CRM and the scheduling tool each hold a piece of the same job, and a person moves information between them by hand every afternoon.
- No new systems to learn
- Usually the cheapest fix
- Built on real APIs
The most expensive person in your business is a copy and paste
An enquiry arrives through the website. Someone reads it and types it into the CRM. When it becomes a job, someone types it into the scheduling tool. When it is finished, someone types it into the accounts package. The same name, the same address, the same job description, entered four times by three people.
Every one of those steps takes minutes, and every one is a chance for a digit to change. The reconciliation afterwards, working out why the accounts and the job list disagree, costs more than the typing did.
Integration removes the retyping. The enquiry becomes a CRM record automatically, the CRM record becomes a job, the completed job becomes an invoice. Nobody learns a new system and nobody changes how they work. The handovers just stop being manual.
Integration is usually the cheapest form of custom software development.
What we connect most often
If a system has a documented way in, it can normally be connected. Where one does not, there is usually a workable alternative.
- Website forms and enquiries into a CRM, with the source and the page recorded rather than lost
- Bookings and orders into the calendar, job list or production schedule they actually need to reach
- Completed jobs into an accounts package, so invoicing stops being a weekly re-entry exercise
- Stock levels shared between a shop and wherever stock is genuinely counted
- Customer records kept consistent across systems, so a change of address happens once
- Reporting pulled together from several systems into one view somebody can act on
- Alerts and notifications routed to the people who need them rather than to a shared inbox
Integration is usually the cheap answer
When a business tells us its systems are a mess, the instinct is to propose replacing them. That is usually the wrong call and always the expensive one. The systems are generally fine. The gaps between them are the problem.
Connecting two systems is a fraction of the cost of replacing either, it requires no retraining, and it can normally be done in weeks rather than months. We would rather do that first and let you decide later whether anything genuinely needs replacing.
- No new software for anyone to learn
- Delivered in weeks, not quarters
- Reversible, unlike a migration
What we check before quoting
The honest answer on any integration depends almost entirely on what each system will let us do, so that is the first thing we establish rather than the last. Some products have a well-documented and stable route in. Some have one that is rate-limited or missing the exact field you need. Some have none at all, and the answer is a different approach or a frank conversation about whether that product is worth keeping.
We check that before giving you a price, because an integration quoted on an assumption is the classic way these projects double in cost. If a connection turns out not to be practical, you will hear that at the quoting stage rather than a month in.
Where the gap between two systems is a judgement rather than a field, that is often AI automation.
How a systems integration project runs, and how long each step takes
A single connection between two systems is usually two to four weeks from the first conversation to running on its own. Most of that is the checking either side of the build, which is the part that stops it failing quietly later.
-
Step 1
Discovery, two or three days
Which systems hold which data, which one is the source of truth for each field, and what each product’s API documentation says it will and will not allow, including its rate limits.
-
Step 2
Field mapping, a few days
Every field written down against its equivalent on the other side, with the awkward cases settled up front: a customer with two addresses, a VAT rate that changes, a job cancelled after it was invoiced.
-
Step 3
Build and test sync, about a week
The connection built against test accounts or a copy of the data, then run with real-looking records until every case on the mapping sheet comes out right.
-
Step 4
Go-live, one day
Switched on with a backup of both systems taken first and a rollback plan written down, usually early in the week so any surprise is found while everyone is at work.
-
Step 5
Monitoring, ongoing
Failed syncs alert us rather than disappearing. When a provider changes its API, which every provider eventually does, the fix is made before the change goes live where there is notice, and the same day where there is not.
Web systems integration: connecting the website to everything behind it
For most small businesses the first integration worth doing starts at the website, because that is where the data enters. An enquiry form that only sends an email relies on somebody reading it, retyping it and remembering to follow it up. A web form connected to the CRM, the diary or the job system turns the same enquiry into a record the moment it is submitted, with the page it came from attached.
The RPH Home Services build is a worked example. Enquiries were arriving by phone, by web form and by social message, each depending on whoever happened to notice. They now land in one place with the job detail captured, and customers can book a real slot rather than wait for a callback.
The full story is in the RPH Home Services case study.
What is the difference between an API and an integration?
An API is the door a piece of software provides for other software to use: a documented way to read or write its data. Xero, QuickBooks, HubSpot and most modern booking and job management tools publish one. An integration is the thing that walks through two or more of those doors on a schedule or in response to an event, and decides what to do with what it finds.
The distinction matters when choosing between a ready-made connector and a built integration. Tools such as Zapier and Make are fine for a simple one-way flow with low volume. They struggle when the logic has conditions in it, when volumes push against rate limits, or when a failure needs to be noticed rather than silently skipped. That is the point at which a built integration is worth paying for.
How is an integration tested?
In three layers. Each piece of logic is tested on its own, so a date or a VAT calculation is checked in isolation. System integration testing, often shortened to SIT, then runs the whole connection end to end between test copies of the real systems, to prove the two sides agree on every field in the mapping. Finally the people who use the systems try it with their own everyday cases, which is where the edge cases nobody mentioned in discovery tend to appear.
Nothing goes live until all three pass, and the test cases are kept so they can be run again whenever either system changes.
Data protection, security and rollback
Syncing customer data between systems is processing personal data under UK GDPR, so it needs the same care as anyone in the office handling it. Only the fields the job needs are moved. The connection uses API keys with the narrowest permissions each system allows, stored encrypted rather than in a spreadsheet or an email. Where data passes to a provider outside the UK, the transfer has to be covered, and the Information Commissioner’s Office guidance on international transfers is the reference for what that means.
Before go-live, both systems are backed up and the rollback steps are written down. An integration that goes wrong at volume can write a lot of bad data very quickly, and being able to put things back by lunchtime is part of the job, not an extra.
How to choose a systems integration provider
Ask who looks after the integration once it is live, because every API changes eventually and an unmaintained integration fails quietly. Ask how failures are reported. Ask whether they have confirmed the API supports what you need before quoting, rather than after. And ask who owns the code, which should be you.
A provider who builds custom software as well as connecting existing tools can also tell you when the honest answer is to connect two systems rather than replace one, which is usually the cheaper result.
For the plain-English definitions, see what an API is.
Start with the handover that annoys everyone
There is usually one obvious candidate: the report somebody rebuilds every Monday, the list that gets exported and re-imported, the inbox that acts as a filing system.
Tell us what that one is. It is normally the cheapest thing to fix and the one that makes the case for everything after it.
Get in touch
Talk to us about systems integration
A few lines is enough. SetWeb replies within 1 working day and will tell you straight whether we can help, what it would cost and how quickly we can be there. No hard sell, and no follow-up sequence if you decide against it.
- We reply within one working day
- A straight answer, including when it is no
- Free process review available, before any money changes hands
Would rather just ring? 01623 354250, Mon–Fri, 9am–5:30pm.
What do people ask most?
If the answer is not here, ask SetWeb on 01623 354250. You will get a straight one, from someone who does the work.
Mon–Fri, 9am–5:30pm
What is systems integration?
Connecting the software you already run so information moves between it automatically instead of being retyped by a person. An enquiry becomes a CRM record, a completed job becomes an invoice, a sale updates stock, without anybody copying anything across.
How much does an integration cost?
Far less than replacing a system, and normally the cheapest useful software work a small business can buy. A single connection between two systems is typically a matter of days rather than weeks. You get a fixed price once we have confirmed what each system allows.
What if our software has no API?
It happens, particularly with older products. There is often still a route through scheduled exports, a database connection or a supported file drop. Where there genuinely is not one, we will tell you plainly and set out what the alternatives would cost, including leaving it alone.
Will it break when one of the systems updates?
Integrations do need looking after, which is why we monitor the ones we build and fix them when a provider changes something. An integration nobody maintains is a fault waiting to happen quietly, and quiet is the dangerous part.
How long does systems integration take?
A single connection between two systems is usually two to four weeks from discovery to running on its own, with the build itself about a week. Several connections, or a system with a difficult or undocumented API, take longer, and you get the timescale with the fixed price.
What is SIT in systems integration?
SIT stands for system integration testing: running the whole connection end to end between test copies of the real systems to prove both sides agree on every mapped field. It sits between testing individual pieces of logic and the users checking it with their own everyday cases.
Can you connect systems you did not build?
Yes, and that is most of this work. The great majority of what we integrate is off-the-shelf software the client chose long before they met us.
