---
title: "Scope a client project from a messy call"
description: "Turn a rambling discovery call into a one-page scope: outcomes, deliverables, exclusions, assumptions, dependencies and open questions — before you quote."
canonical: "https://www.diginomads.win/prompts/scope-a-project-from-a-call"
source: "content/pages/prompts/scope-a-project-from-a-call.md"
updatedAt: "2026-11-10"
---

## Copy-ready prompt

~~~text
You are helping me turn a discovery call into one scoped piece of work.

Inputs:
- Call notes or transcript: [CALL_NOTES]
- What I deliver and how: [OFFER]
- Constraints I already know: [CONSTRAINTS]

Work in this order:
1. Extract every explicit request, promise and constraint. Quote the line it came from. Label anything implied as "inferred".
2. Separate the client's outcome (what changes for them) from my deliverables (what I hand over) and my activities (what I do). Keep the three lists apart.
3. Draft a one-page scope with these sections: Context, Outcome, Deliverables, Out of scope, Assumptions, Dependencies, Acceptance criteria, Open questions.
4. For each deliverable, write an acceptance check the client can run. If it cannot be tested, say so instead of inventing a criterion.
5. List what is missing before I can quote: decisions, access, content, approvals, third parties. Put the three that block the start at the top.
6. End with five questions for the client, ordered by how much the answer changes the scope.

Rules:
- Do not invent a price, a timeline, a promise or a technical fact. Write "to confirm" for unknown values.
- Use the client's words for their problem and plain words for the work.
- If the notes contradict each other, quote both lines and flag the conflict instead of choosing one.
- Keep the scope under 500 words. Do not pad it with a cover paragraph.
~~~

**Use when:** You have notes or a transcript from a discovery call and need a scope you can send before quoting.

**Output contract:** A one-page scope with deliverables, exclusions, assumptions, dependencies, testable acceptance criteria and the open questions that block a quote.

**Inputs you need:**

- Call notes or transcript, verbatim where possible
- What you deliver and how you usually deliver it
- Constraints the client already stated, including budget or deadline

| Variable | What to put there |
|---|---|
| [CALL_NOTES] | The raw transcript or your notes. Include the messy parts; a tidy summary hides the ambiguity this prompt is meant to expose. |
| [OFFER] | What you actually hand over, in your words: audit, build, retainer, workshop, and what is not included by default. |
| [CONSTRAINTS] | Deadline, budget range, tools, approvals and any promise already made to the client's team. |

## How to use it

1. Paste the raw notes, not your summary. If the call was recorded, paste the transcript and mark the speaker changes.
2. Fill in your offer in concrete nouns. “A dashboard” is weaker than “a read-only dashboard with three charts and a CSV export”.
3. Run the prompt, then read the out-of-scope and assumptions sections first. That is where the expensive surprises hide.
4. Send the scope with the open questions on top, not buried after the deliverables.

## Guardrails

- Every deliverable has an acceptance check the client can run, or the scope says why it cannot be tested.
- The open questions are visible before the price, not after it.
- No price, timeline or technical claim appears unless you supplied it.
- Contradictions in the call are quoted, not resolved silently.

## Variations

### If the client wants a fixed price

Add: “For each open question, state whether the answer could change the estimate by more than 10%. If yes, do not quote until it is answered.” This turns the scope into a gate instead of a guess.

### If the work is a retainer

Replace Deliverables with a monthly capacity table: hours or units, what counts against them, what rolls over and what triggers a new scope.

## Why this works

A discovery call mixes four different things: the client's problem, the solution they have already imagined, the promises made to their own team, and the constraints nobody wrote down. A model is good at separating those if you ask it to, and bad at noticing that it has blended them if you ask for “a proposal”.

The prompt forces the separation before it writes a single sentence of scope. It also asks for acceptance checks, which is the part most scopes skip. A deliverable without a check is an argument waiting to happen.

## What a good result looks like

The output should be short enough to read on a phone and specific enough that the client can disagree with a line. If every section says “the client wants a better website”, the input was too thin — go back to the notes and paste the sentences where the client described the problem.

The open-questions list is the real product. A scope that hides its unknowns is a quote with a trap in it.

## Adapt it to your work

If you sell a productized service, keep the acceptance criteria and replace the activities with a fixed process. If you sell judgment rather than deliverables, make the deliverable “a written decision memo with these sections” and keep the acceptance check on the memo, not on the outcome you cannot control.

## Failure modes

- **The model invents a timeline.** Add “no timeline unless I supplied one” if it keeps happening; it is usually filling space.
- **The scope mirrors the client's solution.** Ask it to restate the outcome without naming the deliverable, then compare.
- **The out-of-scope list is empty.** That is a warning, not a success. Every real engagement excludes something.

## Related templates

- [Write a weekly update that prevents scope creep](/prompts/weekly-client-update)
- [Red-team a plan before you commit](/prompts/red-team-a-plan)
- [Build a client-room skill pack](/skills/client-room)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Scope a client project from a messy call",
  "url": "https://www.diginomads.win/prompts/scope-a-project-from-a-call",
  "description": "Turn a rambling discovery call into a one-page scope: outcomes, deliverables, exclusions, assumptions, dependencies and open questions — before you quote.",
  "isPartOf": {
    "@type": "WebSite",
    "name": "DigiNomads",
    "url": "https://www.diginomads.win/"
  }
}
```