What a $2,500 AI readiness assessment actually buys

Pay to find the assumption that would break the build

A paid assessment should find the expensive mistake while it is still a sentence in a brief. You should leave knowing what is worth building, what the records can support, and what needs fixing first.

Perhaps your team is retyping the same information into different systems. Perhaps a handoff keeps disappearing between departments. You can see the waste. What you cannot yet see is whether the proposed automation has enough reliable information to do the job.

That is the gap the assessment needs to close. The software can be well built and still automate a process that only exists in the meeting notes.

Our AI Implementation Audit costs $2,500 and takes two weeks. The fee buys an investigation and a document you keep. It pays for us to follow the work through its awkward parts: the missing value, the exception handled from memory, the spreadsheet someone opens after the official process is supposedly finished.

A recommendation to build earns its place by surviving those checks. So does a recommendation to wait. If the document can only say yes, you have paid for the conclusion before anyone has looked at the evidence.

The useful question at the end is whether you can make a better decision with the document in front of you. A list of available AI tools does not get you there.

The deliverables have to change a decision

You receive a current-state map, a data readiness review, ranked opportunities, a return-on-investment model and a priced roadmap. Each has a job beyond filling a section of the document.

Deliverable	The decision it should help you make
Current-state map	Where does the work actually get stuck, and who handles the exception?
Data readiness review	Can the records support the decisions we want the automation to make?
Three to five ranked opportunities	Which piece of work is worth doing first?
ROI model with visible assumptions	Does the expected benefit justify the build and the running cost?
Priced 30, 60 and 90 day roadmap	What can we commission now, and what depends on something else?

Return on investment, or ROI, compares the benefit of the work with its cost. It becomes useful when you can challenge the assumptions. Hours saved, adoption, error rates and maintenance all belong beside the result.

The map needs the same discipline. We ask what triggers a process, where a record gets copied, how long a handoff waits, and how anyone discovers a failure. Then we check the answers against the people and systems doing the work.

An exception handled by the person everyone asks for help is part of the process. Leaving it outside the diagram does not make it disappear from the build. It just makes it arrive later, as a change request.

The status existed. The completion signal did not.

A field can exist in the software without carrying the meaning your automation needs. A discovery sweep gave us a concrete example: the proposed workflow depended on completion, but the history we inspected showed no records reaching the completed status.

The status name looked perfectly useful. A designer could put it in a flowchart and write a condition against it. Neither task would reveal the missing event.

The important next question was who would record completion, and where. If the source system does not reliably record that transition, the new workflow needs an explicit owner for it. Otherwise it can sit waiting for a signal that the existing process has no reason to send.

That is why field completeness alone is not enough. A status field full of values can pass a superficial data check while being useless for the decision you intend to make. You need to examine the transitions and the work that causes them.

The same review found that a configuration type was not enough to determine the intended behaviour. Different instances of the type had different meanings. The mapping needed the configured instance, not just the shared label.

Those findings change the specification before they change any code. They turn a plausible instruction into questions you can answer: where does the signal originate, who owns it, and which identifier carries the distinction the workflow depends on?

The missing numbers were not missing work

A gap in a sequence does not, by itself, prove that a record has gone missing. The review exposed a reconciliation trap: identifiers could be allocated without leaving a corresponding record in the set being queried.

A monitor built to report every absent number would faithfully report the wrong thing. The design needs to reconcile records or changes the platform actually promises to expose, after establishing how the sequence is allocated.

A shared document counter created a related problem. Subtracting the visible records left a tempting remainder, but other document types could consume the same counter. That remainder could not tell us how much work arrived through a different channel. The denominator was still unknown.

This is where an assessment earns its fee. The arithmetic can be correct while the business conclusion is unsupported. Repeating the calculation more frequently only gives you a faster version of the same mistake.

The useful output is the missing question and the person or system that can answer it. Which document types share the counter? What reserves an identifier? Which endpoint represents the records the workflow needs?

A build quote based on the wrong total can be precise to the penny. It is still based on the wrong total. Finding that out during discovery leaves room to change the scope before the price hardens around it.

Check the mechanism that is actually carrying the work

An integration can look broken while its replacement is quietly doing the job. The review found a disabled webhook, an automatic notification sent when an event occurs. Following the receiving workflow showed that the work had moved to scheduled polling: checking periodically for new records.

The disabled hook was real. So was the working replacement. Re-enabling the old mechanism would have been a poor first response to either finding.

The lesson for the assessment was to trace the whole path. Check the trigger, the receiving workflow, its recent runs and its destination. Record which mechanism now owns the handoff. A monitor attached to the abandoned path tells you little about the one carrying the business.

We also checked the free-text material a proposed AI feature would need for evaluation. A history full of records did not automatically supply enough useful examples. Count the usable text, then check whether it covers the situations the feature must handle. Raw record count is a poor substitute for that work.

The decision that follows may be to retrieve more history, label examples, narrow the first release or keep a human review step. Those are pieces of the build plan, with time and cost attached. Calling the data ready before doing that work simply moves discovery into the implementation budget.

Rank the work, then show what changes the price

The opportunities are ranked by impact and effort, with the reasons written down. The task that irritates you most deserves investigation, but irritation alone cannot set the order of the build.

Measure frequency alongside duration. Include the exceptions, the handoffs and the work of keeping the automation running. A task that looks easy in a demonstration may depend on data cleanup that dominates the actual effort.

Our CRM connector example makes the maintenance cost concrete: the initial connection brings authentication, permissions and response mapping with it. Those obligations belong in the price before the first client connects.

The ROI model should let you change those assumptions and see what happens to the recommendation. Include platform fees, model usage, monitoring and maintenance. Include adoption too: a tool the team does not use saves no time, however well it performs in a test.

The roadmap then puts a price against each phase and names the dependencies. A field that needs fixing should appear before the automation that reads it. A review step should have an owner. A release should have something usable at the end of it.

Our assessment fee is credited in full against the build. That means the assessment adds no separate charge if you proceed. It does not remove the need to inspect the quote. The useful protection is a scope you own, assumptions you can challenge and enough detail for another builder to price the same work.

The document has to work without us in the room

You should be able to hand the assessment to another developer and have a useful conversation about the build. The findings, dependencies and acceptance criteria need to survive the handoff.

A document that only its author can interpret leaves you buying another conversation before you can act on the first. We write the current-state map, data findings and roadmap so that an internal team or another studio can work from them.

A recommendation to wait needs the same specificity. Perhaps the process is about to change. Perhaps a required field has no reliable source. Perhaps the people who would own the system have no room to absorb it yet. Write down the blocking condition and what would make it worth revisiting. That gives you a next action rather than a verdict on whether your business is ready for AI.

The assessment does not include a production pilot. That needs its own representative inputs, success criteria and operational checks. If the scope is already clear, you may not need an assessment at all; bring the specification and ask for a build quote.

If the goal is clear but the path is not, the assessment should leave you with fewer assumptions to pay for later. The discoveries can be unglamorous. A status nobody sets, a counter that counts something else, a trigger that has been replaced. Those are exactly the details that decide whether the impressive part will work.