How to Find and Prioritize AI Opportunities in Your Company

For a company handling recurring digital work, an AI opportunity begins with a specific task and a business result worth improving. The AI-supported approach must improve that result enough to justify its cost, risk, and oversight. Name the problem and desired outcome before choosing a tool.

Slow responses to customer inquiries describe a business problem. A chatbot is one possible response. Better routing rules, staffing changes, or easier access to existing answers may solve the problem more effectively. The right choice depends on why responses are slow and what needs to improve.

Define the outcome in practical terms: less staff effort, fewer errors, faster service, better answers, or a service the company does not currently provide. Choose a measure that matches the outcome. For faster service, track response time or time to resolution; for less effort, measure the work required to handle an inquiry from start to finish.

Adopting AI, or producing more drafts, summaries, and messages, does not show business value by itself. Those outputs matter only when they improve a valued outcome. AI can also shift work instead of reducing it. An employee who spends less time drafting may spend more time checking and correcting the output.

The proposed approach must also fit the task. Authorized users need access to the right information, while permissions must limit what the tool and its users can view or do. Reviewers need time and authority to reject poor results. A named owner must remain accountable for the outcome and decide whether it meets the required standard.

Once the problem is clear, identify the recurring work that creates measurable friction.

Find work worth examining

Service delays, growing backlogs, repeated corrections, error reports, and time spent searching across documents or systems all point to work worth examining.

Ask the people doing the work where they repeatedly read, summarize, draft, classify, compare, or transfer information. Compare their accounts with observation, process records, and performance measures. Interviews reveal workarounds. Records show frequency and delays. Observation captures routine steps people may overlook. Each source misses some exceptions and hidden effort.

Look beyond office administration to tasks in customer service, employee support, sales, operations, quality, and compliance. These tasks affect customers, revenue, cost, quality, or regulatory obligations. For each candidate task, note who owns it and who receives its output. Include how often it occurs and what happens when it goes wrong.

Make it safe for employees to report friction and share experiments. People may hold back if a faster method appears likely to create more work or threaten job security. Explain how managers will use the findings, and ask employees to identify both problems and workable improvements. Research on psychological safety and learning behavior in work teams found that people report errors and seek help more readily when they believe it is safe to speak up.

Break work into tasks

Map the path from the initial request or information to an accepted result. Include checks, handoffs, corrections, and unusual cases. For each step, record the required information and current tool. Also name the responsible person and define the standard for an acceptable result.

This breakdown separates work that requires interpreting variable information from exact calculations, policy decisions, approvals, and actions that change customer or company records. A customer inquiry, for example, may require classification and routing, a drafted reply, a quote calculated in a pricing tool, and approval of unusual terms. Each step has different requirements.

Separate symptoms from causes

A delay does not show that AI fits the task. Check whether repeated data entry, missing information, unclear approval rules, limited staffing, or avoidable demand causes the problem. A clearer procedure, an existing software feature, or removing an unnecessary step may solve it with less complexity.

High volume does not prove that AI is the right tool either. Tasks governed by exact, repeatable rules may fit ordinary software better. Identify the task and the cause of the problem before choosing a tool.

Match tasks to AI

Generative AI is software that produces text, images, code, or other content from instructions and supplied information. It suits work involving varied language or documents when a reviewer can check the result against a clear standard.

Suitable tasks include summarizing records and extracting details from documents. Other uses include drafting responses and categorizing requests, or finding answers in approved company information. Define an acceptance standard before testing: the checks an output must pass before someone uses it. A summary may need to preserve specific facts, while a response draft must answer the customer’s question and use approved terms. The NIST Generative AI Profile identifies risks including inaccurate outputs and information-security failures. The checks should match the consequence of an error.

Use conventional software for exact calculations and explicit rules when the inputs and required result are well defined. Keep people responsible for decisions that require situational context, negotiation, accountability, or judgment about an unusual consequence.

