Prepare for Your First AI Supplier Call

Before you talk to an AI service provider, prepare one repeated job, a few real examples, the rules a person already uses, who will check the result, and what would make you stop.

That is enough for a useful first conversation. You do not need a full technical brief. You do not need to know which model you want. You do not need a perfect process map.

The best early AI conversations are practical. They start with work your team already does, not with a wishlist of features.

Bring one repeated job

Start with a job that happens often enough to be worth improving.

Good candidates are usually small and familiar: reading new enquiries, drafting first replies, checking forms, sorting support messages, summarising meeting notes, matching customer questions to approved answers, or pulling key details out of documents.

The job should be easy to describe in a sentence. If it takes twenty minutes to explain what happens, the first AI project may need to be narrower.

A useful sentence sounds like this: "Every weekday, someone reads new website enquiries, decides which service they relate to, and drafts a first reply for review."

That sentence gives the provider something real to work with. It names the input, the judgement, and the output.

Bring real examples

AI work improves quickly when it is tested against real material.

Bring five to ten examples of the thing your team handles now. That might be contact form messages, product descriptions, customer emails, PDFs, support tickets, booking notes, or internal questions.

If the material is sensitive, redact names, addresses, prices, or anything private before sharing. The examples do not need to be pretty. In fact, messy examples are more useful than polished ones because they show the real shape of the work.

Try to include a mix: easy examples, awkward examples, edge cases, and one example where your team would probably say no.

That gives the provider a better view of what the AI would need to handle, and where a person still needs to make the decision.

Bring the rules a person already uses

Most useful AI projects depend on rules your team already follows, even if nobody has written them down.

For a lead-sorting job, the rules might be service area, budget, urgency, location, and whether the enquiry sounds like a fit. For a document-checking job, they might be required fields, missing signatures, risky wording, or known red flags. For an internal search tool, they might be which source material is approved and which old documents should be ignored.

Write the rules in plain English. Short bullets are fine.

The aim is not to make the AI replace judgement. The aim is to show what good judgement looks like so the tool can do the first pass in a way a person can check.

If the team cannot agree the rules, that is useful to know early. The first piece of work may be clarifying the process before any AI is added.

Bring the risks and permissions

AI projects are easier to plan when the uncomfortable questions are on the table early.

What data would the tool need to read? Is any of it private, regulated, commercially sensitive, or customer-facing? Who is allowed to see it today? Can it leave your systems, or does it need to stay inside a controlled account?

Then ask what happens if the AI gets something wrong.

Some mistakes are low risk: a draft reply needs editing, a category is wrong, a summary misses a point. Some are not: a customer is given the wrong price, a legal commitment is made, private information is shared, or a payment decision is made automatically.

The risk decides the review step. Low-risk work might need a quick human check. Higher-risk work may need the AI to produce a checklist, not a final decision.

Bring a reviewer and a stop condition

Every first AI project needs a named person who checks whether it is actually helping.

That person does not need to be technical. They need to understand the job well enough to say, "This saved time," "This needs too much correction," or "This is not safe enough yet."

Also decide what would make you stop after a short trial.

For example: "We will try this on website enquiries for four weeks. We keep it only if seven out of ten draft replies need light editing and no private information is included by mistake."

That kind of stop condition is useful because it protects the business from keeping a tool just because time has been spent on it.

Do not prepare a perfect specification

You do not need to arrive with a chosen model, a list of software vendors, or a diagram of every system in the business.

You also do not need to turn the first conversation into a huge business-change exercise. A narrow first project is usually easier to value, easier to review, and easier to stop if it is wrong.

The provider can ask about systems, data access, costs, and technical options once the business job is clear.

If the first question is "which AI should we use?", the conversation often gets abstract. If the first question is "which repeated job should we improve?", the conversation becomes useful much faster.

Preparation makes the first chat more useful

When a business comes to us with one repeated job, real examples, rules, risks, a reviewer, and a stop condition, we can usually tell whether it looks like an AI Audit, Agent Workflow, or Knowledge System.

Sometimes the answer is that AI is not the right first move. Sometimes the better first move is cleaning up the source material, changing a form, or writing down the rules people already use.

That is still progress. The goal of the first conversation is not to buy the biggest possible tool. It is to find the smallest useful place where AI can help without creating a new problem for the team.