How to choose an AI consultant: start with one real problem

Choosing an AI consultant means deciding how much to commit before you have seen the work. You can learn a lot from a first conversation if you bring a concrete problem and ask the consultant to work through it with you.

Take a recent request that stalled, a report someone rebuilds every week or an exception that always reaches the same person. Use that case to discuss what a first engagement would need to establish.

Start with a problem you can inspect

Explain how the work happens today. Show an anonymized example if you can. Listen to the questions: where does the information come from, who checks it and what happens when it is wrong?

A useful conversation should make the problem more precise. The consultant may discover that an existing software rule could solve it, or that an AI agent needs access the company cannot yet provide. Both findings help you decide what to do next.

You do not need a finished solution in the sales meeting. You need to understand what remains unknown and how the proposed work will answer it.

Ask to see how they would approach the work

Relevant client work and references are useful when they can be shared. Ask what the consultant personally did and what the result demonstrates. Experience in operations, software delivery or data integration may be relevant even when the project used different technology.

An example can also make an unfamiliar service easier to judge. Ask the consultant to walk through a workflow map or demonstrate a bounded task, including a case where it needs human help. Check which parts are working, which are illustrative and which still need to be built for you.

Our example War Map uses a fictional company to show what a workflow investigation can reveal. It gives you something concrete to discuss before deciding whether that kind of work would help your company.

Agree a small first commitment

If the problem spans several teams and nobody agrees where the delay begins, start by tracing the work. If the workflow is already clear, test the uncertainty that could prevent implementation: source access, answer quality, an integration or an exception rule.

Agree what you are paying for, the access your team must provide and what you will receive. Put a review point before a larger build. The possible decisions should include continuing, changing the scope or stopping.

A paid first phase can produce the evidence needed for that decision. Its fee and scope should be clear before it starts; it should not quietly commit you to the rest of the project.

Know who will do the work

Meet the person leading the engagement. Ask which work they handle directly, where specialists or partners are involved, and who coordinates them. Confirm availability for your dates before signing.

Include your own team in that discussion. Someone needs to provide access and someone who knows the operation needs to validate the result. Agree how much of their time is needed and who can make a decision when the work exposes a disagreement.

Define what an acceptable result looks like

For a first test, this might mean answering a set of questions from agreed documents while respecting access rights, or preparing a complete order case for a planner to approve. Choose examples from the actual workflow, including exceptions.

Write down what must pass, what still requires human authorization and what happens if the test fails. A finding that changes the original plan should be visible, with the supporting evidence, before the next commitment.

For implementation, include the work after the first successful demonstration. Clarify supervised use, support, operating costs and the access and documentation your team receives at handover. Agree which existing products and licenses the solution depends on.

Bring that case to the first conversation

At Solve IT, the Strategy Session starts with one real workflow. We examine the situation with you and recommend a useful next step. A broader investigation and a focused feasibility test answer different questions; the starting scope depends on what your case needs.

You can read how we work before the conversation. Bring a recent example and the question you need answered before committing further.