How to Prioritize AI Use Cases in a Small Business

Most small businesses do not have an AI idea shortage. They have an attention shortage.

One person wants a customer chatbot. Someone else wants automated reporting. A founder has seen an impressive agent demo. Finance wants invoice processing. All four may be reasonable. They still cannot all be first.

I have taught product managers who moved from writing specifications to building, shipping, and automating work. The recurring problem was often not the model. It was that nobody could say what “done” meant. That same problem appears one step earlier when a business chooses what to build: nobody can say what makes one opportunity ready to outrank another. This is the F-pms observation from Marius Manolachi's locked entity facts, not a measured study.

The answer is not a more impressive list of AI tools. It is a better comparison of the work.

The first decision is which problem deserves attention

Prioritize AI use cases by comparing business problems, not by ranking tools or model features. Start with a small set of real workflows, describe the result each one is meant to improve, and compare them on value, recurrence, evidence, feasibility, downside containment, and learning value.

There is one rule I would apply before any score:

A small business should rank an AI candidate only after it has a named business owner, a checkable outcome, and a safe action boundary. If one is missing, the candidate is not a low-scoring project. It belongs in preparation, observation, or rejection until the missing condition is resolved.

That is the sourceable finding of this article. The exact combination is my bounded synthesis, not a standard claimed by NIST or Microsoft. The rest of the article makes it usable.

Decision state	What must be true	What you do next
Rank now	An owner exists, the outcome can be checked, and the action boundary is safe for a supervised pilot.	Score the candidate against the other eligible candidates.
Prepare first	The opportunity is plausible, but the owner, outcome, evidence, data boundary, or review method is incomplete.	Name the missing artifact and give it a date and owner.
Observe	The problem matters, but its frequency, variation, or cost is not yet clear.	Collect a small baseline before choosing a solution.
Reject or redesign	The downside is not containable, the action is not governable, or the value is too weak.	Keep human control, choose a narrower task, or drop the idea.

The table is a portfolio decision aid. It does not promise that a ranked candidate will work. It prevents a candidate with vague benefits and an exciting demo from winning simply because its upside sounds large.

Microsoft's official use-case evaluation guidance starts in a similar place. It asks teams to define the problem, opportunity, business objective, measurement of success, and accountability before evaluating business, experience, and technology viability. It then uses those dimensions to compare and prioritize possible use cases, rather than beginning with a product selection. Microsoft's business-envisioning guidance is written for ISVs and larger customer scenarios, but the discipline transfers well to a small company.

NIST's AI Risk Management Framework adds an important constraint: the business value or context of use must be defined, risk tolerance is contextual, benefits and costs should be examined, and the initial mapping work should inform a go or no-go decision. NIST also says viable non-AI alternatives should be considered when managing risk and benefit. The NIST AI RMF Core is voluntary guidance, not a small-business scorecard. I use it here as a source of questions, not as permission to turn a complex decision into a magic total.

Build the candidate list from work that already exists

Create candidates from recurring work, visible bottlenecks, and decisions people already own. Do not begin by browsing an AI marketplace and asking where each tool might fit.

The difference sounds small. It changes the quality of the list.

“Use an AI sales assistant” is a tool-shaped idea. “Reduce the time between an inbound enquiry and a reviewed first response” is a work-shaped candidate. The second description gives you a process, an owner, an output, and a possible measure. It can be compared with “reduce the time to turn a meeting into assigned actions” because both describe work that moves through the business.

In my Orange workshop, the useful starting point was the work attendees already did, not a tour of agents. That statement is bounded to Marius Manolachi's locked F-orange fact: he led a ChatGPT workshop at Orange. It is not a claim about a broad enterprise transformation. The teaching judgment is simple: people can judge an AI opportunity more clearly when they can point to the current work, its annoying parts, and the person who carries the result.

Four sources of candidate ideas

Use four short conversations or observations to create the first list.

1. Repeated manual work. Ask where a person copies, reformats, compares, classifies, summarizes, or drafts the same kind of material. Repetition is not enough to justify AI, but it makes the work visible.
2. A bottleneck with a named owner. Ask where work waits for a person, a decision, or a missing piece of information. A queue can be a better candidate than an isolated task because improving it may change the whole flow.
3. A quality problem people already notice. Ask where errors, omissions, inconsistent reviews, or missed follow-ups are expensive. Be careful: AI may add a new error source instead of solving the old one.
4. A learning or growth opportunity. Ask whether the business could serve customers, produce insight, or create a new experience it cannot currently afford to staff. Keep these candidates in the portfolio, but do not let strategic excitement excuse vague evidence.

Interview the people doing the work. A founder may describe “automating onboarding” while the person doing onboarding knows that the real problem is incomplete information from sales. An operator may request a chatbot while customers actually need a clearer pricing page. The candidate should describe the work as it is, not as the requested technology imagines it.

Write a candidate as a result, not a feature

Use this sentence pattern:

Improve [business result] in [workflow] for [person or customer], while keeping [human decision or control] with [owner].

Examples:

