Discovery field guide / Department
How to find AI opportunities in Information Technology
Where should discovery start?
Start with a recurring incident or service request and trace the diagnostic work between the ticket, runbook, logs, and system owner. Look for repeated context gathering and evidence interpretation, not merely high ticket volume. Separate missing monitoring, broken integrations, and unclear ownership from work that genuinely needs AI. Keep production-changing actions outside the first trial unless authorization, rollback, and verification are explicit.
The shared framework
Fourteen stages, from objective to portfolio.
Every guide uses this sequence to connect a business problem to an accountable investment. Revisit earlier stages when new evidence changes the assessment.
Stage 1: Business Objective
Name the outcome the organization is trying to move, so every later idea has something to be measured against.
Stage 2: Department
Locate the team that owns the objective and the work that feeds it.
Stage 3: Process
Describe how the work actually runs today: steps, handoffs, systems, and exceptions.
Stage 4: People
Capture who performs and depends on the work, and what they know that no document records.
Stage 5: Problem
State the friction in plain terms: delay, rework, error, cost, or risk, with evidence.
Stage 6: Opportunity
Frame a specific improvement that addresses the problem, not yet tied to any technology.
Stage 7: AI/Automation Fit
Compare AI, RPA, IDP, workflow automation, process redesign, and no technology change.
Stage 8: Value
Estimate benefit in the objective's own terms, with assumptions written down.
Stage 9: Feasibility
Check data, systems, skills, and change capacity needed to deliver.
Stage 10: Risk
Surface compliance, quality, security, and adoption risks and the controls they need.
Stage 11: Scoring
Rate each opportunity on the same dimensions so comparisons are consistent and explainable.
Stage 12: Prioritization
Sequence opportunities by score, dependencies, and capacity, with reasons people can challenge.
Stage 13: Investment
Match approved effort to the sequence; people with budget authority decide what gets funded.
Stage 14: Portfolio
Track opportunities over time as a living set: delivered, in flight, waiting, and retired.
Start with one observable journey
Pick one service with a known owner and recurring support demand. Gather sanitized tickets, a current runbook, and change records. Compare a routine resolution with an escalation and a reopened incident; the differences reveal what the service desk cannot safely infer.
This guide focuses on IT service delivery and operational work. Security-sensitive actions, production deployment, and access approvals require their own controls even when they appear inside a routine ticket.
Where to look in the work
Diagnostic handoffs
Trace the evidence that first-line support gathers before an engineer can act. Look for repeated log summarization, environment identification, and missing reproduction steps. Distinguish the effort to obtain telemetry from the effort to interpret it; better instrumentation can be the correct investment.
Requests stuck between ownership queues
Inspect reassigned access requests, duplicate incidents, and tickets closed without durable fixes. An unclear service catalog may cause routing failures that classification cannot solve. Capture the authoritative system and owner for each action instead of assuming the ticketing platform contains all the context.
Who to interview and what each person knows
Service desk and on-call engineer
Have a service-desk analyst demonstrate the last difficult escalation, then ask the on-call engineer which evidence was useful or misleading. Include the person maintaining the runbook. Differences between documented and actual remediation are discovery evidence, not a reason to automate the undocumented workaround.
Service, security, and change owners
Ask the service owner about reliability objectives and maintenance capacity. Bring identity/security and change-management owners into discussions of tool permissions. An agent's ability to call an API does not establish that it should hold standing permission to change production.
What to ask: follow the evidence
What was missing when the ticket arrived?
Ask: Which diagnostic question did you repeat? How did you identify the affected version and environment? What evidence distinguished this incident from a similar one? Request a case where an old runbook caused a wrong turn and note how engineers detected the mismatch.
What is the action boundary?
Ask what may be read, suggested, or executed, and by whom. Which changes need approval? How is success verified and how would you roll back? Include emergency procedures and dependency failures; a proposed assistant must not bypass a control just because the ticket is urgent.
Signals of opportunity, and reasons to look elsewhere
Stable evidence, repeatable diagnostic questions
Recurring evidence collection with known source systems and an engineer-reviewed standard is a useful signal. Runbook retrieval or draft incident summaries can be bounded. Contradictory alerts, missing telemetry, and undocumented ownership point toward operational hygiene rather than a reasoning layer.
A reversible recommendation
Look for tasks where an incorrect suggestion is detectable before any system change. Compare that with privileged remediation or credential handling, where mistakes can spread quickly. Reopened tickets and engineer corrections matter more than a convincing summary or a reduction in visible queue length.
How to evaluate what you find
Replay before connecting write tools
Evaluate historical incidents with the information available at the time, not the final resolution already attached. Include stale runbooks, contradictory logs, and misleading ticket text. Check grounding, abstention, secret redaction, and prompt-injection exposure before granting access to live operational context.
Include operational upkeep
Measure engineer review, false escalations, and reopened incidents alongside handling time. Assess model and runbook changes, observability, vendor outages, and rollback ownership. Separate a read-only summarizer's evidence from the much higher bar required for automated production changes.
How to compare, prioritize, and invest
Fund dependency fixes first
If reliable service identifiers or telemetry are missing, sequence those repairs ahead of a diagnostic pilot. Prefer one well-owned service over a company-wide assistant with no accountable maintainer. Keep the scope small enough that the support team can inspect every proposed output during the trial.
Use reliability as a constraint
Compare candidates by recovery quality, avoided repeated diagnosis, support effort, and exposure to production harm. Stop if misleading suggestions increase incident duration. An owner should approve expansion only after a replay and bounded trial show useful results under the real permission model.
Turn observations into a comparable opportunity record
Describe the current process before naming a solution. Record the trigger, owner, input, steps, handoffs, systems, output, and exception path. Separate what you observed from what someone recalled and what you still need to verify. A vivid interview story is a useful lead, not proof that every case behaves the same way. Validate it against a sample of ordinary work and difficult exceptions, with the limits of that sample made explicit.
Measure active work separately from waiting. Note the observation period, case mix, frequency, and source of each estimate. Include the receiving team's effort, checking, correction, and escalation so a local improvement does not merely transfer work. Describe the outcome in operational terms before attaching a monetary value. Capacity released is not automatically a budget saving; explain what can actually change and which manager has authority to make that change.
Compare interventions before selecting a tool
If a rule is explicit and the input is structured, test ordinary workflow automation first. If the task repeats a stable interface action, examine RPA and an integration alternative. If the difficulty is reading documents, consider IDP with source checks. AI may help where language or variable evidence requires interpretation, but its output still needs a task-specific acceptance standard. Process redesign or no technology change may be the right answer when policy, ownership, or an unnecessary step causes the problem.
Write down why each alternative would or would not address the observed cause. Do not compare a carefully controlled AI proposal with an artificially weak version of the current process. Include data repair, access approval, integration, training, review, and upkeep in each feasible option. An unavailable prerequisite is a reason to sequence work or pause, not a detail to hide inside a feasibility score.
Agree on a decision, not just a demonstration
Before a trial, name the business owner, evaluator, permitted data, review boundary, and person who can stop it. Define acceptable outputs and failures that must trigger escalation. Use examples held out from development, including missing information and uncommon cases. Compare the complete task with the baseline, including human verification and downstream consequences. Preserve the evidence behind the result so another owner can challenge the conclusion.
Keep value, feasibility, risk, and evidence confidence visible separately. A candidate with an attractive benefit estimate is not ready if its owner cannot obtain the data or operate the controls. Record the decision to investigate, pilot, wait, reject, or retire, with a reason and a condition for revisiting it. After delivery, compare observed results with assumptions rather than leaving the original estimate in the portfolio as fact.
Use the evaluation guide for the evidence standard and the prioritization guide to compare qualified candidates. Your leaders make funding decisions; a score or a discovery tool supplies structured evidence, not investment authority.
Continue through the discovery framework
Browse all departments and industriesRelated practice notes
For focused interview techniques, examples, and scoring detail alongside this field guide:
Qualify an IT service workflow in IntakeOS
Bring a sanitized incident path, the involved systems, and the read/suggest/execute boundary. Use IntakeOS discovery to capture the operational problem before selecting an AI architecture or giving it tools.
IntakeOS supports structured interviews, qualification, and comparison; it does not make funding decisions or replace professional review. Learn about VARA, review the trust page, or explore the platform before sharing sensitive information.
Explore discovery in an IntakeOS demo