Some work benefits from dividing the task by strength. For a customer quote, AI interprets the request and identifies missing details. Pricing software calculates the amount. An authorized employee reviews unusual terms before sending the quote. This design assigns language interpretation to AI, precision to code, and authority over exceptions to people.

A chat window or automated email address does not show that the underlying setup is suitable. Confirm which company information the tool can access, which actions it may take, and who reviews its output. The interface alone does not establish any of those controls.

Estimate the full business value

Compare the current task with the proposed AI-supported task from start to accepted result. Establish a baseline for task volume, staff time, turnaround time, error and rework rates, and the cost of delays or poor quality.

Then estimate the full future effort. Include preparation, staff review, corrections, exceptions, and training. Add integration and security controls, along with vendor and usage charges. Account for ongoing maintenance and the cost to change or retire the solution.

Count quality or service gains only when the company can define and measure them, such as fewer unresolved requests or shorter resolution times. Faster drafting does not prove better service.

Treat saved time as capacity. Choose how the business will use that capacity. It could clear a backlog, improve response times, or serve more customers. It could also help avoid planned hiring or lower expense. Minutes saved across several roles do not justify eliminating a position unless they create dependable replacement capacity and support a specific staffing decision.

Use a simple example

Suppose a support inquiry currently takes eight minutes to read, route, answer, and resolve. In a hypothetical AI-assisted version, drafting takes two minutes, staff review takes three minutes, and corrections or escalation average 1.5 minutes. The task then takes 6.5 minutes, saving 1.5 minutes per inquiry before setup and operating costs.

That saving counts only when the response resolves the request. Track resolution rates, corrections, escalations, and follow-up work rather than the number of replies drafted or sent. Include the recipient's time when an AI-generated reply creates extra clarification work.

At the company level, multiply the net time change by actual inquiry volume, then subtract implementation and operating costs. The result depends on the share of AI-assisted replies that meet the acceptance standard and on how the business uses the released capacity.

Turn the estimate into a decision

Calculate value over a defined period, such as one year. Count labor capacity the business will actually use, along with measurable service or quality gains. Subtract implementation, operating, and exit costs. Apply the estimate only to inquiries that meet the acceptance standard. A low acceptance rate can erase time savings through correction and follow-up.

A project can justify its cost without reducing payroll. Faster resolution creates value when it measurably reduces overdue requests, protects revenue, or improves customer retention. Set the target before the trial, then compare results with the baseline.

Should saved minutes count as cash savings? Count them as cash savings only when the business uses them to lower expenses, avoid hiring, or produce another measurable financial gain. Otherwise, record them as capacity and specify the work that capacity will support.

Rank opportunities with evidence

Use the same criteria for every candidate, then examine the evidence behind each rating. A 1-to-5 scale works for an initial comparison when the anchors are clear: 1 means little expected benefit or poor feasibility; 5 means substantial benefit or strong feasibility. Ratings structure discussion. They do not create a precise forecast.

Rate business value by the outcome that matters: lower cost, released staff capacity, higher revenue, faster service, fewer errors, or better customer service. Rate feasibility by whether suitable information is available, existing tools fit the task, the acceptance standard is clear, and an accountable owner can act on the result. Rate risk separately by considering the harm from an incorrect output, data sensitivity, action permissions, and how easily people would detect mistakes.

Track confidence in the evidence separately from estimated value. A large projected benefit based on assumptions needs more investigation than a smaller benefit supported by workload records or baseline performance data. The RICE prioritization method, which scores reach, impact, confidence, and effort, also treats confidence separately from impact.

Set stop conditions before comparing scores. Pause or reject an opportunity when legal or contractual terms prohibit it, required information is unavailable, an error would cause unacceptable harm, or the full cost exceeds the likely benefit. A high value rating does not override these conditions.

Compare risk and reward

High-value, low-risk candidates with measurable outcomes suit an early test. High-value work involving sensitive information, consequential decisions, or complex integrations needs a feasibility and control review before testing.