• Reduce the time to prepare a reviewed proposal for a sales owner, while the owner approves pricing and commitments.
• Turn weekly operating notes into a checked action list for the operations lead, while the lead confirms owners and due dates.
• Classify incoming service requests for a support owner, while sensitive, ambiguous, or high-impact cases stay with a person.
• Compare invoice fields against a known purchase order for a finance owner, while exceptions and payment approval remain human decisions.

These examples are candidate shapes, not claims that they will work in every company. Each gives the team something to test. Each also makes the action boundary visible.

What not to include in the first list

Do not treat every AI-related ambition as one candidate. Break it down or defer it.

“Transform customer experience with AI” is a direction. It might later produce three candidates: classify incoming requests, draft a reviewed response, and identify recurring product questions. “Build an autonomous back office” is a program. It might contain document intake, exception handling, vendor communication, and approval routing. Ranking the program as one item hides the different risks and evidence requirements.

Also keep “use ChatGPT for everything” out of the portfolio. It names neither a business result nor a reviewable workflow.

The list does not need to be complete. It needs to be comparable. Ten clearly written candidates are more useful than thirty slogans.

Apply three checks before you score anything

Do not assign points to a candidate until you can answer three questions: who owns the result, how will you check it, and what may the system do if it is wrong or uncertain?

These checks are the article's original contribution. They protect the score from rewarding an idea that cannot be operated.

Check one: does a real person own the outcome?

Name the person who will decide whether the work improved and who will handle a failure. “The team” is not an owner. “The founder” is sometimes a stand-in for a decision nobody has designed yet.

The owner does not need to build the system. The owner needs to answer questions such as:

• What does the current workflow produce?
• What must remain true after an AI step is introduced?
• Who reviews the output?
• What happens when the system is uncertain?
• What would make us pause the pilot?
• Which measure matters enough to justify the work?

If nobody can answer these questions, the candidate is not ready to rank. The missing task is to find the owner or remove the candidate from the active queue.

This is not bureaucratic overhead. It is how a small business avoids assigning a system to a group that will discover, after launch, that the result belongs to nobody. NIST's Core asks organizations to document roles, responsibilities, business context, risk tolerance, and human oversight. Its governance and mapping guidance supports this owner-first reading, although NIST does not prescribe the candidate card used here.

Check two: can the outcome be checked?

An output is checkable when a person, rule, comparison, or defined observation can tell whether it is acceptable for the intended use.

“It sounds good” is not a sufficient check for a customer promise, financial record, compliance review, or operational decision. It may be part of a review for an early draft, but it does not define the whole review.

Ask what evidence would allow the owner to say pass, edit, or reject. The evidence might be:

• a comparison with a source document;
• a field-level match against a known record;
• a short rubric for completeness and factual accuracy;
• a human confirmation before an external action;
• a time or queue measure paired with a quality check;
• a record of which cases the system could not handle;
• a user action that shows whether the result helped.

The exact measure depends on the work. NIST says AI systems should be tested before deployment and regularly while operating, with performance or assurance criteria measured for conditions similar to deployment. Microsoft likewise asks teams to define success and measurable key results before comparing use cases. These sources support the need for a check. They do not support any universal threshold such as 90% accuracy or a fixed payback period.

If the owner cannot describe a review, the candidate goes to Prepare first. The next task might be to collect representative examples, define a rubric, or clarify what the output is for.

Check three: is the action boundary safe?

Write the highest-consequence action the AI system might take, then decide whether the first pilot can avoid that action.

The action surface may be narrower than the use case description suggests:

Candidate description	Safer first action	Action to keep out of the first pilot
AI customer support	classify, retrieve, or draft for review	send a consequential answer without approval
AI invoice processing	extract fields and flag mismatches	approve or release payment automatically
AI hiring support	structure notes or summarize candidate-provided information	make or rank a hiring decision without specialist review
AI sales assistance	prepare a researched draft or next-step list	promise terms, discounts, or delivery dates
AI operations reporting	assemble a source-linked briefing	trigger a major operational change without review

“Safe” does not mean risk-free. It means the business has bounded what the system may read, write, recommend, and change, and has a human or deterministic control for the consequences it cannot accept. The boundary includes data as well as actions. A low-impact draft may still be unsafe if it exposes confidential information to an unapproved tool.

NIST describes human oversight, knowledge limits, intended use, potential costs, and organizational risk tolerance as part of the context that informs a go or no-go decision. The U.S. Small Business Administration gives small-business guidance a practical shape: start small, test whether the tool adds value, and have another person review AI products when using free tools or software. The SBA guidance for AI in small business is general, but its sequence is sensible for a first pilot.

If an action cannot be safely bounded, do not score the candidate higher because it would save more time. Redesign the candidate around a recommendation, draft, classification, or read-only result, or reject it.

The three checks are vetoes, not weighted dimensions

Do not give “no owner” one point and let a large theoretical benefit compensate for it. A veto is different from a low score.

This distinction matters because the problems are different:

• A low recurrence score means the work may not justify attention.
• A low feasibility score means you may need better data or integration.
• A missing owner means the business has no decision path.
• A missing check means the business cannot tell whether the output helped.
• An unsafe action boundary means the first version could create a consequence the team has not agreed to carry.

The remedy for a low score is comparison. The remedy for a failed veto is preparation, redesign, or rejection.

