The AI readiness checklists in circulation are written for a board: strategy, culture, talent, data governance, scored on a maturity scale. None of them can be answered by the person who runs the CRM on a Tuesday afternoon, and that person is the one who will find out whether the agent works.
This one can. It is twenty items in five sections, each a yes or a no, for a company whose business runs on Zoho CRM and the applications around it. It rests on one observation: an agent reads records and writes records, under someone's permissions, inside a process. So readiness is whether the records are complete, whether the systems agree who the customer is, whether the process is written down, whether the permissions and approvals exist, and whether anyone will know if it worked. The model is not on the list. The model is the part that already works.
One rule before the items. The first two sections are gating. A no in either means the agent project waits until it is a yes, because an agent acting on incomplete or disagreeing records does the wrong thing with confidence, which is worse than doing nothing. We made that argument in the piece on why your AI is not the problem; this is the checklist that follows from it.
Five items on the records the agent will read and write. A no on any one of them means the agent waits.
Every module the agent will read has a required-field list, and records cannot be saved without it. Not a policy, a validation rule.
The duplicate rule is defined per module and enforced at every door: form, import, connection, hand entry.
Fewer than five percent of accounts and contacts created in the last ninety days are missing the fields the agent will reason from. Run the report; do not estimate.
The fields the agent will act on are facts the system sets or validates, not opinions a person typed and forgot. Stage, amount, close date, owner, last activity. If last activity is updated by hand, it is not a fact.
Someone owns data quality by name, reads a quality report weekly, and has the hours to fix what it shows. Our guide to telling what shape your CRM data is in is the report to start from.
One system issues the customer id, and every other system that holds the customer carries it as a field. The report that joins sales to accounting does so on the id, not the name.
The same is true for the item, the project and the ticket, wherever those cross a system boundary.
For each connection between systems, it is written down which direction data flows and which system is right when the two disagree.
The one-time reconciliation of records that existed before the connections was done, and the duplicates it found were merged.
A cross-system report the leadership trusts exists today, without a spreadsheet step. If every cross-system number passes through a spreadsheet, the keys are not aligned, whatever the integration diagram says.
The sales process is written as stages with entry conditions, in the system, as a Blueprint, not in a slide deck.
For the process the agent will act in, the allowed next actions at each stage are enumerable. If a person cannot list them, an agent cannot choose among them.
The exceptions are known and named: the deal that skips a stage, the order that ships before payment, the ticket that bypasses the queue. The agent will meet them in its first week.
The process has an owner who can change it, and a record of the last time it changed and why.
Profiles and roles are configured so that a user sees only what their job needs. The agent will run as a user, and it will see what that user sees.
There is a named user the agent will run as, with a profile built for it, not a borrowed administrator login.
Approval processes exist for the actions that should wait for a person: amounts, stage moves past a threshold, reassignments in bulk, outbound email to customers above a size. Written before the agent is on, not after the first surprise.
The audit log is on for every module the agent will write to, and someone has read it in the last month.
The outcome the agent is meant to change is a number the business already measures, with a baseline from the last quarter. Response time, stage conversion, days to invoice, denial rate. If the baseline does not exist, success cannot be shown.
There is a review date, a person who will read the number on it, and a written threshold below which the agent is switched off.
Do not answer it from memory, and do not answer it in a meeting. Each item has a report or a setup screen behind it. For section one, the required-field and duplicate rules are visible under the module settings, and the ninety-day completeness figure is one custom report with a filter on created time. For section two, open the integration configuration for each connection and look for a written direction; if the only record is the connector's default, the answer is no. Section three is the Blueprint editor: either the process is there or it is not. Section four is profiles, roles and the approval process list, which take ten minutes to read. Section five is a question for the person who will sponsor the agent, and if they cannot name the number, that is the answer.
Write the twenty answers in one column with the evidence next to each, so that the next person who reads it can check it. A readiness score that nobody can check is an opinion, and the whole point of the list is to replace opinions with the state of the estate.
Twenty items, and the score is not the point. Sections one and two are gates: ten items, and a company we would start an agent project with has at least eight of them as a yes, with the missing two scheduled. Sections three to five are the build list: each no is a week or two of work that is part of the agent project rather than a reason to delay it, and the project plan should list them before the agent itself.
The honest outcome for most mid-market Zoho estates we review is a yes on five or six of the first ten. That is not a failure. It is the actual readiness work, it is cheaper than the agent, and it makes every other system in the company better whether or not the agent follows. The companies that skip it buy an agent that acts confidently on records nobody trusts, and switch it off in month three with the conclusion that AI does not work for them. It worked. The foundations did not.
Discovery is no-risk: we score the twenty against your estate, with the reports rather than the opinions, and you pay only if you go ahead.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Start a Zoho One trial through our sign-up, or tag us as your Zoho partner for free consulting time every month.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
