How to choose the first AI use case for your SaaS

The question is not "what AI use cases exist for a SaaS?". It is "which one do I start with so I see value without losing the quarter?". In meetings a list is almost never missing. Criteria are. The first case is not the one that impresses most in a demo. It is the one that is small, reversible, with a clear metric and data that are good enough.

If you pick the wow case, you take months to find out you could not measure it. If you pick a boring, reversible one, in a few weeks you know whether the agent is worth it or not. The rest of the case sheet waits.

The mistake of starting with the wow case

The wow case is usually the one that closes the meeting: an agent that talks to the customer, writes in the CRM, summarizes contracts, and is "almost there". In the demo it works because the scope is theater. One flow, one friendly tenant, a human behind it who corrects.

McKinsey said it without wrapping in 2024: it is relatively easy to stand up a pilot that amazes, and another thing to take it to scale. Their advice to whoever prioritizes is not "run more experiments". It is to cut the ones that do not perform and concentrate on the ones that are feasible, touch a part of the business that matters, and do not spike the risk. In their survey, only a minority of companies attributed a serious EBIT impact to generative AI. The pattern we see matches: too many fronts, no case you can kill or scale with a number.

The wow is also the one that looks most like "the competitor's product". You start there and build the whole platform for a flow that still has no metric. Then the roadmap eats the pilot. That is not a model problem. It is having picked the first case badly.

Six criteria, not an inspiration list

Before you draw quadrants, each candidate has to hold up under these six questions. If one stays blank, it is not the first.

Volume. Does it happen enough times a week for a hit to show up in the P&L or in the team's time? A flow that happens twice a month teaches nothing.

Data. Is there a source of truth the agent can read, or does the knowledge live in three people's heads and an outdated Notion? If the data are bad, the result is bad. You do not need the perfect dataset. You need one that exists and has an owner. McKinsey puts it the same way: go after the data that matter, not the perfect ones.

Risk. What happens if it is wrong? An internal summary is not the same as a charge, a message to the customer, or a change to an order. The first case has to be able to fail without an incident.

Supervision. Who reviews the output, with what sampling, and what gets recorded? If the answer is "the model is already very good", there is no supervision. There is hope.

Metric. Which number changes, in what timeframe, and who looks at it? Time to resolve, tickets avoided, fields updated without rework, hours in a process. "It improves the experience" is not a metric.

Reversibility. Can you turn it off, undo what was written, or go back to the previous flow in a day? If not, it is not a pilot. It is a commitment in disguise.

Impact versus difficulty

Draw two axes. Impact (what changes the metric) versus difficulty (data, tools, risk, supervision). Four quadrants, one first case only.

High impact, low difficulty. This is where the first agent lives. It is usually an internal flow or one with a human in the middle: classify, summarize, fill in, suggest. The user already does that task. The agent shortens it. The tools are few and read-only, or write with approval.

High impact, high difficulty. The case the committee wants. High autonomy, writes into real systems, dirty data, several tenants. It is not the first. It is the second or the third, when you already have a metric and a harness that does not fall over. If you start here, you are asking for a product, not a pilot.

Low impact, low difficulty. Useful for learning the tool. Dangerous if it becomes the quarter's "we already have AI". If it does not move a number, it does not justify the maintenance.

Low impact, high difficulty. Drop it. A brilliant copilot on a process nobody uses is debt.

Difficulty is not "does our team know how to write a prompt?". It is whether there is a clean API, permissions per tenant, and someone who will inherit the flow. Prioritizing AI use cases without that picture is choosing by slide.

Signs of a good pilot

A good first case looks like this, even if it does not excite in the demo.

One task, one user, one source system. Not "the support agent". The agent that proposes a reply from the documentation and lets the human send it.

A metric you can read at two weeks, not at the quarter. If knowing whether it works requires a new dashboard, the case is bigger than you think.

Data that already feed the product. The agent reads what your SaaS already stores. It does not wait for a "unify the knowledge" project.

Limited writes or writes with confirmation. Creating a draft is not the same as closing a ticket. The second can be case 2.

Someone with a name who can kill it. If the pilot has no owner, it has no end.

Signs of a bad first case

Start with the most visible channel (chat on the home page, voice to the customer, WhatsApp) without having solved the internal flow. You are putting risk in front of the metric.

It needs five tools and three systems for "a first value". That is not a case. It is a platform.

Nobody can say what counts as a hit. The team argues about whether the answer "sounds good".

The data live in contradictory PDFs and in operations' heads. The agent is not going to tidy the company for you.

The plan is to build the shared infrastructure for twenty agents first. The first use case is not a harness. It is a flow. The layer is discussed later, when the flow already exists. If the temptation is to stand up a platform before you have a case, the debate is another one: whether the team should build that layer.

It cannot be undone. The agent writes in production and rollback is "we open a ticket".

Three places it usually lives (and where it does not)

No customer names. Patterns that repeat.

Support. The reasonable first case is almost never the autonomous bot that closes tickets. It is search the documentation, propose a reply, and leave sending to the human. High volume, data you already have (help center, orders), contained risk, obvious metric (time to first response, rework). The wow (the agent executing refunds) waits for permissions and a cap. If that jump tempts you, look at what is missing between demo and production before you widen scope.

CRM and sales. The first case is usually turning a note or a transcript into fields and a follow-up draft, with someone who confirms. The bad first case is the agent that updates deals on its own, across every tenant, on a Friday afternoon.

Documents. Extract fields from one document type that already comes in through the product, with review. Not "understand all our contracts". One type, one schema, one sample.

If your first case does not fit one of these shapes (one task, read or draft, metric at two weeks), ask yourself whether you are choosing the agent or the announcement.

Kickoff: what has to be written before you build

You do not need a ruling. You need one page.

Which flow, which user, what the agent will not do.

Which metric, baseline, and threshold to continue or stop.

Which data it reads, from where, and who owns that source.

What it can write, and what it asks confirmation for.

How it gets turned off, and who turns it off.

If you cannot fill that in in an hour, the case is not a case yet. It is an idea. Sometimes the first step is not an agent: it is a rule, a workflow, or cleaning the source of truth. An agent on an unstable process is theater.

When the page is full, the next job is not "more AI". It is operating that flow with real tools, a cap, and a trace. That is Product: one case, not twenty. If the number does not close, the problem was not the quadrant. It was not killing the case in time, and that shows up in the agent's TCO.

The first AI use case for your SaaS does not have to be memorable. It has to be reversible. The memorable part arrives when you already know what works.