Use a candidate card before you use a score

Write one short card for each surviving idea. The card is the smallest unit of evidence in your portfolio. It makes assumptions visible before the team debates arithmetic.

Use these fields:

Field	What to write	Why it matters
Candidate	One sentence describing the work result	Prevents tool-led wording.
Current workflow	Trigger, inputs, major steps, output, and owner	Shows what would actually change.
Business outcome	Time, quality, revenue protection, customer experience, or learning objective	Gives the candidate a reason to exist.
Affected people	Operator, reviewer, customer, or other person affected by the result	Surfaces demand and change resistance.
Recurrence	How often the work occurs and when the next occurrence is expected	Separates a real workflow from a one-off annoyance.
Evidence available	Examples, records, rubrics, baseline measures, or user feedback	Shows whether the result can be checked.
Data boundary	What the system may use, what it may not use, and where data lives	Makes privacy and access questions concrete.
Action surface	Read, draft, classify, recommend, write, send, or change a record	Defines the first safe capability.
Human owner	One person accountable for outcome and escalation	Prevents orphaned automation.
Smallest pilot	The narrowest slice that can produce evidence	Controls scope and time.
Stop condition	What would make the team pause, narrow, or reject the pilot	Keeps the pilot reversible.
Next evidence	The single missing fact that would change the decision	Creates a learning loop.

Do not fill every field with a guess. Mark an unknown as unknown. An explicit unknown is useful because it tells you why a candidate should not yet win.

Example of a weak card

Candidate: AI assistant for customer service.

Value: Save time and improve customer satisfaction.

Feasibility: High because tools exist.

This card is too vague to rank. It does not say which service work changes, what the assistant may do, how satisfaction will be observed, or who reviews the result.

Example of a usable card

Candidate: Classify incoming service requests by topic and urgency, retrieve the relevant internal guidance, and draft a suggested next response for a support owner to review.

Current workflow: A support owner reads an incoming request, identifies its topic, searches internal guidance, drafts a response, and decides whether to escalate.

Business outcome: Shorten the time to a reviewed first response without increasing incorrect routing or unsupported promises.

Evidence available: A sample of past requests, the guidance used by the support owner, examples of correct escalation, and a review checklist.

Action surface: Read and draft only. No automatic sending, refunds, account changes, or commitment to a delivery date.

Owner: Support lead.

Smallest pilot: A review-only draft on one request category, with every draft compared against the source guidance before it is used.

Stop condition: Pause if the system invents policy, misses an escalation class, or makes the review slower than the current workflow.

Now the candidate can be scored. More importantly, the business can see what it is actually agreeing to test.

Score the eligible candidates on six dimensions

Score only candidates that pass the three checks. Use a 0-3 scale with written evidence beside each number. The number is a way to expose trade-offs, not a prediction of return.

The six dimensions are outcome value, recurrence, evidence quality, feasibility, downside containment, and learning value. Microsoft’s business, experience, and technology categories support the broad shape of this comparison. NIST supports examining business value, costs, impacts, risk tolerance, human oversight, and available resources. The specific six-part rubric is my editorial artifact, not an official framework.

Score	Outcome value	Recurrence	Evidence quality	Feasibility	Downside containment	Learning value
0	No agreed benefit	Rare or unclear	No examples or review method	Major unknowns	Consequences cannot be bounded	Teaches little that transfers
1	Nice to have or indirect	Occasional	Some anecdotes, weak baseline	Significant missing data, access, or workflow detail	Narrow action is possible but controls are immature	Some local learning
2	Clear operational, customer, or strategic benefit	Regular enough to observe	Representative examples and a plausible check	A small pilot can be assembled with known gaps	Read-only, draft, recommendation, or approval-gated path is credible	Builds a reusable capability
3	Important result tied to a current priority	Frequent with visible queue or cost	Baseline, cases, expected result, and reviewer are available	Pilot dependencies are understood and affordable for the team	Failure can be detected, contained, reversed, and escalated	Teaches a method or integration useful elsewhere

The table intentionally puts evidence and containment beside value. A candidate with a 3 for value and a 0 for evidence is not a strong candidate. It is an exciting unknown.

Outcome value is not the same as theoretical upside

Score the result the business can explain now. Do not award a 3 because the market for a future product might be enormous.

A high outcome-value score could come from reducing a current bottleneck, protecting a customer relationship, improving a repeated decision, or creating a capability tied to a stated business priority. It does not require immediate revenue. Internal work can matter if the freed capacity has a clear use.

Ask:

• Which business priority does this support?
• What changes for a customer, operator, or owner if it works?
• What is the cost of leaving the current problem alone?
• Is the value visible to the person who must adopt the change?
• What would count as useful even if the pilot never becomes fully autonomous?

Microsoft's guidance notes that value can include internal productivity and cost-effectiveness, not only revenue. That is helpful for small businesses, where a founder or small team may care about response time, fewer missed follow-ups, or more time for customer work. State the value in the language of the business, not in generic “AI transformation” language.

Recurrence measures opportunity to learn

Frequency matters for two reasons. Repeated work can accumulate value, and it gives the team more opportunities to learn whether the method works.