Easy, low-value tasks also deserve comparison with simpler software or a process change. Return a candidate for clarification when it lacks an owner, baseline, acceptance standard, or plan for using the capacity it would release.

Why score at all?

Ratings expose assumptions and make candidates comparable. When two managers rate a task differently, record why. The disagreement identifies the evidence needed before committing to a test.

Key takeaway

Favor opportunities that are valuable, testable, and reversible. Show risk and confidence separately instead of combining every rating into one total.

Should the highest score win?

No. Use ratings to decide what happens next. Investigate when confidence is low, and review controls when risk is high. A test makes sense when value is clear, delivery is feasible, and risk is manageable.

Check data and operating fit

A proposed AI use loses its expected value when the company lacks reliable information, clear access limits, qualified reviewers, or people who can maintain the service. Check these conditions before expanding a prototype. Data gaps and operating costs can erase the expected value.

Check the information

Identify the records the tool will use. Confirm that they are accurate, current, relevant to the task, and consistent across sources. Ensure that authorized people and services can access those records without exposing them to people who lack permission. When documents conflict or contain outdated guidance, name the source that governs the decision.

Identify personal, confidential, and regulated information before sending it to an AI provider. Review the provider's current product documentation and contract terms for how it handles submitted data, including storage, retention, and reuse. Seek qualified privacy or legal advice when obligations depend on the data type, industry, or location.

Separate privacy from security

Privacy governs how personal information is collected, used, and shared. Security governs who can access the tool and its data, what connected software can do, how activity is logged, and how the company recovers from errors.

Grant only the access and actions the task requires. A tool that drafts a customer response may need to read a support record. It does not need authority to issue a refund or change a customer account. Decide what to log, who reviews the logs, and how to suspend access or reverse an action after an error. The NIST AI Risk Management Framework treats governance and risk management as ongoing work across an AI system's life cycle.

Set review and ownership

Define what an acceptable output must include, which errors require rejection, and which cases require escalation. Reviewers need subject knowledge, time to examine supporting evidence, and authority to reject incorrect work. An approval step provides little protection when reviewers cannot perform meaningful checks.

Assign named owners for the tool, business rules, information access, output review, and final decisions. Include ongoing work in the operating estimate, from maintaining integrations and permissions to updating instructions and test examples. Also account for monitoring results and resolving failures.

Before broader use, add the controls a production service requires: authentication, error handling, monitoring, deployment procedures, and support. Use a bounded pilot with representative work to test whether those controls and the operating model hold up.

Run a bounded pilot

A pilot should answer one business question before the company commits to broader use. For example: Does AI-assisted drafting reduce the time needed to resolve customer inquiries while maintaining answer quality and avoiding added review work?

Limit the pilot to one task, a named owner, a defined user group, and approved information and actions. Keep the tool from changing customer records or making decisions with material consequences unless those actions are part of the test and have suitable controls. The NIST AI Risk Management Framework recommends evaluating AI risks and performance before and during use.

Test representative work

Measure the current process before introducing the tool. During the pilot, measure the same outcome, such as time to resolution. Track speed alongside answer quality and customer impact. Also record correction time, escalations, user effort, and total operating cost. More drafts or responses do not show that the work improved.

Include routine requests, incomplete information, unusual circumstances, and known failure patterns. Use task-relevant data while limiting access to sensitive information. Give reviewers enough time and subject knowledge to verify outputs and reject poor ones.

Set acceptance thresholds and stop conditions before the pilot begins. For example, require a defined reduction in resolution time while holding quality at the current standard. Pause the pilot if the tool exposes information improperly, produces a serious error, or creates more correction work than the business can sustain. Predetermined thresholds prevent reviewers from calling a weak result successful after the fact.

Choose the next step

At the end of the pilot, decide whether to stop, revise the task or controls and test again, or expand. Expansion requires a named owner and a plan for access management, monitoring, support, and issue handling. Keep a person responsible for decisions with material consequences until evidence shows that output quality and safeguards meet the required standard.

