Before connecting your CRM: seven questions for an integration proposal.

What exact handover are we connecting?

Replace connect our website to the CRM with a concrete statement. For example: after a valid enquiry is submitted, create or update the agreed contact record, attach the request, assign a coordinator and show the team whether the handover completed. Specify the fields, attachments and customer-facing messages involved.

An API is a supported way for software systems to exchange requests and information. Its existence does not prove that every screen or action in a product is available through it. Ask the supplier to demonstrate the precise handover with representative records, including an incomplete request. Keep unrelated reporting and outreach features outside the first release unless they are separately justified.

Which system owns each fact?

A CRM might own contact details while a project platform owns delivery status. Decide that at field level before discussing two-way sync. If both products can change the same value, write down how the integration will handle disagreement. The latest update is not automatically the correct update when one system contains an old imported record.

Use stable record references rather than names alone to connect the two sides. Consider a customer who submits another enquiry, changes their email address or has two active projects. Ask what happens when staff merge or archive a record. The aim is a coherent relationship between records, not a rule that copies every edit everywhere.

The connection is only useful when the team knows what it changes—and what happens when it cannot.

Does our actual account support the required access?

Confirm capabilities against the subscription and account the business will use, not a supplier's demonstration account. Ask which API operations and permissions are required, whether an account upgrade is necessary, and what test environment is available. Keep the authorisation limited to the work the integration needs to perform.

HubSpot's documentation illustrates why this check matters: API limits vary by app type and subscription, and some endpoints have their own stricter limits. That is not a reason to avoid the product. It is a reason to request an account-specific feasibility check before approving a fixed scope or accepting an assumption that every connector behaves identically.

How will it handle repeated or out-of-order updates?

Some integrations use webhooks: notifications sent when something changes in a source system. Stripe's documentation explicitly describes possible duplicate deliveries, retries and events arriving out of order. Other suppliers have their own delivery behaviour, which the implementation team should verify rather than assume.

Translate that into a business test. If the same enquiry notification arrives twice, does the team get one request or two? If an older update arrives after a newer one, can it put the record back into the wrong state? Ask the supplier to show these cases in a test environment. A green success message from one normal run does not answer them.

What happens during a busy period or an outage?

A monthly import can generate a different load from the normal trickle of new enquiries. Ask how the proposed connection handles backlogs, service interruptions and limits on API requests. HubSpot documents rate-limit responses and approaches such as throttling requests. The appropriate design depends on the supplier and on how quickly your business needs an update.

Agree what staff will see while work is waiting. A pending handover should not look completed, and a delayed update should not vanish from the team's view. Identify which activities can safely wait and which need an immediate human route. Test recovery using synthetic records before connecting a customer-facing workflow.

Can a person understand and recover a failed handover?

Request an exception view that shows the affected request, the destination, what completed and what needs attention. A coordinator should not have to interpret a long technical log to decide whether to contact a customer. At the same time, the support team needs enough diagnostic detail to investigate without copying unnecessary personal information into every alert.

Ask who can retry an operation, how duplicate actions are prevented during a retry, and what requires a developer. Include a pause control and a way to reconcile the two systems after an interruption. A retry button is useful only when the team understands which part of the handover will run again.

Who owns the connection after launch?

The proposal should name the owner of the accounts, credentials, configuration and support process. Ask how access is revoked when a staff member or supplier leaves, where operational documentation lives, and who reviews supplier changes. Include a handover plan for another maintainer if the working relationship ends.

Compare an existing connector, a configurable automation tool and a custom integration using the same acceptance tests. Each may be appropriate. The decision should turn on required behaviour, practical ownership and ongoing support—not whether one option sounds more advanced. Start with one reliable data flow, then add the next connection when the team can explain why it is needed.

Put the idea to work.