AI Integration

AI integration checklist: 12 things to do before you start

The AI integration checklist: 12 items before you sign

The difference between an AI integration project that ships in two weeks and one that drags for six months is almost never the technology. It is the preparation. The businesses that have smooth AI integrations are the ones that resolved the following twelve items before the first build session, not during it.

This checklist has two parts: items you need to resolve about your own systems, and questions you need to ask any provider before signing.

Your systems

1. Confirm the target system has API access at your plan tier.
Not all CRM or messaging platforms expose full API access on their base subscription. Some limit API calls per day. Some require a higher plan for the specific endpoints the integration needs. Pull up the API documentation for your CRM and your messaging tool before scoping the integration. If your current plan does not include the required access, upgrading may be necessary before any build work starts.

2. Audit the data quality in the target system.
A lead qualification integration that reads from HubSpot is only as good as the HubSpot data. Spend one hour reviewing your CRM: are contact records consistently structured, are deal stage labels being used accurately, are there duplicate records or fields that are routinely left empty? Data quality issues discovered mid-build extend timelines significantly. They are better handled as a pre-integration cleanup task.

3. Identify who owns the workflow the integration will change.
Every integration changes at least one workflow. The person whose daily routine changes needs to be involved from the scoping session, not introduced to the new system on launch day. Identify that person before engaging a provider. They are the internal owner of the integration after handover.

4. Map the current workflow in writing before the first meeting.
Write down the current process step by step: what triggers the workflow, what decisions are made at each step, what systems are touched, and how long each step takes a human. This document makes scoping faster and prevents the integration from solving the wrong problem. It also creates a baseline for measuring the impact after the integration is live.

5. Confirm credentials and admin access are available.
Integrations require API keys, admin account access, and in some cases app review approvals from platform providers. WhatsApp Business API, for example, requires a Meta Business Manager account with a verified business. If credential setup is required, it can take days to complete. Confirm all access requirements before agreeing to a build timeline.

6. Check whether the integration requires changes to any team workflows that will need training.
Not every integration change is visible to the end user. But some are. If the integration changes what a sales rep sees in their inbox, or what a customer service agent sees in their ticketing tool, that person needs to understand why the view has changed. Identify training requirements before launch, not after.

Your provider

7. Ask for the last three working integrations they shipped.
Not the last three case studies on the website. The last three systems in production right now, including the stack they run on and the time from brief to live. A provider who can describe these specifically, with named tools and timelines, is doing the work. A provider who redirects to testimonials is selling, not building.

8. Get a specific ship date before signing.
Any provider who cannot tell you when the first working integration will be live in your stack before the contract is signed is building in escape time. The discovery phase should identify which workflow to build, not delay the ship date by four to six weeks. A real integration engagement has a delivery date, not a phase structure without milestones.

9. Confirm what you receive at handover.
Ask for a list of what the provider will hand over at the end of the engagement. The minimum for a real integration is: running code or configured workflow, all credentials and API keys in your ownership, documentation of how the integration works and what to check if it behaves unexpectedly, and at least one handover session where the internal owner is trained on the system.

10. Ask whether the system will continue to function after the engagement ends.
Some integrations are built in a way that requires ongoing provider access or a continuing retainer to run. If the system breaks when the retainer stops, the client has not received an integration. They have received a dependency. Ask directly: if we end this engagement in three months, will the integration continue to run without your involvement?

11. Confirm which tools will be used and who owns the subscriptions.
If the integration requires a Make.com account or an n8n instance, confirm whether you will own and pay for that subscription directly, or whether it sits in the provider's account. A provider account means a handover dependency. Your own account means you own the infrastructure.

12. Ask how failure is handled.
Every integration breaks eventually. Software updates change API responses. Rate limits get hit. Credentials expire. Ask the provider how the integration handles failure: does it alert someone when a step fails, does it queue failed operations for retry, and who is responsible for fixing it when it breaks after the engagement ends?

After the checklist

If you cannot answer all twelve of these items before signing, do not sign yet. The items you cannot answer are the scope gaps that will become the timeline extensions and the budget overruns. A provider who will not wait for these items to be resolved before starting is a provider who benefits from the gaps, not from your success.

The full context for evaluating AI integration providers is in our guide to AI integration services, including what a real engagement looks like from brief to handover.

Related reading

AI integration checklist: 12 things to do before you start | twohundred.ai