An AI consultant should do more than recommend a model or give your team a list of tools. The useful job is to understand a business process, find the part worth improving, test the right technical response and help the people responsible for the work use it safely.
01
The job starts before AI gets involved
Imagine an established business with a busy shared inbox. Customer enquiries arrive with documents and questions. Staff read each message, copy details into the CRM, work out who owns the request, chase missing information and prepare a reply. Somebody suggests putting AI on the inbox.
That suggestion is not yet a useful project. It does not say which part of the work should change, what a good result looks like or what happens when the system gets something wrong. Buying a clever tool at this point would be a little like employing somebody before deciding what their job is.
An AI consultant bridges that gap. The role is to connect a real business goal with a proportionate technical response. That involves understanding the process, choosing the right task, testing what is feasible, designing the surrounding system and helping the team adopt it. The model is only one component of that work.
02
Process discovery follows the work from request to result
The first responsibility is process discovery. A consultant needs to see how work really moves through the business, including the unofficial steps that people use to keep it moving. The documented process may say that an enquiry goes straight into the CRM. The team may quietly know that it first sits in an inbox until one experienced person decides what it means.
For our inbox example, discovery would follow several representative enquiries from arrival to resolution. Which information is present? Which details are copied? Which checks are made? Where does responsibility change? What causes delay, rework or mistakes? Which decisions require experience, and which simply follow a stable rule?
This is not a ceremonial workshop before the technology starts. It is how the consultant finds a problem small enough to solve and important enough to justify the effort. Without it, the project risks automating the most visible step while leaving the real bottleneck untouched.
03
Choose the task, not the trend
A broad process usually contains several smaller tasks. The inbox work might include classifying the enquiry, extracting approved fields from attachments, checking whether required information is missing, finding an existing customer record, assigning an owner and drafting a response for review.
Those tasks do not have equal value or equal risk. Preparing a suggested category may save useful time and remain easy for a person to check. Sending a final answer about a sensitive customer case without review carries a different consequence. A consultant should separate the possibilities and prioritise them using frequency, effort, business value, data quality and the cost of a wrong result.
The first project should normally be a narrow use case with a visible outcome. That creates evidence without asking the company to redesign an entire operation around a promise. It also gives the team a chance to learn where AI is dependable and where human judgement still matters.
04
Decide whether AI is even the right tool
Some work described as an AI opportunity is ordinary automation wearing a fashionable hat. If every enquiry from an existing customer needs to be attached to the matching CRM record, a clear identifier and a reliable integration may solve the problem more cheaply and predictably than a language model.
AI becomes useful when the task involves language, images, patterns or variation that fixed rules handle poorly. A language model might summarise an email and draft a reply. Document processing could extract information from inconsistent forms. A predictive model might help rank cases if the business has enough relevant, well governed historical data.
A good consultant should be comfortable recommending a rule, an integration, a standard product, a generative AI service or no change at all. Custom machine learning is a specialist engineering and data science commitment, not the automatic destination of every AI conversation. The right answer is the smallest dependable approach that improves the operation.
05
Design a test that can fail usefully
Once a use case has been selected, the next responsibility is designing a fair test. A polished demonstration using three perfect examples proves very little. The consultant needs representative material, including the awkward cases, incomplete documents and unusual wording that make the real process difficult.
The test should define success before the result is known. For the inbox, that might include correct classification, complete field extraction, a useful draft, acceptable response time and a clear route to a person when confidence is low. Cost matters too. A solution that works well but costs more per case than the work it replaces is an interesting experiment, not an improvement.
A prototype should produce evidence about quality, feasibility and risk. If it shows that the data is too inconsistent or the output is too hard to review, stopping is a useful result. The purpose is to reduce uncertainty before more money and operational trust are committed.
06
Turn the prototype into a dependable workflow
A successful prototype is not a production system. It may still depend on somebody copying a message into a tool, choosing the right prompt and pasting the answer somewhere else. That can prove an idea, but it does not yet remove work or give the business much control.
Implementation design connects the useful capability to the systems and responsibilities around it. The consultant may map how the inbox, document store, CRM and AI service communicate. The design needs permissions, logs, retries, failure handling, data retention rules and a clear point where a person reviews or takes over.
This is where software experience matters. The AI component may produce the summary, but the wider application decides which information it receives, who can use the result and what happens next. A dependable workflow is deliberately less exciting than a demo. It keeps working on an ordinary Tuesday when a supplier is slow and an attachment arrives in the wrong format.
07
Risk and governance belong in the design
AI risk is not a form to complete after launch. It changes which use cases are sensible and how the system should work. A consultant needs to ask what information is being shared, where it is processed, how long it is retained, who can see the result and what harm a confident but wrong answer could cause.
The National Institute of Standards and Technology describes AI risk management through four connected activities: govern, map, measure and manage. That is a useful practical order. Establish ownership, understand the context, test the behaviour and control the remaining risk. In the UK, the Information Commissioner's Office also makes clear that accountability and data protection apply when personal data is used in AI systems.
For the inbox workflow, controls could include limiting the data sent to the provider, preventing automatic replies for sensitive categories, recording the source material and draft, requiring human approval and giving somebody the authority to pause the service. Governance should make useful work safer, not create paperwork nobody reads.
08
Help the team adopt the new way of working
An AI system creates no value if the people doing the work avoid it, repeat every task manually or trust it without checking. Change management is therefore part of the consultancy role. The team needs to understand what the tool does, what it does not do and how their own responsibility changes.
Training should use the real workflow rather than a tour of generic AI features. Staff working in the inbox need to see good and bad examples, recognise when information is missing, know how to correct a result and understand when the case must leave the automated route. Managers need visibility of exceptions and enough information to improve the process without watching every click.
Adoption also depends on interface design. If reviewing the AI output takes longer than doing the task from scratch, the system has moved the work rather than removed it. A consultant should listen to users, observe where the process catches and refine the experience before declaring success.
09
Measure whether the change earns its place
The project needs a baseline and a small set of measures tied to the original problem. For the inbox, useful signals might include time to first action, handling time, missing information found before handover, rework, overdue enquiries and the proportion of suggestions accepted after review.
Accuracy on its own can be misleading. A system may classify most messages correctly while failing on the few categories where a mistake matters most. The consultant should look at quality by case type, the number of exceptions, operating cost and the effort needed to supervise the service. Those details show whether the workflow is becoming more useful or merely more complicated.
Measurement continues after launch because models, providers, data and business processes change. The right review rhythm depends on the risk and volume of the task. The aim is not to promise a dramatic return before the evidence exists. It is to make value and problems visible early enough to act on them.
10
What a useful AI consultancy engagement should leave behind
A useful engagement should leave the business with more than a presentation and a list of products. It should define the problem, map the relevant process, prioritise the use case, explain why the chosen approach fits and record what the prototype or assessment actually showed.
It should also make the next decision easier. That may include a production scope, integration design, risk controls, ownership, adoption plan and an honest view of cost. It may instead recommend improving the data, simplifying the process or using a standard automation before investing in AI. Clarity is part of the deliverable, even when the answer is smaller than the original idea.
The simplest definition is that an AI consultant helps a business decide where AI can contribute, then turns that decision into a controlled piece of work people can use. For our shared inbox, that means moving from the vague instruction to add AI towards one testable task, a dependable workflow and a team that knows how to operate it. If you have a repetitive process or an AI idea that needs a practical first step, I can help assess it and build the right response around the systems your business already uses.
Useful questions
Before hiring an AI consultant, ask:
- Will they start with the business process and the result you need, rather than a preferred AI product?
- Can they explain which tasks need AI and which are better handled by rules or integrations?
- How will the idea be tested using representative cases and clear measures of success?
- Who will own data protection, human review, exceptions and the decision to stop the system?
- Will the engagement leave your team with a workable next step, even if AI is not the answer?
