Service
Systems Integration
We connect the systems you already run so a record entered once appears everywhere it is needed, with one place that decides what is true.
The problem
What usually goes wrong
Most businesses do not have a software problem, they have a boundary problem. The scheduling tool knows about the job, accounting knows about the invoice, and the only thing connecting them is a person with two windows open.
When those systems are connected badly it gets worse rather than better: two systems both believe they own the customer record, and the one that syncs last wins.
Integration work is mostly about deciding ownership and then enforcing it.
Scope
What we deliver
System and data inventory
What each system holds, which fields overlap, where records are created, and how many copies of a customer currently exist.
System of record decisions
For every shared entity, one system owns each field. Everything else receives. This single decision removes most sync conflicts.
Identity resolution
Matching rules for customers, products and orders across systems that were never designed to share keys, with a review queue for ambiguous matches.
Sync layer
Event driven where the source emits events, scheduled where it does not, with checkpointing so a restart does not reprocess everything.
Field mapping and transformation
Documented mappings including units, formats, time zones and enumerations, which is where quiet corruption usually starts.
Monitoring and reconciliation
A scheduled comparison that reports records present in one system and missing in another, before a person finds it by accident.
Method
Technical approach
We map the entities before touching an API. A customer in a scheduling tool, a contact in a marketing platform and a payer in accounting are three records that usually refer to one person, and integration starts by writing down how you will know that.
Ownership is declared per field, not per entity. Accounting may own the billing address while the operational system owns the service address, and the sync respects that rather than overwriting.
Where a system emits webhooks we consume them, verified and deduplicated. Where it does not, we poll with a high water mark so each run reads only what changed. Checkpoints are stored so an interruption resumes rather than restarts.
Transformations are explicit and tested: currency and unit conversion, date and time zone normalisation to a single canonical form, and enumeration mapping with a rule for unknown values rather than a silent default.
A reconciliation job runs on a schedule and reports drift. Integrations decay quietly, and the only reliable defence is a comparison that runs whether or not anyone is worried.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01System and data inventory with field level mapping
- 02System of record matrix covering every shared field
- 03Identity resolution rules and a review queue for ambiguous matches
- 04Sync services with checkpointing, retries and dead letter handling
- 05Transformation layer with unit, format and time zone normalisation
- 06Reconciliation job and drift report
- 07Operations view for failures and pending work
- 08Runbook, source code and deployment guide
Related
Systems this service builds
- ERP Integration and CustomizationWe connect and extend the ERP you already run, adding the workflows it does not cover without forking the platform or breaking your upgrade path.
- DMS IntegrationsWe connect dealership tools to the DMS so inventory, customers, repair orders and deal records stay consistent without anyone rekeying them.
- POS IntegrationWe connect point of sale to the rest of your business so sales, stock, customers and loyalty stay consistent across the counter, the website and the back office.
FAQ
Questions people actually ask
Which system should own the customer record?
Usually the one where the customer is created first and corrected most often, which is often the operational system rather than accounting. We decide it per field, because ownership is rarely uniform across a record.
What if two systems already disagree?
We run a reconciliation before go live, produce the list of conflicts, and agree a resolution rule with you. Some are automatic, some go to a person once.
Can you integrate a vendor system we cannot modify?
Yes, through whatever it exposes: an API, webhooks, scheduled exports or a read replica. The adapter absorbs the awkwardness so the rest of your estate sees a clean interface.
How do you avoid sync loops?
Writes made by the integration are tagged, and inbound events carrying that tag are ignored. Without it, system A updates B, B emits an event, and the two update each other forever.
Is this the same as an integration platform subscription?
It can include one. Where a hosted orchestrator such as n8n fits, we use it and hand it to you configured. Where the logic is complex or the volume is high, code is cheaper to run and easier to test.
How do we know it is still working next year?
The reconciliation report and the failure queue are the answer. Both are built as part of the work rather than offered later.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.