What should AI consulting include?

Use this as a comparison sheet. Proposals in this field are written to sound similar and differ substantially in what actually arrives.

A map of how your operation runs

Not an org chart. A description of how work moves: where it enters, who touches it in what order, where it waits, and what happens on an exception.

This is the foundation and it is the part clients find most immediately useful even when they ignore everything else, because most companies have never had it written down. If a proposal skips straight to recommendations, ask what they are recommending against.

A ranked list of candidates, with values attached

The core deliverable. Every opportunity identified, scored on how often it happens, what it costs you now, and what could go wrong if a machine did it badly.

Values can be rough. They cannot be absent, because without them nothing can be ranked and ranking is the entire point. "This will save time" is an observation, not a finding.

An explicit list of what not to do

The mark of a real diagnosis. Candidates that were considered and rejected, with reasons: frequency too low, exception rate too high, process broken and needs fixing on paper first, human contact is the value.

A roadmap where everything is recommended is a sales document. Prioritization method.

Build-or-buy on each item, with named options

For every recommendation: build custom, buy something existing, or fix the process without technology. Where the answer is buy, actual product names and why those.

A roadmap containing only build recommendations from a firm that builds should be read with that in mind.

A sequence with a horizon

What to do first, second, third, and roughly when. Ninety days is a sensible planning window because it is long enough to accomplish something and short enough that nobody pretends to see beyond it.

Sequencing matters more than the list. Doing three things at once is how none of them get owned.

The cost of running it, not only building it

Model usage, platform fees, monitoring, and whoever maintains it. Ongoing and often usage-based, so it scales with your volume.

A build number with no run number is incomplete and you will make a worse decision without it. The lines people forget.

What has to stay human

An explicit boundary. Which decisions require a person, which outputs need review before a customer sees them, and what the system must never attempt.

Anything touching money, legal commitments, safety, or a promise you have to honor belongs here. A consultant who treats every human step as waste will recommend something you regret.

Escalation design

What happens when the system does not know, who is told, how fast, and what happens if that person does not respond.

This is where most of the real engineering goes and it is invisible in a demo. Its absence from a proposal is the most reliable signal that nobody has run one of these in production.

A baseline and a way to measure

The number the work is supposed to move, captured before anything changes.

Without it, success becomes a matter of opinion six months later, which is convenient for the supplier. Insist on it early: it takes an afternoon and it is the difference between evidence and vibes. Designing measurement.

Documentation aimed at a stranger

Enough for a competent person who never met the author to understand what runs, when, on what trigger, and what to do when it breaks.

Tie a payment milestone to it. It is the most promised and least delivered item in this business.

Ownership terms in writing

Who owns the deliverables, the code, and the configuration. Whose accounts the services run under. What you receive if you part ways, in what format, within how long, at what cost.

The configuration is the one to insist on, because in AI work the prompts and rules are the product. The anti-lock-in list.

If the engagement continues into a build, the delivery inventory is a separate and longer list: what implementation should hand over.

The test to apply to the whole thing

Could a competent third party execute this without the author in the room?

If yes, you own something. If no, you own a dependency, and the advice was inseparable from the pitch.

What is reasonable to leave out

Not everything absent is a gap.

Precise long-range figures. Anybody forecasting a specific improvement before looking at your operation is guessing.

Detailed technical architecture, at the diagnostic stage. That belongs to the build.

A plan for every department. A good roadmap is narrow on purpose, because breadth at this stage produces a document nobody acts on.

Our version of the deliverable list is on the consulting page: the roadmap, ROI estimates per recommendation, build-or-buy calls with vendor picks, a ninety-day order, and the option rather than the obligation to have us build it.