Before signing an AI consulting proposal, ask the delivery team to explain what happens when its system encounters a case it cannot resolve. Listen for a named person, a working queue and a way to recover. You can learn a surprising amount about a project from that answer.
A proposal needs enough detail to evaluate the business outcome, the evidence behind it and the cost of keeping it running. Start with the process boundary and baseline. Then check testing, access to company systems, ongoing responsibility and handover. A product demonstration can help with the discussion, provided it uses cases representative of your work.
The scorecard below is the framework I would use to review a proposal with a business owner and their IT and finance colleagues. It also gives a consultancy a fair way to explain what it needs from the client.
Give bidders the same small piece of work
Imagine a manufacturer receiving requests for delivery updates by email. Staff look up the order, check the latest warehouse information and reply. Some requests concern split shipments. Others include an order number belonging to a different customer. Occasionally, the customer asks for a delivery promise nobody is authorised to make.
An AI assistant could help retrieve the relevant information and draft a response. Whether it should send the response automatically is a separate decision.
For this illustrative project, I would give bidders an approved sample of the workflow, the existing service measures and the same constraints. Ask each to describe the proposed change. Keep a separate set of cases for evaluation. Include the difficult cases, with personal and commercial data handled under the organisation's approved arrangements.
That produces a comparison procurement can use. One supplier may propose a reviewed draft in the existing inbox. Another may propose automatic replies within narrow permissions. Their delivery costs and risks will differ. The proposals should explain those differences before anyone treats the prices as comparable.
If management has only specified "we need AI", start with a process review. Our article on moving beyond basic ChatGPT use explains how to find work suitable for that first investigation.
Check what the named consulting firm would actually deliver
Accenture, BCG, Capgemini and IBM all have substantial AI propositions. Their public materials can help identify questions for a shortlist. The team and scope offered to you still need checking.
| Firm or delivery model | Relevant public evidence | Question for your proposal |
|---|---|---|
| Accenture | Its Anthropic partnership announcement includes plans for embedded model evaluation and safeguards testing | Which evaluation specialists and methods are included in our engagement? |
| BCG | Its 2025 business review describes AI work and BCG X's role in building and scaling solutions | Who stays accountable through implementation and adoption after the strategy is agreed? |
| Capgemini | Its 2026 half-year release connects AI with business operations and the integration of WNS | Where does transformation work end and ongoing process operation begin? |
| IBM Consulting | Consulting Advantage describes AI assistants, agents and applications used in consulting delivery | Which assets can our team continue using, and on what licence and support terms? |
| Amalgama | Kirill Kiryushin's operating background connects enterprise technology, consulting and business ownership | Can we define a bounded operational problem for direct senior involvement and a testable implementation? |
Treat a partnership as evidence of a relationship. Ask separately about your proposed team's experience, access and contractual responsibilities. A firm's capability somewhere in its organisation is not a staffing commitment to your project. Our analysis of AI's effect on the consulting contract examines the delivery economics behind that discussion.
For a broader shortlist, our AI consulting company comparison covers additional firms and specialisms. Use this proposal review after you have narrowed the field.
A scorecard for the evidence in front of you
Rate each area from 0 to 2. Give 0 when evidence is missing, 1 when there is a specific plan with unresolved dependencies, and 2 when the approach has been demonstrated on an approved sample and reflected in the proposed terms.
Record the evidence behind each score and use the total to identify where a proposal needs more work. Keep mandatory requirements separate. A data-access arrangement your security team rejects must be resolved regardless of the scores elsewhere.
| Area | Evidence to request | Who should review it |
|---|---|---|
| Business result | A process owner, baseline and operational measure that the owner wants to improve | Business sponsor |
| Scope | Start and end points, exclusions, exception routes and client dependencies | Process owner |
| Evaluation | A withheld test set, failure categories and agreed acceptance criteria | Domain experts and quality lead |
| Data and permissions | A map of data flows, provider access, retention and authorised actions | IT and security |
| Integration | The actual destination systems, retry behaviour and recovery process | System owner |
| Economics | Implementation and ongoing costs, including human review and support | Finance |
| Handover | Documentation, training, usable assets and an operational ownership plan | Future service owner |
If the supplier needs paid discovery to establish some of this evidence, make that phase explicit. Give it a bounded scope and a decision at the end. A proposal for discovery should be assessed on the questions it will resolve, rather than pretending the final implementation is already understood.
Ask for the failed cases
Test the cases that should stop or reach a reviewer as carefully as the ones that should complete.
Return to the delivery-update example. A fluent reply may still expose another customer's order or turn an uncertain warehouse estimate into a firm promise. A general accuracy score can hide both problems among hundreds of routine successes.
Agree distinct failure categories. Check whether the system retrieved the right order, used current information, respected access permissions and stayed within its authority. Include cases where the correct action is to ask a person. Measure how often that happens and how much work it creates.
For a pilot, require the supplier to show the input, the proposed action and the evidence used to reach it. Domain staff should be able to inspect the result without relying on the developer's interpretation. Keep enough test cases out of development to see how the system handles unfamiliar work.
An approval rule also needs an owner. "Human in the loop" leaves a lot undecided. The proposal should identify who reviews, what they can see and what happens if nobody responds. A backlog of approvals can consume the time the automation was expected to save.
These checks are part of the transition from an enterprise AI pilot to a service people depend on. Ask for them while the supplier is estimating the job.
Follow the cost through a normal month
Keep implementation costs separate from recurring operations. The latter can include model usage, hosting, licences, support and review time. Establish which charges vary with volume and which continue when usage is low.
Ask finance to examine the claimed benefit with the process owner. If a system frees time in several teams, specify how the organisation will use that capacity. Avoid treating every released hour as cash saved. Cost reduction requires a corresponding change in spending. Faster service, increased capacity and reduced rework can still justify a project when they are measured honestly.
Test the proposal under awkward conditions. More cases may need review than expected. An integration may take longer because the source system is poorly documented. A provider may change its terms. Ask which assumptions would make the project uneconomic and what decision would follow.
Vendor relationships deserve the same scrutiny. Request disclosure of referral payments, resale margins or platform incentives where applicable. Ask for the reasoning behind the selected model and hosting arrangement, plus the practical consequences of changing them. You are buying a solution your organisation will have to live with.
Decide who owns the second month
There is often plenty of detail about launching a system. Read the proposal again with an ordinary later month in mind. A new document format arrives. Someone changes a policy. An employee who knows the process leaves. A model update changes the output.
Who sees the problem first? Who can investigate it? Who approves and tests the correction?
The handover should specify access to the configuration, relevant code and evaluation materials, subject to agreed licences and third-party restrictions. Include monitoring instructions, a manual fallback and ownership of routine updates. Ask the future service owner to perform a recovery exercise before accepting the handover.
For some clients, an ongoing managed service will be the sensible choice. In that case, examine service responsibilities and exit terms with the same care as the initial build. For others, internal staff should be able to run and improve the process. Price and scope the training needed to make that realistic.
Send this request with the proposal
You can make the next supplier conversation quite short.
Please show us the process you will change, the baseline you will measure against, and a failed case from the proposed evaluation. Include the ongoing review effort, the people responsible after launch and the assets our team will receive. List the unresolved assumptions and the decision each one could change.
A capable supplier may need to investigate before answering every part. Its response should make the remaining work clearer. You can then commission that investigation with an explicit limit and a reason to continue.
At Amalgama, we can help you review a proposed AI project against the workflow it is meant to improve. Bring the proposal and one representative example of the work, with confidential material removed or shared through an agreed secure route. That gives us something useful to question together.