Do not confuse frequency with importance. A rare task can be worth improving if each occurrence is consequential. A frequent task can be a poor candidate if the output cannot be checked or the downside is unacceptable.

Use a simple description rather than false precision:

• 0: no reliable occurrence pattern;
• 1: occasional or seasonal;
• 2: recurring and observable;
• 3: frequent enough to produce feedback during a bounded pilot.

For a seasonal business, “frequent” may mean a concentrated period rather than a weekly task. Write the actual rhythm on the card.

Evidence quality is the difference between a pilot and a demo

Evidence quality asks whether the business can inspect the problem and judge the result. It is not a measure of model sophistication.

Evidence can include a baseline, representative normal cases, edge cases, failure cases, a source of truth, a reviewer, and an explicit rubric. You do not need a perfect historical dataset before starting. You do need enough material to know what you are testing and what a bad result looks like.

NIST's Measure function says AI systems should be tested before deployment and regularly in operation, and that measurements should be documented. That does not mean every first pilot needs a large benchmark. It means the team should not confuse a smooth demonstration with evidence that the intended work is reliable.

If evidence quality is 0 or 1, the candidate can still remain in the portfolio. It should move to Prepare first with a task such as collecting examples, defining a review rubric, or measuring the current workflow.

Feasibility includes people and workflow, not only APIs

A use case is feasible when the team can assemble the smallest pilot with the data, access, integration, reviewer time, and change capacity it actually has.

Ask:

• Can the chosen tool receive the allowed input safely?
• Can the team retrieve the source of truth or connect the required system?
• Does someone have time to review the result?
• Is there a way to pause or undo the action?
• Can the team observe what happened when the output is wrong?
• Does the pilot fit the team's current learning capacity?

The EU publication on AI in micro, small, and medium-sized enterprises points to skills, finance, infrastructure, data availability, interoperability, cybersecurity, and bias awareness as practical conditions for AI uptake. Those conditions explain why a technically possible idea may still be a poor first project for a small business. The EU publication's summary is from 2021, so treat it as durable context rather than a current market statistic.

Downside containment is a first-order dimension

Downside containment asks how bad a wrong result could be and how quickly the business could detect, stop, correct, and learn from it.

Score the first pilot's action, not the most ambitious future state. A read-only classification may have a different risk from a workflow that sends a customer message. A draft may be containable if a reviewer sees every output. A recommendation about hiring, credit, health, legal position, or access to essential services deserves much stronger scrutiny, and in some contexts should not be automated as a consequential decision.

NIST emphasizes that risk tolerance is use-case and context specific. It also says treatment should consider impact, likelihood, and available resources, and that non-AI alternatives should remain in the comparison. That is why a high theoretical value cannot erase a weak control path.

Learning value should be practical, not fashionable

Learning value is what the team will know after a small pilot that it does not know today. The lesson might be about document handling, review design, retrieval, a system connection, customer behavior, or whether the task should be automated at all.

This dimension helps a small business avoid two opposite errors. It stops the team from choosing a trivial experiment that teaches nothing, and it stops the team from betting the company on a complex strategic system before learning the underlying workflow.

A candidate has high learning value when the same artifact, integration, reviewer habit, or evaluation method will help with a later candidate. This does not mean every first pilot must become a platform. It means the team should know what capability it is building besides the immediate output.

Read the score as a conversation, not a forecast

Add the six dimension scores only after writing the evidence beside them. Then inspect the reasons for disagreement before you sort the rows.

If you want a simple total, add the six values for a maximum of 18. Use the result to make the portfolio easier to discuss. Do not present it as a probability of success, a guaranteed return, or a universal threshold.

Total, used cautiously	Meaning	Required follow-up
0-6	Weak or poorly evidenced candidate	Put it in preparation, observe the work, or reject it.
7-11	Plausible candidate with important gaps	Name the missing evidence and compare its cost with other candidates.
12-15	Strong candidate for a bounded pilot	Confirm sequence, owner capacity, and action boundary before starting.
16-18	Strong on the stated assumptions	Check for hidden dependencies, high-impact consequences, and whether ordinary automation is simpler.

These bands are a reading aid I created for this article, not a validated scale. A candidate with a total of 16 can still fail the pre-score rule, need legal review, or depend on a system the business cannot safely access. A candidate with a total of 10 can become the better first experiment if it shares infrastructure with a strategic project and produces important evidence quickly.

Do not weight every business the same

A small company may want to weight outcome value more heavily during a cash constraint. A regulated team may put more attention on containment and review. A product business may value strategic learning. A services business may care more about repeatable delivery and customer response time.

Make the priorities explicit before scoring. Use a note such as:

For this quarter, we will favor candidates that improve a current customer or cash-flow bottleneck, can be reviewed by an existing owner, and can produce evidence within the team's available capacity.

Then check whether the score reflects that statement. If you change the weights after seeing the winner, record why. Changing the weights is not dishonest. Hiding the change is.

Use a veto when the score hides the risk

Even eligible candidates need a second look for hard constraints. Stop the ranking process if any of these are true:

