A client is buying a clearer decision or a working improvement, not an impressive collection of AI terminology. Before agreeing to a project, name the business decision the client will be able to make at the end. A discovery engagement might deliver a prioritized opportunity register. A pilot might deliver tested evidence and a go-or-no-go recommendation. A deployment should leave the client with a system that people can operate safely. The deliverable changes with the engagement; the requirement for clarity does not.

Practical guide: Use the examples and templates below as starting points. Adjust them to your client, industry, risk and contractual obligations.

Start with a result, not a slide deck

A client is buying a clearer decision or a working improvement, not an impressive collection of AI terminology. Before agreeing to a project, name the business decision the client will be able to make at the end. A discovery engagement might deliver a prioritized opportunity register. A pilot might deliver tested evidence and a go-or-no-go recommendation. A deployment should leave the client with a system that people can operate safely. The deliverable changes with the engagement; the requirement for clarity does not.

A good acceptance test is simple: could a person who did not attend the meetings read the output, understand what was done, identify limitations and know what to do next? If not, the document may be polished but is not yet useful. Link each artifact to an owner, a decision date and an observable criterion for completion.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—start with a result, not a slide deck—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Discovery: the current-state pack

Begin with a one-page problem statement in the client’s words. Record the workflow trigger, the people involved, systems used, weekly volume, exception types, handoffs, existing time and error baseline. A workflow map should show where work enters, where it waits, who approves and where it exits. Distinguish observed facts from assumptions. Add an evidence log identifying the interview, process sample or system report behind each major conclusion.

Deliver a stakeholder map, current-state workflow diagram, baseline worksheet, list of pain points and a short risks-and-dependencies register. A useful discovery pack also says what was not examined. If you interviewed two staff members but never observed the busiest shift, say so. The client should not mistake a small sample for a comprehensive operational audit.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—discovery: the current-state pack—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Opportunity assessment: a prioritized decision

A list of twenty exciting use cases is not an assessment. For each candidate, describe the actual task, frequency, manual effort, input quality, exception rate, human-review burden, data sensitivity and cost of failure. Score feasibility separately from potential benefit. A high-value but poorly documented process may not be the best first project. Explain why the first recommendation outranks the alternatives.

Use a simple register with columns: opportunity; business owner; estimated annual volume; current effort; expected improvement; data readiness; risk; implementation complexity; evidence confidence; recommended next action. Include a do-not-automate list. The consultant earns trust by rejecting poor candidates as well as recommending promising ones.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—opportunity assessment: a prioritized decision—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Strategy: a roadmap with decisions

An AI strategy deliverable should identify business priorities, the selected use cases, dependencies, governance expectations, investment assumptions and decision gates. Avoid a technology shopping list presented as strategy. A useful roadmap shows what can start in thirty days, what requires process cleanup, and what should wait for better data or controls. Each phase should have an accountable owner and a measurable outcome.

Separate three kinds of commitment: decisions already approved, recommendations awaiting approval and exploratory hypotheses. State what changes if a key assumption fails. If the business cannot supply clean source documents, for example, a knowledge assistant pilot may need a document-cleanup phase before any AI configuration.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—strategy: a roadmap with decisions—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Pilot: a tested outcome, not just a demo

A prototype that works for three handpicked examples is not proof of operational readiness. The pilot package should contain a scope statement, representative test cases, expected answers or outcomes, test results, error categories, reviewer feedback, cost observations and a clear recommendation. Include cases where the system refuses, escalates or asks for human help. Record model and workflow versions so results can be reproduced.

The final report should distinguish technical performance from business value. An assistant might answer accurately yet take so long to review that it saves no time. It might reduce handling time but create unacceptable privacy risk. Document both benefits and harms. A defensible conclusion may be proceed, revise and retest, or stop.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—pilot: a tested outcome, not just a demo—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Implementation: what must be documented

For a production deployment, deliver an architecture overview understandable to the business owner, a data-flow map, access and permission matrix, approved configuration inventory, integration list, operating procedures, monitoring plan and incident response steps. Include who can change prompts, connectors and model settings. Record the environment, subscription owner and relevant renewal dates.

A business should not need to call the consultant to learn which account pays for an automation or how to pause it. Document manual fallback, rollback, escalation and the consequences of a vendor outage. If credentials were shared informally during setup, replace them with appropriate role-based access before declaring handover complete.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—implementation: what must be documented—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Training and adoption: prove someone can operate it

A training session is not complete simply because a presentation was delivered. Provide role-specific instructions, realistic exercises, examples of acceptable and unacceptable use, escalation paths and a brief knowledge check. Identify a business owner who can answer everyday questions. People need to understand when to override the automation, when to report an error and when not to enter sensitive information.

Measure adoption with appropriate indicators, such as trained users who can complete a workflow unaided, exception reports submitted correctly and the percentage of outputs reviewed as required. Do not present usage alone as success. A tool that is used frequently but produces rework may be making the business worse.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—training and adoption: prove someone can operate it—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Sample deliverables register: copy this structure

Use one row per artifact. Record its purpose, owner, format, due date, acceptance criterion, source of evidence and revision status. Example: Current-state map; purpose—confirm process boundaries; owner—operations manager; format—PDF plus editable diagram; acceptance—manager confirms all decision points and exception routes; due—end of discovery. Example: Pilot evaluation; purpose—support go/no-go decision; owner—sponsor; acceptance—results cover agreed test cases and costs.

A useful handover register adds storage location, edit permissions, version number and next review date. Never promise deliverables that the client cannot reasonably maintain. A simple spreadsheet with clear ownership is often more valuable than an elaborate dashboard no one understands.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—sample deliverables register: copy this structure—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Worked example: a fictional service company

Fictional example: Cedar Lane Property Services has eight office employees who manually sort incoming maintenance requests. An AI consultant interviews staff, observes one week of intake and identifies three common categories plus a large exception group. The agreed engagement is a four-week feasibility pilot, not an autonomous dispatch system. The consultant delivers a current-state map, baseline worksheet, labeled test set, pilot configuration, error report and recommendation.

Suppose the pilot categorizes routine requests reliably but misroutes urgent safety issues in testing. The consultant recommends keeping urgency detection under human review and limiting any automation to drafting categories for staff confirmation. That is a useful project result even though the initial automation ambition is reduced. No real company, customer data or actual measured results are implied by this example.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—worked example: a fictional service company—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Acceptance checklist and change control

Before sign-off, ask: does every deliverable have a named recipient? Are editable source files included where promised? Can the client reproduce key calculations? Are limitations, test coverage and outstanding risks visible? Are data access and retention decisions recorded? Does the owner know how to stop the system? Is the next review date agreed? Are out-of-scope requests documented separately?

If the client asks for a new department, additional integration or expanded autonomy, treat it as a scope change. Record the requested change, effect on cost, timing, testing and risk, then seek written approval. A project can be collaborative without allowing unlimited additions to quietly replace the original agreement.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—acceptance checklist and change control—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Sources and next steps

The NIST AI Risk Management Framework offers a useful structure for governance, mapping, measurement and management. Its Generative AI Profile highlights risks that should be considered when evaluating generative systems. The U.S. Small Business Administration also provides practical guidance for businesses exploring AI, including privacy and responsible adoption. These are frameworks to adapt, not a substitute for the client’s legal, security or industry requirements.

For the next stage, use the AI consulting proposal template to agree on outputs before work starts, the discovery-call guide to gather evidence, and the implementation roadmap to sequence delivery.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—sources and next steps—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

For additional guidance, see the AI Consulting Resource Library, AI consulting services and small-business AI governance guides.