What an AI Consultant Actually Delivers in 30 Days

The fear I hear most from buyers is "we will pay for a month of meetings and get a deck". It is a reasonable fear. MIT's Project NANDA report on enterprise generative AI found that 95% of organisations were seeing no business return, and only 5% of custom enterprise AI tools reached production. Plans that never meet real systems are a large part of that gap.

So here is what I think a month should produce, week by week, with the shape of each artefact. It is the structure I follow on discovery engagements, and you can use it to judge any consultant's proposal.

What should you have after 30 days?

You should have one working thing, evidence about whether it works, and a costed decision about what to do next. Everything else in the month exists to make those three trustworthy.

Week 1: an opportunity map, not a wish list

The first deliverable is a ranked list of places AI could help, scored on value, feasibility and risk, with one recommended starting point. It comes from interviews with the people who actually do the work and from watching the process, not from a generic list of AI use cases.

A row in the map looks like this:

The columns matter more than the rows. "Time spent today" is filled in with the client's own numbers, so the business case later rests on their data, not mine. "Risk if wrong" keeps autonomous actions out of the first pick.

Week 2: a data review and success criteria

The second deliverable answers two questions: can the chosen use case actually be built with the data and systems you have, and how will everyone know if it works? This is the week where most pilot plans quietly fall apart, for the reasons in why AI pilots stall, and it is better that they do so in a document than in production.

The data and systems review covers:

• where the data lives, who owns it and how the prototype will access it,
• quality problems found in a real sample, such as duplicates, gaps or scanned PDFs,
• personal or sensitive data involved, and how it will be kept out of prompts or protected,
• the integrations needed, such as the help desk, CRM or shared inbox.

Alongside it come written success criteria. Anthropic's guidance on evaluating model output asks for criteria that are specific, measurable, achievable and relevant, and lists dimensions such as task fidelity, consistency, latency and price. In practice I write three to five of these with the client, for example "at least 8 of 10 drafted replies need only light edits, judged by the support lead on a fixed set of 50 past tickets". The number is the client's call; the point is that it is agreed before anything is built.

Week 3: a working prototype in your real tools

The third deliverable is software, not a mock-up: a thin, working version of the chosen use case, running against your real data in a safe environment. For a support use case, that might be drafts appearing as internal notes in your help desk. For invoices, a sheet filling itself from a test inbox.

What makes it a useful prototype rather than a demo:

• it uses your data and your tools, so integration problems surface now,
• a person reviews every output before it affects anything,
• every input and output is logged so the week 4 test is possible,
• it lives in accounts you own, with code in your repository.

This is also where the consultant's model shows. If nobody on the engagement can build, week 3 becomes another document. I compare the advisory and builder models in AI consultant vs agency vs freelancer.

Week 4: a test report, a roadmap and a cost model

The final week turns the prototype into a decision. Three documents do the work.

The test report runs the prototype against the test set from week 2 and reports results against each success criterion, with failure examples. My guide to why AI agent projects fail and the evals that prevent it covers how to build that test set properly.

The roadmap sets out what it would take to go from prototype to production: hardening, monitoring, permissions, the next two use cases from the opportunity map, and the risks. I organise the risk section loosely around the four functions in NIST's AI Risk Management Framework, govern, map, measure and manage, because it gives non-technical stakeholders a familiar structure.

The cost model has two halves:

• Build cost: the estimated effort for the production version, phased so you can stop after any phase.
• Running cost: model usage per task multiplied by monthly volume, plus hosting and software subscriptions, with the assumptions written down so your team can change them.

Set against the time saved from the opportunity map, the cost model gives a payback estimate. The method I use is in AI automation ROI.

The month ends with a recommendation: build, change course, or stop. A stop is a valid outcome. Spending a month to avoid a failed six-month project is money well spent.

How do you spot a slides-only engagement in a proposal?

Check whether each week has a named artefact that you will own and could hand to someone else. Warning signs include:

• deliverables described as "workshops", "alignment" or "insights" without a document or system attached,
• no prototype, or a prototype on the consultant's own data,
• no written success criteria before building,
• running costs missing from the final estimate,
• work stored in the consultant's accounts.

For what a month like this typically costs, see how much an AI consultant costs; if you are considering someone offshore, hiring an AI consultant in India covers the practicalities.

Work with me

I run discovery engagements that end with working software and a costed decision, then build the production version if it makes sense. See AI integration and workflow automation, browse my work, and book a scoping call.