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 that builds in two weeks and one that drags for six months is almost never the technology. It is the preparation. The businesses with smooth AI integrations are the ones that resolved the items on this AI integration checklist before the first build session, not during it. Every item you cannot answer before signing turns into a timeline extension or a budget overrun later. This page splits the work into two parts: the items you settle about your own systems, and the questions you ask any provider before you sign. Work through both. If a provider pushes you to start before these are answered, that is information about the provider.

Your systems

These six items are inside your own control. Resolve them before you brief anyone.

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 cap 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 build. If your current plan does not include the required access, you may need to upgrade before any 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 behind it. Spend one hour reviewing your CRM. Are contact records consistently structured? Are deal stage labels used accurately? Are there duplicate records or fields routinely left empty? Data quality problems discovered mid-build stretch timelines. They are far 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 you engage a provider. They become the internal owner of the integration after handover, so their input on how the current process actually runs is the most valuable input you have.

4. Map the current workflow in writing before the first meeting

Write down the current process step by step before you talk to anyone. Record what triggers the workflow, what decisions get made at each step, which systems are touched, and how long each step takes a human. This document makes scoping faster and stops the integration from solving the wrong problem. It also gives you a baseline. Once the integration is live, you can only prove it saved time if you wrote down what the work cost before.

5. Confirm credentials and admin access are available

Integrations need API keys, admin account access, and in some cases app review approvals from the platform providers themselves. The WhatsApp Business API, for example, requires a Meta Business Manager account tied to a verified business. If credential setup is required, it can take days to clear. Confirm every access requirement before you agree to a build timeline, because a build cannot start without the keys.

6. Check which team workflows 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 changed. Identify the training requirements before launch, not after the support tickets start arriving.

Your provider

These six questions separate a provider who builds from a provider who sells. Ask all of them before you sign.

7. Ask for the last three working integrations they built

Not the last three case studies on the website. The last three systems running 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 you to testimonials is selling, not building.

8. Get a specific build 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. It should not push the build date out by four to six weeks. A real engagement has a delivery date, not a phase structure with no milestones attached to it.

9. Confirm what you receive at handover

Ask for a written list of what the provider hands over at the end. The minimum for a real integration is four things: running code or a configured workflow, all credentials and API keys held in your ownership, documentation of how the integration works and what to check when it misbehaves, and at least one handover session where the internal owner is trained on the system.

10. Ask whether the system keeps running after the engagement ends

Some integrations are built so they need ongoing provider access or a continuing retainer to run. If the system breaks the moment the retainer stops, the client did not receive an integration. They received a dependency. Ask it plainly. If we end this engagement in three months, will the integration keep running without your involvement, or does it go dark?

11. Confirm which tools get used and who owns the subscriptions

If the integration relies on a Make.com account or an n8n instance, confirm whether you own and pay for that subscription directly, or whether it sits inside the provider's account. A provider account is a handover dependency waiting to bite you. Your own account means you own the infrastructure outright, and the provider cannot switch it off.

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 build 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 has ended?

What to do once you have worked through the list

If you cannot answer all twelve items before signing, do not sign yet. The items you cannot answer are the scope gaps, and scope gaps are exactly what become timeline extensions and budget overruns once the work is underway. A provider who refuses to wait for these items to be resolved is a provider who benefits from the gaps, not from your success. The full picture of what a real engagement looks like from brief to handover sits in our guide to AI integration services. For the broader context on what integration actually means and where it fits, start with the AI integration explainer and read it alongside this checklist.

How twohundred works through this checklist in practice

When we scope an integration at twohundred, we treat the first six items as your homework and the last six as our open book. Before a build is booked we want the current workflow mapped in writing, the credentials confirmed, and the data audited, because those three alone account for most of the delays we have seen. On our side, we name a build date before you sign, we hand over the running system with every key in your ownership, and we build so the integration keeps running if you never speak to us again. That is the test that matters. If a system only survives while the provider stays attached, it was never an integration. You can see how we structure that work on our AI implementation services page.

Frequently asked questions

What should be on an AI integration checklist before signing a contract?

A complete AI integration checklist covers two areas. First, your own systems: API access at your plan tier, data quality in the target system, the internal owner of the affected workflow, a written map of the current process, confirmed credentials, and any training needs. Second, your provider: proof of recent production builds, a committed build date, a defined handover, independence after the engagement, tool ownership, and a failure plan. Every gap you leave open becomes a delay once the build starts.

How long does an AI integration take to build?

A well prepared integration can have its first working version live in around two weeks, while a poorly prepared one can drag for six months. The gap is rarely the technology. It is the preparation. When the data is clean, the credentials are ready, and the current workflow is documented, the build moves fast. When those are discovered mid-project, the timeline stretches. Ask any provider for a specific build date before you sign, because vague discovery phases that add four to six weeks are a warning sign.

What should a provider hand over at the end of an AI integration?

At minimum, four things. Running code or a configured workflow. All credentials and API keys held in your ownership, not the provider's. Documentation that explains how the integration works and what to check when it behaves unexpectedly. And at least one handover session where your internal owner is trained on the system. If a provider cannot list these before signing, the engagement is likely to leave you dependent on them.

Who should own the automation tools and subscriptions?

You should. If the integration runs on a Make.com account or an n8n instance, that subscription belongs in your account, paid by you directly. When the tooling sits inside the provider's account, you have a handover dependency. The day the relationship ends, the integration can be switched off or held to a renewal. Owning the infrastructure yourself means the system keeps running on your terms, regardless of who built it.

Related reading

• AI integration costs in 2026: what you actually pay for, at /blog/ai-integration-costs
• AI integration challenges: the most common ones and how to fix them, at /blog/ai-integration-challenges
• How to integrate AI into your business: an operator map, at /blog/how-to-integrate-ai-into-business