A successful demonstration does not answer the business question by itself. Expand only when the pilot improves the full task at an acceptable cost and the company can maintain the required safeguards and support.

What a pilot cannot prove

A well-run pilot does not guarantee the same results when used more widely. A small user group or selected cases can make performance look better than it will under normal conditions. Extra reviewer attention can have the same effect. Treat the result as evidence for the tested task, user group, and controls. Test again when those conditions change.

Common pilot questions

How long should a pilot run?
Run it long enough to include representative work and normal operating conditions. The duration depends on task volume and how often unusual cases occur.

Can historical cases be used?
Yes, when they represent the task, access is authorized, and sensitive information is protected. Historical cases help test difficult scenarios, but they do not replace observing live use under the pilot's defined controls.

When a simpler solution fits better

A clear procedure, better search, a software configuration change, rule-based automation, or removing unnecessary work can solve a well-defined task more cheaply, with less uncertainty and disruption than an AI feature. If a form always goes to the same department when a known field has a certain value, a routing rule handles it directly. If employees struggle to find approved answers, better search or better-organized documents may solve the underlying problem.

AI can also shift work rather than remove it. A generated draft still needs someone to review, correct, and follow up on it. The burden may move to the employee who receives, verifies, or acts on the output. Count time across every affected role before treating faster drafting as a real saving.

A convincing demonstration does not show that a tool handles routine exceptions, protects company data, or remains economical at normal request volumes. Test those conditions against the intended business outcome. A pilot also needs a named owner who can act on its findings. If nobody owns the result, or the business has no use for the released capacity, a technically successful pilot creates little business value.

Defer or reject an AI candidate when a simpler intervention solves the problem, the risks exceed the likely value, or nobody can measure and own the outcome. Record the decision, supporting evidence, and conditions that would justify reconsideration. Revisit the candidate if the task, available tools, or business need changes.

Further reading

For work with fixed rules and predictable inputs, see Vincent Schmalbach's guide to AI versus automation. For a closer look at handling company information, read AI data privacy. When comparing build options, integration requirements, validation, and ongoing support, see building custom AI tools.

Key Takeaways

• Start with recurring friction: Find work that repeatedly involves reading, drafting, classifying, searching, or transferring information, and define the business outcome to improve.
• Measure the whole task: Count preparation, review, corrections, handoffs, exceptions, and follow-up alongside time saved. Assign a clear use for any released capacity.
• Choose the right fix: Compare AI with clearer procedures, existing software, ordinary automation, or removing unnecessary work. Use AI for suitable language-heavy tasks, code for exact rules, and people for consequential judgment.
• Rank with evidence: Compare expected value, feasibility, full operating cost, risk, and confidence in the evidence. Stop or defer candidates with unacceptable risks, missing information, or no accountable owner.
• Pilot against a baseline: Test a narrow task with representative cases, preset success thresholds, and stop conditions. Expand only when the whole-task outcome improves and someone can maintain and support the solution.

FAQ

Where should a small company start with AI?

Choose one recurring task with a visible cost, delay, or quality problem. Check what causes the problem, measure the current workload, and define how you will judge a limited test.

How many AI opportunities should we test at once?

Test only as many as you can measure and support. A few well-monitored tests provide clearer evidence than many pilots without an accountable owner.

Do we need a custom AI tool?

Start by checking whether existing software, a configurable tool, or ordinary automation can solve the problem. Consider custom development only when an existing option cannot meet the task's information, integration, or control needs and the full operating cost makes sense.

How do we know whether a pilot worked?

Compare the result with a baseline across the whole task, accounting for review, corrections, exceptions, quality, and cost. Set success thresholds before the test, then expand only if the results meet them and someone can support the solution.

What if the task involves sensitive information or consequential decisions?

Pause before testing and check data access, provider handling, security controls, and the consequences of an incorrect output. Limit the information and actions available, and keep an authorized person responsible for consequential decisions until the controls and output quality meet the required standard.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com