# D1 · Finding and Scoping Opportunities

Screening recurring work for AI suitability using frequency, time cost, error tolerance and data sensitivity, and scoping a candidate before any tool is built.

import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components';

This domain is worth **16%** of the mock — roughly **8 of 50 items**. It tests whether you can look at the work in front of you and decide *what to automate first*, before you touch a prompt. The Applied AI course opens here for a reason: the most common failure of a competent prompter is not writing bad prompts, it is building repeatable workflows for the wrong tasks — high-visibility, low-frequency ones that never pay back, or high-sensitivity ones that should never have left a human's hands.

## What you need to know

An automation opportunity is a *recurring* task whose value, risk and data profile make it worth turning into a repeatable workflow. The screen has four dimensions: how **frequently** the task happens, how much **time** each instance costs, how much **error** the task can tolerate, and how **sensitive** the data is. High frequency and high time cost pull toward automating; low error tolerance and high data sensitivity pull toward caution and heavier oversight (or not automating at all). Scoping means writing down the trigger, the inputs, the output and the definition of done *before* building, so you are solving a real bounded problem rather than a vague wish.

## Learning objectives

By the end of this page you should be able to:

1. **Screen** a recurring task against frequency, time cost, error tolerance and data sensitivity to decide whether it is a good automation candidate.
2. **Rank** several candidates so you automate the one with the best payback and acceptable risk first.
3. **Recognise** the anti-patterns — the impressive-but-rare task, the irreversible task, the sensitive-data task — that look like opportunities but are not.
4. **Scope** a chosen opportunity into a bounded problem statement with a trigger, inputs, output and definition of done.
5. **Distinguish** the part of a task that is genuinely repeatable from the part that needs a human every time.

---

## 1.1 The four screening dimensions

Every candidate task is scored on four axes. Two of them measure *value*; two measure *risk*.

| Dimension | Question | Pulls toward automating when… | Pulls toward caution when… |
| --- | --- | --- | --- |
| **Frequency** | How often does this happen? | Daily, or many times a week | Once a quarter, or one-off |
| **Time cost** | How long does one instance take a person? | 15+ minutes of tedious work | Two minutes of trivial work |
| **Error tolerance** | What happens if it is wrong and slips through? | A typo, an awkward sentence, an easy fix | A wrong number in a filing, a mis-sent email, a compliance breach |
| **Data sensitivity** | What data does it touch? | Public or low-sensitivity internal text | PII, regulated data, secrets, protected characteristics |

Value is roughly **frequency × time cost** — a task that happens 40 times a week and takes 20 minutes each is 13 hours a week, an obvious target. Risk is governed by **error tolerance** and **data sensitivity** — and risk does not reduce the value, it changes *how* you build (more review, more sampling, sometimes a human kept fully in the loop).

:::tip[Assessment signal]
When a stem lists how *often* a task happens and how *long* it takes, it is testing the value side of the screen. When it mentions "customer records", "financial figures", "regulated", "irreversible", "protected", or "PII", it is testing the risk side. The best answer weighs both, not one.
:::

## 1.2 A mental model for the screen

Plotting value against risk turns the four numbers into a decision.

```text
                 HIGH VALUE (frequent × time-consuming)
                              ▲
        Automate with         │        Automate now —
        strong oversight:     │        the obvious win.
        review gates,         │        Lightweight review.
        sampling, kept        │
        human-in-the-loop     │
   ───────────────────────────┼───────────────────────────►
        LOW RISK              │              HIGH RISK
        Skip or defer —       │        Usually do NOT
        automating a rare,    │        automate end-to-end;
        cheap task rarely     │        assist a human instead,
        pays back.            │        or leave it manual.
                              ▼
                 LOW VALUE (rare × quick)
```

The top-right quadrant — high value *and* high risk — is where judgment matters most: the task is worth automating but a mistake is expensive, so you automate the drafting and keep a mandatory human review (the topic of [Domain 5](/openai/applied-ai/domains/d5-review-points-and-human-oversight/)).

