Home/Solutions/Integration and automation
Solutions

Seven systems. Six of them right.

Most businesses do not have a bad system. They have several good ones holding part of the same truth, with nothing deciding which is authoritative.

Thirty minutes · no predetermined package

A typical stack
and where it disagrees
2 hold the same customer
Website formsthe front door
Partner feedssubmissions
Ad platformsspend and clicks
Your CRMthe record
Dialercalls and outcomes
Documents & e-signcontracts
Accountinginvoices
Reportingthe numbers
7 systems11 connections3 maintained by hand
1
One record, seven opinions
nothing decides which one wins
Start here

Which of these is actually your problem?

Six sentences. The one that sounds like your week decides which page to read next.

“Data has to move between systems that were never designed to talk.”

API integrations

Field ownership, validation at the edge, deduplication and alerting.

Go to api →
“A person is doing a job a rule could do, every day.”

Business automation

The sequence written down, then enforced by the system rather than remembered.

Go to business →
“The first touch could be handled without a person.”

AI agents and assistants

An assistant that opens the conversation and hands back when a human should have it.

Go to ai →
“Salesforce was built by people who have left.”

Salesforce development

Read the org, decide what stays, and remove what nobody can account for.

Go to salesforce →
“HubSpot is charging for a database that grew.”

HubSpot consulting

Optimise, extend, integrate or leave — and usually the first one.

Go to hubspot →
“The platform is Odoo, Zoho or GoHighLevel.”

Platform work

Upgrade paths, app sprawl and account ownership, each with its own page.

Go to platform →
Symptoms

What a disconnected stack looks like from inside.

01

A recurring calendar reminder exists whose only purpose is moving data between two systems.

02

Two systems hold the same customer and neither is authoritative.

03

An integration broke silently and the first sign was a number that looked wrong at month end.

04

The platform is right and the setup is fourteen years of exceptions nobody documented.

05

Reporting stops at the boundary of one system, and the question spans four.

06

Somebody is paid to do a job a rule could do.

Evaluation

Six questions before connecting anything.

The first one is the whole job. The rest follow from how it is answered.

01Which system owns each field when two of them disagree?This is the whole job. Bidirectional sync on a contested field is the most common cause of corruption.
02What breaks silently, and who finds out?An integration with no alerting is a scheduled job that fails quietly and takes the reporting with it.
03Which manual step happens on a schedule?Anything on a recurring calendar reminder is a candidate. That list is usually the first project.
04Is the platform the constraint, or the configuration?Configuration is cheap to fix. A data model is not. Answering this decides the budget.
05What has to keep working while this changes?Integration work happens on a running business. The rollback path matters more than the plan.
06Who will own this once we are gone?Automation nobody understands is a liability that arrives later, dressed as an outage.
The sequence

Five stages, and the map comes first.

01

Map what exists

the diagram

Every system, what it holds, and which fields overlap. Signed off before anything is connected.

02

Decide ownership

the rules

Per field, which system wins. This is the deliverable, and everything after it is implementation.

03

Build at the edges

validated

Accept or reject in-request, deduplicate on the identifiers that matter, and never write silently.

04

Instrument it

visible

Alerting on failure rate, latency and volume drift, so a break is noticed in minutes rather than at month end.

05

Document and hand over

operable

What to do when the other end changes, rotates a credential, or starts rate-limiting.

Where this comes up

The systems change. The ownership question does not.

Lending and financial services

Partner feeds, bank data, dialer and servicing, all holding part of the same file.

Home services

Dispatch, financing and accounting, where the job record has to reconcile across three.

Insurance

Carrier portals and rating platforms, several of which have no API at all.

Professional services

Practice management, billing and intake — three vendors, one client between them.

Questions

What people ask about integration and automation.

What is systems integration?

Connecting systems so a record created in one appears correctly in the others. The connection is the easy half; deciding which system owns which field when they disagree is the work.

What is business process automation?

Having software perform a sequence a person would otherwise perform by hand. It is worth doing when the sequence is repeatable and a missed step has a real cost.

Where should we start?

With the list of manual steps that happen on a schedule. Anything on a recurring calendar reminder is a candidate, and that list is usually the first project.

Do we need an iPaaS platform?

Use one when the connectors exist and your mapping is close to default. Build custom when the rules are specific to your business or a wrong record costs real money.

How do you stop integrations breaking silently?

Alerting on failure rate, latency and volume drift, plus idempotency so a retry never creates a duplicate. Most breakages we are called about were visible for hours.

Can you work with our existing platform?

Usually, and it is normally cheaper than replacing it. Routing, reporting and automation can sit around a platform rather than inside it.

What if a system has no API?

The honest answer is a structured manual step with a named owner, not a fragile scrape. Several carrier and utility portals fall into this category.

How long does integration work take?

The mapping decision takes longer than the code. Expect the ownership table to occupy the first week, and expect it to change what everyone thought the project was.

Should we automate before or after fixing the process?

After. Automating a broken process makes it fail faster and more consistently, which is worse than the manual version.

Who owns the code and the credentials?

You do. The repository is created in your organisation from the first commit, and access concentrated in a supplier is a failure point we are often asked to fix.

Do you take commission on software you recommend?

No. No commission, referral fee or partner margin, which is what makes the recommendation worth having.

What happens after it is built?

The engineers who built it run it, or hand it over documented. Automation nobody understands is a liability that arrives later dressed as an outage.

Usually alongside

What this is normally built with.

C
Custom CRM development
when the record itself is wrong
D
Data and reporting
the reason it all has to reconcile
O
Ongoing support
so it stays connected