• the action affects a person's access to employment, credit, essential services, insurance, health, safety, or legal rights without specialist oversight;
• the data boundary is unknown or cannot be enforced;
• the output cannot be checked before the consequence occurs;
• the named owner cannot provide review capacity during the pilot;
• the candidate depends on a system or vendor contract the business cannot inspect or change;
• a deterministic or manual path would be clearer and safer for the same result;
• the business cannot say what would cause it to pause or reverse the pilot.

These are not claims that every such use is prohibited in every jurisdiction. They are decision triggers for additional review. NIST's guidance is deliberately context-specific, and the legal status of a use case depends on the business, location, data, affected people, and current law. Treat high-impact work as a separate review path, not as a normal item on a marketing automation spreadsheet.

A worked portfolio: why the biggest idea is not always first

Consider a fictional twelve-person professional services business. The following example is hypothetical. It is not a Marius client, and the scores are invented to show how the artifact works.

The business has six suggestions:

1. A customer-facing chatbot that answers questions and qualifies leads.
2. A tool that extracts invoice fields and flags exceptions for a finance owner.
3. A system that turns meeting notes into proposed actions and owners.
4. An assistant that drafts proposals from approved service descriptions and prior examples.
5. An automated hiring screener that ranks applicants.
6. A forecasting system that predicts next quarter's revenue from a small, inconsistent dataset.

First apply the three checks

Candidate	Named owner	Checkable outcome	Safe first action	Status before score
Customer chatbot	Sales lead	Partly, if answers are source-linked and reviewed	Draft or classify, not send commitments	Rank after narrowing the scope
Invoice extraction	Finance lead	Yes, by comparing fields with records and reviewing exceptions	Extract and flag only	Rank now
Meeting action drafts	Operations lead	Yes, by checking people, decisions, and due dates	Draft for owner confirmation	Rank now
Proposal drafting	Sales or delivery lead	Yes, against approved service language and a review list	Draft only	Rank now
Hiring screener	People owner	The final decision is not a safe automated action	Structure notes or summarize with specialist review	Redesign before ranking
Revenue forecasting	Finance or founder	Unclear with inconsistent historical data	Read-only analysis with explicit uncertainty	Prepare evidence first

The hiring idea may sound valuable, but its original description fails the action-boundary check. It does not get rescued by a high theoretical time saving. The revenue forecasting idea has a real owner and a possible result, but it needs a baseline and a better understanding of the data before the team can claim that a pilot is checkable.

Score the candidates that remain eligible

The following table is fictional. It is a demonstration of the method, not evidence about what usually works.

Candidate	Value	Recurrence	Evidence	Feasibility	Containment	Learning	Total	Initial reading
Invoice extraction and exception flags	2	3	3	2	3	2	15	Strong first pilot
Meeting action drafts	2	3	2	3	3	2	15	Strong first pilot
Proposal drafting	3	2	2	2	2	3	14	Strategic candidate, needs review design
Narrow customer FAQ drafting	2	2	2	2	2	2	12	Pilot after source and escalation work

The tie between invoice extraction and meeting action drafts cannot be resolved by the total. That is useful. The team now has to compare the reasons:

• The invoice candidate has stronger evidence because records and expected fields exist. Its dependency is access to the accounting or document system and a reviewer who can inspect exceptions.
• The meeting candidate may be easier to assemble, but names, decisions, and actions can be ambiguous. Its reviewer needs a clear definition of what the summary may assert and what it must preserve as unresolved.
• The proposal candidate has a higher strategic value score, but the business needs to protect pricing, terms, and claims. Its first version should stay inside approved service language.
• The customer FAQ candidate needs a trusted source set and an escalation path. A general chatbot is not the first candidate. A narrow, source-linked draft for review may be.

The small business might choose invoice extraction first because it offers a clear comparison against existing records and teaches a reusable document-review pattern. It might choose meeting action drafts if the operations owner has an immediate, reviewable queue and the business can gather examples quickly. Both are defensible. The point is not that invoice processing is universally better. The point is that the artifact reveals why the decision changes.

What would change the order?

Write the next evidence beside the decision:

Candidate	Missing evidence	Evidence that could move it up	Evidence that could move it down
Invoice extraction	Access pattern and exception volume	A safe read-only export and a clear exception reviewer	Sensitive data cannot be handled within the allowed tool boundary
Meeting action drafts	Agreement on what counts as a correct action	A short sample with human-reviewed decisions and owners	Review takes longer than writing the actions manually
Proposal drafting	Approved source material and claim boundary	A reusable library with clear reviewer ownership	Drafts introduce unsupported commitments or pricing errors
Customer FAQ drafting	Source freshness and escalation rules	A small category with stable answers and visible handoff	Questions require judgment the source set cannot support
Revenue forecasting	Baseline and data quality	Consistent historical records and a decision that uses the forecast	Forecast uncertainty is too large for the decision it would influence

A candidate is not dead because it is not first. It is healthier when the team knows what would change the order.

Separate ranking from sequencing

Ranking asks, “Which candidate looks strongest under the current assumptions?” Sequencing asks, “Which candidate should this small team do next, given dependencies, capacity, reversibility, and learning?”

