Describe the handover in business terms
Name the information that should move, what triggers the handover and what the receiving system should do. “Connect our website and CRM” is too broad to estimate. “Create a new enquiry record when a valid website form is submitted, then assign it by service” gives the investigation a useful boundary.
An integration is not always two-way. A one-way transfer may meet the need with fewer conflicts. If both systems can edit the same field, decide which value wins before implementation begins.
Check that the interface supports the actual task
Ask the product supplier or developer to verify the relevant documentation and account access. The existence of an API does not mean every screen action is available through it. Access may depend on a plan, permission level or agreement with the supplier.
- Can the required records be read and written?
- Are there limits on request frequency or the volume of data returned?
- How are changes detected: a scheduled check, a notification or a manual action?
- Can historical records be retrieved for an initial import?
- What happens when the supplier changes its API or the account permissions?
Make one system authoritative for each fact
A common design problem is two systems both believing they own the same customer details or booking status. Document the source of truth by field or record. A contact correction may belong in the CRM while payment status belongs in the payment system.
Use stable identifiers rather than matching records only by names or email addresses that can change. Decide how duplicates are detected and how conflicts are reviewed. Data mapping should include the meaning of a field, not just a similar label. “Confirmed” may mean different things in two products.
Plan for delays and failure
Connections fail and services become temporarily unavailable. The integration needs a way to record incomplete work, retry where appropriate and make unresolved errors visible to a named person. Blindly repeating an action that charges money or reserves stock can make the failure worse.
Some systems send webhooks: notifications about events. Stripe, for example, documents that its webhook events can be duplicated and are not guaranteed to arrive in order. Its webhook guidance supports the need for deliberate duplicate handling and event processing. The booking payments guide explains the business consequences.
Include operation in the scope
Ask who monitors the integration, where errors are recorded, how access is renewed and how staff can correct a failed record. Agree what information may be logged; diagnostic records should not become an unnecessary copy of private customer details or credentials.
For a new project, a small feasibility check against a test account can expose limitations before the main build. The appropriate commercial route is often business automation or custom software development, depending on whether existing systems already do most of the work.
Discuss a connection between your systems
Name the products, the information that needs to move and the action that should follow. We can discuss what needs verifying before promising an integration.