What should an AI consulting proposal actually deliver?

“AI consulting” can describe an assessment, a plan, a software build or ongoing support. Before comparing prices, identify which of those outcomes you need and what the supplier will hand over.

A proposal should connect a business problem with specific work, evidence and responsibility. This guide explains the deliverables to ask about. It is separate from our AI consultancy service page and the guide to comparing delivery models.

Discovery and assessment

The purpose of discovery is to understand the work before recommending a build. Useful inputs include interviews with the people doing the task, examples of current documents, a system inventory and a baseline for workload and errors.

Ask for outputs you can use: a process map, information requirements, a list of opportunities, known constraints and a reasoned priority. The assessment should identify work that needs a simpler process or normal automation as well as potential AI uses.

Check whether the proposal includes validation with staff. A process map based only on a manager's description can miss exceptions and informal handovers.

Strategy and prioritisation

A strategy should explain the sequence of decisions, rather than offer a long list of tools. It should relate proposed work to business needs, dependencies, ownership and the consequences of getting it wrong.

For each priority, ask what must be true for it to proceed. That might include a reliable source of information, permission to use it, access to a system or a person available to review outputs. Record the assumptions behind any estimated benefit.

Agree a sensible stop condition. If discovery shows that the data is unsuitable or the review effort outweighs the benefit, the next deliverable may be a documented decision not to build.

Implementation and integration

An implementation proposal should define the workflow being built, its users, connected systems, permitted actions and review points. It should also identify hosting, licences, data storage and the responsibilities of third-party providers.

Ask for acceptance cases before development. Include normal inputs, missing information, conflicting records, unavailable services and repeated requests. Verify the outcome in the destination system, not just the success message shown on screen.

A handover should include the source or configuration you are entitled to receive, operating instructions, access arrangements, known limitations, monitoring and recovery steps. Clarify whether the supplier is delivering a demonstration, a pilot or a production service.

Training and adoption

Specify who the training is for and what they should be able to do afterwards. A director evaluating a supplier needs different material from a member of staff using an approved workflow every day.

Useful training includes relevant exercises, permitted information, examples of unsuitable output and the route for getting help. Staff should practise the fallback as well as the successful path. Ask what materials remain available and who updates them when the system changes.

Ongoing support

Separate incident support, maintenance and new development. Agree who checks failed runs, who handles an expired connection and who approves changes. Ask how usage costs are monitored and which events trigger a review.

Define the exit route before the arrangement becomes critical. Confirm account ownership, export options, notice arrangements and the information another maintainer would need. Ongoing support should have a clear purpose and scope.

A deliverables and acceptance worksheet

Compare the full cost

Ask the supplier to separate discovery, building, integration, review, training and support. Identify recurring software and usage costs, as well as internal staff time. Confirm what happens if a required system is harder to connect than expected.

Do not treat estimated hours released as guaranteed cash savings. Ask how the baseline was measured and include preparation, review and correction time in the proposed calculation. Any revenue projection should state its assumptions separately from demonstrated results.

Blue Canvas's own published offers are on the pricing page. Written project quotes should establish scope, exclusions, delivery arrangements and applicable tax treatment.

Questions that expose an unclear proposal

• What exactly will exist at the end of the engagement?
• Which business decision will each deliverable help us make?
• What access and staff time do you need from us?
• What evidence will show that the workflow works?
• What happens when a test fails or the scope changes?
• Who owns the result and runs it after handover?

If these cannot be answered yet, a small defined discovery phase may be more appropriate than an open-ended build. Bring one workflow and its current difficulty to a free conversation.