Skip to main content
Immense Click

Consulting service

Systems & Data Integration Implementation

Building the integration an assessment established as practical, including failure handling, duplicate protection and a record of what moved.

What you need to know first

What problem does this solve?
An assessment has confirmed the integration is feasible and how it should work. Building it well is the difference between an integration that quietly loses records and one that is trustworthy — and that difference is almost entirely in the failure handling.
What exactly do I receive?
A working integration between the agreed systems, with one authoritative source per field, defined behaviour when either side is unavailable, protection against duplicates, an audit record of what moved and when, and documentation your team can operate from.
How is it priced?
Custom quoteThe fee is quoted for your requirement, because scope, systems and complexity differ in every case.Quoted from the assessment findings. Effort is determined by the number of systems, what their integration points support, the volume and cleanliness of the data, and how current it must be.
How long does it generally take?
Confirmed in the written scopeStated in the written scope from the assessment findings, and dependent on third-party API availability and on any tier upgrade you need to arrange.
What happens next?
Send an enquiry describing the requirement. We confirm whether an assessment is the right starting point, then set out its scope and fee in writing before any work begins. An enquiry is not an order: an engagement becomes binding only when it is expressly accepted, as set out in the Terms of Service.

Deliverables

  • The working integration between the agreed systems
  • One authoritative source per field, enforced by the design
  • Failure handling: retries, backoff, alerting and a defined manual recovery path
  • Duplicate protection
  • An audit record of what moved, when, and what was rejected
  • Handover documentation covering operation, failure modes and how to extend it

Included

  • Implementation of the agreed integration
  • Record matching as specified by the assessment
  • Failure handling and duplicate protection
  • Testing against real records, including the known bad ones
  • Two adjustment rounds after go-live
  • Handover documentation

Not included

Stating the boundary is part of the offer. Anything here can usually be arranged separately.

  • The assessment — an implementation is not quoted without one
  • Bulk data cleansing or historical migration, unless separately scoped
  • Software licences, subscriptions or tier upgrades
  • Ongoing operation, monitoring or support, unless separately scoped
  • Any guarantee about a third-party API continuing to exist or behave unchanged

Customer prerequisites

  • A completed assessment with specific, implementable findings
  • Scoped access to each system in scope
  • Any licence-tier upgrade the assessment identified as necessary
  • A named owner on your side

Information and access we need

We will ask for these. Where the work needs access to a system, access is arranged and scoped with you rather than assumed.

  • Scoped credentials issued through your own identity and access management
  • Test or sandbox environments, where they exist
  • Confirmation of the authoritative source for each field
  • Who is alerted when a record cannot be matched or moved

Expected process

  1. Assessment first

    An implementation is quoted from an assessment, not from a description. If no assessment exists, that is the starting point.

  2. Written scope and fee

    What will be built, what is excluded, the revision allowance, the indicative timescale and the fee — agreed in writing before work starts.

  3. Access and environment

    Scoped access is arranged through your own identity and access management. We work in a test environment where one exists.

  4. Build and review

    Implementation with review points, so you see it working against real cases rather than at the end.

  5. Handover

    Documentation of what was built, how it behaves when something fails, and what you need to know to operate it.

Meetings, revisions and scope

Meetings
Meeting optional, at the delivery review (about 60 minutes)
Revisions
2 revisions included. Two rounds of adjustment after the integration is running against real data. Additional systems or fields are a scope change.
Scope
Deliverables are limited to those expressly included in the agreed scope. Additional revisions, meetings, research or services outside that scope may require additional fees — see the Consulting Terms.

Frequently asked questions about this service

What happens if a proposed implementation is not feasible?

You are told, with the reason, and you are not charged for an implementation that cannot be delivered.

This is the main reason the Consulting catalogue separates an assessment from an implementation. The assessment is the paid piece of work that establishes whether something is practical, what it would take, and what it would cost. Its output is useful even when the answer is "not this way": it will say what does work, what the blockers are, and what a smaller or different change would achieve.

Where a recommendation depends on software, platforms, vendors, APIs or external suppliers, their availability and their decisions are outside our control — stated in Third-Party Dependencies.

Can you connect applications we already use?

Often, yes — and that is the question the integration assessment answers for your specific systems rather than in general.

What determines it:

  • whether each application exposes an API, an export, a webhook or a supported integration point
  • whether your licence tier includes that access — this is a common blocker and is worth checking early
  • whether the data in the two systems can actually be matched reliably (a shared identifier, or a rule that produces one)
  • how often the data has to move, and what happens when one side is unavailable

We do not commit to an integration before those answers exist. Where a supported route does not exist, the assessment says so and sets out the alternatives, including the ones that are not software.

How do you approach cross-application data integration?

Assessment first, implementation second, and never the other way round.

  • Assessment — what data exists, where it is authoritative, how records can be matched, what the integration points genuinely support, what the failure modes are, and what it will take.
  • Implementation — build the integration, including what happens when it fails: retries, duplicate protection, and a record of what moved and when.

One rule shapes the design: exactly one system is authoritative for each piece of data. Two systems that both believe they own the same field will eventually disagree, and no amount of synchronisation resolves that afterwards.

Will you need access to our systems?

For most Consulting work, some access is needed — but it is scoped and agreed with you, never assumed. Each service page lists what it needs under "Information and access we need".

The principle applied is least privilege and shortest duration: read-only where reading is enough, a sandbox or test environment where one exists, access limited to the systems in scope, and removal at the end of the engagement.

The Consulting Services Terms record that the client provides reasonably necessary access and credentials, and that each party will use reasonable safeguards for confidential information received in connection with the engagement.

How is sensitive access handled?

Practically, and with your own controls rather than ours:

  • access is requested for named systems and a stated purpose, not as blanket administrator rights
  • credentials are issued by you through your own identity and access management, so you can see and revoke them
  • shared credentials are avoided wherever your systems support individual accounts, because a shared one cannot be attributed or cleanly revoked
  • production data is not copied out of your environment where the work can be done inside it
  • access ends when the engagement does, and you should verify the removal yourself

Where a more specific arrangement is needed, an NDA or engagement agreement controls over the general terms — Confidentiality.

Why do some services require a quote?

Because their effort is determined by your environment, not by our method. An implementation depends on how many systems are involved, what those systems support, how clean the existing data is, how many exceptions the process has, and who has to approve what.

A published figure for that kind of work would be a guess, and a guess in a price list is either too high for the simple cases or a source of change requests for the complex ones. Quoting it means the number you receive describes your requirement.

A quote-required service never displays a price on this website — not a "from" figure, and not a zero.

Next step

Request a quote

Reference systems-data-integration-implementation is added to your enquiry automatically so it reaches the right place.