Those are different questions. A high-value candidate can be second because it depends on an artifact the first pilot will create. A modest candidate can be first because it gives the team a fast way to learn a review method without exposing customers to an uncontrolled action.

Use a second table after the score:

Sequence question	If the answer is yes	If the answer is no
Can the team run the first slice with existing people?	Keep the candidate in the active sequence.	Find an owner or reduce scope.
Can the pilot stay read-only, draft-only, or approval-gated?	Treat reversibility as a sequencing advantage.	Add controls or move the candidate to specialist review.
Does the pilot create an artifact or capability needed by another candidate?	Consider it an enabling first step.	Compare it on direct value and learning value.
Can the team observe enough cases within the pilot window?	Define a small evidence review.	Observe longer or choose a more frequent task.
Does the candidate depend on a system change or procurement decision?	Confirm the dependency owner and date.	Do not pretend the candidate is ready because a model call works.
Is the current workflow stable enough to compare?	Establish a baseline and pilot.	Repair or document the workflow before automating it.

The first pilot should be reversible

Reversibility is not the same as low value. A pilot can matter while keeping the existing workflow in charge. Prefer a draft, classification, extraction, source-linked recommendation, or proposed action list that a person confirms. The first version should make the pilot visible: a reviewer needs to know what came from the system, which sources were used, what remains uncertain, and what action is still theirs. The SBA's “start small and test value” guidance fits this approach.

Give the pilot a capacity budget

Small businesses often budget software costs and forget review costs. The first pilot needs time for setup, examples, reviewer training, corrections, and a decision meeting.

Write down:

• the number of people who will participate;
• the expected review time per case;
• the maximum number of cases in the first test;
• the time the owner can protect each week;
• the date of the stop-or-continue decision;
• the work that will not be done while the pilot runs.

This is not a claim that there is a universal number of cases or hours. It is a way to stop “small pilot” from meaning “unpriced extra work.” If the business cannot protect review capacity, the candidate is not feasible no matter how attractive the tool is.

Decide whether the winner needs AI at all

After prioritizing the opportunity, compare AI with ordinary software, a fixed workflow, a search or retrieval step, or a human process improvement. The top candidate is a business problem, not a commitment to use a language model.

The existing guide When Should You Use an AI Agent? covers the later architecture decision in more depth. The short version is:

If the work is mostly...	Start by considering...
Stable, explicit, and rule-shaped	Ordinary automation or deterministic software
A fixed sequence with a small language step	A bounded workflow with an AI component
Search across trusted internal information	Retrieval with source visibility and a review boundary
Open-ended, tool-using, and difficult to script	A more flexible agent design, only with stronger controls
High-impact or difficult to verify	Human-led work, specialist review, or a redesigned lower-risk task

This is an analysis decision, not a source claim about a particular vendor. NIST's AI RMF explicitly keeps viable non-AI alternatives in the benefit and risk conversation. That is a useful guardrail because AI can make a badly defined process faster without making the result better.

The tool should follow the action boundary

If the first safe action is “draft a response,” you do not need to start with an autonomous agent that can change a customer record. If the first action is “extract a field and flag a mismatch,” you may not need a general chat interface. If the required action is a stable rule, a normal validation script may be more observable and reliable.

Marius Manolachi is building TryUncle, an AI agent that watches a screen and annotates it live. The locked F-tryuncle fact makes one product constraint clear: latency and human approval are part of the product, not details to add after the demo. That observation transfers to prioritization. A candidate that looks attractive on paper may move later if the actual user needs timely, precise, and safe assistance that the team cannot yet observe or approve.

Do not choose a more autonomous architecture because it sounds like a bigger AI opportunity. Choose the smallest capability that can produce evidence about the business problem.

Design the first pilot around evidence

The pilot should be a decision instrument. Its output is not just a generated artifact. It is evidence about whether the candidate deserves more investment.

Define the baseline before the AI step

Record enough about the current workflow to make a comparison possible. The baseline might include elapsed time, queue age, number of handoffs, correction effort, response delay, missed items, customer feedback, or another outcome that the owner already understands.

Do not invent a baseline because the article needs a number. If the business does not track the metric, say so and decide whether a light observation is worth the effort. A baseline can be qualitative when the first question is whether the workflow is understandable and reviewable, but the team should explain what it observed.

Write:

• what enters the workflow;
• what the current owner does;
• what output counts as complete;
• where the work waits or fails;
• what correction looks like;
• what the current process costs in time or attention;
• what the pilot is allowed to change.

This does not turn the pilot into the separate question of whether a whole business process is ready for automation. It keeps prioritization honest by ensuring the chosen candidate has something concrete to compare.

Use representative cases, not only attractive cases

Collect normal cases, edge cases, and failure cases. Include the examples that make the owner uncomfortable. If the system is only shown easy material, the team learns that a demo can look good, not whether the use case is useful.

For each case, define what the system should do:

Case type	Expected behavior
Normal and well-specified	Produce the bounded output with the required fields or source references.
Incomplete input	Ask for the missing information, flag the case, or stop. Do not fill a consequential gap with an invented assumption.
Ambiguous request	Route for clarification or human review.
Sensitive or restricted data	Refuse the path, use an approved environment, or follow the documented escalation.
Out-of-scope request	State the limit and return control to the owner.
Conflicting source material	Surface the conflict instead of selecting silently.

