Before comparing firms, write down what your business should be able to decide, do or achieve at the end of the engagement. A full strategy, a technical build and an improvement to existing operations require different combinations of skills.
Use the selection conversation to understand how the proposed team would approach your situation. The questions below help move beyond a presentation of credentials.
Ask the team to work through your problem.
Describe the outcome, what you know and where explanations conflict. Ask what they would need to examine before recommending a course of action.
A useful answer connects the business question to customer evidence, commercial records and the work behind the result. It should identify important unknowns and explain how to resolve them. An immediate recommendation for a particular tool may be reasonable for a tightly defined brief; a complex business problem needs more investigation.
Ask: “What could you discover that would change your recommendation?”
Define what the engagement should produce.
Apparently similar proposals can buy different work. An “AI strategy” might mean a workshop and a list of ideas, or an examination of customers, competition, economics and the capabilities the business needs. A “pilot” might be a demonstration or a working capability tested in daily operations.
A strategy the business can act on.
The starting point may be a new planning cycle, a strategy already under way or a proposed plan that needs testing. Scope the work around that context.
Start with customers, competitive position and the economics of the business. How could AI change what customers expect, which services they value and how they choose? Where could it strengthen the proposition, create new revenue or alter the cost of serving customers?
The strategy should explain which choices change and why. Existing plans may contain assumptions that need another look; other priorities may remain sound. Compare opportunities through strategic fit, value potential, time to value, the work affected and practical delivery requirements.
For each priority, expect the intended outcome, the current position and the assumptions connecting the change to value. Distinguish time saved from cost removed, faster output from additional revenue and better model performance from a better customer experience. Record what is known, estimated and still to be tested.
Technology is part of the plan. So are the data, skills, processes and decisions needed to use it well. Examine handoffs, exceptions, queues, reviews and information flows across teams. Distinguish shared foundations from work specific to one opportunity: common data investment needs a clear connection to the uses it will support.
Leadership should leave with:
- strategic choices and the evidence behind them;
- priorities linked to customer, commercial and operating outcomes;
- a view of investment, dependencies and running costs;
- named owners and clear decision rights;
- success measures and recommended next actions.
Agree when leadership will review progress, which signals would change a decision and how priorities or funding will be adjusted. Make clear what to pursue, defer or stop. A customer investigation, a further test or a defined build may be the right next action; a pilot is not compulsory.
An opportunity assessment.
Expect customer, commercial and operating evidence relevant to the question, with a recommendation about what to pursue, test, defer or stop. The initial investment case should make costs, benefits, dependencies and uncertainty visible.
Agree what is included in the investigation and what needs a separate build or implementation decision. The readiness and opportunity assessment guide helps distinguish an organisation-wide constraint from a specific opportunity.
A working capability and evidence of its value.
Expect a working capability, testing with representative work and people, and an updated view of its value and operating requirements. Agree technical scope, quality standards, necessary controls and what counts as a completed test. The guide to proving and measuring AI value explains how to choose the smallest useful test.
An improvement to an existing operation.
The work may need to establish why the expected result has not arrived before changing the system or process. Agree the improvement sought, what will change, who will own it and how performance will be measured. Where the original case no longer holds, revising or stopping the work may be the appropriate recommendation.
Establish who will do the work.
Meet the people expected to deliver. Clarify who will lead the strategy, investigate the business, build the capability and help the team use it. One person may cover several of those roles; several firms may share them. The responsibilities between them need to be clear.
Ask about experience relevant to your situation. Operating experience can be particularly useful when the result depends on changing service, incentives, costs or responsibilities. Specialist technical expertise matters when feasibility, architecture or integration carries the main uncertainty.
There is no universally best team structure. Match the experience and capacity to the work.
Examine one relevant example closely.
Choose an example related to your problem rather than the largest headline result. Ask:
- What was the starting situation?
- What did these people personally own and deliver?
- What changed in the product, process or decisions?
- How was the result measured?
- What contribution came from the client team or other partners?
- What became part of everyday operation?
Company work, an individual’s prior role and a founder-built venture are different forms of evidence. All can be relevant when the role and result are explained accurately.
Find out how they test a build.
For a proposed capability, ask how representative users, difficult cases and existing systems enter the work. A demonstration may establish technical feasibility. A wider investment decision may also require evidence about review effort, quality, running costs and the effect on customers or colleagues.
Ask the team to describe what would justify expansion, revision or stopping. A useful test can conclude that an opportunity should not receive further investment.
If you already have strong evidence and a defined requirement, the engagement may start with the build. There is no reason to purchase another assessment solely because it is the supplier’s standard first stage.
Agree what your organisation will own.
Look beyond the launch date. Establish who will run the capability, resolve problems and decide what changes next. Agree what code, documentation, data rights and operating knowledge transfer to you, and what remains dependent on a supplier.
The client team also needs time and authority to contribute. Ask the consultancy to name the access, decisions and practical effort it requires from your people.
Choose a commercial structure that fits the uncertainty.
| Structure | When it can fit | What to make explicit |
|---|---|---|
| Fixed fee | Scope, access and outputs can be defined | Assumptions, exclusions and how changes are agreed |
| Fees by stage | Later work depends on what the team learns | Evidence and decisions at each stage; no automatic continuation |
| Time and materials | Priorities or specialist effort need to vary | Spending limits, useful outputs and regular reviews |
| Retainer | Leadership needs continuing advice or support | Availability, response expectations and separately scoped delivery |
| Value-linked element | The result can be measured and attributed credibly | Baseline, timing and dependencies outside the supplier’s control |
The charging method does not define whether the work is valuable. Each arrangement still needs clear responsibilities and a way to judge progress.
Compare the complete cost.
Include the time your leadership team, specialists and future users will contribute. Examine data preparation, software, integration, controls, training, parallel running and ongoing support.
Ask which costs are included in the proposal, estimated separately or still unknown. Clarify how much senior involvement is included and the likely work required after this engagement. These details make the initial fee easier to assess.
Define acceptance before starting.
For each output, write what “complete” means. Depending on the engagement, that might include:
- leadership can review the strategic choices and the evidence supporting them;
- an investment recommendation records the baseline, assumptions and next actions;
- a capability operates on an agreed set of representative cases;
- review effort, quality and running costs have been measured;
- an operating change has an owner, measures and support arrangements;
- code, documentation, data rights and other agreed assets have been handed over.
The consultancy should be accountable for the agreed work. A specific financial outcome may remain uncertain, depend on client action or take longer to appear. Keep that distinction visible in the agreement and the review of results.
Compare proposals on the same basis.
| Compare | Look for |
|---|---|
| Scope | The questions, work and outputs included |
| Delivery | Named people and their responsibilities |
| Evidence | How assumptions and results will be tested |
| Client input | Access, time, decisions and dependencies |
| Total cost | Consulting, technology, integration and operating costs |
| Acceptance | What counts as complete and how you will judge it |
| Continuity | Ownership, support and the choices after this engagement |
Use gaps in the proposals to shape the next discussion. A lower fee is easier to interpret once you can see whether it buys the same work, evidence and responsibility.