Module 11. Discovery, ROI and proposals

Technical skill gets you a pilot only if the client trusts your numbers. This module turns discovery into a repeatable product: a two-week readiness audit, a scored list of use cases, an ROI model that survives a sceptical CFO, and a proposal the client can sign.

11.1 The readiness audit as your entry offer

A small company does not buy "AI transformation". It buys a clear answer to "what should we do first, what will it return, and what could go wrong?". The readiness audit sells that answer for a fixed scope and a short time. It is also the cheapest way for you to learn whether the client is a good fit before you commit to a build.

The audit is the design stage of Vastama's design, build, test, monitor pipeline, packaged so a client can buy it alone. Done well, it sells the build stage for you, because the pilot is already specified and costed.

What makes it a product and not a favour: a fixed scope, a fixed number of interviews, named outputs, and a readout where the sponsor makes a decision. What stays out: building anything, connecting to production systems, or touching personal data beyond samples the client chooses to share.

11.2 Stakeholder interviews

Interviews are where you find the real work. Ask about the last time something happened, not about how things usually go. Ask to see the artefacts: the spreadsheet, the inbox, the form. Forty-five minutes per person; two people from the same function if the team is large. Interview in the language the person works in (Hebrew, Russian or English) and take notes in English.

11.3 Process mapping and the data and systems inventory

For each of the two or three processes that came up most in interviews, draw a current-state swimlane: one lane per actor (person, team or system), steps left to right, and a note on each step for volume, time and pain. Do it on a whiteboard or in a shared document with the process owner in the room. Do not draw the future state yet; the point is to see where time and errors accumulate.

Data and systems inventory

One row per system or data source. Keep it a table, not a diagram.

Connected data is the step that most often blocks SMBs. A system with an export is enough for a pilot; a system with no export means the first project is the export.

11.4 Maturity scoring: the five-step ladder

The ladder gives the owner a picture of where they are and what "better" means, without jargon. Score the company as a whole and each department that matters, with evidence from interviews.

Score four dimensions from 1 to 5 each: people and skills, data and systems, process clarity, governance. The overall step is the lowest of the four, rounded down, because the weakest dimension limits what you can safely build. A company with a good team but no usable data is at step 1 or 2, whatever the enthusiasm.

11.5 Use-case scoring: value, feasibility, risk

Collect 10 to 15 candidate use cases from interviews. Score each 1 to 5 on three questions, with the client in the room for value and risk.

Combine them in a weighted sheet. Risk is inverted so a higher total is always better: score = w_v × value + w_f × feasibility + w_r × (6 − risk). A starting set of weights is 0.45, 0.35 and 0.20, but agree the weights with the client before you score, so the ranking is theirs. Then apply a gate: risk 4 or 5, or feasibility below 3, is never the first pilot, whatever the total.

11.6 The ROI model

A credible ROI model is boring and conservative. It has five parts.

1. Baseline first. Measure what happens today before you promise anything: items per month, minutes per item, errors per month, cost per error. Use a two-week sample, a log, or a timesheet extract. If you cannot measure, say "estimate" next to the number and widen the range.
2. Time value. Hours saved per month × loaded cost per hour. Loaded cost is salary plus employer costs and overhead, from the client's finance manager. Hours saved = baseline hours × share of time removed × adoption.
3. Error reduction. Errors avoided × average cost to fix one. Include rework time and the cost of a customer complaint only if the client can show it.
4. Revenue lift. Faster quotes or follow-ups can raise margin, but count it only when you can name the mechanism and the number. Default to zero in the low case.
5. Run costs. Licences, API usage, maintenance and monitoring time (yours or theirs). Take licence and API prices from the current pricing pages on the day you quote, and write that date in the model.

Then compute net benefit per month = time value + error value + revenue lift − run costs, and payback period = one-off cost ÷ net monthly benefit. Show it as low, base and high so the client sees the range, not a single hopeful number.

Sensitivity and honesty

• Vary only the inputs that are uncertain: share of time removed, adoption, error reduction, API usage. Leave measured inputs alone.
• If the low case never pays back, say so. Offer a smaller pilot, a gate after two weeks, or a different use case. A client who sees the low case in your model will trust the base case.
• Time saved is not cash saved. State where the freed hours go: more quotes answered, faster month end, no new hire. If the answer is "nowhere", the benefit is soft; label it soft.
• Re-measure at the end of the pilot with the same method as the baseline. That comparison is what you show at the retainer conversation.