These expected behaviors are recommendations for a pilot contract, not universal model capabilities. They make the result easier to review and reduce the chance that a fluent output is mistaken for a successful outcome.

Decide what would stop the pilot

A stop condition should be visible before the first run. Examples:

• the owner cannot review outputs within the planned time;
• the system exposes data outside the agreed boundary;
• it changes a record or sends a message outside the approved action surface;
• it produces unsupported claims that the review process does not catch;
• it increases correction work instead of reducing it;
• users cannot tell when the result is a draft or recommendation;
• the workflow changes so much that the baseline no longer describes the comparison.

The stop condition is not an admission that the pilot will fail. It is a promise that the business will not keep expanding a candidate simply because effort has already been spent.

End with a decision packet

At the end of the pilot, keep a short packet:

1. Candidate card and original assumptions.
2. Baseline and pilot scope.
3. Cases used, including failures and exclusions.
4. Outputs, corrections, and review notes.
5. Changes in time, quality, delay, or another chosen outcome, with the measurement method stated.
6. Data, permission, and action-boundary findings.
7. Owner recommendation: stop, narrow, repeat, expand, or replace with ordinary automation.
8. New evidence for the next portfolio review.

This packet is where a use-case list becomes organizational learning. It also gives the next candidate a more informed starting point without pretending that a result from one workflow proves another workflow will work.

Keep a not-yet queue instead of a discard pile

Deferred candidates should carry a next evidence task. Otherwise the portfolio is just a recurring argument about which idea sounds exciting today.

Use these statuses:

Status	Use it when	Example next task
Observe	The problem may matter, but frequency, variation, or cost is unclear.	Sample the workflow for two weeks and record where work waits.
Define	The business outcome or owner is unclear.	Interview the person who carries the result and write a one-sentence candidate.
Evidence	The result or quality bar cannot yet be checked.	Collect normal and failure cases and write a review rubric.
Boundary	Data access, permissions, or action risk is unresolved.	Specify allowed input, forbidden output, human approval, and rollback.
Dependency	The idea depends on a system change, source library, or skill the team lacks.	Name the dependency owner and decide whether the first pilot can avoid it.
Ready	The three checks pass and the pilot can be run within capacity.	Compare the candidate with the eligible portfolio.
Rejected	Value is weak, downside is not containable, or a simpler path wins.	Record the reason so the idea does not return unchanged.

The status is a decision about the candidate's current evidence, not a judgment about the people who proposed it. A good idea can be “Evidence” today and “Ready” later. A bad idea can remain “Boundary” until the business decides that the consequence is not worth carrying.

Review the queue on a fixed rhythm

Pick a review rhythm that matches the business. A monthly review may suit a small company with few candidates. A shorter cycle may make sense during a product launch or a concentrated operational season.

At each review:

• remove candidates that no longer connect to a current priority;
• update the next evidence task;
• record any change in data, owner capacity, tool availability, or risk;
• rescore only when the underlying evidence changed;
• compare the active pilot with the queue instead of letting it run indefinitely;
• promote one candidate only when the owner and review capacity are real.

Do not keep rescoring a candidate with no new evidence. The number will move because people are tired of the old discussion, not because the business learned something.

Common prioritization mistakes and their repairs

Prioritization fails in predictable ways. The repair is usually a better question, not a more elaborate spreadsheet.

Mistake: choosing the most impressive demo

A demo proves that a tool can produce one visible interaction in one prepared context. It does not prove that the business has a valuable workflow, the right data, a reviewer, or a safe action path.

Repair: rewrite the demo as a candidate card. Name the current problem, outcome, owner, review method, and smallest reversible action. If the vendor cannot help you answer those questions, the demo is inspiration, not a priority.

Mistake: choosing the loudest internal champion

Champions are useful because they create momentum. They are not a substitute for the person who owns the result or for users who must adopt the change.

Repair: ask the champion to bring the outcome owner into the card review. Score the work, not the seniority or enthusiasm of the proposer.

Mistake: treating every automation as an AI use case

Some tasks need a rule, a form, a better source of truth, or a workflow change. An AI layer may add variability where a deterministic path would be easier to check.

Repair: include a non-AI alternative on every card. The alternative can be “fix the source document,” “add a validation rule,” “change the queue,” or “keep the human process.”

Mistake: using ROI as a permission slip

A large estimated saving can conceal review work, data preparation, correction costs, adoption friction, or an unacceptable consequence. A spreadsheet can be precise while the assumptions are not.

Repair: use expected value only after describing how the outcome will be observed. For an agent-specific economics calculation, see How to Calculate ROI for an AI Agent, but do not use an ROI estimate to bypass ownership, evidence, or safety checks.

Mistake: giving all dimensions equal weight without saying so

Equal weighting looks neutral. It may quietly conflict with the business's current priority. A company trying to protect cash flow should say so. A company learning a new capability should say so. A regulated business should state its review threshold.

Repair: write the quarter's priority statement before scoring and record any deliberate weighting. Keep the raw scores visible so another person can challenge the choice.

Mistake: running too many pilots