## 1.3 Good candidates, with worked examples

Good candidates are frequent, time-consuming, tolerant of small errors, and touch low-sensitivity data.

<Tabs>
  <TabItem label="Weekly status digest">
    **Task:** every Friday, summarise a dozen project update threads into a one-page digest for a team channel.

    **Screen:** frequency weekly (good), time cost ~45 min (good), error tolerance high — an imperfect digest is easily corrected and low-consequence (good), data sensitivity low — internal status text (good).

    **Verdict:** strong candidate. Build a repeatable workflow with a fixed digest template and a quick human skim before posting.
  </TabItem>
  <TabItem label="Support macro drafting">
    **Task:** draft first-reply text for common support tickets from a known set of issue types.

    **Screen:** frequency very high (excellent), time cost ~6 min each × hundreds/week (excellent value), error tolerance medium — a wrong draft is caught by the agent before sending (acceptable with review), data sensitivity medium — customer names, handled inside a sanctioned workspace.

    **Verdict:** strong candidate with a **human send gate** and **sampling** of drafts for quality.
  </TabItem>
  <TabItem label="Meeting-notes to action items">
    **Task:** turn raw meeting notes into a structured action-item list with owners and dates.

    **Screen:** frequency daily (good), time cost ~15 min (good), error tolerance medium — owners/dates must be right, but the human confirms them (acceptable), data sensitivity low-to-medium.

    **Verdict:** good candidate as an *extract-then-confirm* workflow: the model extracts, the human confirms owners and dates.
  </TabItem>
</Tabs>

## 1.4 Bad candidates, with worked examples

Bad candidates fail on frequency, on risk, or both. The trap is that some of them look *impressive*.

| Candidate | Why it is tempting | Why it fails the screen | Better move |
| --- | --- | --- | --- |
| The annual board narrative | High-visibility, senior audience | Frequency once a year — no payback on building a workflow; low error tolerance | Draft it manually with AI assistance, not a repeatable workflow |
| "Approve refunds automatically" | High frequency, real time saved | Irreversible, financial, low error tolerance | Automate the *drafting/triage*, keep the approval human |
| Summarise the confidential M&A folder | Genuinely time-consuming | High data sensitivity; likely policy-restricted | Only inside a sanctioned workspace with clearance; otherwise manual |
| Diagnose a customer's medical query | Frequent, high value | Regulated, high harm on error | Do not automate the judgment; provide vetted information only |
| A one-off data cleanup for a migration | Time-consuming this once | Frequency = one; a workflow never runs again | Just do it with AI help ad hoc; do not "productise" it |

:::tip[Assessment signal]
"It will be seen by the executive committee" or "it is our most important report" is a **distractor**: importance is not frequency. A once-a-year showpiece is usually a *bad* automation candidate even though it matters, because the workflow you build will never run again.
:::

## 1.5 Ranking candidates when you can only build one

When several tasks pass the screen, you still build one first. Rank by **expected payback adjusted for risk**.

| Step | What you do |
| --- | --- |
| 1 | Estimate weekly time saved = frequency × time-per-instance × fraction the workflow actually removes |
| 2 | Multiply by a confidence factor — how sure are you the workflow will hold up? |
| 3 | Subtract the review burden the risk forces on you (a heavy gate eats into the saving) |
| 4 | Discard anything whose error tolerance or data sensitivity your organisation's policy forbids |
| 5 | Build the highest remaining score first; it funds the next one |

A task saving 10 hours a week with a light review beats a task saving 12 hours a week that needs a human to check every single item — the second one's net saving is smaller once you subtract the review labour.

## 1.6 Scoping the chosen opportunity

Screening picks *what*. Scoping defines the *bounded problem* so you can build it. A scoped opportunity has five parts.

