How to Prepare for an AI Consultation

Why the preparation decides the outcome

In a first session, most of the time goes on establishing facts rather than giving advice. What actually happens, how often, who does it, what it costs when it goes wrong. If those facts have to be reconstructed live from memory, the session is largely spent on discovery and the advice at the end rests on approximations.

Arrive with the facts and the shape of the conversation changes. The time goes on which parts are worth automating, what the sequence should be, and what it would cost — the part you actually came for.

There is a second reason, less obvious. Preparing forces you to look at your own process closely enough to notice things. A fair number of businesses find, while assembling the numbers, that the bottleneck is not where they assumed it was. That finding is worth having whether or not you go on to automate anything.

Pick one process, not your whole business

The single most useful thing you can do is arrive with one specific process rather than a general interest in AI. Not "we want to use AI in operations" but "every enquiry that comes through the website gets copied into the CRM by hand, and it takes about ten minutes each."

A named process can be measured, scoped and costed inside one session. A general interest cannot, and the conversation stays at the level of possibility.

Choose the process using a rough test: it should be something that happens often, follows roughly the same steps each time, and irritates someone. Frequency makes the automation worth building, repeatability makes it possible to build, and the irritation tells you somebody will actually adopt it.

If two or three candidates come to mind, bring all of them and say which one hurts most. Comparing candidates is a reasonable use of the session. Surveying your entire operation is not.

This is the ground we cover in an AI consultation — a diagnostic session that ends with a costed plan rather than a proposal.

The four numbers to have in hand

For the process you picked, these four are what turn a conversation into a scope. Estimates are fine — a defensible estimate you can explain beats a precise number you had to invent.

• Volume: how many times this happens a day, a week, or a month. Say which.
• Time: roughly how long one instance takes, and who does it — a name and a role, because an hour of a senior person is not an hour of an assistant.
• Failure cost: what it costs when this goes wrong or gets missed. A lost lead, a duplicate invoice, an angry customer, a compliance problem. This is the number most people have never worked out, and it usually matters more than the time saved.
• Growth: whether this volume is rising, flat, or seasonal. A process at 40 instances a week that will be 200 next year is a very different build.

Show the artifacts, do not describe them

Descriptions of a process are always tidier than the process. People describe the version that works, and the edge cases — the exceptions, the manual overrides, the client who insists on a different format — are exactly where the cost and the difficulty live.

So bring the real things. A screenshot of the inbox as it actually looks. The spreadsheet, with the messy columns still in it. One real record from the CRM, with names removed if you need to. A photograph of the whiteboard, if that is where the process lives.

Bring a normal example and an awkward one. The awkward one is more informative: it shows what the automation would have to handle, and often it is the reason a straightforward-sounding job turns out to need judgement.

If a step happens in someone's head — "Sarah just knows which ones are urgent" — say so explicitly. Undocumented judgement is not a barrier, but it needs to be found before the build rather than during it.

Know your systems and who controls them

Write down every tool the process touches, in order. The website form, the inbox, the CRM, the spreadsheet, the accounting package, the scheduling tool. Include the ones you are slightly embarrassed by — the shared inbox nobody has cleaned out, the spreadsheet that is really a database.

Then note two things against each: who owns the account, and whether anyone has ever connected it to anything else. Integration is usually what decides whether a build is straightforward or awkward, and access is the most common cause of a project stalling in week two.

If a tool is on a plan that does not allow outside connections, or the only person with the login left last year, that is worth knowing before anyone scopes anything. It is a cheap thing to check now and an expensive thing to discover later.

Decide your constraints before the call

Three decisions are yours rather than the consultant's, and having them settled prevents the session ending in a vague proposal.

The first is a budget range. Not a precise figure, but an order of magnitude — whether this is a few thousand or a few tens of thousands. Withholding it does not get you a better price; it gets you a proposal that may be aimed at entirely the wrong scale, and a second session to correct it.

The second is a timeline and, more importantly, what is driving it. "Before our busy season in November" is a real constraint that shapes the sequence. "As soon as possible" is not a constraint and tells nobody anything.

The third is who inside your business will own this once it is running. Someone has to be the person who notices when it breaks and who tells you when the process changes. If that person is nobody, the honest answer is that you are not ready to automate yet — which is a finding worth reaching in a free half hour rather than three months in.

What not to prepare

The one thing that reliably makes a session worse is arriving with a solution already specified. "We want a chatbot on the website" or "we need an AI agent that reads our emails" narrows the conversation to how to build that thing, and skips the question of whether it is the thing worth building.

This happens often and it is understandable — you have read about a tool and it sounds like it fits. Keep the idea, by all means, but present it as a candidate rather than a requirement. The useful version is: here is the problem, here is what I was thinking, tell me if that is the right shape.

You also do not need to research the technology beforehand. Which model, which platform, whether to use one tool or another — those are implementation choices, and paying for advice you then do not use is a poor trade. Bring the process and the numbers; the tooling is the easy part and it is what you are hiring for.

And do not tidy the data first. The instinct to clean the spreadsheet before showing it is a strong one, but the mess is diagnostic information. Cleaning it hides the exact problem that would have driven the cost estimate.

What you should leave with

Preparation is worth doing because it changes what you can reasonably expect at the end. With one process, four numbers and a real artifact on the table, a first session should be able to tell you which parts of that process are worth automating and which are not, roughly what a build would involve, and what the sequence should be if there is more than one candidate.

What it should not produce is a proposal for something nobody has looked at yet, or a number attached to a scope that was never defined. If the session ends with a quote but no diagnosis, the preparation was wasted on the wrong consultant rather than the wrong preparation.

One last practical point: write down what you were told while it is fresh, including the parts where you were advised not to automate something. Those are usually the most valuable sentences in the session, and the easiest to forget.