# Vetting script: the standing questions

Ask these on every discovery call, in this order, before you draft a proposal. Do not skip a question because the call feels good. A good-feeling call is exactly the condition this script checks against.

## The questions

1. **Scope.** "Walk me through exactly what you want built or fixed, start to finish." (Listen for a concrete deliverable list versus a vague wish. "Something like what my competitor has," with no specifics, is a flag.)
2. **Timeline.** "When do you need this live, and why that date?" (A real business reason, a launch, an event, a contract deadline, is fine. "Yesterday," with no reason attached, is a flag.)
3. **Budget.** "What have you budgeted for this, roughly?" (A number, even a range, is fine. "What do you charge?" deflected back at you three times is a flag.)
4. **Decision maker.** "Who signs off on this and cuts the check?" (Get a name. "I'll run it by my partner, my board, my spouse," said after you've already quoted, is the flag, not the mention itself.)
5. **Last vendor.** "Have you worked with someone else on this before? How did that go?" (Listen to how they talk about the last person. One bad story can be true. Three, or contempt with no specifics, is a flag.)
6. **Payment terms.** "My standard terms are a deposit up front and milestone billing. Does that work for you?" (Say your real terms out loud on this call, not after the proposal. Resistance, "can we start and figure out payment later," or "I don't pay deposits on principle," is a flag.)
7. **Success picture.** "What does done and working look like to you, in your own words?" (Vague, shifting, or "I'll know it when I see it," is a flag. It means scope will keep moving.)

## What a flag sounds like

- **Scope vagueness:** describes the outcome, not the deliverable; keeps saying "you're the expert, figure it out."
- **Blame-the-last-vendor:** every past vendor was terrible, incompetent, or a scammer, with no specifics about what actually went wrong.
- **Payment-term resistance:** pushes back on the deposit or milestones more than once, or asks to start work before terms are settled.
- **Missing decision-maker:** the person on the call cannot commit without someone absent, and that someone has not been named or looped in.
- **Ambiguous success picture:** cannot describe "done" in concrete terms even after a second try.

## The second-call rule

If the flag count from `references/red-flag-scoring.md` is at or above the agreed threshold, or any single answer above was ambiguous, do not draft a proposal off this one call. Book a second call and re-ask the flagged questions directly: "Last time we talked about X, tell me more about that." Watch whether the answer changes, sharpens, or gets defensive under a direct follow-up. A sharpened answer clears the flag. A defensive or evasive answer confirms it.

# Intake record template

Copy this into the deal log for every new prospect, the first time the vetting script runs on them. One record per deal. Fill in the standing defaults once during setup, then everything below for each new deal.

## Standing defaults (fill in once, reuse for every deal)

- Standard deposit: ____%
- Milestone split: 25/50/25, or your own: ____
- Scope-creep buffer / change-order clause wording: (paste the agreed version from `references/pricing-levers.md`)
- Flag-count threshold for a second call: ____
- Flag-count threshold for auto-decline: ____

## Deal record

- **Prospect / company name:**
- **Date of call 1:**
- **Date of call 2 (if triggered):**
- **Logged by:**

### Answers (prospect's own words, not paraphrased)

| Question | Answer as given |
|---|---|
| Scope | |
| Timeline | |
| Budget | |
| Decision maker (name) | |
| Last vendor experience | |
| Payment terms reaction | |
| Success picture | |

### Scoring

| Flag pattern | Present? (Y/N) | Note |
|---|---|---|
| Scope vagueness | | |
| Blame-the-last-vendor | | |
| Payment-term resistance | | |
| Missing decision-maker | | |
| Ambiguous success picture | | |
| **Total flags** | | |

### Gate decision

- [ ] Proceed, standard terms
- [ ] Proceed, adjusted terms (list below)
- [ ] Second call scheduled
- [ ] Decline

**Reasoning (one line, tied to the specific flags):**

### Adjusted terms applied (if any)

- Deposit raised to: ____% (reason: ____)
- Milestone triggers: ____
- Scope-creep clause added: Y/N (wording used: ____)
- Named-signer clause added: Y/N

### Proposal sent

- **Date sent:**
- **Terms that went out (final):**
- **Approved by user before sending:** Y/N

### Outcome (fill in at the standing review or on close)

- **Payment history:** on time / late / disputed
- **Scope held or crept:**
- **Did the flag pattern predict the outcome?** Y/N
- **If terminated:** date, reason, referral given (Y/N)

# Red-flag scoring

Score every logged deal against these five patterns. Count how many are present. The count decides the gate.

## The patterns

1. **Scope vagueness.** The prospect cannot name a concrete deliverable after being asked twice. "Something modern," "what my competitor has," "you're the expert," with no list of what "it" actually is.
2. **Blame-the-last-vendor.** Every past vendor is described as terrible with no specific, checkable complaint. Contempt without detail is the tell, not the fact that a past project went badly.
3. **Payment-term resistance.** Pushes back on the deposit or milestone structure more than once, or asks to begin work before terms are agreed in writing.
4. **Missing decision-maker.** The person on the call needs sign-off from someone who was not on the call and has not been named or looped in by the second call.
5. **Ambiguous success picture.** Cannot describe what "done" looks like in concrete, checkable terms, even on a direct follow-up.

## Thresholds (defaults; adjust with the user during setup and record the agreed numbers in the intake record)

- **0 flags:** proceed on standard terms.
- **1 flag:** proceed, but apply the matching lever from `references/pricing-levers.md` to that specific flag.
- **2 flags:** do not draft off one call. Book a second call and re-ask the flagged questions directly before any proposal goes out.
- **3 or more flags, or the same flag confirmed a second time on the follow-up call:** decline, or proceed only on materially adjusted terms the user explicitly signs off on (higher deposit, shorter milestone cycle, named-signer clause, or all three).

## Notes on scoring

- Score what was actually said, not a vibe. If you cannot point to the specific words that triggered a flag, do not log it as a flag.
- A single bad-vendor story with real, specific detail ("they missed three deadlines and never gave a revised timeline") is not automatically a flag. Vague contempt with no detail is.
- These thresholds are the user's system. Do not change them without the user's explicit approval, even if a pattern looks wrong in hindsight; raise it at the next standing review instead.

# Pricing levers

Convert flags from the vetting script into priced, written proposal terms. Match the lever to the specific flag that triggered it. Do not apply every lever to every flagged deal; apply the one that addresses the actual risk.

## Standard defaults (confirm with the user, record in the intake template)

- **Deposit:** ____% of total project value, due before work starts.
- **Milestone split:** 25/50/25 (deposit, midpoint, final) is a common default. Some sellers use 50/50 or a straight monthly draw for longer engagements. Use the user's own standard once they've stated it, not this default.
- **Scope-creep buffer:** a fixed number of revision rounds or hours included in the quoted price, with anything past that billed at an agreed hourly or day rate.

## Milestone triggers (write these into the proposal, client-visible and concrete)

Use a deliverable the client can look at and confirm, never a vague fraction of effort.

- Correct: "approved homepage design," "staging site live for client review," "final files delivered and client sign-off received."
- Wrong: "50% complete," "halfway done," "most of the work finished."

## Matching a lever to a flag

| Flag | Lever |
|---|---|
| Payment-term resistance | Raise the deposit percentage above the standard default. Consider requiring the deposit non-refundable once work begins. |
| Scope vagueness | Add the scope-creep clause: a fixed number of revision rounds in the quoted price, everything past that at a stated hourly or day rate, written into the proposal, not left as a verbal understanding. |
| Missing decision-maker | Add a named-signer clause: the proposal names the actual decision-maker as the signer, and the deposit is not invoiced until that person has signed. |
| Blame-the-last-vendor | Add explicit written deliverable definitions and a mutual communication-cadence clause (an agreed check-in schedule), so "this isn't what I meant" has less room to happen. |
| Ambiguous success picture | Do not quote a fixed final price yet. Quote a paid discovery or scoping phase first, with the fixed-price proposal to follow once the deliverable is written down and confirmed by the client in writing. |

## Scope-creep clause, sample wording

> This proposal includes [N] rounds of revisions on each milestone deliverable. Additional revisions, or requests that fall outside the deliverables listed above, will be quoted separately or billed at $[rate]/hour, with written approval from the client before work begins.

Adjust the bracketed values to the user's own rate and revision count; do not invent a number. This sample is a starting point, not a reviewed contract; confirm the actual wording against the user's own contract and local law (see the skill guardrails) before it goes into a signed agreement.

## Named-signer clause, sample wording

> This agreement is executed by [decision-maker name], who confirms authority to approve project scope, payment terms, and sign-off on deliverables. The deposit invoice will be issued upon receipt of this signed agreement.

Same caution applies: this is sample language, not legal advice, and enforceability of a named-signer requirement can vary by jurisdiction and business structure.

# Decline script: when the vetting record says no

Use this when Phase 2 scoring, and a second call if one was triggered, puts the gate decision at decline (`references/red-flag-scoring.md`: 3 or more flags, or the same flag confirmed a second time on the follow-up call). Present this language to the user for approval before it is used, same as any other send-gated language in this skill.

## When to use this

Decline is one of three gate outcomes at step 9, alongside proceed on standard terms and proceed on adjusted terms. It is the right call when the flag count stayed at or above the auto-decline threshold after a second call, or when a single flag is severe enough on its own that no pricing lever fixes it: a decision-maker who never gets named after two calls, or a prospect who will not agree to any deposit in writing at all.

## The call (the default; prefer this over email or text)

A decline does not need a long justification. Keep it to two or three sentences and do not negotiate on the call.

Sample opener:

> "Thanks for walking me through this. After our conversation(s), I don't think I'm the right fit for this project, so I'm going to pass. I want to be upfront rather than string this along."

If the prospect asks why, give one concrete, non-personal reason tied to the actual mismatch, never a vague brush-off and never a personal judgment about the prospect:

> "The scope and timeline you're describing don't line up with how I price and structure a project I'd stand behind. I'd rather say that now than partway through the engagement."

## Written fallback, only when a call genuinely was not possible

A call is still the default. Use written language only when a call attempt genuinely failed (no response to a scheduling request, the relationship was entirely async from the start).

> "Thanks for the time you put into this. After going through the details, I don't think this is a good fit on my end, so I'm going to pass rather than take on something I can't deliver the way I'd want to. Wishing you luck finding the right person for it."

## Referral, only when it is genuinely warranted

Offer a referral only when a specific person or resource actually fits and nothing on the call raised a trust issue (a blame-the-last-vendor pattern with real contempt, or payment-term hostility). A referral is a real recommendation, not a reflexive politeness; do not offer one you would not actually stand behind.

## Log it

Write the gate decision, the flags that drove it, and which decline language was used (call or written) into the intake record at step 9, same as any other gate outcome. This keeps declined deals visible at the next Phase 4 review, so a pattern of repeated declines on the same flag can be checked against whether the threshold is still calibrated correctly.

# Exit playbook: when a flagged pattern shows up anyway

Use this when a client, flagged or not at intake, starts showing one of the red-flag patterns in practice during the engagement. Most of these are recoverable with a direct conversation. Termination is the last step, not the first.

## Step 1: Raise it directly

Have a direct conversation with the client before assuming the relationship is over. Name the specific pattern you are seeing, tied to something concrete, not a general feeling.

Sample opener:

> "I want to flag something before it becomes a bigger issue. We agreed the milestone deliverable was [X], and I'm seeing requests that go past that scope. Can we talk through what you actually need, and get it written into the plan so we're both working from the same page?"

Give the client a real chance to respond and adjust. Log the conversation and the outcome in the intake record. Most flagged patterns end here.

## Step 2: If it is not resolved, prepare the termination approach

If the direct conversation does not change the pattern, prepare to end the engagement. Draft the following before the call, and get the user's explicit approval on all of it before it is used:

1. **The call, not an email.** End the relationship on a call. A termination-by-email reads as cowardly and invites a worse written dispute later.
2. **Cite the documented pattern.** Reference the specific pattern from the intake record ("we discussed the scope issue on [date], and it's continued past what we agreed"), not a vague "this isn't working."
3. **Offer a referral or handoff where reasonable.** If the work is salvageable by someone else and the relationship allows it, offer a referral. This is not required when the client has been abusive or is disputing payment in bad faith.
4. **Hold final deliverables until the account is settled.** Do not hand over final files, source assets, or credentials until outstanding payment is resolved, consistent with the contract terms. Withholding deliverables carries its own legal footing that varies by jurisdiction (lien rights, contract language, consumer-protection rules); confirm this practice against the user's actual contract and local law before advising it as a blanket rule (see the skill guardrails).

## Step 3: Written follow-up

After the call, send a short written follow-up confirming what was said: the reason for ending the engagement, the final invoice or settlement amount, and what happens to any outstanding deliverables. Present this written message to the user for approval before it is sent, same as the talking points; a call cannot be pre-approved line by line, but everything written can be and must be.

Sample written follow-up:

> "Following up on our call today. As discussed, we're ending our engagement effective [date], due to [specific pattern, e.g. repeated scope changes past what was agreed in the signed proposal]. Final invoice for [amount] is attached, due [date]. [If applicable: happy to recommend someone else for the remaining work.] Files will be released upon receipt of final payment, per our agreement."

## Step 4: Close the loop

Once the engagement is closed, log the outcome and final payment status in the intake record. Feed it into the next standing review (`references/red-flag-scoring.md` and the review cadence) so the scoring keeps improving against what actually happened, not just what was predicted at intake.

# Filled intake example

One worked record, shown as a reference shape for what a completed intake record looks like. Names and numbers below are invented for illustration; do not treat this as a real client.

## Standing defaults (this seller's own, agreed once during setup)

- Standard deposit: 30%
- Milestone split: 25/50/25
- Scope-creep buffer: 2 revision rounds per milestone, additional at $95/hour
- Flag-count threshold for a second call: 2
- Flag-count threshold for auto-decline: 3

## Deal record

- **Prospect / company name:** Riverside Dental Group (example)
- **Date of call 1:** 2026-08-04
- **Date of call 2:** 2026-08-11
- **Logged by:** J. Alvarez

### Answers (prospect's own words)

| Question | Answer as given |
|---|---|
| Scope | "We need a new website, something modern, you know what dental sites look like these days." |
| Timeline | "Before our 20th anniversary event, October 15." |
| Budget | "We haven't really set a number, what do you usually charge?" |
| Decision maker | "I handle this, my partner Dr. Kim doesn't really get involved in this stuff." |
| Last vendor experience | "Our last web person just disappeared on us halfway through, never finished, total nightmare." |
| Payment terms reaction | "A deposit up front? We usually just pay when it's done." |
| Success picture | "Something that looks professional and gets us more new patients." |

### Scoring

| Flag pattern | Present? | Note |
|---|---|---|
| Scope vagueness | Y | "Modern," no deliverable list; deflected "what does modern mean to you" twice |
| Blame-the-last-vendor | N | Specific complaint (vendor disappeared mid-project), not vague contempt |
| Payment-term resistance | Y | Pushed back on deposit, asked to pay on completion instead |
| Missing decision-maker | Y | Dr. Kim is a named partner but explicitly not looped in; deposit not yet approved by an actual signer |
| Ambiguous success picture | Y | "Gets us more new patients" is an outcome, not a checkable deliverable |
| **Total flags** | 4 | |

### Gate decision

- [x] Second call scheduled (then, after call 2, proceed on adjusted terms)

**Reasoning:** Flag count of 4 is above the auto-decline threshold of 3, but the missing-decision-maker and payment-resistance flags both softened on the direct follow-up call: the client agreed to loop in Dr. Kim as signer and accepted a reduced deposit. Scope vagueness and ambiguous success picture did not resolve, so proceeding on adjusted terms with a discovery-phase-first structure rather than a fixed final quote.

### Adjusted terms applied

- Deposit raised to: not raised; reduced from the standard 30% to 20% as a negotiated middle ground, tied to the discovery-phase structure below rather than a full fixed quote
- Milestone triggers: paid discovery/scoping phase first (deliverable: written sitemap and page-by-page content list, client sign-off required), fixed-price build quote to follow
- Scope-creep clause added: Y, wording from `references/pricing-levers.md`, 2 revision rounds per milestone
- Named-signer clause added: Y, Dr. Kim named as co-signer on the discovery-phase agreement

### Proposal sent

- **Date sent:** 2026-08-13
- **Terms that went out:** Paid discovery phase, $1,200, 20% of that due up front, deliverable equals a written sitemap and content list with client sign-off; full build quote to follow discovery.
- **Approved by user before sending:** Y

### Outcome

- **Payment history:** on time
- **Scope held or crept:** held; the discovery phase defined the deliverable concretely enough that the build quote scope did not shift
- **Did the flag pattern predict the outcome?** Partially. The two flags that softened on the follow-up call (payment resistance, missing decision-maker) did not cause problems later. The two that did not soften (scope vagueness, ambiguous success picture) were the reason the discovery-phase structure was used instead of a straight fixed quote, and that structure is what kept scope from creeping.
- **If terminated:** not applicable; engagement is ongoing as of this record

Three or more, or the same flag confirmed twice after a direct follow-up call, is the standard auto-decline threshold in this system. Two flags means book a second call before you draft anything. One flag just means price around it. You can tighten or loosen these numbers to match your own risk tolerance, but write the number down once so you're not re-deciding it under pressure on every call.

Say your real terms out loud on the discovery call, not after you've already sent a proposal. Pushback once is normal. Pushback more than once, or a request to start work before terms are settled, is the payment-term-resistance flag, and the fix is to raise the deposit percentage, not to drop it to close the deal.

No. The sample wording is a starting point, not a contract reviewed for your jurisdiction. Contract enforceability, lien law, and what you're allowed to do around holding deliverables until payment all vary by state and country, so get the exact clause wording, and any practice of withholding final files, checked against your own contract and local law before you rely on it word for word.

Vetting at intake and handling a problem mid-engagement are two different moves. Raise the specific pattern directly with the client first; most of these are recoverable with one honest conversation. If it doesn't resolve, that's when the termination sequence, not the decline script, applies: ending the relationship on a call and citing the documented pattern instead of a vague complaint.