On this page
- What an AI readiness audit is
- Who it is for, and who it is not for
- The scoring model
- What we actually produce
- How the audit works
- What we check in your systems and data
- The audit week by week
- What you get at handover
- Where audits go wrong
- What the resulting systems cost to run
- How to tell whether you need an audit
- How to start
What an AI readiness audit is
An AI readiness audit is a structured survey of a company's processes, data and systems that produces four things: a ranked list of automation candidates with a measured baseline for each, an estimate of build effort against that baseline, a named list of processes to leave alone with the reasoning attached, and the specific access, data and ownership blockers that must be cleared before any of it can be built. It is not a strategy document and it is not a slide deck. The test of a good one is that an engineer who was not in the room can read it and start on Monday.
The problem it solves is narrower than it sounds. Most companies do not lack ideas about what to automate. They have twelve, ranked by whoever argued hardest, with no measurement behind any of them and no check on whether the data required is reachable. The first build then takes twice as long as planned, and the reason is almost never the model.
- Measured, not askedDurations come from watching the work being done. Self-reported timings cluster around the median and omit the tail, and the tail is the cost.
- The leave-alone listAn audit that only says yes is a sales document. Naming what not to automate, and why, is what makes the rest credible.
- Access is the schedule riskCredential and sandbox provisioning routinely takes longer than the build. It belongs in the plan, not in the retrospective.
- Volume amplifies errorAutomation multiplies whatever your error rate is by your volume. High volume is a reason to check verifiability harder, not a reason to skip it.
- Process inventory
- The list of every repeated piece of work a team does, assembled from interviews, system logs and the shared inboxes and spreadsheets where undocumented work lives.
- Shadow process
- Work that is not in any documentation because it was never designed: the spreadsheet somebody maintains, the inbox rule, the weekly copy and paste. Shadow processes are frequently the best automation candidates precisely because nobody owns them.
- Blast radius
- What a wrong output costs and whether it can be undone. Classified as cheap, reversible but expensive, or irreversible. The class decides how much human review the design needs.
- Baseline
- The measurement of the current process taken before anything changes: volume, duration at median and at the tail, error rate, and cost. Without it, no later claim about improvement can be checked.
- Straight-through rate
- The share of items a system completes with no human touch. It is the honest headline number for an automation, and it is always lower than the demo suggests.
Who it is for, and who it is not for
For companies with budget approved and no agreement on where to spend it. If the argument in your building is about which process goes first rather than whether to do this at all, you are the reader.
- You have a list of candidate processes and no measurement behind any of them.
- A previous pilot went well in a demo and never reached production, and nobody has written down why.
- You are about to sign for a build and want an independent read on whether the scope survives contact with your systems.
- Your data is spread across systems that were never designed to be joined, and you suspect that is a problem.
- You need a document that an internal team or an external vendor can price and start from.
Who should not buy this
- You have one obvious process, one owner and reachable data. Skip the audit and build it. We will tell you this on the call.
- You want a document to justify a decision already made. The leave-alone list will be inconvenient and the audit will be shelved.
- You cannot give access to watch people work. Interviews alone produce the process as designed rather than the process as run.
- Nobody will own the resulting systems. That is worth fixing first, and an audit will only produce a ranked list of things that will not be maintained.
If budget is tight, run one process yourself with the intake record further down this page. Watch it being done, time it, fill in the fields, and see which ones you cannot answer. The empty fields are the audit finding. Most teams stop at the join key question.
The scoring model
Ranking by enthusiasm is the default, and it reliably puts the hardest process first because it had the loudest sponsor. This is the model we score against instead. It is deliberately simple enough to argue with in a room.
The ChatGPTalker Automation Fitness Score
Six signals, each scored 0 to 3, where 3 is best. Verifiability counts double because it decides whether anything else can be trusted. Reachability and ownership are gates rather than weights: a zero on either means the process is not ready, whatever the total says.
How often it runs. High volume justifies effort, and it also multiplies your error rate. A three percent error rate on twenty items a day is a nuisance somebody catches. The same rate on twenty thousand is an incident.
How similar one instance is to another. High repeatability suits a deterministic workflow. Low repeatability is not disqualifying, it changes the shape: you need an agent that plans, and a larger review budget.
Whether the output can be checked cheaply and objectively, by code or by a person in seconds. This is the signal that decides everything, which is why it counts double. Work you cannot check is work you cannot safely scale.
Whether a wrong output can be undone, and what undoing costs. Irreversible plus hard to verify means automate the preparation and leave the decision with a human. That is still most of the value.
Whether the data and systems can be reached programmatically today, with credentials somebody can actually grant. A gate, because no score compensates for a system with no API and no service account.
Whether a named person will own the system after launch and whose work improves if it runs well. Also a gate. An unowned automation degrades quietly and is switched off within a year.
Score each signal 0 to 3, where 3 is best. Maximum is 21 because verifiability counts double. Read the gate output first: if it is 0, either reachability or ownership is missing and the total does not matter yet.
| Score | What it means | What we recommend |
|---|---|---|
| 16 to 21 | Strong candidate with the gates clear | Build it first, take the baseline before anything changes |
| 11 to 15 | Worth doing, usually after a specific blocker is cleared | Fix the named blocker, then build, and expect a longer review period |
| 6 to 10 | Automate the preparation, leave the decision with a person | Scope it as assistance rather than replacement |
| 0 to 5, or any gate at 0 | Not ready, and no amount of model quality changes that | Leave-alone list, with the reason and what would change it |
What we actually produce
Documents an engineer can build from and a finance person can price. Not a maturity model, not a two-by-two.
| Deliverable | What is in it | Who uses it |
|---|---|---|
| Process inventory | Every repeated process found, including shadow processes, with observed volume and duration | The sponsor, to see the real surface area |
| Ranked candidate list | Each candidate scored on the six signals, with the gate result stated separately | The decision meeting |
| Baseline pack | Measured volume, median and tail durations, known error rate, and how each was measured | Whoever has to prove the build worked later |
| Blocker register | Each missing credential, absent service account, missing join key, with the named owner and their stated lead time | The project manager, on day one rather than week six |
| Build briefs | For the top three: scope, data flow, integration points, review design, and the failure modes to design for | The internal team or the vendor you hire |
| The leave-alone list | What not to automate, why, and what would change the answer | Everyone, and it is the part that gets quoted back to us |
// audit/process.record.json one record per candidate process.
// Copy this and fill one in yourself. The empty fields are the findings.
{
"id": "ops-invoice-intake",
"name": "Supplier invoice intake",
"owner_after_launch": null, // null is a gate failure, not a to-do
"observed": { // measured by watching, never self-reported
"runs_per_week": 420,
"minutes_median": 4,
"minutes_p90": 22, // the tail is where the cost actually is
"method": "screen recording, 12 runs, 2 people, one Monday and one Thursday"
},
"signals": { // 0 to 3 each, scoring model below
"volume": 3, "repeatability": 2, "verifiability": 3,
"reversibility": 2, "reachability": 1, "ownership": 3
},
"verification": {
"machine_checkable": true,
"check": "line total must match the purchase order within tolerance",
"who_checks_today": "AP clerk, by eye, when the amount looks odd"
},
"error_cost": {
"class": "reversible_expensive", // cheap | reversible_expensive | irreversible
"worst_case": "duplicate payment to a supplier",
"current_error_rate_known": false // if false, that is finding number one
},
"systems": [
{ "name": "SupplierPortal", "access": "api", "auth": "oauth_client_credentials",
"sandbox": true, "rate_limit": "60/min",
"credential_owner": "IT, states a two week lead time" },
{ "name": "Ledger", "access": "screen_only", "auth": "human_sso",
"sandbox": false, "blocker": "no service account exists" }
],
"join_key": { "field": "supplier_id", "present_in_all_systems": false },
"decision": "prepare_not_decide",
"note": "Extract and match automatically. A human approves the payment."
}The field most audits skip is whether a stable identifier exists in every system the process touches. Without one, a project that looked like automation becomes an entity resolution project, which is a different discipline with a different budget. We check this before scoring anything, because it can move a candidate from first place to the leave-alone list in one afternoon.
How the audit works
Three sources, deliberately, because each one lies in a different direction. Managers describe the process as designed. The people doing it describe it as run, workarounds included. The logs describe what actually happened, and they do not have opinions.
- Interview the people doing the work, not only their managers
The manager's version is the documented process. The operator's version includes the spreadsheet, the second inbox and the step everyone skips on Fridays. Both versions are useful and only one of them is buildable.
- Watch, and time it
We record a handful of real runs on different days. Self-reported durations are unreliable in a predictable direction: people report a typical case and forget the twenty minute exception, which is where the cost concentrates.
- Pull the system logs
Ticket counts, message volumes, export histories. Logs settle arguments about frequency in minutes, and they usually reveal a process nobody mentioned in any interview.
- Test reachability for real
We attempt an authenticated call against each system in scope, or establish precisely why we cannot. A vendor saying an API exists and a working credential are different facts.
- Score, then challenge the score
Each candidate is scored on the six signals with the evidence attached. We then argue the top three with your team, because a score nobody has pushed back on is a score nobody believes.
- Write the briefs and the leave-alone list
The top candidates get build briefs detailed enough to price. Everything rejected gets a reason and a condition that would change the answer, so the list stays useful next year.
Ask how long something takes and you get the median of the pleasant cases. The tail is invisible to the person doing the work because it feels like an interruption rather than the job. Since the tail is usually where the money is, an audit built on interviews alone tends to rank the wrong processes first, confidently.
What we check in your systems and data
The technical half, and the half that decides schedules. A process can be perfectly automatable and still be unbuildable this quarter because of one credential nobody can grant.
Reachability, in order of how often it blocks
- Is there an API, or is the only route a human logging into a screen? Screen-only systems are workable and they cost more and break more.
- Can a service account exist? If the only way in is a person's login, the automation inherits that person's permissions, which is a security finding rather than a design.
- Who grants the credential, and what is their real lead time? Ask for the number and put it in the plan.
- Is there a sandbox? Without one, the first end-to-end test happens in production, which changes how the build has to be sequenced.
- What is the rate limit? It sets the maximum throughput of the whole process regardless of how fast anything else is.
Data quality, in the order that matters
- Is there a stable join key across every system the process touches? This is the first question, not the last.
- How are duplicates handled today? If a human silently deduplicates by eye, that is a step in the process nobody documented.
- What share of records have the fields the process needs? A field that is present in sixty percent of rows is not a field the design can rely on.
- Is there history, and how far back? Retrieval and evaluation both need examples of the work, and a system that keeps ninety days limits both.
- Where does personal data enter, and what may leave the building? This constrains the architecture, so it belongs at the start.
An automation acting on behalf of a person should never hold more access than that person. Where the only available integration is a shared admin account, say so in the register as a risk with a named owner rather than absorbing it quietly into the build.
The audit week by week
Interviews with operators and managers, screen recordings of real runs, and log pulls. We come out with a longer process list than anyone expected and rough volumes for each.
Authenticated calls attempted against every system in scope, join keys tested on real records, field completeness measured. The blocker register is written this week, because its lead times drive everything else.
Every candidate scored on the six signals with evidence attached, then the top of the list argued through with your team. Scores move in this session, which is the point of holding it.
Build briefs for the top candidates, the baseline pack, and the rejections with their reasons and reversal conditions. Handed over as documents, then walked through with whoever will do the building.
Two quarters, roughly. After that your systems, staff and volumes have moved enough that the ranking is a history document. If the audit will sit on a shelf awaiting budget, take the baseline again before you build, because building against a stale baseline means you can never prove what changed.
What you get at handover
Everything as working documents and data, in formats you can edit without us. The scoring spreadsheet matters as much as the report, because next year's candidates get scored the same way.
The test of an audit is whether an engineer who was not in the room can start on Monday. Everything else is decoration.How we grade our own audit documents
Where audits go wrong
The honest section. Seven failures, and we have caused some of them.
- It becomes a slide deck. Beautiful, strategic, and impossible to build from. If there is no data flow and no integration detail, it is a point of view rather than an audit.
- Only managers were interviewed, so the document describes the process as designed and the build hits the workaround spreadsheet in week three.
- No baseline was taken, so nobody can prove the automation helped, and the argument at renewal is unwinnable by anyone.
- Access provisioning was ignored. Four weeks of build, ten weeks waiting for a credential, and the delay gets attributed to the technology.
- Processes were audited and data was not. The process is automatable, the data lives in three systems with no shared key, and the project silently becomes an entity resolution project.
- Only a yes list was produced. Without the leave-alone list nobody can tell whether the yes list was considered or merely collected.
- Could was confused with should. Plenty of processes can be automated and are not worth the effort, and effort is a real number that belongs in the ranking.
Ranking by sponsor enthusiasm. The loudest process is usually the hardest one, because it is painful precisely for the reasons that make it difficult to automate: high variance, poor verifiability and messy data. It fails, and the failure is remembered as AI not working here rather than as a sequencing mistake.
What the resulting systems cost to run
An audit that ranks by value and ignores running cost is half a document. Here is the arithmetic we put next to each candidate, with assumptions stated so you can substitute your own.
Take a process running 400 times a day where each run is a 6,000 token round trip. That is 2.4 million tokens a day. At an assumed 3 per million, roughly 7 a day, so a few thousand a year. Those numbers are illustrative arithmetic on stated assumptions and not a quote: check your provider's current price and your own token count, because both move. The useful observation is the shape. Token cost is usually the smallest line, and the ones below it are the ones that get forgotten.
| Cost line | What drives it | How it behaves |
|---|---|---|
| Model tokens | Runs per day times tokens per run, retries included | Linear with volume, and usually the smallest line |
| Orchestration and hosting | Queues, workers, schedulers, a database | Mostly fixed, and largely the same whether you run one automation or five |
| Retrieval infrastructure | Vector or search index, re-embedding when documents change | Grows with corpus size, with a step change when you re-embed everything |
| Observability | Traces and decision logs holding customer content | Grows with traffic and with your retention period |
| Human review | The share of items a person still touches, which is never zero at launch | Falls as the system matures, and only if somebody is working on it |
| Integration maintenance | Every third party API you touch will change something | Lumpy and certain. Budget engineering hours per integration per quarter. |
The last row is the line that separates a system still running in year two from one quietly switched off. For the full treatment, see total cost of ownership for an AI system.
How to tell whether you need an audit
Five questions. If you can answer all five, you do not need us, you need to start building.
- Name your top three candidate processes and the volume of each, measured rather than estimated. If the numbers came from a meeting, they are estimates.
- For your top candidate, can a machine check whether an output is correct? If not, high volume makes the risk worse rather than the case better.
- Does a stable identifier exist in every system that process touches? If you are not sure, that uncertainty is the finding.
- Who owns the system after launch, by name, and does their work improve if it runs well? If the name is a team rather than a person, treat that as no.
- Which processes have you decided not to automate, and why? An empty answer usually means the yes list was collected rather than chosen.
If question one already stops you, that is the ordinary case and it is fixable in a few weeks. If you sailed through all five, read how to pick the first process to automate to check your reasoning, then go and build it with business process automation.
Even if you skip the audit, measure the current process before you change it: volume, median and tail duration, error rate, and cost. It takes a fortnight of light instrumentation and it is the only thing that makes a later claim of improvement checkable. The method is in the baseline you must take before any automation.
How to start
A scoping call, then access to watch two or three processes being done. Watching is the part that cannot be substituted, and it is the part companies are most reluctant to arrange, usually because it feels like surveillance. Framed as helping us understand the work, operators are generally glad someone asked.
- The processes you think are candidates, in the order you currently believe in.
- Names of the people who actually do the work, not only the people who own it.
- A list of the systems involved, and who can grant access to each.
- Any previous pilot, including one that failed. A failed pilot is the most informative document you have.
You leave the call with a written scope naming which processes we would observe and what we expect the blockers to be, before we have looked. Comparing that guess against what we find is a fair way to judge whether the audit was worth its fee. If your situation is one obvious process with one owner, we will say so and you should skip straight to the build. Related reading: what not to automate, and how to tell.
ChatGPTalker, AI Readiness Audit: a structured survey of a company's processes, data and systems that produces a ranked list of automation candidates with measured baselines, an estimate of build effort, a named list of processes to leave alone with the reasoning attached, and the access, data and ownership blockers that must be cleared before anything can be built.