```text
TRIGGER        When does this workflow run? (a new ticket, Friday 4pm, a file arrives)
INPUTS         What does it need to start? (the ticket text, the thread list, the file)
OUTPUT         What exactly does it produce? (a drafted reply, a one-page digest, a table)
DONE           How do we know it worked? (reply passes review, digest posted, table imports)
BOUNDARY       What is explicitly out of scope? (no refunds, no medical advice, no sending)
```

Writing the boundary is the step people skip, and it is where scope creep starts. "Draft the reply" quietly becomes "and send it" and "and issue the refund" unless the boundary says otherwise.

:::tip[Assessment signal]
Stems that describe a vague wish — "use AI to handle our support" — are testing scoping. The right answer narrows it to a bounded task with a trigger and a definition of done, not "build an agent that does support".
:::

## 1.7 Separating the repeatable part from the human part

Almost no real task is 100% automatable, and pretending it is produces brittle workflows. The skill is to find the **stable core** — the part that is the same every time — and route the **variable judgment** to a person.

| Task | Repeatable core (automate) | Human-every-time part (keep manual) |
| --- | --- | --- |
| Weekly digest | Gather threads, summarise to the template | Decide what to escalate to leadership |
| Support first reply | Draft using known issue types | Approve/edit and send; handle novel issues |
| Expense categorisation | Classify routine receipts | Approve outliers and policy exceptions |
| Job-applicant screening | Extract skills into a table | *Every* hiring judgment (regulated, sensitive) |

The larger and more variable the human part, the smaller the payback — which feeds back into your ranking in 1.5.

---

## Decision framework

**The FTED opportunity screen** — Frequency, Time cost, Error tolerance, Data sensitivity. Score each candidate 1–3 and read the guidance.

| Dimension | Score 1 | Score 2 | Score 3 | Reading |
| --- | --- | --- | --- | --- |
| **F**requency | One-off / yearly | Monthly | Weekly+ | Higher = more payback |
| **T**ime cost | &lt; 5 min | 5–20 min | 20+ min | Higher = more payback |
| **E**rror tolerance | Irreversible / regulated | Correctable with effort | Trivial to fix | Higher = safer to automate |
| **D**ata sensitivity | PII / regulated / secret | Internal confidential | Public / low | Higher = safer to automate |

**How to read the totals:**

| F+T (value) | E+D (safety) | Verdict |
| --- | --- | --- |
| 5–6 | 5–6 | Automate now with light review — the ideal candidate |
| 5–6 | 3–4 | Automate the drafting, keep a mandatory human gate |
| 5–6 | 2 | Assist a human; do not automate end-to-end |
| 2–4 | any | Usually skip — low payback; do it ad hoc with AI help |

The framework's value is that it forces the risk axes to be scored *separately* from value, so a high-value task cannot bully its way past a data-sensitivity problem.

## Common mistakes

| Mistake | Why it happens | What to do instead |
| --- | --- | --- |
| Automating the impressive-but-rare task | Visibility feels like value | Score frequency honestly; rare tasks rarely pay back a workflow |
| Ignoring the review burden when ranking | The time saved is exciting; the checking is invisible | Subtract the oversight labour from the saving before ranking |
| Automating an irreversible action end-to-end | The manual step feels like the slow part | Keep the irreversible step human; automate the drafting up to it |
| Feeding sensitive data into an unsanctioned tool | Convenience beats caution in the moment | Screen for data sensitivity first; use only sanctioned workspaces |
| "Productising" a one-off | The task is painful right now | If it runs once, do it ad hoc — do not build a workflow |
| Scoping too wide ("handle support") | Ambition outruns definition | Narrow to one bounded task with a trigger and a definition of done |
| Skipping the out-of-scope boundary | Everything feels in scope at the start | Write what the workflow must *not* do; it prevents scope creep |
| Assuming a task is 100% automatable | The happy path looks complete | Find the human-every-time part and design around it |

## Scenario challenge

