Internative Logo

AI Consulting: Seven Questions to Ask Before You Hire One

AI Consulting: Seven Questions to Ask Before You Hire One

AI Consulting: Seven Questions to Ask Before You Hire One

AI consulting is the work of examining how a company actually operates, identifying where AI would produce a measurable return, proving it with one pilot, and then integrating the result into the systems the business already runs on.

The definition is the easy part. The harder question is what to look for when you buy it.

This guide covers the seven questions worth asking a consultant, typical cost and timeline ranges, and where these projects usually stall.

What AI consulting actually does

Most service descriptions in this market read the same: strategy, roadmap, training, ethical compliance. Those are real headings, but none of them produces an outcome on its own.

In practice the work does three things.

It picks the right problem. Any organisation has dozens of candidate processes. Most have data that is not ready, and some have returns nobody can measure. Half the job is deciding which ones to skip.

It produces evidence. A small but real pilot on the chosen process, with the output measured. The decision to invest at scale rests on that evidence.

It gets to production. If the pilot works, it is integrated into the existing CRM, ERP and data infrastructure. Without this stage a pilot stays a demo.

Why most pilots never reach production

You will see figures quoted about AI project failure rates. The sourcing behind those numbers is usually vague, so we will not repeat them here. What we can describe is the three patterns that recur.

Starting from the wrong end. If a project begins with "we should be using AI", the problem gets searched for afterwards. The right order is reversed: first the decision you want to improve, then the tool.

Integration left until last. The model works, but its output sits on a screen nobody opens. If it does not land where people already work, it will not be used.

No definition of success. When the pilot ends and nobody can answer "did it work", the project stops there. Metrics are agreed before the build, not reverse-engineered after it.

Seven questions to ask a consultant

1. Which processes would you tell me to skip?

This one reveals the most. A consultant who says yes to every candidate has not looked at your operation yet. A good assessment lists what not to do.

2. How many weeks until the pilot produces output?

A focused pilot typically produces measurable results in 4-8 weeks. Much longer suggests the scope is not clear; much shorter suggests no real integration is planned.

3. What metric are we measuring?

The answer has to be settled before work starts: handling time, error rate, cost per case, manual touchpoints. "Improved efficiency" is not a metric.

4. How will it connect to our existing systems?

SAP, Dynamics, Logo, Netsis, your CRM, your warehouse system. If the integration plan is not discussed at proposal stage, it arrives later as an unbudgeted cost.

5. Where does our data go?

What the model sees, where it is processed and whether it is retained should all be in writing. GDPR and KVKK compliance belong in the architecture, not in an appendix.

6. What do I own when the project ends?

Will the codebase, documentation and architecture be yours, or will you depend on the consultant's platform? Both are legitimate models, but you should know which one you are buying.

7. Describe a case where AI was the wrong answer.

A consultant who cannot give a concrete example will propose a model for every problem. Sometimes the right answer is a rules engine, a better integration, or fixing the data first.

Cost and timeline ranges

Consulting is usually priced in three shapes.

Assessment. Reviewing the current state, prioritising candidate use cases, producing a roadmap. Typically 2-4 weeks.

Pilot build. A working solution on one use case. Typically 4-8 weeks, priced on an expert-day basis.

Production integration and run. Phased delivery followed by ongoing support. Scope-dependent.

Be sceptical of a fixed list price. A number quoted before anyone has seen the scope is either padded or will change later.

Which processes are genuinely suitable

Four areas produce returns most reliably.

Document and request handling. Classifying, summarising and routing incoming email, forms and documents. Where volume is high, the return shows up quickly.

Customer communication. Assistants that answer common questions from source documents. Handover points to a human have to be defined explicitly.

Operational forecasting. Demand, inventory, maintenance and risk. Where historical data is clean, this is the most measurable area.

Internal knowledge access. Letting staff query internal documentation in natural language. If source quality is poor, the output will be too.

Against that: if the data infrastructure is fragmented, if the process is not standardised across the organisation, or if output accuracy is critical, those problems come first.

In-house or external?

The answer has less to do with team size than with continuity.

AI is not a one-off project. Models get updated, data shifts, usage spreads. If nobody inside owns it, an externally built solution decays just as fast.

A practical approach: build the first pilot with outside support, but appoint an internal owner from day one. Decide which team will inherit the codebase and documentation before you reach production.

Before the first conversation

If you are considering AI consulting, come prepared with three things: which process slows you down most, where that process's data lives, and what number you would use to measure success.

With those answers, an assessment moves considerably faster.

At Internative we run this process for mid-sized and large companies: selecting the right use case, proving it with a measurable pilot, and integrating it with the systems already in place.