Most enterprise AI programmes do not fail at the model. They fail one step earlier, when someone picks the wrong problem. AI use case discovery is the structured work of finding tasks where AI can measurably help, checking that the data and permissions exist, and ranking the candidates so the first build is low risk, visible and easy to measure. This playbook covers discovery workshops, shadowing, AI fit, scoring, a one-page brief and choosing where to start.
It is written for Forward Deployed Engineers, consultants and IT leaders. If you are new to the role, read what a Forward Deployed Engineer does first. Discovery is the step before the POC; once a use case is chosen, the stage-gate playbook for taking AI from POC to production takes over.
Why discovery decides the outcome
When an AI pilot stalls, the post-mortem usually finds a problem chosen for the wrong reason: a leader saw a demo, a vendor offered credits, or a team wanted to try agents. The task was low volume, the data was locked away, or the "AI problem" was really a broken approval process. Many of the failure modes in why AI demos fail in enterprise production trace back to choices made in the first two weeks.
Good discovery flips the question. Not "where can we use AI?" but "which task costs us time, money or risk today, how do we know, and would a language model plausibly reduce that cost under human review?" In Cloudsoft's FDE chain, discovery sits between the customer problem and the business requirement:
Customer problem
|
Discovery <-- workshops, shadowing, data check
|
Business requirement (one-page brief)
|
Data -> Architecture -> POC -> Pilot -> ...
|
Business outcome
Everything downstream, from enterprise AI architecture to evaluation, inherits the quality of this step.
Running discovery workshops
Who to invite
Keep the room to people who can describe the work, own the data or approve the change:
- Process owner who knows volumes, backlogs and pain.
- Two or three front-line practitioners who do the task every day. They are the most valuable people in the room and the most often left out.
- A data or system owner for the main sources (ERP, ticketing, document management, CRM).
- Someone from security, risk or compliance, so hard constraints surface on day one, not month three.
- The likely sponsor, at least for the last half hour, to hear the shortlist and commit to a metric.
- A facilitator (the FDE or consultant) and a note-taker.
Run one workshop per business area. Finance, procurement and quality describe different pain, and mixing them produces a wish list instead of a shortlist.
Questions to ask
Avoid AI vocabulary; ask about the work.
- Process pain: Which part of your week do you dread? Where do you copy information between screens? What do you look up again and again?
- Volume: How many of these do you handle a day or a month? Does it spike at month-end or audit time? Where does that number come from?
- Errors and rework: What goes wrong most often, how do you find out, and what does a mistake cost?
- Wait time: Where does work sit waiting for an expert, an approval or a reply? What does the bottleneck person actually do when it arrives?
- Data availability: Where does the information for this task live: a system with an API, a shared drive, email threads, someone's head? Who decides who can read it?
Write every candidate as a task sentence: "Quality engineers spend time searching past deviation reports to find similar root causes." A task sentence forces a who, an action and a purpose, and exposes vague ideas such as "AI for HR" immediately.
Shadowing real work
Workshops tell you what people believe about their work; shadowing shows what they do. Spend a few hours with practitioners on a normal day, on the strongest two or three candidates.
- Watch the screens. Count the systems, tabs and searches behind one item of work.
- Time a small sample. Hand-timing ten items gives a rough baseline that the enterprise AI business case and ROI will need later.
- Collect real artefacts. With permission, gather redacted inputs and outputs: emails, tickets, reports. They seed your evaluation set.
- Look for the workaround. Personal cheat sheets, macro-filled spreadsheets and "ask Ravi" habits signal a knowledge task AI might support.
- Notice the judgement. Where the practitioner pauses to think is where AI can help most or harm most.
Shadowing often kills a candidate, which is a good outcome. A task that sounded painful may be quick, or blocked by a policy no model can change.
Good signs a task fits AI
Strong generative AI use cases in the enterprise tend to share these traits:
- Language-heavy. Reading, writing, summarising, classifying or searching unstructured text: documents, emails, tickets, manuals, logs.
- Repetitive judgement. The same type of decision made many times with varying details, such as triaging tickets or matching a query to the right policy.
- Tolerant of review. A human already checks the output, or could do so cheaply. A draft an expert edits is far safer than an answer sent straight to a customer; see human-in-the-loop AI design.
- Clear success measure. Both sides agree what "better" means: handling time, first-time-right rate, backlog age, time to find a document.
Bad signs: when it is not an AI problem
- It needs every answer to be correct, with no review. Payment instructions, safety interlocks, unchecked regulatory filings. Models produce plausible output, not certified output. Add a review step or use deterministic software.
- There is no data. The knowledge lives only in experts' heads, or nobody can approve access to the documents.
- It is actually a process or policy problem. If approvals wait because three managers must sign, a delegation rule helps more than an AI summary. If people re-key data between systems, an integration is cheaper and more reliable.
- It is rare, or nobody owns it. A task that happens a few times a year rarely justifies the build and operations effort, and without an owner there is no adoption (see enterprise AI adoption and change management).
An enterprise AI use case framework: the scoring matrix
With eight to fifteen task sentences, score each from 1 (weak) to 5 (strong). The aim is to make trade-offs visible and arguable, not precise. For risk, a higher score means lower risk, so a higher total is always better.
| Dimension | What you are judging | Scores 5 when | Scores 1 when |
|---|---|---|---|
| Value | Time, cost, error or risk reduction if it works | High-volume task with visible cost of delay or error | Occasional, nice to have |
| Feasibility | Can known patterns (RAG, extraction, classification, a simple agent) do it? | Well-understood pattern | Needs research or perfect accuracy |
| Data readiness | Is the data digital, reasonably clean and accessible? | Clean source, API, owner has said yes | Scattered, scanned or access refused |
| Risk (inverted) | Consequence of a wrong output; data sensitivity | Internal users, every output reviewed | Customer-facing, unreviewed, regulated data |
| Time to value | How soon real users see a benefit | Pilot with real users in weeks | Needs a platform build or migration first |
| Sponsor | A named leader who wants it and will measure it | Metric and pilot group agreed | Interest but no owner or budget |
If you weight dimensions, agree the weights before scoring, not afterwards to favour someone's preferred idea. Treat a 1 on risk or data readiness as a blocker regardless of the total.
The effort/value 2x2
Combine feasibility, data readiness and time to value into an effort view, keep value on the other axis, and plot each candidate as a short label.
HIGH VALUE
|
BIG BETS | QUICK WINS
plan, fund, | start here:
de-risk data | first use case
|
HIGH ----------+---------- LOW
EFFORT | EFFORT
|
AVOID | FILLERS
park or | only if they
drop | build reuse
|
LOW VALUE
- Quick wins are candidates for the first use case.
- Big bets go on the roadmap with a data-readiness plan; shared retrieval, identity and evaluation built for the first project make them cheaper.
- Fillers are worth doing only if they reuse the same platform and help adoption.
- Avoid is where many "chatbot for everything" ideas land once examined honestly.
Want to practise running an engagement end to end, from discovery workshop to production system? Cloudsoft's AI Forward Deployed Engineer course includes a weekly Customer Engagement Lab and a simulated "GlobalBank" capstone engagement, in Ameerpet or live online.
Check data access and permissions early
The most common late surprise is data access: the POC is built on a sample someone emailed, then the data owner or security team refuses production access. Check during discovery, before anything is built.
- Name each source system and its owner. "SharePoint" is not an owner; the site owner of the quality-records library is.
- Ask for the classification. Personal data, customer data, export-controlled drawings? In India, personal data brings obligations covered in India's DPDP Act for AI teams.
- Agree the access path: API, read replica, scheduled export or nothing.
- Check permission inheritance. The AI system must respect source-system permissions at retrieval time, so plan identity integration (for example Microsoft Entra ID groups) from the start.
- Confirm where the model may run: approved providers and regions, and whether data may leave the corporate tenancy.
- Get a representative sample approved in writing, messy documents included.
The one-page use-case brief (template)
Write one page per shortlisted candidate. If it does not fit, the use case is not yet understood. The brief becomes the input to the first gate of the POC.
- Title: the task sentence.
- Sponsor and process owner: named people, not departments.
- Users: role, how many, where.
- Current process: three to five steps, painful step highlighted.
- Evidence: volume, errors, wait time, with sources and shadowing notes.
- Proposed AI assistance: what the system does (draft, retrieve, classify, summarise, route) and what the human still decides.
- Out of scope for the first release.
- Data sources: system, owner, classification, access path, approval status.
- Success metric and baseline: one primary metric, how it is counted, the measured baseline.
- Quality bar: what the output must achieve on an agreed test set.
- Risks and controls: consequence of a wrong output, review step, sensitive-data handling.
- Constraints: providers and regions, identity provider, change process, timeline.
- Scores and quadrant.
- Decision: proceed, park or drop, with date and decision-maker.
Picking the first use case
The first use case also earns the trust and platform for everything after it. Choose for three qualities:
- Low risk. Internal users, every output reviewed, low-sensitivity data where possible. An early incident can freeze a programme for a long time.
- Visible. A team others watch, and a pain people already complain about.
- Measurable. A metric with a baseline captured during shadowing, so the result is evidence, not opinion.
Prefer one that builds reusable foundations: document ingestion, permission-aware retrieval, an evaluation harness, tracing and cost tracking. Later use cases then cost less.
Avoiding the "chatbot for everything" trap
When discovery is skipped, the usual output is "an enterprise chatbot that answers any question about the company". It fails AI opportunity assessment on almost every dimension:
- No clear user or metric. When everyone is the user, no one owns success.
- Unbounded data. Every repository, each with its own owner, permissions and quality issues.
- Unbounded evaluation. You cannot build a meaningful test set for "anything".
- High risk. Wide access plus confident answers on HR, finance and legal topics is a governance problem.
Start narrow instead: one role, one task, one or two sources, one metric. A focused assistant can grow into a broader one once retrieval, permissions and evaluation are proven. Breadth is earned, not assumed.
Illustrative example: a manufacturing GCC in Hyderabad
Consider an industrial-equipment manufacturer whose Global Capability Centre in Hyderabad supports engineering, quality, procurement and IT for plants in several countries. Leadership asks the GCC to "find where AI can help", and an FDE-led team runs discovery over three weeks.
Workshops for quality, procurement, engineering change and the IT service desk produce twelve task sentences. Shadowing shows quality engineers keyword-searching an old document library, opening many PDFs and messaging a senior colleague who "remembers a similar case". Procurement analysts already use a good template; their delay is waiting for plant sign-off, a policy issue.
| Candidate | Value | Feasibility | Data | Risk (inv.) | Time to value | Sponsor | Quadrant |
|---|---|---|---|---|---|---|---|
| Deviation history search and similar-case summary | 4 | 5 | 4 | 4 | 4 | 5 | Quick win |
| Engineering change request summaries | 4 | 4 | 3 | 4 | 3 | 3 | Big bet |
| IT ticket classification | 3 | 5 | 5 | 5 | 5 | 2 | Filler |
| Company-wide policy chatbot | 3 | 3 | 1 | 2 | 2 | 2 | Avoid |
| Machine failure prediction | 5 | 2 | 2 | 3 | 1 | 4 | Big bet (not GenAI) |
The policy chatbot is blocked on data: many repositories, no single owner, region-specific HR content. Machine failure prediction is a classic machine-learning problem on sensor data, so it goes to the data-science team. Procurement delays go to the procurement head as a process recommendation, not a build.
Deviation history search wins. Users are internal, every output is reviewed before a deviation closes, the library owner approved read access mapped to Entra ID groups, and shadowing produced a baseline. The head of quality signs the brief, which puts automatic root-cause decisions out of scope. Its retrieval and evaluation components will later make the engineering change summaries cheaper.
No model was chosen and no code was written in those three weeks. The GCC enters its POC with a sponsor, a metric, a baseline, approved data and a narrow scope.
Frequently asked questions
What is AI use case discovery?
AI use case discovery is the structured process of finding business tasks where AI can measurably help, checking that the data and permissions exist, and ranking candidates before anything is built.
How do you prioritize AI use cases?
Score each candidate from 1 to 5 on value, feasibility, data readiness, risk, time to value and sponsor strength, treat very low data or risk scores as blockers, plot the candidates on an effort and value grid, and start with a high-value, low-effort quick win.
Who should attend an AI discovery workshop?
The process owner, two or three front-line practitioners, the data or system owner, someone from security or compliance, the likely sponsor, and a facilitator with a note-taker. Run one workshop per business area.
How long should AI use case discovery take?
For one business area, typically a few weeks of workshops, shadowing, data access checks and briefs. It should end with a signed brief for the first use case, not a long strategy document.
What makes a task a bad fit for generative AI?
Needing every answer to be correct with no human review, having no accessible data, being rare or unowned, or really being a process or policy problem that an integration or rule change would fix.
Should our first AI use case be a company-wide chatbot?
Usually not. It has no clear user or metric, unbounded data and permissions, and no definable test set. Start with one role, one task and one or two sources, then widen.
What goes into an AI use-case brief?
The task sentence, sponsor and owner, users, current process, evidence, proposed AI assistance and human decisions, out-of-scope items, data sources and approvals, success metric and baseline, quality bar, risks and controls, constraints, scores and the decision.
Who runs AI use case discovery in an enterprise?
Often a Forward Deployed Engineer, solutions consultant or internal AI lead working with the business process owner. The engineer knows what AI can do reliably; the business knows the work, the data and the people.
If you want to learn discovery, architecture, build and deployment as one connected skill set, from AI demo to enterprise outcome, explore Cloudsoft FDE PRO: 12 weeks, 120+ hours live, five enterprise projects and the GlobalBank capstone, in Ameerpet beside the Metro or live online. Call +91 96660 19191 for a free demo. Leaders training teams to run discovery this way can see our corporate training options.
