Turn Your Painful-Process List Into an AI Use-Case Register

Ask a leadership team what they’d use AI for, and you’ll get one of two answers. Either a list of big, vague ideas from a strategy offsite (“AI for customer service,” “AI-powered insights”), or an awkward silence. Neither gets funded, and neither turns into a working pilot.

Meanwhile, every department already has the raw material for good AI use case prioritization. It’s the list of processes they complain about: the weekly report that takes a day to assemble, the same twenty questions HR answers every month, the contracts someone reads line by line to find renewal dates. Those complaints are specific, owned, and measurable. Turn them into a register, and you have a pipeline of AI work that’s much easier to fund than any offsite brainstorm.

Why a register instead of a brainstorm

A brainstorm produces ideas. A register produces decisions. The difference is that each entry in a register has an owner, a rough measure of value, an honest view of how feasible it is, and a status. That makes it possible to compare ideas, pick the right first pilot, and show leadership that AI investment is going somewhere deliberate.

It also becomes the single place where AI ideas land. Champions add to it. The AI council reviews it. The CFO sees it. Without it, AI ideas arrive in hallway conversations and get pursued by whoever is most persistent.

Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:

U1. How well defined are your AI use cases?

0. None identified
1. General ideas, nothing written down
2. A list exists but isn’t prioritized
3. A prioritized backlog with business owners
4. Prioritized by value and feasibility, each with success metrics

Most teams are at 1 or 2. The jump to 3 is mostly about owners. The jump to 4 is about scoring and metrics, and it’s what separates a backlog from a portfolio.

Step 1: collect painful processes, not AI ideas

Don’t ask departments “what could AI do for you?” People either don’t know or answer with something they saw in a demo. Ask instead:

• What do you do every week that’s repetitive and slow?
• Where do mistakes happen most often, and why?
• What involves reading or writing a lot of text?
• What do you wait on other people for?
• What questions do you answer over and over?

Aim for thirty to fifty specific items across departments. Specific means “answering the same benefits questions from employees every open enrollment,” not “an HR chatbot.” The specific version tells you who owns it, how often it happens, and what good looks like.

Step 2: filter for AI fit

Not every painful process is an AI problem. Some are better solved with ordinary automation, a policy change, or a better form. A quick filter:

Good fits for AI: text-heavy work (summarizing, drafting, classifying, extracting information from documents), searching across lots of documents, and judgment-based tasks where a person reviews the output before it’s used.

Poor fits for AI: tasks that need perfect accuracy with no human review, tasks that depend on data you can’t reach, rare tasks that don’t justify the effort, and tasks that follow fixed rules. That last group is worth flagging: if a process follows clear rules, regular automation is cheaper, faster, and more reliable than a model.

The asset: the use-case register

Keep it in a shared spreadsheet or a list in your collaboration tool. One row per use case, with these fields:

1. ID and name: short and specific.
2. Department and business owner: a named person outside IT who wants it.
3. Current process: two or three sentences on how it’s done today.
4. Frequency and volume: how often, and how many.
5. Time per occurrence: a rough estimate from the people doing it.
6. Pain type: time, errors, delays, compliance risk, or customer experience.
7. Data needed and where it lives: use your source-of-truth map.
8. Data sensitivity: public, internal, confidential, or regulated.
9. Approach: licensed assistant, automation, custom build, or buy a specialized product.
10. Value score, 1 to 5.
11. Feasibility score, 1 to 5.
12. Risk: low, medium, or high.
13. Success metric: the one number that would show it worked.
14. Status: proposed, prioritized, piloting, in production, parked, or rejected (with a reason).

Step 3: score value and feasibility

Keep the scoring simple enough that people agree on it. Anchors help.

Value considers how often the task happens, how long it takes, how many people it affects, and how much it matters strategically. A 5 is frequent, time-consuming, affects many people, and ties to a stated business goal. A 1 is occasional and minor. The business owner should propose the value score; IT shouldn’t set it alone.

Feasibility considers whether the data is reachable, whether the owner is engaged, whether a tool you already have can do it, and whether the risk is manageable. A 5 means data is accessible, the owner is committed, and your approved assistant could handle it now. A 1 means major prerequisites are missing.

Then sort the register into four groups:

• High value, high feasibility: do these first.
• High value, low feasibility: fix the foundations that are blocking them; they tell you which readiness work matters most.
• Low value, high feasibility: useful for learning if they’re cheap, otherwise skip.
• Low value, low feasibility: park them.

A decision rule for the first pilot

Your first pilot should be high feasibility, at least medium value, low risk, and have an engaged business owner. It should not be the highest-value item on the list. The highest-value items are usually hard, and a first pilot’s main job is to succeed visibly and teach your team how to run the next one. The details of picking and proving that first one are in picking your first AI use case.

Before building anything, capture the baseline numbers for the success metric. Pilots without baselines can’t prove they worked, which is covered in baseline before you build.

Keep the register alive

A register that’s built once and never touched is back at level 2 within a quarter. Review it monthly for thirty minutes: new items, status changes, re-scoring anything whose feasibility changed because a foundation got fixed. If you have an AI council, this is a standing agenda item. Champions in each department should add to it as ideas come up.

Mistakes I see at this stage

Every item scored 5. If everything is high value, nothing is. Force a spread by ranking before scoring, or cap the number of 5s.

IT scoring value on its own. IT is well placed to judge feasibility and poorly placed to judge business value. Business owners score value.

No owners. An item without a business owner isn’t a use case yet; it’s an idea. Keep it, but don’t prioritize it. The reason is in why IT-only pilots stall.

Never rejecting anything. Rejected items, with a short reason, are some of the most useful rows. They stop the same idea from being re-proposed every quarter.

Starting with the most senior person’s idea. It’s tempting, and it’s often the hardest item on the list. Score it like everything else.

Where does your team actually stand?

Use-case definition is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

• Where Should Your Business Data Live Before AI?
• Picking Your First AI Use Case (and Proving It Worked)
• Baseline Before You Build: Metrics That Make AI Pilots Fundable
• The 30-Minute AI Council: Lightweight Governance That Sticks
• Business Owners for AI Projects: Why IT-Only Pilots Stall