What you need to know first

What problem does this solve?: Several systems across more than one team hold overlapping information, and each team believes its system is the authoritative one. The integration problem is real but it is downstream of an ownership problem: connecting the systems without resolving that would propagate the disagreement instead of fixing it.
What exactly do I receive?: An agreed data-ownership model across the applications and teams in scope — exactly one authoritative source per field — and integrations built against it, with failure handling and a record of what moved between which systems.
How is it priced?: Custom quoteThe fee is quoted for your requirement, because scope, systems and complexity differ in every case.Always quoted. The effort is dominated by the number of systems, the number of teams who must agree, and the state of the existing data — none of which can be estimated from outside. A staged scope is normal: ownership model first, then integrations in priority order.
How long does it generally take?: Confirmed in the written scope, and normally stagedWork of this shape is scoped in stages so each one has its own deliverable and decision point. Timescales are stated per stage rather than as one figure, and the pace of the ownership stage depends on your teams, not on us.
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

A data-ownership model across the applications and teams in scope: one authoritative source per field, agreed in writing
An integration architecture, with the priority order and the reasoning for it
The integrations for the agreed stages
Failure handling, duplicate protection and an audit record per integration
Handover documentation per stage

Included

Assessment across all applications and teams in scope
Facilitated agreement on data ownership
Integration architecture and staged plan
Implementation of the agreed stages
Failure handling and audit records
Two adjustment rounds per stage, and handover documentation

Not included

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

A commitment to any particular integration before the assessment stage completes
Deciding data ownership on your behalf — that decision belongs to your teams, and we facilitate rather than impose it
Data cleansing or historical migration, unless separately scoped
Software licences, subscriptions or tier upgrades
A replacement or consolidation of applications, unless separately scoped
Ongoing operation or support, unless separately scoped

Customer prerequisites

A sponsor with authority across all the teams involved — without one, the ownership stage cannot conclude
Named representatives per application and per team
Acceptance that some current practices will have to change for the model to hold

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.

The applications and teams in scope, and who owns each system today
The overlapping data, and where each field is currently maintained
Licence tiers and integration capability per application
Read-only or sandbox access per application
Your priority order, and the business reason behind it

Expected process

Enquiry
You describe the systems, the teams and the overlap.
Assessment
Assessment across every application and team in scope, ending in a proposed ownership model and a staged plan.
Ownership agreement
Facilitated sessions until one authoritative source per field is agreed in writing. Nothing is built before this.
Staged implementation
Integrations delivered in the agreed priority order, each stage with its own scope, fee and decision point.
Handover per stage
Failure handling, audit record and documentation delivered with each stage rather than at the end.

Meetings, revisions and scope

Meetings: Meeting required, during the assessment (about 90 minutes)
Revisions: 2 revisions included. Two adjustment rounds per delivered stage.
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.

Read every answer in the FAQ & Trust Center

Next step

Request a quote

Reference multi-application-integration is added to your enquiry automatically so it reaches the right place.