AI discovery
AI use-case discovery starts with work that has a clear decision, owner, input, consequence, and possible improvement path. The objective is to identify opportunities that can be tested honestly inside a defined service or process.
Map the task, decision, person doing it, information used, and condition that ends the work. Ask whether AI is assisting, recommending, classifying, summarising, or taking an action.
The AI and machine-learning services route provides an internal path when discovery needs technical evaluation.
Identify data sources, quality limits, access boundaries, sensitive content, freshness needs, and what a wrong output would cause.
Name the service owner, data owner, user, support route, human checkpoint, exception path, and evidence needed to accept the result. A use case without an owner is an idea, not a delivery candidate.
Compare the value question, data readiness, workflow fit, integration effort, control needs, user change, support, and reversibility.
Define the evaluation question, reviewer, acceptance condition, failure response, and next decision. Record what discovery did not establish.
Repetition is only one signal. The work also needs a clear outcome, suitable data, an accountable owner, and a safe way to review errors.
Many organizations arrive at discovery with a list. The list came from a leadership offshoot, a vendor demonstration, a staff member who had a good week with a chat tool, or a general sense that the competition is doing something. Few entries on that list describe a piece of work with a defined decision, a named person who makes it, a source of information and a consequence when it goes wrong. Discovery is the process of turning the list into a short set of candidates that can be tested honestly, and of removing the ideas that cannot be tested at all.
The reader for this page is usually an operations director, a head of a business function or a transformation lead who has been asked to say which AI work should be funded next. The decision is not whether AI is worth using. It is which single piece of work deserves an evaluation effort in the next few weeks, and what would make that evaluation worth stopping early.
Before any scoring happens, each idea should pass a short gate. If it fails the gate, it is not a weak candidate. It is not yet a candidate at all, and it should go back for rewriting rather than into a ranking. The gate asks for five things: the task being done today, the person doing it, the information they use, the condition that ends the task, and the decision the output would feed. An idea that cannot name the decision usually describes a feeling of inefficiency rather than a piece of work.
A worked example helps. Imagine a team that receives written requests and sorts them by hand into a handful of queues. The idea on the table is that a model should read the requests and sort them automatically. The gate questions expose the real work: sorting is a decision, the person doing it applies rules that are partly written and partly learned from experience, the information includes attachments that are sometimes unreadable, and the decision feeds a queue that carries a service commitment. That description is far more useful than the original idea, and it already suggests the evaluation question.
Once candidates pass the gate, they can be compared against a common set of criteria. The grid below is deliberately simple. Each criterion has a question, and a weak answer is described so that a reviewer can recognize it quickly. Score the answers as strong, partial or weak rather than attaching numbers that create false precision.
| Criterion | Question to answer | What a weak answer looks like |
|---|---|---|
| Outcome | What changes for the work or the customer if this succeeds? | "Staff will be happier" with no measurable change named |
| Data | Is the input available, current and lawful to use for this purpose? | The data lives in personal inboxes or in a system nobody can export |
| Consequence of error | What happens when the output is wrong, and who would notice? | Nobody has considered what a wrong answer would cause |
| Workflow fit | Where does the output enter the process, and who acts on it? | The output lands in a document that nobody reads |
| Ownership | Who owns the service, the data and the exceptions? | "The team" or "IT" is named for everything |
| Reversibility | Can the process return to manual work without loss? | Switching off the tool would strand records or commitments |
The reversibility criterion is often skipped, and it can be decisive. A candidate that can be paused in an afternoon can be evaluated with more ambition than one that rewrites records in a way no one can undo.
Ranking candidates is where discovery usually goes wrong. The person who proposed an idea is naturally in favor of it, the team that would have to change is often silent, and the attractive use case is the one that gets presented first. A simple discipline helps. Ask the sponsor to describe the strongest objection to their own candidate before the candidates are compared, and ask a person who would have to work with the output to state what would make it unusable. When both answers are vague, the candidate has not been examined enough to rank.
Repetition is a useful signal but not a sufficient one. A task that arrives many times a week may still be a poor candidate if every instance needs a different judgment, or if the correct answer depends on information that sits outside the system. Conversely, a rare task with a high consequence can be a strong candidate for assistance rather than automation, because the value lies in giving a reviewer better information, not in removing the reviewer.
A discovery phase is complete when it produces a short evidence plan for one or two candidates, not a roadmap for the whole list. The plan should state the evaluation question, the reviewer who will judge the output, the condition under which the candidate is accepted, the condition under which it is stopped, and the next decision that depends on the result. It should also record what discovery did not establish. Those gaps are as important as the findings, because they tell the next team where to begin.
The data side of that plan frequently needs its own preparation, and the AI data readiness page is the related pointer for checking whether a source is authoritative, accessible and owned before an evaluation depends on it. Where the candidate involves a decision about people or customers, the governance and risk controls should be drafted at the same time, not after the evaluation has produced an encouraging result.
A discovery program that never stops anything is not doing its job. The most useful outcome of a well-run exercise is often a candidate that was dropped for a clear reason: the data could not be obtained lawfully in the time available, the consequence of error was higher than the benefit, or the process itself was about to change. Record the reason, the person who made the call and the condition under which the idea might be reopened. A stopped candidate with a clear record is far more valuable to the next team than a parked idea that is quietly kept alive.
Usually one or two for evaluation, with a small number held in reserve. Running many evaluations at once spreads the reviewers thin and makes it hard to tell which result caused which decision.
Someone who understands the work well enough to challenge it, with a technical partner who can say honestly whether the data and the integration are workable. Sponsors can contribute, but they should not be the only voice in the scoring.
That is a result. It usually means the list was built from technology interest rather than from work. A better starting point is a map of decisions made in one process, which often reveals candidates the list missed.
Bring the list of ideas, the processes they touch and any evaluation already started. A useful first session tests each idea against the gate and produces a shortlist with the evaluation question written out. If you are deciding between discovery and a broader strategy, the governed enterprise AI strategy page is the related pointer for the broader view. For a specific list of candidates, discuss your AI use-case shortlist with us, and the data strategy consulting page is the related pointer where the sources themselves are unclear.
Bring the work, decision, or data question that needs an evidence-led AI assessment.
Discuss AI use-case discoveryGuides from the Oblytech ServiceNow library that explain the practice behind this page.