How to Choose an AI Consulting Firm

Criteria that predict results

• Implementation track record — do they ship and run systems, or only recommend?
• Seniority on the work — who actually does it, the partner who sold it or a junior?
• Industry depth — have they solved problems like yours before?
• Outcome orientation — is success defined by results or by deliverables?
• Ownership plan — what happens after launch?

Questions to ask in the first call

1. Can you show a system you built that is running in production today?
2. Who specifically will do the work, and how senior are they?
3. How do you decide what to build first, and how do you measure the payback?
4. How do you handle our existing tools and data?
5. What does ownership and support look like after go-live?

Red flags

• All strategy, no implementation.
• Senior people in the sales meeting who vanish during delivery.
• Generic answers with no reference to your industry or operations.
• Enthusiasm for technology with no business case.
• No plan for what happens after the project ends.

Why the market is so hard to read

Three very different kinds of business now sell under the same label. Large consultancies bring process rigour, brand safety, and deep benches, but the people who scope the work are rarely the people who build it, and the commercial model rewards duration. Boutique implementation firms build and operate systems with senior people on the work, but capacity is finite and they cannot cover every domain. Individual contractors and small dev shops are fast and inexpensive, but continuity, documentation, and operational support depend entirely on one or two people staying interested.

None of these is wrong. They are wrong for particular problems. A multi-country ERP migration is not a boutique's job; a single intake workflow is not worth a global consultancy's minimum engagement. Decide which category fits the size and specificity of your problem before you start comparing individual firms, or you will end up comparing incomparable things.

Evidence that actually counts

Case studies are marketing artefacts. They are written after the fact, by the firm, with the client's approval, and they almost never mention what went wrong. Treat them as evidence that a project existed, not that it worked. What counts is testable in a conversation.

• A system they still operate today — ask what breaks most often and how they find out.
• A named person who did the build and is available to talk about it.
• A specific number: hours recovered, error rate before and after, cycle time reduced.
• A description of a project that went badly and what they changed as a result.
• Documentation from a past engagement, redacted — this reveals more about rigour than any deck.

A firm that answers the fourth of those honestly is usually more trustworthy than one with a perfect record, because a perfect record generally means either a short history or a selective memory.

How to structure the evaluation

1. Write your problem down first — the process, its volume, and what it costs you monthly. This becomes your control question for every firm.
2. Shortlist three, not eight. Beyond three you compare pitches instead of substance.
3. Give each the same brief and the same access, and note who asks the sharpest questions back.
4. Ask each for a diagnosis before a quote, and be prepared to pay for it.
5. Compare their diagnoses against each other — the differences tell you who understood your operation.
6. Buy a small paid pilot from the leader before committing to anything larger.

Step three is where most of the signal lives. The firm that spends the first meeting asking about your exceptions, your systems of record, and who currently owns the messy parts is the one thinking about delivery. The firm that spends it presenting is thinking about the sale.

Contract terms worth negotiating

• Named key personnel, with a clause covering what happens if they are replaced.
• Ownership of the code, prompts, configurations, and documentation on completion.
• A defined handover: documentation, monitoring, and a training session for your team.
• Access to your own systems and data throughout, not mediated through the firm.
• An exit path — what it takes for another provider, or your own team, to take this over.

The last point is the one firms resist most and the one that protects you most. If taking over the system requires the firm that built it, you have not bought an asset; you have bought a dependency.

What to expect in the first ninety days

A well-run engagement has a recognisable shape. In the first two to three weeks you should see a mapped process and a prioritised shortlist with estimates attached. By roughly week six there should be something working in a limited scope against real data, not a prototype on sample inputs. By the end of the first quarter one workflow should be live, monitored, documented, and measured against a baseline you agreed at the start.

If week six arrives with no working software and the conversation is still about frameworks and roadmaps, that is the moment to intervene — not month six. Set that expectation explicitly during selection and you will filter out a meaningful share of the firms that would have disappointed you.

Questions that separate operators from presenters

Selection conversations reward polish, which is exactly why they mislead. These questions are hard to answer well without having actually shipped, and the quality of the answer tells you more than any case study deck.

• Describe the last engagement that did not work. What did you get wrong, and what changed in how you work because of it? A firm with no failures has either not shipped or will not tell you.
• Walk me through what happens in week one, day by day. Vague answers here predict vague delivery.
• Which of your recommendations did a client decline, and were you right? Tests both judgment and honesty.
• Who exactly will be doing the work, and what else are they on during our engagement? Named people, not a capability slide.
• What would make you tell us not to automate something? A firm that automates everything is selling, not advising.
• Show me something you built. Not a diagram of an approach — a working system.

Reading a proposal properly

Most proposals are structured to obscure the two things you need: what you will actually receive, and what happens when reality diverges from the plan. Read for these specifics and ignore the rest.

• Deliverables stated as artefacts, not activities. 'A working intake workflow live in production' is a deliverable. 'Discovery and strategic alignment' is not.
• A named first milestone with a date inside the first month.
• Assumptions listed explicitly — what they expect from you in access, data, and people's time. Unstated assumptions become change orders.
• Change control: how scope changes are priced and approved, agreed before you need it.
• Acceptance criteria: how both sides agree a deliverable is done.
• Exit terms: notice period, and what you keep if you stop early.

If a proposal is heavy on methodology and light on artefacts, that imbalance will repeat throughout the engagement. Ask for it to be rewritten in terms of what will exist and when.

Ownership, access, and lock-in

This is where engagements quietly go wrong, and it is entirely preventable at contract stage. Settle it in writing before work starts, because renegotiating after a system is live puts all the leverage on the other side.

• You own the code, workflows, prompts, and configuration outright — not a licence to use them.
• Everything lives in accounts and repositories you own, under your credentials, from day one.
• Documentation and handover are deliverables with acceptance criteria, not a favour at the end.
• No proprietary black box you cannot maintain or hand to another firm.
• Your data is not used to train anything, and is deleted on request when the engagement ends.
• Subcontractors and offshore delivery are disclosed, with the same confidentiality obligations.

A firm confident in its work will agree to all six without friction. Resistance on ownership is the single clearest signal that the commercial model depends on you being unable to leave.

Pricing structures and what each one incentivises

Structure shapes behaviour more than rates do. Match the structure to the certainty of the work rather than accepting whatever is offered.

• Fixed-price per deliverable: best when scope is genuinely clear. Incentivises speed, and can incentivise cutting corners — so make acceptance criteria tight.
• Time and materials: honest for exploratory work, but has no natural stopping point. Cap it and review weekly.
• Retainer: right for ongoing operations and iteration once systems are live. Wrong for an initial build with no defined output.
• Outcome-based: appealing and rarely clean, because attribution is contested and the firm rarely controls every variable.

A sound default is a small fixed-price diagnostic, then a fixed-price first build with a named milestone, then a retainer only if there is real ongoing work. That sequence lets you evaluate the firm on delivered work before committing to a long relationship.