**Scenario.** Priya leads a 12-person operations team. She has an afternoon to pilot AI on *one* recurring task and wants a quick win the team will notice. Four candidates are on the table. (1) The **quarterly board report** — highly visible, the CEO reads it, takes a full day to assemble four times a year. (2) **Vendor-invoice categorisation** — 200 invoices a week, ~3 minutes each, currently done by hand, occasional mis-categorisation is caught at month-end reconciliation, data is internal financial. (3) **Refund approvals** — 60 a week, currently a manager approves each after reading the case; irreversible once issued. (4) **Weekly customer-health summaries** — pulled from internal notes every Monday, ~90 minutes, low consequence if slightly off, internal data. Her instinct is the board report, because "that is the one leadership will see".

**Expert reasoning trace.**

1. **Resist the visibility trap.** The board report is high-value *per instance* but frequency is 4×/year, so a workflow built for it runs four times and the build cost never amortises. It is the classic impressive-but-rare candidate — assist it manually, do not automate it. Priya's instinct is exactly the mistake this domain warns about.
2. **Score the frequent candidates on value.** Invoices: 200 × 3 min = 10 hours/week. Health summaries: 90 min/week. Refunds: 60 cases, real time, but the *approval* is the point. Invoices win on raw value.
3. **Apply the safety axes.** Invoices are internal financial with errors caught at reconciliation — medium error tolerance, so automate the categorisation with **sampling** at month-end rather than a gate on every invoice. Refunds are **irreversible and financial** — error tolerance is low, so you must never automate the approval itself; you could automate the *case summary* the manager reads, but that is a smaller, different win. Health summaries are low-risk and easy.
4. **Rank by risk-adjusted payback.** Invoice categorisation: ~10 h/week saved, light sampling review, internal data — top of the list. Health summaries: ~1.5 h/week, trivial risk — a fine, safe second pilot but smaller. Refunds: keep human; automate only the summary later. Board report: not a workflow at all.
5. **Scope the winner.** Trigger: invoices arrive in the shared inbox. Input: invoice fields. Output: a category label per invoice. Done: month-end reconciliation error rate no worse than today. Boundary: the workflow **labels**, it never **pays** or approves.

**The decision:** pilot **vendor-invoice categorisation** with month-end sampling, not the board report. It has the best risk-adjusted payback, low-to-medium risk handled by sampling, and a clean boundary. The board report is a manual-with-assistance job; refunds keep their human approval. The "quick win the team notices" is real precisely because invoices are the daily grind, not the quarterly showpiece.

## Assessment traps

| Trap | Why it is tempting | The discriminator |
| --- | --- | --- |
| "Automate the report the executives read" | Importance feels like the strongest signal | Importance ≠ frequency; a yearly task rarely pays back a workflow |
| "It saves the most hours, so build it first" | Raw hours look decisive | Subtract the review burden; a lighter-oversight task can net more |
| "Automate refund approvals to save manager time" | The manual approval is the slow step | Irreversible/financial actions keep a human; automate the drafting only |
| "Feed the confidential folder in — it is just summarising" | The task itself seems harmless | Data sensitivity is scored independently; sanctioned workspace or manual |
| "Build one agent to handle all of support" | Sounds efficient and ambitious | That is unscoped; narrow to one bounded task with a definition of done |
| "This task is fully automatable" | The happy path looks complete | Find the human-every-time judgment; design around it |

## Practice questions

Each item states how many responses to select. Commit before revealing.

