AI Consulting Services

Most AI projects fail before a model is ever called. They fail because nobody agreed what the process was, where the data lived, or what a good outcome looked like. The model was never the hard part.

I come at this from process engineering rather than data science. Seventeen years of that work, including Lean Six Sigma, means the first question is not which model to use. It is which step in your operation is slow, expensive or error-prone, whether it is repeatable enough to automate, and whether the data behind it is trustworthy.

Roughly half the AI ideas I am asked to scope should not be built. Saying so early is the most valuable thing this engagement does.

Process first, model last

The sequence that works is unglamorous. Map the process as it genuinely runs, not as the documentation claims. Measure where time and money leak. Identify the steps that are repetitive, rule-bound and high volume. Check whether the data those steps depend on is complete and consistent. Only then decide whether a model helps.

Skipping to the model produces the usual outcome: a working demonstration that never reaches production because the input data was messier than anyone admitted, or because the step it automated was not the expensive one.

This is the same discipline as DMAIC applied to a different class of problem, and it is why the process background matters more than it sounds.

What tends to be worth building

Across the engagements I have run, the work that pays back reliably clusters in a few places.

Document handling. Extracting structured data from invoices, drawings, statements and forms that people currently retype. High volume, rule-bound, and the error rate of the manual process is usually worse than anyone believes.

Triage and routing. Classifying incoming work so it reaches the right person first time. Cheap to build, and the saving is in cycle time rather than headcount.

Drafting inside a defined format. First drafts of quotes, reports, summaries and responses where a template exists and a human approves the output.

Answering from your own material. Retrieval over your documents so staff stop searching shared drives. This is where retrieval systems genuinely earn their cost.

What tends not to be

Equally useful to know. Fully autonomous decisions with real financial consequence and no review step. Automation of a process that runs a handful of times a month. Anything depending on data that three departments record three different ways, until that is fixed. And chat interfaces built because a chat interface was wanted, rather than because a question needed answering.

Each of those can be made to work eventually. None of them should be the first project, because the first project has to succeed visibly or the programme loses its sponsor.

Guardrails, from the start

Every system I build ships with spend controls before it ships with features: a hard cap per run and per day, a circuit breaker that stops calling a failing service rather than retrying into a bill, metering that records what every call cost, an off switch that works without a deploy, and an alert when something trips.

This is not optional engineering polish. An unmetered integration calling a paid model in a loop is the single most common way a small AI project turns into an unexpected invoice.

Working alongside your existing team

The usual arrangement is that I do the scoping, the architecture and the first build, and your developers take it from there. That is deliberate. Ongoing internal tooling is almost always cheaper and better maintained in-house, and an outside consultant who becomes a permanent dependency has failed at the handover.

In practice this means documentation written for your engineers rather than for a business sponsor, code structured to be read by someone who did not write it, and an explicit recommendation whenever a piece of work is better done by your own team than by me.

The first conversation

It is usually short and it is mostly questions. What does the process look like today, who touches it, how often does it run, where does it hurt, and what happens to the data when it does.

By the end of that conversation it is normally clear whether there is a project worth scoping. A fair share of these end with a recommendation that costs nothing: a step that can be removed, a report that already exists somewhere, or a product that solves it off the shelf. That is a better outcome than a proposal, and it is why the conversation comes before the quote.

How engagements usually begin

With a conversation about the process rather than the technology. What it looks like today, who touches it, how often it runs, and what happens when it goes wrong.

From there the usual first step is a scoped discovery: map the process, score the opportunities, and recommend one to prove. That is a defined piece of work with a defined end, and it produces a decision rather than a commitment to a platform.

What the engagement includes

• A process map that reflects reality. The workflow as it actually runs, with the time and cost of each step measured rather than estimated.
• A scored opportunity list. Every candidate use case scored on value, feasibility and data readiness, including the ones I recommend against and why.
• A proving case. One use case built end to end and measured against the manual baseline, so the business decides on evidence rather than a demonstration.
• Data readiness assessment. Whether the data behind each opportunity is complete, consistent and accessible, since this is where most projects actually die.
• Spend guardrails. Caps, circuit breaker, metering, kill switch and alerting, built in from the first line rather than added after a surprise bill.

How the work runs

1. Map. Document the process as it runs today, with real timings and real error rates.
2. Score. Rank the opportunities on value, feasibility and data readiness. Say plainly which ones should not be built.
3. Prove. Build one case end to end and measure it against the manual baseline.
4. Harden. Add the caps, metering, breaker and kill switch before it touches production volume.
5. Hand over. Documentation and operating notes written so your team can run and extend it without me.

Proof

An applied example, from process mapping through to a governed data platform, is in the awards manufacturer case study.

Related

• Custom GPT Development
• RAG Chatbot Development
• Process Improvement

Talk about your situation

The first conversation is short and mostly questions. Get in touch and tell me what you are trying to fix. Or see how this is priced.

Frequently Asked Questions (FAQs)

What does an AI consultant actually do?

The useful version of the job is deciding what to build and what not to build, then proving it on one case before anyone commits a budget. That means mapping the real process, checking whether the underlying data can support the idea, and scoping the smallest thing that would demonstrate value. Model selection is a late and comparatively minor decision.

How do I know if my business is ready for AI?

Readiness is mostly about data and process, not technology. If a process is documented, runs often, and the data behind it is recorded consistently, you are ready. If three teams record the same field three different ways, that gets fixed first, and it is usually a data engineering job rather than an AI one.

Should I build or buy?

Buy whenever a product covers the need, which is more often than vendors of custom work admit. Build when the process is genuinely specific to your business, when the data cannot leave your environment, or when the per-seat cost of a product exceeds the cost of owning the thing. The scoring exercise answers this per use case rather than as a policy.

What stops AI projects from reaching production?

In order: input data that turned out to be inconsistent, no agreed definition of success, automating a step that was not actually the expensive one, and no owner once the consultant leaves. Every one of those is a scoping failure rather than a technical one, which is why the early work is deliberately unglamorous.

Can you work with our existing team?

Yes, and that is the usual arrangement. The handover is written so your developers can extend the system, and where a piece is better built in-house the recommendation says so rather than expanding the engagement.