Several small pilots can sound prudent. In a small business, they often compete for the same reviewer, technical owner, and leadership attention. The result is a set of half-observed experiments with no decision packet.

Repair: choose one primary pilot and a short not-yet queue. Start a second pilot only when it shares an owner, evidence method, integration, or learning objective with the first, or when its independent value clearly justifies the capacity.

Mistake: keeping the highest-scoring candidate forever

The score can become a reason to avoid starting. Teams keep refining the spreadsheet because launching the pilot creates accountability.

Repair: add a decision date and a smallest action to the candidate card. If the checks pass and the capacity exists, run the bounded test. If they do not, move the candidate to its missing evidence status.

Mistake: treating “not yet” as failure

Some ideas are not ready because the business lacks a baseline, examples, owner, or safe boundary. That is valuable information.

Repair: assign one preparation task and a review date. A not-yet queue should make future progress easier, not preserve a list of guilt.

A practical 30-day prioritization sequence

If the business needs a concrete starting plan, use four weeks. Adjust the pace to the team's actual capacity. The schedule is a procedure, not a guarantee that a pilot will be ready in thirty days.

Week one: collect and rewrite candidates

Talk to the people doing recurring work. Collect no more than the number of candidates the group can explain. For each one, write the work-shaped sentence, current workflow, business outcome, affected people, and likely owner.

At the end of the week, remove tool-only ideas and combine duplicates. Do not score yet. Ask whether a person can describe the current work without showing a product demo.

Week two: run the three checks

Meet with each outcome owner. Decide whether the result can be checked and whether the first action boundary is safe. For every failed check, assign one status: Define, Evidence, Boundary, Dependency, or Observe.

Choose the two or three candidates most likely to become eligible. Collect examples, source material, and a basic baseline only for those candidates. You do not need to do full discovery on every idea before choosing where to learn.

Week three: score and sequence

Score the eligible candidates with the 0-3 rubric. Write evidence beside every score. Record disagreements rather than averaging them away.

Then run the sequence table. Check review capacity, reversibility, dependencies, learning value, and the non-AI alternative. Select one primary pilot and define its stop condition. If no candidate passes, the outcome is not “try harder with AI.” The outcome is a preparation queue.

Week four: run the smallest evidence-producing test

Keep the first action read-only, draft-only, or approval-gated unless the business has a clear reason and stronger controls. Use representative cases. Record corrections and failures. End with a stop, narrow, repeat, expand, or replace decision.

Put the decision packet back into the portfolio. A pilot is complete when the business has learned enough to make the next decision, not when a tool has produced a polished output.

Copyable candidate worksheet

Use the following in a shared document. Keep the fields visible to the people who own the work.

Candidate:
Current workflow:
Business outcome:
Why this matters now:
Affected people:
Named owner:
Expected recurrence:
Current baseline or observation:
Examples and source of truth:
How the result will be checked:
Allowed data:
Restricted or prohibited data:
First action surface:
Human approval point:
Smallest reversible pilot:
Stop condition:
Non-AI alternative:
Missing evidence:
Status: Observe / Define / Evidence / Boundary / Dependency / Ready / Rejected

Pre-score checks:
[ ] A named owner accepts responsibility.
[ ] The outcome can be checked.
[ ] The first action boundary is safe and enforceable.

Score from 0 to 3:
Outcome value:
Recurrence:
Evidence quality:
Feasibility:
Downside containment:
Learning value:

Sequence notes:
Dependencies:
Review capacity:
Reversibility:
Shared learning with other candidates:
Decision and date:

The worksheet is deliberately plain. A complicated tool cannot compensate for a missing owner or an undefined result.

What this method still does not know

The rubric does not tell you whether a model will perform well. It tells you whether the business has a candidate that deserves a bounded test under stated assumptions.

It also does not tell you the correct legal treatment of a use case. Privacy, employment, financial, health, consumer-protection, accessibility, and sector rules depend on context and location. A small-business owner should get qualified advice when a candidate affects people's rights, access, safety, money, or sensitive data. The NIST AI RMF is voluntary guidance and explicitly does not prescribe one risk tolerance for every organization or use case.

The method does not prove that a first pilot will produce a positive return. It keeps the decision honest by asking for a baseline, a reviewer, and a stop condition. It also does not imply that a small business needs an enterprise governance program before experimenting. The NIST AI RMF Playbook says organizations may borrow the suggestions that fit their needs. Use the amount of process that helps the business make a better decision, then keep the evidence.

Finally, the method cannot replace the judgment of the people who do the work. A spreadsheet may show that an idea is feasible while the person who serves the customer knows that the proposed change would damage trust. That is why candidate cards include affected people, action boundaries, and the owner beside the score.

The next step is a decision, not another brainstorm

Choose one candidate that passes the three checks, has a clear owner, and can be tested without giving the system more authority than the team can review. Write the baseline and the stop condition before you choose a tool.

If you have a real portfolio and want help turning it into a capability your own team can build and operate, Marius Manolachi offers AI consulting and AI tutoring through the AI learning and consulting page. The article's decision is complete without that next step. The useful work is to make one candidate clear enough to test and one future candidate easier to judge.