Choosing an AI consultant

An operations leader considering an AI consultant needs to answer two questions: what work needs to change, and what help is missing inside the business? A consultant might investigate a problem, teach a team, connect existing tools, or build software. Those are different assignments. A credible proposal should say which one you are buying.

This guide gives you a briefing exercise and a proposal comparison you can use before choosing a provider. The recommendations are buying criteria, not a certification scheme or a promise of results.

Bring a troublesome task to the first conversation

Choose a task people already do. Collect a normal input, a difficult input, the output somebody accepts, and the places information travels. Remove information you are not authorized to share. Ask the person doing the task where they lose time and which mistakes matter.

Consider an illustrative estimating team. Enquiries arrive by email; someone checks service area, asks for missing photographs, then creates a job in a scheduling tool. The owner initially asks for an AI assistant. A closer review might show that required form fields and a basic integration solve most of the problem. AI might help summarize a long message, but it does not need to decide which customers deserve service.

A useful consultant can explain that distinction and recommend a smaller assignment. Ask them to walk through the difficult input as carefully as the normal one.

Match the engagement to the uncertainty

Advice can be a complete, valuable deliverable when your team can implement it. Implementation is appropriate when you need someone to build and test the system. Neither should be disguised as the other.

Compare proposals using the same evidence

Send each provider the same task brief. Ask for written answers to these questions:

1. What will exist at the end? Name the document, training material, workflow, or working software. A list of activities is not enough.
2. What would make you recommend against this? Look for conditions such as unavailable data, unreliable inputs, or a cheaper existing feature.
3. How will we test it? Ask for ordinary cases, exceptions, and unacceptable outcomes. Agree who judges the result.
4. What access is required? Identify systems, permissions, data categories, and who approves access.
5. Who maintains it? Separate launch support, routine maintenance, new features, and third-party subscription charges.
6. Can we leave with the work? Clarify account ownership, documentation, source code where relevant, exports, and offboarding.

Do not compress these answers into a score that hides a serious weakness. A provider with excellent design examples still needs to explain data access if the assignment involves private records.

NIST's voluntary AI Risk Management Framework organizes risk work around governance, context, measurement, and management. It is useful background for asking who is responsible and how a system will be evaluated; referencing it does not establish that a provider or product is certified. NIST AI RMF.

Read the portfolio for scope, not borrowed confidence

Look for work with comparable users, integrations, or operating constraints. Ask what the provider actually owned and what the published evidence supports.

The ValleyMen case study describes a public site, member and admin portals, messaging, and operating workflows. That shows the scope of a connected software engagement. It does not establish a percentage improvement in staff productivity. Valori is a founder-built product, a different kind of evidence from a client commission.

If your problem concerns existing tools and repeated handoffs, explore AI Automation at Jiberish Labs →

For a decision review your own team will act on, advisory is also available. Published package fees apply to their stated scope; a broader implementation requires its own estimate.

A brief you can send

Write one paragraph describing the task, its owner, frequency, current process, and the consequence of an error. Attach approved examples. Then list the decisions you want help making, the systems involved, and any deadline that has a real business reason.

Finish with acceptance conditions: “We can trace each result to its input, handle an incomplete submission, and resume manually if the integration fails.” Replace these with conditions appropriate to your task. They make the proposal discussable before a budget is committed.

If you cannot yet describe the workflow, start with mapping an automation candidate. If the missing capability is team confidence, use the workshop planning guide.