Your AI Isn't Underperforming. Your Business Context Is. An AI Readiness Assessment Shows Why.
Somebody turned the AI on last quarter. A Zia agent for support triage, maybe predictive scoring on the lead pipeline. The demo was convincing. Six weeks later, nobody can point at a number that moved.
The instinct is to blame the model. It is almost never the model.
At Zoholics 2026 in Houston this May, Zoho chief strategy officer Vijay Sundaram put it in one sentence: “AI isn’t underperforming because the models aren’t powerful enough. It’s underperforming because the business context those models rely on is fragmented, ungoverned, and invisible to the systems meant to act on it.” In a session the same week, Zoho’s head of applied AI told the room that companies are “torching budgets on AI.”
Gartner reads it the same way from outside the ecosystem. In June 2025 it predicted that more than 40% of agentic AI projects will be canceled by the end of 2027 — on escalating costs, unclear business value, and inadequate risk controls. Note what is not on that list: model capability.
Zoho’s own adoption figures show the same gap in miniature. As of Zoholics 2026, 9,000 customers had signed up for Zia Agents, 19,000 agents had been created, and 13,000 had been deployed. Roughly a third of everything built never went into service.
That gap between built and running is what this post is about — and what an AI readiness assessment should actually be measuring.
Most AI readiness assessments score you across strategy, talent, culture and infrastructure, then hand back a maturity level. That makes a fine board slide. It does not tell an operations manager what to fix on Monday.
For a business running Zoho One, the readiness question is narrower and far more answerable: can the systems this agent is about to read from actually answer the question it is about to be asked?
Four things decide that. Data hygiene. Documented process. Permissions. And one party accountable for all three. None of them are interesting. All of them are the difference between an agent that saves a team four hours a week and one that produces confident nonsense at speed.
The failure modes are specific, and they stop being mysterious once you have seen a few of them.
Predictive lead scoring learns from your closed-won and closed-lost history. If Industry is blank on 40% of Accounts, if Lead Source has been a free-text field since 2022, if a third of last year’s Deals were closed by an admin doing bulk cleanup on the final day of a quarter — that is the pattern Zia learns, and it will score against it without hesitating. Zia’s predictive scoring and manual rule-based scoring answer different questions, and the strongest setups use both deliberately. But both degrade on exactly the same input problem: fields that are optional in practice and therefore blank in bulk.
A custom picklist gets added for one campaign. The campaign ends. The field stays, half-populated, and nobody was ever assigned to maintain it. Two years later a workflow rule still fires on it, generating tasks into a queue an agent now reads as signal. The output is wrong and nothing errors. That silence is the real problem — a broken integration raises an alert, a decayed field does not. Validation rules stop bad data at entry while approval processes put a human in front of a decision; which one a field needs depends on whether you are preventing an error or reviewing a judgment call. Most estates have neither on the fields their agents depend on most.
Ask an agent what your exposure is with a customer that exists three times in CRM — once from a trade show import, once from a storefront sync, once typed in by a rep — and you get a third of the answer delivered with the confidence of a whole one. A human looking at that screen notices the duplicates. An agent summarizing four hundred records does not, and nothing in its output tells you it missed two-thirds of the relationship.
An agent acts inside a security context, and that context comes from the access model you already have. In Zoho CRM, roles set how far a user can see and profiles set what a user can do. Estates that have grown for five years usually have a role hierarchy that no longer matches the org chart and two or three profiles that were cloned once and never revisited. Point an agent at that and it will summarize across records a person in that seat would never have been shown. This is where “inadequate risk controls” stops being a Gartner phrase and becomes a specific setting in your setup panel.
Data hygiene. Not a one-off cleanup project. Deduplication rules that run continuously, fields that are required at the stage they matter rather than required always, picklists instead of free text on anything you will later want to group by, and a named owner for each. A cleanup that is not maintained decays back to roughly where it started inside a year.
Documented process. An agent can only act on a process somebody has decided. Sundaram’s point at Zoholics was that institutional knowledge lives in three places: systems, documents, and people’s heads. Only the first is legible to an agent. Where the real process lives in the third place — the rep who knows which discounts actually get approved — the agent has nothing to reason over, so it produces a plausible invention instead.
Permissions. Decide what an agent is allowed to see and change before deciding what it should automate. That means a deliberate role and profile model and a named security context per agent, rather than whatever access the person who built it happened to hold.
Accountability. Somebody has to be answerable for all three, continuously, after the project closes. This is the part most estates never assign, and it is why readiness scores drift back down within a year of any cleanup.
Seven checks. Most of a day’s work, and more useful than any maturity score.
Pick the one question you want an agent to answer. Write it down as a single sentence.
List every field and module that question depends on.
Run a fill-rate report on each of those fields. Anything under 90% populated is not ready.
Count the duplicates in the modules involved. If you cannot count them, that is your answer.
Find who owns each of those fields, by name. Not a department. A person.
Write out the process the agent would follow, in numbered steps. If two people write different versions, the process is not documented.
Decide what the agent may read and what it may change, then check that against the profile it will actually run under.
If four or more come back bad, the honest conclusion is that you are not ready to deploy that agent yet. The cheaper project is fixing the middle layer, not buying more AI.
The reason this work does not get done is not that it is hard. It is that it belongs to nobody. Data hygiene sits between sales ops and IT. Process documentation belongs to whoever last had time. Permissions belong to the admin who is also doing four other jobs. Each of them is somebody’s third priority, which makes it nobody’s first.
That is the argument for treating the middle layer as an ongoing operational responsibility rather than a project with an end date. Managed technical operations exists for exactly this shape of work — maintenance with no launch date and no obvious finish line, which quietly decides whether everything built on top of it works. It is the same reason AI demand forecasting only pays off once the data behind it is production-ready and the output actually drives the schedule. The model was never the constraint.
CodeStringers structures the commercial terms around that. Discovery is no-risk — you pay for it only if you proceed to implementation, so finding out how thin your foundation actually is costs nothing if the answer is “don’t build this yet.” Estimates are guaranteed: if we estimate low, we absorb the difference. Retainer clients get a project plan with the full cost of a release before committing to it, instead of an open meter.
That is what accountability means here. Not that we take the system off your hands, but that we commit to an outcome and carry the consequences of being wrong about it.
No. Clean what the agent reads. Pick one question, map the fields behind it, and fix those. A full-estate cleanup in front of a single use case is how these projects stall before anything ships.
For one agent’s worth of scope in a mid-market Zoho estate, usually two to six weeks — most of it deduplication, assigning field ownership, and writing down a process that already exists informally. Estate-wide governance is a longer program, and it should be sequenced behind the first working agent rather than ahead of it.
The argument is not. The failure points are. Zia scoring on incomplete records, workflow rules firing on unmaintained fields, and role-versus-profile drift are Zoho mechanics, and knowing exactly where they break is what makes the diagnosis fast instead of theoretical.
The next time an AI pilot underdelivers, resist the upgrade. Ask what the model was reading, who owns those fields, and whether the process it was asked to follow was ever written down. Fixing that answer is almost always cheaper than the next model.
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:
You Can't Automate a Process Nobody Has Written Down (article)
Your Business Should Warn You Before the Month Goes Wrong (video)
Your Small Business Has Plenty of Data but You Still May Not Know What Is Happening (video)
A useful one checks four things for a specific use case rather than scoring the whole company on strategy and culture. Data hygiene: fill rates, duplicates and free-text fields in the modules the AI will read. Documented process: whether the steps the AI would follow are written down and agreed. Permissions: what the AI may see and change, and under which identity. Accountability: who owns each of those three after the project closes. A maturity score makes a board slide; these four tell an operations manager what to fix.
Almost never because of the model. It underperforms because the records it reads are fragmented and ungoverned: fields blank on a large share of accounts, a customer that exists three times, workflows firing on picklists nobody owns, and an agent running under whichever administrator set it up. The model learns and reasons from exactly what it is given. The page cites an analyst prediction that a large share of agentic projects will be cancelled for cost, unclear value and inadequate risk controls, none of which is model capability.
For a single use case, usually weeks rather than quarters, because the scope is the fields and modules that one question depends on, not the whole estate. The seven-point check on the page is a day's work. Fixing fill rates, deduplicating the relevant modules, writing the process in numbered steps and building the agent's own permission profile typically fits inside a few weeks. A full-estate cleanup in front of one use case is how these projects lose momentum, so it is best avoided.
No. Clean what the agent reads. Pick the one question you want it to answer, list the fields and modules behind that question, and fix those: fill rates above ninety percent, duplicates counted and merged, free text replaced by picklists where you will group by the value. Maintain those fields with deduplication rules, stage-based required fields and a named owner. A cleanup that is not maintained decays back within a year, which is why the ongoing ownership matters more than the one-time project.
A named person, continuously, for data hygiene, documented process and permissions together. The reason the work does not get done is that it belongs to nobody: data sits between sales operations and IT, process documentation belongs to whoever last had time, and permissions belong to an administrator doing four other jobs. Treating it as an ongoing operational responsibility, with managed technical operations or an equivalent internal role holding it, is what keeps readiness from drifting back down after any project ends.
"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.