ENLV
Book diagnostic
Book diagnostic Calculator

FREE TOOL

Integration scope estimator

Twelve questions about the systems involved, the data that should move between them, how it may move and what should happen when a step fails. The result is the list of building blocks your integration needs with a reason for each, what has to be settled first, the risks your answers reveal, what you receive at the end, and what monthly care covers. No prices: scope first, proposal after the first conversation.

OWNERSHIP BEFORE CONNECTORS

What would your integration consist of?

Answer as things are today. An integration is rarely one missing link; it is a data path with an owner for every field. The estimator shows that path as blocks, marks what must be decided before anything is connected, and names the risks that turn a two-week job into a six-month cleanup.

Step 1 / 4Systems
1 of 4
  1. Systems
  2. Flows
  3. Access
  4. Operations
What should be connected

The systems in play and the one that should own the truth.

Which systems are involved?

Which system should own the customer and order truth?

HOW IT DECIDES

Flows become blocks; ownership and access decide the rest

Each block is included for a reason you can read next to it.

  • Every integration gets a field map, ownership rules, a queue with retries, duplicate protection, an error path and monitoring. That is what keeps data safe when a step fails.
  • Each data flow you chose adds its block; two-way customer records add conflict rules.
  • Exports-only access adds an import bridge; partner access adds coordination; existing no-code flows are consolidated rather than thrown away.
  • Historical migration is scoped separately after a data quality review, so it never inflates the integration quietly.

WHY MONTHLY CARE

Integrations fail quietly; someone has to be looking

APIs change, tokens expire, a field is renamed, a vendor updates.

  • Monitoring catches failed and stuck transfers the same day.
  • Error queue review resolves records and turns recurring causes into validations.
  • API change care keeps connections working when systems and authentication change.
  • A monthly report shows transfers, failures and what was changed, so the integration stays trusted.

HONEST LIMITS

What this estimator does not do

  • It does not give a price. The access check and the data quality review can change the scope by half in either direction, and we do not sell guesses.
  • It does not replace the access check. Which systems have APIs, admin access and sandboxes is verified before any proposal.
  • It does not include data cleanup or migration in the integration. Those are scoped separately once their quality and ownership are reviewed.
  • It does not replace the first conversation, where the data path usually turns out simpler, and the ownership question harder, than the form suggests.

Questions about the estimator

Why does it insist on a system of truth?

Because an integration copies whatever is in the source. If two systems both own the customer record, every sync has to guess which change wins, and the guess is wrong often enough to destroy trust in both systems. Deciding the owner is one conversation; cleaning up after not deciding takes months.

Make, Zapier or a direct API integration?

Make and Zapier work well for simple, low-volume flows such as creating a lead from a form. For higher volumes, custom fields, duplicate protection or flows that must not lose a record when a step fails, we connect directly to the APIs with validation, queues and error handling. The estimator shows which one your flows need.

What if we only have exports, no APIs?

Then the integration runs on scheduled exports and validated imports. It is slower and needs checks on every import, but it works, and it is often the first step while API access is arranged.

What happens to my answers here?

They stay in your browser until you choose to send the result through the contact form. We do not store questionnaire answers otherwise.