Prioritising AI use cases by value, feasibility and risk

Run an AI workshop in almost any company and you'll leave with a wall of sticky notes. Forty ideas, sometimes more. A chatbot for customers. Automatic invoice processing. A demand forecast. "Something with our knowledge base". An assistant that writes offers.

Then comes the awkward part. The ideas people are most excited about tend to be the hardest ones, and the budget covers one project, maybe two. So how do you choose?

We use three questions. None of them is clever. The value is in answering them honestly, for every idea, before anyone falls in love with one.

Value: what actually changes?

"It saves time" isn't a value. Whose time, how much of it, and what happens with the time that's freed up?

A good test is to write the before and after as one sentence each. Before: two people in accounting spend most of Monday typing supplier invoices into Abacus. After: they check the ones the system flags, and the rest go through on their own. If you can't write that sentence yet, the idea isn't ready to be scored.

Value can also mean fewer errors, faster answers for customers, or a service you couldn't offer before. All fine. What matters is that someone in the business can name it, and ideally put a rough number on it: hours per week, the cost of a mistake, days of lead time.

Feasibility: can we actually build this?

This is where the exciting ideas tend to lose points. A few things decide it.

• Data. Does the data exist, and can you get at it? "It's all in the ERP" sometimes means it's in the ERP, in free-text fields, entered differently by every branch.
• Process. Is the process stable and understood, or does it change every time someone new takes it over? Automating a process nobody can describe gives you a faster version of the chaos.
• Systems. Do the systems involved have an interface, or will the solution have to click through screens?
• Ownership. Is there someone in the business who wants this and will give it time? Projects without an owner on the business side quietly die after the pilot.

Risk: what happens when it's wrong?

Every AI system is wrong sometimes. The question is what that costs.

An internal tool that drafts a summary for an employee to check is low risk. If the draft is bad, someone rewrites it. A system that answers customers directly, approves something, or makes decisions about people is a different category. So is anything that processes personal data, where the Swiss data protection act (and often the GDPR) sets rules you'll want to think about early rather than after the pilot.

Reversibility matters too. A wrong label on an email is fixed in a second. A wrong payment or a wrong message to a customer can't be taken back.

Putting it together

Give each idea a simple score from 1 to 3 for value, feasibility and risk, with risk counted the other way round, so low risk gets a 3. Don't over-engineer this. A spreadsheet with forty rows and three columns is plenty.

Then look at the results together, and pay more attention to the arguments than to the totals. If an idea scores high on value but low on feasibility because the data isn't there, that's not a reason to drop it. It's a reason to start fixing the data, and to put the idea on the roadmap for later.

What usually makes a good first project

The first project has a special job. It has to work, it has to be visible enough that people notice, and ideally it builds something the second project can reuse, like access to a data source or a way of reviewing AI output.

The good first candidates tend to be internal, frequent and low-risk: sorting incoming emails or documents and pulling out the data, preparing summaries for staff, drafting texts that a person approves. Boring, maybe. But they ship.

The ideas we'd usually not start with:

• the company-wide chatbot that "knows everything"
• anything that makes decisions about customers without a person in between
• anything that depends on data you've only promised to start collecting

Decide up front when to stop

One last thing that's easy to skip. Before the project starts, agree on what result would make you stop. For example: if after six weeks the system can't handle most of the test cases correctly, you end it and keep what you learned.

It sounds negative. It's actually what makes it safe to try things, because everyone knows a failed experiment will stay small.