<Accordions>
  <AccordionItem title="Q1 · Which pair of factors most directly estimates the value of automating a recurring task? (Select one)">
    A. Visibility and seniority of the audience
    B. Frequency and time cost per instance
    C. Error tolerance and data sensitivity
    D. Model choice and prompt length

    **Answer: B.** Value is roughly frequency × time-per-instance — how much work the automation removes. Audience visibility (A) is importance, not value, and is a classic distractor. Error tolerance and data sensitivity (C) govern *risk*, not value. Model and prompt (D) are build details that come after the screen.
  </AccordionItem>

  <AccordionItem title="Q2 · A task happens 200 times a week, takes 4 minutes each, and a mistake is corrected easily at a weekly reconciliation. On the FTED screen, how should you treat it? (Select one)">
    A. Skip it — 4 minutes is trivial
    B. Automate it with a mandatory human gate on every instance
    C. Automate it and check quality by sampling, since error tolerance is reasonable
    D. Automate it with no review of any kind

    **Answer: C.** High frequency × real time = strong value, and errors are correctable, so a sampling-based quality check fits the risk without a gate on all 200 items. Skipping (A) ignores the aggregate 13 hours/week. A gate on every instance (B) destroys most of the saving for a low-consequence error. No review at all (D) is reckless even for tolerant tasks.
  </AccordionItem>

  <AccordionItem title="Q3 · Your CEO reads one high-profile report each quarter; assembling it takes a full day. Is it a good candidate for a repeatable AI workflow? (Select one)">
    A. Yes — it is the most important thing the team produces
    B. Yes — a full day of work is a large time saving
    C. No — at four times a year the workflow build never pays back; assist it manually instead
    D. No — reports can never be produced with AI

    **Answer: C.** Frequency is the deciding factor: a workflow built for a task that runs four times a year rarely amortises, and the low error tolerance of a board document argues against automating it end-to-end. Importance (A) is not frequency. The one-day cost (B) is per-instance, not weekly. Reports absolutely can be AI-assisted (D) — just not as a productised workflow here.
  </AccordionItem>

  <AccordionItem title="Q4 · A manager wants to 'use AI to handle our customer support'. What is the FIRST thing to do? (Select one)">
    A. Build an autonomous support agent
    B. Pick the most powerful model available
    C. Scope one bounded task — e.g. drafting first replies for known issue types — with a trigger, inputs, output and definition of done
    D. Feed the whole ticket history into a single prompt

    **Answer: C.** "Handle our support" is a vague wish; the first move is to narrow it to a bounded, scoped task. An autonomous agent (A) skips scoping entirely. Model choice (B) is premature. One giant prompt (D) is a decomposition anti-pattern, and also premature.
  </AccordionItem>

  <AccordionItem title="Q5 · Which task should you NOT automate end-to-end, even though it is frequent and time-consuming? (Select one)">
    A. Summarising internal meeting notes
    B. Approving customer refunds automatically
    C. Drafting first-reply text for support tickets
    D. Categorising routine internal expenses

    **Answer: B.** Refund approval is irreversible and financial — low error tolerance means the approval stays with a human even though the volume is tempting. Meeting notes (A), support drafts (C) and expense categorisation (D) are all correctable, lower-consequence tasks suited to automation with appropriate review.
  </AccordionItem>

  <AccordionItem title="Q6 · You have four passing candidates but time to build only one. What determines which you build first? (Select one)">
    A. Whichever is technically easiest
    B. Risk-adjusted payback: time saved, minus the review burden the risk forces, discarding anything policy forbids
    C. Whichever the loudest stakeholder wants
    D. Whichever uses the newest ChatGPT feature

    **Answer: B.** You rank by expected value net of the oversight the risk demands, after removing policy-forbidden tasks. Technical ease (A) ignores payback. Stakeholder volume (C) and feature novelty (D) are not selection criteria for value.
  </AccordionItem>

  <AccordionItem title="Q7 · A task would save 12 hours/week but needs a human to verify every single item; another saves 10 hours/week with a light monthly sample check. Which has the better net payback? (Select one)">
    A. The 12-hour task, because raw hours are higher
    B. The 10-hour task, because its review burden is far smaller
    C. They are identical
    D. Neither is worth automating

    **Answer: B.** Net payback subtracts the review labour: verifying every item can consume most of the 12 hours, whereas a light monthly sample barely dents the 10. Raw hours (A) ignore the oversight cost. They are not identical (C), and both clearly pass the value screen (D).
  </AccordionItem>

  <AccordionItem title="Q8 · Which TWO tasks are strong automation candidates on the FTED screen? (Select two)">
    A. Drafting weekly status digests from internal update threads
    B. Approving wire transfers over $50,000
    C. Categorising 150 routine internal receipts per week
    D. Writing the annual investor letter
    E. Diagnosing customers' medical symptoms

    **Answer: A and C.** Both are frequent, time-consuming, correctable and low-sensitivity — the ideal profile. Wire approvals (B) are irreversible and financial. The annual letter (D) fails on frequency. Medical diagnosis (E) is regulated and high-harm. Only A and C sit in the automate-now zone.
  </AccordionItem>

  <AccordionItem title="Q9 · A workflow will summarise documents from a folder that includes confidential M&A files. What does the data-sensitivity axis tell you? (Select one)">
    A. Nothing — summarising is always safe
    B. Reduce the value score to compensate
    C. High sensitivity gates the build: use only a sanctioned workspace with clearance, or keep it manual
    D. Use a cheaper model to reduce risk

    **Answer: C.** Data sensitivity is scored independently of value and can block or constrain a build regardless of how time-consuming the task is; the answer is a sanctioned environment or manual handling. Summarising is not inherently safe (A). Sensitivity is a separate axis, not a discount on value (B). Model price (D) has nothing to do with data handling.
  </AccordionItem>

  <AccordionItem title="Q10 · When scoping an opportunity, which element most directly prevents scope creep? (Select one)">
    A. Choosing the most capable model up front
    B. An explicit out-of-scope boundary stating what the workflow must not do
    C. A longer, more detailed prompt
    D. Adding more knowledge files

    **Answer: B.** The out-of-scope boundary is what stops 'draft the reply' quietly becoming 'and send it' and 'and issue the refund'. Model choice (A), prompt length (C) and knowledge files (D) do not define scope limits.
  </AccordionItem>

  <AccordionItem title="Q11 · A one-time data cleanup for a system migration will take two days by hand. Should you build a repeatable workflow for it? (Select one)">
    A. Yes — two days is a large saving
    B. Yes — always build workflows for painful tasks
    C. No — it runs once; do it ad hoc with AI assistance rather than productising it
    D. No — data cleanup can't be done with AI

    **Answer: C.** Frequency = one means a repeatable workflow never runs again, so the build overhead is wasted; use AI ad hoc instead. The two-day cost (A) is real but one-off. 'Always build' (B) ignores frequency. AI can certainly help with cleanup (D).
  </AccordionItem>

  <AccordionItem title="Q12 · For a high-value task with low error tolerance (e.g. drafting regulated disclosures at volume), which TWO scoping choices are appropriate? (Select two)">
    A. Automate the drafting up to the point of the risky action
    B. Automate the final sign-off to save time
    C. Define a mandatory human review gate before anything is filed
    D. Remove review entirely because the model is capable
    E. Skip scoping and start building immediately

    **Answer: A and C.** For high-value, low-tolerance work you automate the drafting but keep a mandatory human gate before the irreversible/regulated action — you capture the value while containing the risk. Automating the sign-off (B) and removing review (D) both put an irreversible regulated step in the model's hands. Skipping scoping (E) is never the answer.
  </AccordionItem>
</Accordions>

## Key takeaways

- Screen every candidate on **FTED**: Frequency, Time cost, Error tolerance, Data sensitivity — two value axes, two risk axes.
- **Value ≈ frequency × time cost.** Importance and visibility are not value; the impressive-but-rare task rarely pays back a workflow.
- **Risk changes how you build, not whether the task has value.** High-value + high-risk means automate the drafting and keep a human gate.
- Rank candidates by **risk-adjusted payback** — subtract the review burden and discard anything policy forbids — then build the top one first.
- **Irreversible, financial, regulated or sensitive** steps stay human; automate everything up to them.
- **Scope before you build**: trigger, inputs, output, definition of done, and an explicit out-of-scope boundary.
- A one-off task is not a workflow — do it ad hoc with AI help.
- Find the **stable core** to automate and route the **variable judgment** to a person.