On this page
Most organisations we talk to about a first AI project have already picked a technology — an LLM, a forecasting model, a vision system — before they have answered the questions that actually determine whether the project will succeed. Here is the order we work through instead.
1. Is there a specific decision this changes?
"We want to use AI for customer service" is not a decision — it is a department. "We want to reduce the average time to resolve a billing query" is a decision. AI projects that start from a named decision, with a way to measure whether that decision improved, have a target to build toward. Projects that start from a technology tend to drift.
2. Does the data already exist, or does it need to be created?
This is the single biggest predictor of timeline. If the data your model needs already exists — historical transactions, sensor logs, past support tickets — a proof of concept can often be built in weeks. If the data does not exist yet (you need to instrument new sensors, start logging new events, or collect labelled examples), the project has an unavoidable data-collection phase before any modelling can start. Naming this upfront prevents a "why isn't the model ready yet" conversation three months in.
3. Who looks at the output, and what do they do with it?
Every AI system produces an output that someone has to act on: an alert, a score, a suggested answer. If nobody has explicitly agreed who reviews that output and what they are expected to do with it, the system will either be ignored (alert fatigue) or trusted more than it should be (automation bias). This is a process design question, not a technical one, and it needs an answer before launch, not after.
4. What does "good enough" look like, numerically?
"Accurate" is not a target. "95% precision on high-value transactions, reviewed weekly" is a target. Defining the acceptance threshold before building lets you evaluate honestly, rather than adjusting the definition of success after seeing the results.
5. What happens when it's wrong?
Every model will be wrong sometimes. The question is whether the cost of being wrong is recoverable — a customer waits an extra day for a support reply — or not — a fraud model that wrongly declines a legitimate transaction, at scale, damages trust quickly. Projects with a low cost of error can tolerate a faster, more experimental rollout. Projects with a high cost of error need a longer proof-of-concept phase, a narrower initial scope, and a human in the loop for longer.
What a readiness call actually does
A 30-minute readiness conversation is not a sales pitch — it is us asking these five questions against your specific situation, and being honest if the answer to any of them suggests the project needs more groundwork before it needs a model. Sometimes that means recommending a smaller first step than the one you asked about. That is usually the fastest route to something that actually ships.
Put it to work
AI Consulting