“Where should we use AI?” is a large assignment. A warehouse or enterprise leader may have dozens of sites, hundreds of workflows, and no agreed list of problems to solve. Starting with a favored workflow or a vendor demo can make the search feel productive while leaving the best opportunities undiscovered.
The job is to move from that ambiguous mandate to a stack-ranked list of use cases: each linked to a recurring pain point, a measure of current performance or a plan to establish one, a plausible intervention, an estimate of value and effort, and the evidence still needed before investment. For each serious candidate, the team must compare what happens now with what it expects to happen after the change, then test that expectation. That reduces time and money spent on attractive ideas that cannot be built, adopted, or measured.
A research agent is an AI tool that carries out a multi-step investigation: it plans what to examine, uses the sources it can access, revises its search when the evidence changes, and reports what it found. Examples include ChatGPT's deep research and Claude's Research, where those features are available and approved for your sources. With approved notes, files, or connections, it can help organize findings from across the organization. People still have to observe the work, validate the agent's account, and make the investment decision.
The research begins broadly. It narrows to specific workflows only after patterns emerge from staff, managers, leaders, and system records.
Give the agent a broad discovery brief
State the coverage boundary, the decision the work must support, and the material the agent is approved to use. Decide which business units, sites, shifts, and support functions need representation, and which outcomes matter to leadership. An organization chart, process catalog, system inventory, scorecards, issue logs, and previous improvement efforts can show where to start. If your organization has not approved a tool for sensitive records, use anonymized notes or keep that part of the investigation in your own environment. The brief should leave room for the evidence to change the direction of the search.
The boxes throughout this guide are prompts for an AI research agent, such as ChatGPT deep research or Claude Research. Use them in sequence as interviews and records become available. Replace bracketed details with your own scope and give the agent only approved source material.
Begin with coverage. Replace the example sources with those available in your organization.
AI research-agent prompt — map the organization
Map the sites, shifts, functions, and roles this discovery
must cover. Using only the approved organization chart,
process catalog, scorecards, and issue logs, identify the
systems and measures available in each area. Show whose
perspective is missing. Draft open interview questions for
frontline staff, managers, and leaders about recurring
problems, workarounds, and outcomes. Return a coverage plan
and source inventory. Do not propose use cases yet.
Work through the assignment in stages as evidence arrives. Have the agent show its coverage plan and source list. Redirect it if it overweights polished presentations or generic market trends while missing a shift, site, or handoff. Require the final report to link back to the observations and records so another person can verify its findings.
The investigation has five phases. The agent can carry context from one phase into the next, while the team checks the evidence before scoring a candidate:
| Step | What the research agent prepares | What the team checks |
|---|---|---|
| Map the organization | A stakeholder and system map across functions and sites, a source inventory, and a coverage plan. | The sponsor checks scope, missing perspectives, access, and the outcomes that matter. |
| Interview and observe | Open interview questions, organized field notes, and a long list of reported and observed pain points. | Staff and managers check whether the account reflects actual work across sites and shifts. |
| Validate the pain | Clusters of recurring problems, relevant measures, conflicting accounts, and questions for cross-functional sessions. | The team checks frequency, consequence, affected roles, and whether a problem merits deeper study. |
| Develop use cases | Current-state maps and measures for shortlisted workflows, competing hypotheses, proposed future states, requirements, and open questions. | Operators and system owners challenge root causes, forecast outcomes, and simpler alternatives. |
| Score and sequence | An evidence-backed screen, RICE worksheet, directional value estimate, and stack-ranked roadmap. | Operations, IT, and finance approve inputs and choose what to test in the first pilots. |
An agent with approved data tools can run queries and save the code beside its findings. Without that access, it can draft the query and identify the fields an analyst needs; the resulting number stays unknown until someone runs it.
Listen across the organization before selecting a workflow
With the coverage plan in hand, identify people doing the work, managers responsible for the process, and leaders accountable for results. Documents can identify whom to visit; they cannot tell you which problem matters most in practice.
Visit representative sites and interview across roles and functions. Ask open questions about delays, recurring exceptions, handoffs, workarounds, decisions that need more information, and measures people already trust. Ask where reported metrics differ from what they experience. Record the problem before asking whether AI would help. A pain point named independently by an operator and a manager, then corroborated by a system record, deserves more attention than a feature idea supplied in a meeting.
The agent can prepare interview guides, keep track of whose perspective is missing, organize approved notes, and maintain source IDs. The team's first output is a long list of pain points and open questions across the organization. It is not yet a backlog of AI features.
AI research-agent prompt — review interview coverage
Using the approved coverage plan and interview notes, show
which sites, shifts, and roles have been heard and which are
missing. Group reported problems without assuming their cause
or proposing AI solutions. For each theme, link the source
notes, flag conflicting accounts, and suggest an open question
or observation that would test it. Do not invent interviews.
Turn interviews and observations into a pain-point map
The agent should turn interview notes, site observations, scorecards, and issue logs into one comparable register. For each pain point, record the affected roles and sites, what happens, how often it appears, its operational consequence, the current measure or missing baseline, the source IDs, and who can verify it. Keep a stated frustration distinct from a measured loss, and keep a suspected cause distinct from both.
A receiving manager may report recurring short shipments, an outbound lead may describe failed waves, and an IT manager may point to slow access requests. Those are signals to investigate, not three AI projects. The agent can cluster similar reports, look for corroboration in event data, and show where the sample overrepresents one site or one leadership view. Cross-functional sessions then test whether each problem recurs beyond the first account.
Choose a small set of pain points for deeper study based on recurrence, consequence, strategic relevance, and the evidence available to investigate them. A missing baseline can itself become the next data task; it should not erase a serious problem. Record why the other pain points wait. This first cut selects problems to investigate; solution feasibility, value, and RICE come after the team has defined possible interventions.
AI research-agent prompt — build the pain-point register
Using the approved interview notes, field observations,
scorecards, and issue logs, group recurring problems across
sites and functions. For each, show affected roles, frequency,
consequence, current measure or missing baseline, source IDs,
conflicting accounts, and missing perspectives. Separate facts
from suspected causes. Recommend which problems need deeper
study, and explain why. Do not propose solutions yet.
Investigate the strongest signals
Now bound each selected workflow from trigger to outcome. A process map drawn in a conference room often misses the delays and workarounds that define the actual job. Visit the place where work happens. Watch a task move between people and systems. Ask what happens when the documented procedure does not fit the case. Record the role, workflow step, date, and condition behind each observation.
Suppose slow employee access requests emerge from the interviews and records as one recurring problem. Analysts check a ticket, an identity record, application policy, and prior approvals before approvers can decide. A meeting might describe the problem as “slow IT support.” Field observation could reveal that people repeatedly reconstruct the same context before an authorized person can decide.
Give the agent numbered notes from staff, managers, and system events for this shortlisted workflow. Its first pass should reconstruct the sequence and flag conflicts. Perhaps the ticket log says a case was assigned at 10:04, while the analyst did not see a complete request until 10:19. The agent should identify that gap and ask what happened inside it. A process owner can then verify the timeline in the system and with the people involved.
The most useful early output may be a list of questions for a second visit or a workflow-specific discussion: Which requests are missing a business reason? Which applications require extra review? Which cases look “closed” but reopen? Begin those sessions with open questions about the work, then test the pain points the team observed, and only then discuss possible solutions. The agent helps the team spend its next hour on the unknowns that matter.
AI research-agent prompt — examine a shortlisted workflow
For [selected pain point], use the verified field notes and
event records to reconstruct the workflow from trigger to
outcome. Show roles, handoffs, exceptions, and timestamps.
Flag contradictions and gaps, with source IDs. List the next
questions for workers and system owners. Do not infer a cause
from an unexplained gap in the timeline.
Form the first hypothesis from the evidence
Once the team has a credible picture of a shortlisted workflow, write down a problem hypothesis. In the access-request example, it might be: “Analysts lose time because they repeatedly reconstruct the same context from several systems.” A competing explanation is that incomplete requests or the approval queue cause most of the delay. Both fit “slow IT support”; only one may make case preparation the right first intervention.
Ask the research agent to look for evidence that would weaken each explanation. If event records show little active preparation time, or observation finds that most waiting happens after the case is ready, a summary assistant may not improve the outcome. If analysts already have a reliable rules-based way to assemble the case, AI may add cost without useful capability. The aim is to discover which explanation survives contact with the work, not to defend the first idea.
Only then form a solution hypothesis: a source-linked case summary could reduce active preparation time without increasing corrections or access risk. That is a claim for a pilot to test, not a conclusion the research agent can reach from documents alone. Keep the problem, competing explanation, proposed intervention, expected measure, and disconfirming evidence together as the investigation develops.
AI research-agent prompt — test competing explanations
Using the verified workflow and records, write two or three
competing explanations for the recurring problem. For each,
show supporting and disconfirming evidence, a measure that
could distinguish it, and the cheapest credible next check.
Identify which explanation currently has the strongest support
and what finding would change your mind.
Measure the current state and proposed future state
Before estimating value, agree on the unit of work, eligible cases, observation period, and measures that would change an investment decision. For access requests, measure the current volume, active preparation time, end-to-end turnaround, corrections, and approval exceptions. Use event records and direct observation together: a ticket timestamp may capture queue time while missing the work done outside the system. Record the distribution, not just an average, and name any baseline the team still needs to collect.
Then describe the proposed workflow using the same cases and measures. A case-summary assistant might reduce preparation time but add review time, corrections, or security checks. Estimate those effects as a range, including operating cost and possible shifts in the approval queue. A process model or digital twin can help test how a change might affect the whole workflow, provided it can reproduce the current state closely enough to trust its scenarios. NIST's digital-twin work emphasizes model validation and uncertainty. The proposed future state is a forecast until a pilot measures what actually changes.
The research agent can draft the measurement plan, find the relevant data fields, prepare queries for approved tools, and expose assumptions. Operators and system owners must verify the baseline; finance must check which improvements could create economic value. Compare the forecast with pilot results on the same basis before claiming ROI.
AI research-agent prompt — compare current and future states
For [shortlisted workflow], define the eligible cases and
measurement period. Using approved records and observations,
show current volume, active work time, wait time, rework, and
outcome measures, with sources and gaps. For the proposed
change, forecast low, central, and high outcomes on the same
cases and measures. Include review effort, exceptions, risks,
and operating costs. Separate measured baselines from modeled
assumptions, and specify what a pilot must verify.
Challenge the proposed solution
For the access-request example, one candidate is an assistant that assembles a reviewable case summary from approved records, flags missing evidence, and routes it to a human approver. It does not grant access. If requests and policies are already structured and consistent, a rules-based workflow may be simpler. A research agent should be required to test that alternative, not rewarded for recommending AI.
Our human- and agent-centered design screen asks whether the workflow serves the people accountable for it and gives any agent a clear, bounded role. Before ranking ideas, test each candidate against three conditions:
| Condition | What the agent must establish |
|---|---|
| Feasibility | Which data and systems are available, reliable, and permitted for this use? |
| Viability | What outcome could improve, and what would building and operating the change cost? |
| Desirability | Do the people doing the work recognize the problem and want this intervention? |
The agent should distinguish evidence by how it was obtained. Observation shows the work people perform; event records show what the systems capture. Compare both with retrospective accounts, since none is complete on its own. An unprompted statement from someone doing the work is stronger evidence of felt pain than agreement after the team proposes an AI feature. Standard procedures show intended work; analyst inference remains a question to test.
For each feasibility, viability, and desirability score, keep the supporting observation, system fact, or stakeholder statement with its role, date, and context. When a meeting account conflicts with what happened in the field, investigate the difference instead of averaging the two. In our working rubric, a dimension without sourced evidence cannot score above 1 out of 5 until the gap is resolved. That is an evidence status, not proof that the idea is bad.
A research agent can assemble this evidence ledger, compare independent accounts, and flag claims supported only by inference. The investigator still needs access to people who can confirm the record. Skipping observation can make a desirability score look persuasive while missing the workaround people actually prefer.
In our method, a candidate needs at least three out of five in every category before it advances. That is a working threshold, not an industry standard. The agent can prepare a provisional score and source list; operators, IT, and finance must challenge them. If a dimension lacks evidence, record the gap at the minimum score and assign the next check. Do not let a strong RICE score rescue an idea that fails the first screen.
The case-summary assistant might have good evidence for desirability if analysts independently identify preparation as a burden. It may still have weak feasibility if the identity and policy records cannot be accessed safely. The agent should say so plainly. Conversely, an easy-to-build chatbot may score well on feasibility but poorly on desirability if it does not solve the team's actual delay. A polished prototype cannot repair a missing permission or an unwanted workflow.
AI research-agent prompt — challenge each proposed solution
For each validated problem, compare an AI intervention with
a rules-based option and a process change. Describe the human
decision owner and the agent's permitted role, if any. Score
feasibility, viability, and desirability from 1 to 5 using
linked evidence for every dimension. Flag missing permissions,
data, costs, or user support before recommending a pilot.
Compare candidates, then check the arithmetic
Once a candidate passes that screen, the agent can help assemble a shortlist. We use RICE to compare reach, impact, confidence, and effort on consistent units:
RICE = (Reach × Impact × Confidence) ÷ Effort.
The agent can prepare each input, but each comes from a different kind of evidence:
| Input | Agent's investigation | Owner's check |
|---|---|---|
| Reach | Count eligible people, transactions, or events in a fixed month or quarter; show the query, exclusions, and missing cases. | Operations confirms the unit of reach, eligibility rule, and whether the period is representative. |
| Impact | Use time studies or a shadow test to estimate net improvement per eligible unit. Map that evidence to one agreed relative impact scale used for every candidate. | The process owner checks whether the proposed change would actually affect the measured step and its downstream outcome. |
| Confidence | Show which reach, impact, and effort assumptions have measured support and which rely on interviews or guesses. Apply a stated confidence rubric. | The team lowers confidence when the sample, source quality, or integration assumptions are weak. |
| Effort | Break the pilot into data access, integration, security, review workflow, testing, training, and measurement work, all in person-weeks. | Engineering and process owners estimate the work and name dependencies the agent missed. |
In an illustrative scenario, records show 800 requests per month, but only 75% meet the pilot's eligibility rule. Reach is 600 eligible requests per month, not 800. A preliminary time study suggests a medium relative impact, scored 1 on the agreed scale. The team assigns 80% confidence because the volume is measured but the time saving still needs a pilot, and estimates 8 person-weeks of work. The provisional score is (600 × 1 × 0.80) ÷ 8 = 60. A second candidate reaching 300 monthly cases, with impact 2, 50% confidence, and 10 person-weeks scores 30. If only 400 requests qualify and effort rises to 12 person-weeks, the first score falls to about 27, holding impact and confidence constant. That sensitivity matters more than a neat ranking.
RICE confidence is a judgment about evidence, not a statistically calibrated probability. Intercom's original method uses broad confidence bands and effort in person-months; this pilot comparison uses person-weeks, so its numeric scores are comparable only within a shortlist using the same units and time period. Define the rubric before scoring and apply it consistently. Across functions, a "request" and a "receiving discrepancy" may have different economic weight, so the raw RICE scores cannot settle the organization-wide ranking on their own. The access-request assistant is one row in the roadmap; a receiving use case could outrank it once the team measures loss and expected change. The agent can expose weak assumptions, but it should not assign false precision to them. Recalculate its arithmetic outside the agent before a decision.
Treat the ranking as another hypothesis to test. Ask the agent which unmeasured assumption could reverse the order, what data would settle it, and whether that check is cheaper than building the highest-scored idea. Update the score when the evidence changes, even if the original favorite falls down the list.
RICE suggests an order for investigation, not a return on investment. If a case summary saves an illustrative four minutes on each of the 600 eligible monthly requests, the gross annual capacity released would be 480 hours. At a hypothetical loaded rate of $60 per hour, that is $28,800 of capacity value before review, build, and operating costs. It is not automatically cash savings. Before pricing a rollout, measure net time saved after review and corrections, then show how the recovered capacity changes a business outcome.
Every candidate that passes the first screen also needs a directional value estimate. Choose a measure that matches the work: labor time recovered, throughput gained, inventory loss avoided, service commitments protected, or safety and compliance risk reduced. The agent can calculate eligible volume × estimated change per case and show low and high cases. Finance decides which part could become money. Do not multiply the RICE impact rating by a dollar rate; that rating is a relative prioritization scale, not a measured benefit.
AI research-agent prompt — estimate priority and value
For candidates that pass the first screen, calculate RICE
using one stated time period, reach rule, impact scale,
confidence rubric, and effort unit. Show sources, exclusions,
arithmetic, and a sensitivity case that could change the order.
Separately estimate low and high business value from eligible
volume and measured change per unit. Mark assumptions that
operations, engineering, or finance must confirm.
Ask for a decision record, not a slide of ideas
The research agent's final deliverable should let another person reproduce the organization-wide ranking and see why alternatives were rejected. Have it maintain five linked artifacts across the research and the workflows selected for deeper study:
- Pain-point analysis: the recurring problems, severity, possible root causes, and supporting sources.
- Current-state process map: actual stages, roles, handoffs, exceptions, and decisions.
- Business requirements: the desired outcome, proposed future workflow, measures of success, constraints, and dependencies.
- Prioritized backlog: candidate solutions, evidence-backed scores, estimated effort, and proposed sequence.
- Open-questions log: each unresolved hypothesis or assumption, its owner, disconfirming evidence to seek, and the next check.
A master use-case register ties those artifacts together. Give every pain point a stable ID, including those held for later investigation. Link each developed candidate to its problem, baseline, proposed intervention, evidence-backed screen, RICE inputs, directional value range, owner, and next test. Then stack-rank the viable candidates into Pilot Now, Plan Next, Backlog, or Defer, recording why a candidate with a lower RICE score may still come first because of value, risk, or a dependency. Save every revision with its date and new evidence. The agent can draft a weekly leadership pre-read from that register, highlighting changed rankings and missing measures instead of redrawing a polished roadmap each week.
Open the source behind each important claim before approving the brief. A citation should resolve to the actual observation or record; NIST's generative AI guidance notes that convincing output can still contain false information and citations. The research agent makes the chain easier to maintain, but the chain has to be real.
The first pilot should test the most consequential uncertainty in the solution hypothesis. For access requests, begin with a bounded set of applications, human approval, and no automated provisioning. Agree on a success threshold against the current-state baseline before running the pilot, using the same eligibility rule and measures in both states. For example, the team might require a measurable drop in median active preparation time with no increase in corrections; it should also track end-to-end turnaround and any error that could lead to an unauthorized grant. If reviewers spend more time repairing summaries than preparing cases themselves, revise the idea. If preparation gets faster but the approval queue still determines completion time, revise the expected benefit and perhaps the problem definition. A research agent can compare the result with the original forecast; the team decides whether to stop, change course, or expand.
AI research-agent prompt — prepare the investment decision
Combine the candidates from every function into a ranked
register. For each, show the pain point, current-state baseline
or missing measure, proposed future state, evidence strength,
value range, delivery effort, key risk, owner, and next test.
Explain why the top pilot comes first and why the others wait.
Draft its success threshold and guardrails against the current
baseline.
Keep unverified claims visible rather than filling the gaps.
A credible AI roadmap is a record of what the team has learned, what it still needs to prove, and why the next investment comes next.
You do not need a vendor selection, a data science team, or an approved build budget to begin. You do need access to people doing the work, their managers, and the leaders accountable for the outcome; the relevant procedures and system inventory; and at least one direct observation where the work happens. Give a trusted research agent that evidence and a bounded question. Its value is a faster, more traceable investigation—not a shortcut around the field.
At CrateOS, our proprietary tools take the investigation further: we connect approved operational records, replay the work, test a change, and keep the evidence tied to the measured outcome. We improve our methods and evaluation checks through each engagement, within each customer's data boundaries. Talk with us if you want to build that learning loop in your operation.
Matthew Kim is a co-founder of CrateOS.