11.7 Packaging: audit, pilot, retainer

The retainer is Vastama's monitor stage sold as a service. It is the part clients underestimate, because models, prices, data and staff change. Sell it as keeping the result alive, with a monthly report showing the same metrics you measured in the pilot.

Pricing approaches

This course does not give prices; market rates change and depend on your positioning. Choose the approach by how well the work is defined.

A common sequence: fixed scope for audit and pilot, then a monthly retainer, with value-based elements only after a measured pilot. Whatever you choose, state what is included, what is billed separately (for example licences and API usage, which belong to the client's account), and when prices are reviewed.

11.8 Writing the SOW

A statement of work is a short contract-backed description of what you will do. Its job is to prevent the argument you can already see coming. Seven parts do most of the work.

The full skeleton is in the Deliverable section below. Have an Israeli lawyer review your template once; after that you adapt it per client.

11.9 Change management

Most pilots that fail technically work; most that fail in practice were never adopted. Plan the human side with the same discipline as the build.

11.10 Objection handling

Objections are information. Treat each as a request for evidence, not a challenge to answer cleverly.

mkdir audit-lab && cd audit-lab
python -m venv .venv && source .venv/bin/activate
pip install pandas matplotlib

"""Sample data for the mock audit: Negev Import & Distribution Ltd (fictional, 45 people)."""

INTERVIEWS = [
    {"function": "Owner / CEO", "who": "Avi, owner",
     "notes": "Wants margin visibility every Monday. Today it takes the CFO two days to assemble. "
              "Worried about customer price lists leaving the company. Has used ChatGPT personally."},
    {"function": "Finance", "who": "Irina, finance manager",
     "notes": "About 600 supplier invoices a month, PDF and scanned, English, Chinese and Turkish. "
              "Two clerks key them into the ERP. Customs documents arrive by email. "
              "Chasing late payers is done by hand, in Hebrew and Russian."},
    {"function": "Sales", "who": "Moshe, sales manager",
     "notes": "Eight reps. Quote requests arrive by email and WhatsApp, many in Hebrew with part numbers. "
              "A quote takes 25 minutes on average. Reps forget follow-ups. CRM notes are thin."},
    {"function": "Operations", "who": "Dana, operations manager",
     "notes": "Shipment delays and supplier confirmations are tracked in a shared spreadsheet. "
              "Exceptions are found late. Demand planning is done in Excel by one person."},
    {"function": "Customer service", "who": "Yulia, service lead",
     "notes": "Four agents. 70 percent of questions repeat: delivery dates, stock, invoices. "
              "Answers live in people's heads and old emails."},
    {"function": "Marketing", "who": "Tal, marketing",
     "notes": "5,000 SKUs. Descriptions exist only in English from suppliers. "
              "Hebrew and Russian versions for the web shop are mostly missing."},
    {"function": "HR", "who": "Shira, HR",
     "notes": "Hires about 10 people a year. Reads every CV. Wants help with job posts and onboarding packs."},
    {"function": "IT (outsourced)", "who": "Boris, IT contractor",
     "notes": "ERP is a local Israeli system with CSV and database export, no modern API. "
              "Shared drive is a mess. Microsoft 365 for email. No data policy on paper."},
]

# value, feasibility, risk: 1-5 (risk: 5 = most risky). hours = baseline hours per month today.
USE_CASES = [
    # id, name, function, value, feasibility, risk, hours
    ("UC01", "Supplier invoice extraction and ERP pre-coding", "Finance", 5, 4, 2, 150),
    ("UC02", "Quote request triage and draft replies", "Sales", 5, 4, 2, 170),
    ("UC03", "Late-payment reminders in Hebrew and Russian", "Finance", 3, 5, 2, 25),
    ("UC04", "Catalogue descriptions and translation (HE/RU/EN)", "Marketing", 3, 4, 1, 60),
    ("UC05", "Shipment exception alerts and supplier chasers", "Operations", 4, 3, 3, 70),
    ("UC06", "Weekly management summary from ERP exports", "Management", 4, 3, 2, 16),
    ("UC07", "Service knowledge base answers for agents", "Customer service", 4, 3, 3, 90),
    ("UC08", "Demand forecasting", "Operations", 4, 2, 3, 40),
    ("UC09", "CV screening summaries", "HR", 2, 4, 4, 20),
    ("UC10", "Warehouse pick-path optimisation", "Operations", 3, 1, 2, 10),
    ("UC11", "Supplier contract review", "Legal", 3, 3, 5, 12),
    ("UC12", "Autonomous price changes in the ERP", "Sales", 4, 2, 5, 15),
]

import matplotlib
matplotlib.use("Agg")  # no display needed
import matplotlib.pyplot as plt
import pandas as pd

from audit_data import USE_CASES

WEIGHTS = {"value": 0.45, "feasibility": 0.35, "risk": 0.20}  # agree these with the client first
assert abs(sum(WEIGHTS.values()) - 1.0) < 1e-9

def build_sheet() -> pd.DataFrame:
    cols = ["id", "name", "function", "value", "feasibility", "risk", "hours"]
    df = pd.DataFrame(USE_CASES, columns=cols)
    # risk is inverted so that a higher number is always better
    df["risk_inv"] = 6 - df["risk"]
    df["score"] = (
        WEIGHTS["value"] * df["value"]
        + WEIGHTS["feasibility"] * df["feasibility"]
        + WEIGHTS["risk"] * df["risk_inv"]
    ).round(2)
    # gate: risk 4-5 or feasibility below 3 is never a first pilot, whatever its score
    df["pilot_ok"] = (df["risk"] <= 3) & (df["feasibility"] >= 3)
    df = df.sort_values("score", ascending=False).reset_index(drop=True)
    df["rank"] = df.index + 1
    return df

def plot_matrix(df: pd.DataFrame, path: str = "usecase_matrix.png") -> None:
    fig, ax = plt.subplots(figsize=(8, 6))
    colors = df["risk"].map(lambda r: "#c8642c" if r >= 4 else "#0f7a72")
    ax.scatter(df["feasibility"], df["value"], s=df["hours"] * 4 + 40, c=colors, alpha=0.75)
    for _, r in df.iterrows():
        ax.annotate(r["id"], (r["feasibility"], r["value"]), xytext=(6, 6), textcoords="offset points")
    ax.axhline(3.5, color="grey", lw=0.8)
    ax.axvline(3.5, color="grey", lw=0.8)
    ax.set_xlim(0.5, 5.5)
    ax.set_ylim(0.5, 5.5)
    ax.set_xlabel("Feasibility (1-5)")
    ax.set_ylabel("Value (1-5)")
    ax.set_title("Use cases: value vs feasibility (size = baseline hours, orange = high risk)")
    fig.tight_layout()
    fig.savefig(path, dpi=130)
    plt.close(fig)

if __name__ == "__main__":
    sheet = build_sheet()
    pd.set_option("display.width", 140)
    pd.set_option("display.max_colwidth", 52)
    print(sheet[["rank", "id", "name", "value", "feasibility", "risk", "score", "pilot_ok"]].to_string(index=False))
    sheet.to_csv("usecase_scores.csv", index=False)
    plot_matrix(sheet)
    print("\nSaved usecase_scores.csv and usecase_matrix.png")

from dataclasses import dataclass

@dataclass
class Case:
    name: str
    baseline_hours: float          # MEASURED hours per month on this task today
    loaded_cost_hour: float        # salary + employer costs + overhead, per hour (ILS)
    time_saved_share: float        # share of baseline hours removed at full adoption
    adoption: float                # share of the team actually using it
    errors_per_month: float        # MEASURED errors or rework items today
    cost_per_error: float          # average cost to fix one (ILS)
    error_reduction: float         # share of errors removed
    revenue_lift_month: float      # extra gross margin per month, 0 if you cannot defend it
    seats: int                     # paid licences for this use case
    seat_cost_month: float         # PLACEHOLDER: copy from the current plan page on the day you quote
    api_cost_month: float          # estimate from tokens per item x items x current API pricing
    maintenance_hours_month: float # your retainer time or client time
    maintenance_cost_hour: float
    one_off_cost: float            # audit share + pilot build + training (ILS)

# Multipliers applied to the "base" case. Low = cautious, high = good adoption.
SCENARIOS = {
    "low":  {"time_saved_share": 0.60, "adoption": 0.70, "error_reduction": 0.50,
             "revenue_lift_month": 0.0, "api_cost_month": 1.5},
    "base": {"time_saved_share": 1.00, "adoption": 1.00, "error_reduction": 1.00,
             "revenue_lift_month": 1.0, "api_cost_month": 1.0},
    "high": {"time_saved_share": 1.25, "adoption": 1.10, "error_reduction": 1.20,
             "revenue_lift_month": 1.5, "api_cost_month": 0.9},
}

def run(case: Case, scenario: str) -> dict:
    m = SCENARIOS[scenario]
    share = min(case.time_saved_share * m["time_saved_share"], 0.9)
    adoption = min(case.adoption * m["adoption"], 1.0)
    hours_saved = case.baseline_hours * share * adoption
    time_value = hours_saved * case.loaded_cost_hour
    err_red = min(case.error_reduction * m["error_reduction"], 0.95)
    error_value = case.errors_per_month * err_red * case.cost_per_error
    revenue = case.revenue_lift_month * m["revenue_lift_month"]
    gross = time_value + error_value + revenue
    run_cost = (case.seats * case.seat_cost_month
                + case.api_cost_month * m["api_cost_month"]
                + case.maintenance_hours_month * case.maintenance_cost_hour)
    net = gross - run_cost
    payback = case.one_off_cost / net if net > 0 else float("inf")
    return {
        "scenario": scenario,
        "hours_saved": round(hours_saved, 1),
        "time_value": round(time_value),
        "error_value": round(error_value),
        "revenue": round(revenue),
        "gross_month": round(gross),
        "run_cost_month": round(run_cost),
        "net_month": round(net),
        "payback_months": round(payback, 1) if payback != float("inf") else None,
        "net_year_1": round(net * 12 - case.one_off_cost),
    }

def table(case: Case):
    import pandas as pd
    return pd.DataFrame([run(case, s) for s in SCENARIOS]).set_index("scenario")

# Example: UC01 invoice extraction. All numbers are fictional inputs for the exercise.
UC01 = Case(
    name="UC01 Supplier invoice extraction",
    baseline_hours=150, loaded_cost_hour=95, time_saved_share=0.55, adoption=0.85,
    errors_per_month=30, cost_per_error=180, error_reduction=0.40,
    revenue_lift_month=0,
    seats=3, seat_cost_month=100, api_cost_month=900,
    maintenance_hours_month=6, maintenance_cost_hour=250,
    one_off_cost=45000,
)

UC02 = Case(
    name="UC02 Quote triage and drafts",
    baseline_hours=170, loaded_cost_hour=110, time_saved_share=0.35, adoption=0.75,
    errors_per_month=12, cost_per_error=400, error_reduction=0.30,
    revenue_lift_month=3000,
    seats=8, seat_cost_month=100, api_cost_month=600,
    maintenance_hours_month=4, maintenance_cost_hour=250,
    one_off_cost=40000,
)

if __name__ == "__main__":
    import pandas as pd
    pd.set_option("display.width", 140)
    for c in (UC01, UC02):
        print(f"\n{c.name}  (one-off cost {c.one_off_cost} ILS)")
        print(table(c).T.to_string())

import pandas as pd
from audit_data import INTERVIEWS
from score_usecases import build_sheet, WEIGHTS
from roi_calc import UC01, UC02, run

def outline() -> str:
    sheet = build_sheet()
    shortlist = sheet[sheet["pilot_ok"]].head(3)
    lines = ["# AI readiness audit: Negev Import & Distribution Ltd", ""]
    lines += ["## 1. Executive summary (one page)",
              "- Maturity today: step 1 of 5, ad hoc chat. Target in 12 months: step 3, connected data.",
              f"- Recommended pilot: {shortlist.iloc[0]['name']}",
              "- Decision requested: approve a 4-6 week pilot", ""]
    lines += ["## 2. What we did",
              f"- {len(INTERVIEWS)} stakeholder interviews ({', '.join(i['function'] for i in INTERVIEWS)})",
              "- Current-state swimlane for invoice-to-ERP and quote-to-order",
              "- Data and systems inventory, maturity scoring", ""]
    lines += ["## 3. Maturity scoring (table: 5-step ladder, current step, evidence)", ""]
    lines += ["## 4. Use-case ranking",
              f"- Weights: {WEIGHTS}", "- Table of 12 use cases, 2x2 chart, gate: risk 4-5 or feasibility under 3 is never a first pilot"]
    for _, r in shortlist.iterrows():
        lines.append(f"- Shortlist: {r['id']} {r['name']} (score {r['score']})")
    lines.append("")
    lines += ["## 5. ROI for the shortlist (low / base / high, baseline measured, assumptions listed)"]
    for c in (UC01, UC02):
        b, lo = run(c, "base"), run(c, "low")
        lines.append(f"- {c.name}: base net {b['net_month']} ILS/month, payback {b['payback_months']} months "
                     f"(low case {lo['payback_months']} months)")
    lines.append("")
    lines += ["## 6. Risks, privacy and governance (data classes, who sees what, human review points)", "",
              "## 7. Roadmap: pilot (4-6 weeks), then retainer (monitor and improve)", "",
              "## 8. Change plan: champions, training, communications, adoption metrics", "",
              "## 9. Next steps and SOW reference", "",
              "## Appendix: interview notes, scoring sheet, ROI workbook, data inventory"]
    return "\n".join(lines)

if __name__ == "__main__":
    text = outline()
    print(text)
    with open("audit_report_outline.md", "w", encoding="utf-8") as f:
        f.write(text)

python score_usecases.py   # prints ranking, writes usecase_scores.csv and usecase_matrix.png
python roi_calc.py         # prints low/base/high tables for UC01 and UC02
python report_outline.py   # prints and writes audit_report_outline.md

Deliverable: your consulting kit

Four reusable documents. Build them from the lab, then clean them so you could send them to a real client tomorrow.

1. Audit questionnaire

A two-page document with: an opening script (purpose, confidentiality, how notes are used), eight function sections from 11.2 with 6 to 8 questions each, the four closing questions, and a one-page pre-interview data request (org chart, process documents, system list, a sample of each key document). Keep Hebrew and Russian versions of the opening script.

2. Use-case scoring sheet

A spreadsheet or the CSV from the lab with columns: id, use case, function, owner, value, feasibility, risk, weights, score, gate result, baseline hours, baseline source, notes. Include a "scale anchors" tab with the table from 11.5 so scorers rate consistently.

3. ROI calculator

roi_calc.py from the lab, with these upgrades: read cases from a CSV, write the results to a spreadsheet, add a column for the source and date of every input, and add a line that prints "BASELINE NOT MEASURED" when an input is flagged as an estimate.

4. Proposal and SOW template

The full skeleton. Replace square brackets; delete what does not apply; have a lawyer review the legal clauses.

STATEMENT OF WORK
Vastama Ltd (company no. 515052702) and [Client legal name, company no.]
SOW number: [ ]    Date: [ ]    Version: [ ]

1. PURPOSE AND BACKGROUND
   [Two or three sentences: the client's goal, the problem, and how this
   engagement fits in the sequence audit -> pilot -> retainer.]

2. SCOPE
   2.1 Deliverables (nouns, with quantities)
       D1  [e.g. 8 stakeholder interviews, notes in English]
       D2  [e.g. 2 current-state process maps]
       D3  [e.g. Data and systems inventory]
       D4  [e.g. Scored list of up to 15 use cases]
       D5  [e.g. ROI model for the top 3, low/base/high]
       D6  [e.g. Audit report and one readout meeting]
   2.2 Working method and timeline
       Start date [ ]. Milestones: [M1 date], [M2 date], [readout date].
   2.3 Languages of deliverables: [English / Hebrew / Russian]

3. OUT OF SCOPE
   - [Building or deploying any workflow (covered by a separate pilot SOW)]
   - [Connection to production systems or write access]
   - [Training of all staff]
   - [Legal advice or regulatory certification]
   - [Work in languages or departments not listed above]

4. ASSUMPTIONS
   - [Sponsor available for a 45-minute weekly check-in]
   - [Interviewees available in the agreed week]
   - [Data samples supplied by date X, in the formats listed in Annex A]
   - [Client holds, or will obtain, the Claude plan needed for the pilot]
   - [Third-party prices and terms are as published on the date of this SOW]
   If an assumption proves false, timeline and fees are adjusted through
   change control (section 11).

5. ACCEPTANCE CRITERIA
   - Each deliverable is accepted when it matches the description in 2.1
     and the client has had [5] working days to review it.
   - [For a pilot: accuracy of at least X percent on the agreed sample set of N items,
     measured against the human reviewer, and median time per item below Y minutes.]
   - Comments are consolidated by the sponsor; one revision round is included.
   - Silence after the review period counts as acceptance.

6. CLIENT RESPONSIBILITIES
   - Name a sponsor with authority to decide, and a day-to-day contact.
   - Provide people, documents and system access listed in Annex A within [2] working days of request.
   - Review deliverables within the review period.
   - Ensure it has the right to share the data it provides.
   - Delays by the client move the timeline day for day.

7. DATA ACCESS AND SECURITY
   7.1 Data the Supplier may access: [list systems, read-only or not].
   7.2 Data classes excluded unless approved in writing: [personal data of customers,
       employee records, payment card data, ...].
   7.3 Access method and accounts: [client-issued accounts, least privilege, revoked at end].
   7.4 Where data is processed and which AI services are used: [list], under the
       client's own account and its current commercial terms.
   7.5 Retention and deletion: working copies deleted within [ ] days of acceptance.
   7.6 Incidents: the Supplier informs the client without delay and within [ ] hours of discovery.

8. TIMELINE AND MILESTONES
   [Table: milestone, date, dependency, owner.]

9. FEES AND PAYMENT
   9.1 Pricing approach: [fixed scope / time and materials with cap / value-based].
   9.2 Fee: [amount and currency, VAT treatment].
   9.3 Payment schedule: [on signature / on milestone / on acceptance], payment terms [ ] days.
   9.4 Pass-through costs (licences, API usage) are paid by the client directly to the provider.
   9.5 Expenses: [included / billed at cost with prior approval].

10. RETAINER OPTION (only in a pilot SOW)
    Monitoring, improvements and support after acceptance: scope [ ], monthly report,
    notice period [ ], price review date [ ].

11. CHANGE CONTROL
    Any change to scope, timeline or fees is requested in writing, estimated by the
    Supplier within [3] working days, and takes effect only when both parties sign.

12. INTELLECTUAL PROPERTY
    [Client owns its data and the deliverables made for it; Supplier keeps its tools,
    templates and know-how; licence terms for reuse.]

13. CONFIDENTIALITY AND PRIVACY
    [Mutual confidentiality for [ ] years; compliance with applicable Israeli privacy law;
    data processing terms if personal data is processed.]

14. WARRANTIES AND LIMITS OF LIABILITY
    [AI outputs may contain errors; the human review step in section 5 is part of the
    design. Liability cap and exclusions per master agreement, reviewed by counsel.]

15. TERM AND TERMINATION
    [Start, end, termination for convenience with notice, what is delivered and paid on early end.]

16. CONTACTS AND GOVERNANCE
    Supplier: [name, role, email, phone]    Client: [name, role, email, phone]
    Check-ins: [weekly, 30 minutes]    Escalation: [role at each side]

17. SIGNATURES
    For Vastama Ltd: ____________  Name/Title: ________  Date: ______
    For [Client]:    ____________  Name/Title: ________  Date: ______

ANNEX A  Data, systems and people requested
ANNEX B  Interview schedule or pilot plan
ANNEX C  ROI assumptions and baseline measurements (pilot SOW)

Self-check

1. Why do you measure the baseline before you build the ROI model, and what do you do if the client cannot provide one?
   Model answer

   Without a baseline you cannot prove any improvement, and the model rests on guesses. If none exists, take a short sample (two weeks of logs or a timed sample of items), label the figures as estimates, widen the low-to-high range, and make baseline measurement the first task of the pilot.
2. A use case has the highest total score but risk 5 (it changes prices in the ERP without review). What do you do?
   Model answer

   Apply the gate: risk 4 or 5 is not a first pilot. Propose a lower-risk step on the same process, for example Claude proposes price changes and a person approves them, and plan governance work before any autonomy. Keep the full-automation version on the roadmap.
3. In the lab, the low case pays back in more than five years. What do you tell the client, and what do you change?
   Model answer

   Show it openly: the project depends on adoption and time saved. Change the design to protect it: smaller scope, a two-week checkpoint with a stop option, a training plan to raise adoption, lower fixed costs, or choose a use case with stronger value. A visible low case builds trust in the base case.
4. Name three items that belong in "out of scope" for a pilot SOW, and the section that handles a client request for more.
   Model answer

   For example: connecting to production systems beyond the agreed read access, supporting additional languages or departments, training every employee, ongoing monitoring after handover (that is the retainer). New requests go through change control: written estimate, written approval, adjusted timeline and fee.
5. An owner says: "AI makes mistakes, and my staff are afraid for their jobs." Give a response that deals with both without overpromising.
   Model answer

   Agree that mistakes happen and show how you control them: human review, accuracy measured on their own samples against today's human error rate, acceptance criteria. On jobs, say the pilot changes specific tasks, say where freed time will go, involve staff and champions in the design, and do not promise either outcome on headcount.

Further reading

• Anthropic Economic Index (task-level usage patterns for framing opportunity)
• Anthropic customer stories (how other organisations describe results; use for ideas, not as your own evidence)
• Anthropic Academy (free courses)