Many B2B projects now begin with a request for “AI”. Sometimes it comes from the board, sometimes from a competitor’s announcement, sometimes from a team that tried a chat assistant and wants the same thing for its own work. The request is rarely wrong. It is just not yet a project.
Behind most AI requests sits a familiar business problem that could be solved with analytics, automation, better data, or occasionally a machine learning model. The useful work is translating one into the other without dismissing the ambition or overpromising what a model can do.
What buyers usually mean
Most requests fall into a few patterns. Recognizing which one you are looking at shapes everything that follows.
- “We want to predict things.” Demand, churn, late payments, equipment failure. This is forecasting or classification, and it succeeds or fails on the quality of historical data more than on the method.
- “We want less manual work.” Reading documents, sorting emails, filling forms, routing requests. This is automation, sometimes with a language model handling the unstructured part.
- “We want answers faster.” Managers waiting days for a report. This is usually a data model and BI problem, perhaps with a natural-language interface on top.
- “We want to use what we already know.” Manuals, contracts and past tickets that nobody can search. This is retrieval and search, an area where language models genuinely help.
- “We need an AI strategy.” Pressure without a problem attached. This needs discovery before anything else.
Questions that turn a request into a scope
A scoping conversation should end with a problem statement precise enough to estimate. These questions get you there:
- Which decision or task do you want to change? Name the people who do it today and how often they do it.
- What happens now? Walk through the current process, workarounds included.
- What would better look like, in terms you already measure? Response time, error rate, forecast accuracy, hours spent. If nobody measures it today, measuring it is step one.
- What data exists? Where it lives, how far back it goes, who owns it, and whether anyone trusts it.
- What happens when the system is wrong? Every model makes mistakes. The cost of a wrong answer decides how much human review the design needs.
- Who will use the output, and where? A prediction nobody sees changes nothing.
The data question usually decides the project
Many AI ambitions stall on the same obstacle: the data needed to train or ground the system is scattered, inconsistent or missing. Imagine a manufacturer that wants to predict which quotes will convert. If won and lost quotes are recorded inconsistently, and the loss reason is a free-text field someone fills in now and then, no model will give a reliable answer. The honest scope starts with fixing how quotes are recorded and adds the prediction later.
That is not a disappointing answer. It is often the most valuable one, because the cleaned-up data supports reporting and automation long before any model goes live.
Red flags in an AI request
- A technology is named, but no user or process.
- Success is defined as “using AI” rather than as a business result.
- There is an expectation that the system will be right every time.
- Sensitive data is involved, with no clarity on where it may be processed. In the EU that is a GDPR question, and depending on the use case the AI Act adds its own obligations, which apply in stages.
- The deadline was set by an announcement rather than by the work.
None of these means the project should not happen. Each one means a conversation is needed before a budget is set.
Scope small, then expand
The best first AI project is narrow: one process, one team, a measurable result within a few months. It should leave something useful behind even if the model turns out weaker than hoped, such as cleaner data, a documented process or a working integration. Broad programs that aim to “bring AI to the whole company” tend to produce pilots that never reach production, and a narrow win is a better argument for the next budget than a wide plan.
A good test for any proposed first project: if you removed the word “AI” from the description, would the business still want it? If yes, you have a real problem worth solving, and the technology choice can follow the problem.
If your organization has an AI mandate but no defined project, start with a discovery conversation that lists the decisions and tasks people most want to change, then check which of them have the data to support it. The shortlist that comes out of that exercise is a far better starting point than a technology choice.