Meeting Notes to Retainer Pipeline

Build a payment-gated client pipeline from meeting note to retainer.

Introduction

30 Second Summary

Every solo advisor knows the tension: you deliver great work, but chasing payments, managing proposals, and converting one-off projects into recurring revenue feels like running a second business on top of your actual expertise.

In this project, you will build a seven-station client operating system that carries a prospect from a meeting note to a monthly retainer, with payment gates wired to Stripe that hard-stop delivery on non-payment automatically.

What You'll Build

A payment-gated client pipeline powered by Claude Code, n8n automation, Stripe payment links, and PandaDoc proposals that turns meeting notes into recurring retainer revenue.

By the end of this project, you'll have:

  • A seven-station pipeline from meeting note intake through signed proposal, gated payments, delivery, and retainer offer.
  • A three-option value-based offer engine with proposal templates, acceptance criteria, and a billing schedule wired to Stripe payment links.
  • Four self-enforcing payment gates (deposit, design approval, final acceptance, retainer) that pause work automatically on non-payment without confrontation.
  • Secret Mission: Run portfolio intensity with multiple concurrent clients, a tiered care-plan retainer, live change-order negotiation, and stalled-payment resolution through the clauses.

Are there any prerequisites?

This project assumes you have a Claude Max subscription with Claude Code access, a Stripe account (test mode is sufficient), a PandaDoc account with API access (Business plan or higher), an n8n instance (self-hosted or cloud), a Notion workspace, and Granola or Pocket with an MCP connector configured.

You do not need prior experience with any of these tools beyond having accounts created and access confirmed.

Set Up and Wire the Stack

Before building any pipeline logic, every integration your conveyor relies on needs to be live and connected.

In this step you will wire Claude Code to your meeting notes, stand up a lightweight CRM in Notion, and connect n8n to both Stripe and PandaDoc. Once these connections are confirmed, every station on the pipeline has a working integration underneath it.

In this step, get ready to:
  • Connect Claude Code and Granola MCP (or Pocket MCP), then create a Notion CRM database.
  • Wire n8n to Stripe and PandaDoc with live credential tests.
  • Create four Stripe Products and record their Price IDs for payment gating.
Connect Claude Code, MCP, and your CRM

The pipeline starts with meeting notes. Claude Code needs direct access to those notes so the intake agent can parse them without manual copy-paste.

  • Open Claude Code on your machine (it runs on your Claude Max subscription).
  • Confirm it launches and you can interact with it in the terminal.

What is Claude Code?

Claude Code is an agentic coding tool that runs in your terminal. On a Claude Max subscription, it operates at a flat rate with no per-token cost. You will use it as the orchestrator for the entire pipeline.

  • Connect your meeting-note source via MCP. If you use Granola, enable the Granola MCP connector in Claude Code's MCP settings. If you use Pocket, enable the Pocket MCP connector instead.
  • Test the connection by asking Claude Code to list your recent meeting notes. You should see note titles returned.

Why MCP for meeting notes?

MCP (Model Context Protocol) gives Claude Code direct, structured access to external data sources. Instead of pasting transcripts manually, the intake agent can pull notes programmatically on demand.

🙋‍♀️ Not seeing your meeting notes?

Make sure the MCP connector is enabled and authenticated. Granola's free tier provides the last 30 days of notes. Pocket requires authentication via OAuth or a pk_ API key to access the MCP server.

Ask for help: Why can't Claude Code see my meeting notes via MCP?

Next, create the CRM that tracks every client through the seven stations.

  • Open Notion in your browser.
  • Create a new full-page database. Name it Pipeline CRM.
  • Add the following properties to the database:
  • Client Name (Title property, already present by default).
  • Station (Select property). Add these options: Intake, Scope, Design, Build, Demo, Deliver, Support.
  • Gate Status (Select property). Add these options: Pending Sign-off, Pending Payment, Cleared.
  • Proposal Link (URL property).
  • Payment Links (Rich text property). This will hold deposit, milestone, final, and retainer links per client.
  • Last Updated (Last edited time property).
  • Leave the database empty for now. You will add test client records in a later step.

Why Notion as a CRM?

For a solo practice, Notion is the lightest CRM that still gives you structured data, select-field filtering, and a native n8n integration. You can always migrate to a heavier tool later without changing the pipeline logic.

Wire n8n to Stripe and PandaDoc

n8n is the automation spine. It listens for payment events from Stripe and calls PandaDoc to generate proposals. Both credentials must be confirmed working before you build any workflow logic.

  • Open your n8n instance. If you are using n8n Cloud, log in at your workspace URL. If self-hosting with Docker, confirm the container is running and access the editor UI.

What is n8n?

n8n is a workflow automation platform. You can self-host it (data stays local, no per-execution cost) or use the cloud version. It connects services via nodes and triggers workflows on events like Stripe payments.

First, add your Stripe credentials.

  • In n8n, go to Settings then Credentials.
  • Click Add Credential and search for Stripe.
  • In the Secret Key field, paste your Stripe test-mode secret key (it starts with sk_test_).
  • Save the credential.

Where to find your test secret key

In the Stripe Dashboard, make sure you are in test mode. Go to Developers then API Keys. Under Standard Keys, click Reveal test key next to the Secret key. Copy the value that begins with sk_test_.

Now add the Stripe Trigger node so n8n can receive payment events.

  • Create a new workflow in n8n.
  • Add a Stripe Trigger node.
  • Select your Stripe credential.
  • In the Events dropdown, select * (labelled Any time any event is triggered (Wildcard Event)). You will filter to specific events like payment_intent.succeeded in a later step.
  • Save the workflow. n8n will register a webhook endpoint with Stripe automatically.

Why use the wildcard event?

Starting with the wildcard lets you see all Stripe events during development. This makes debugging easier. In a later step you will add filter logic inside the workflow to act only on payment success events.

Next, add PandaDoc credentials so n8n can generate proposals.

  • In n8n, go to Settings then Credentials.
  • Click Add Credential and search for Header Auth.
  • Set the Header Name to Authorization.
  • Set the Header Value to API-Key followed by a space and your PandaDoc API key (for example: API-Key your-pandadoc-api-key-here).
  • Name this credential something recognizable like PandaDoc API.
  • Save the credential.

Now confirm the PandaDoc connection works with a quick test call.

  • In your workflow, add an HTTP Request node after the Stripe Trigger.
  • Set the method to GET.
  • Set the URL to:
https://api.pandadoc.com/public/v1/documents
  • Under Authentication, select Header Auth and choose the PandaDoc credential you just created.
  • Click Test step (or execute the node manually).
  • You should see a JSON response with a results array (it may be empty if your account is new). A 200 status confirms connectivity.

Getting a 401 from PandaDoc?

Double-check that your Header Value is formatted exactly as API-Key followed by a space and then your key. The prefix is required. Also confirm your PandaDoc account is on the Business plan or higher, which is required for API access.

Ask for help: Why is my PandaDoc API call returning 401 Unauthorized in n8n?

Create Stripe Products and record Price IDs

Each payment gate on the pipeline needs a corresponding Stripe Product and Price. When n8n generates a payment link for a client, it references these Price IDs.

  • Open the Stripe Dashboard in your browser. Make sure you are in test mode (toggle at the top).
  • Navigate to Product catalog (or Products in older dashboard layouts).
  • Click Add product.

Create the first three products as one-time payments representing the milestone gates.

  • Product 1: Name it Deposit (50%). Set the pricing to One time and enter a placeholder amount (for example, $1.00 in test mode). Save.
  • Product 2: Name it Design Approval (25%). Same settings. Save.
  • Product 3: Name it Final Acceptance (25%). Same settings. Save.

Now create the retainer product with recurring billing.

  • Product 4: Name it Monthly Retainer. Set the pricing to Recurring with billing period Monthly. Enter a placeholder amount. Save.

Why placeholder amounts?

The actual fee per client will vary based on the engagement. When n8n generates a payment link, it uses the Price ID but sets the quantity dynamically based on the client's agreed fee. The placeholder price ensures the Product and Price objects exist in Stripe.

  • For each of the four products, open the product detail page and find the Price ID (it starts with price_).
  • Record all four Price IDs somewhere accessible (a note in Notion, a text file, or directly in a comment in your n8n workflow). You will reference these when building the payment-link generation workflow.

Keep Price IDs handy

You will use these four IDs as the line_items when n8n creates Stripe Payment Links via the API in a later step. Label each ID clearly: Deposit, Design Approval, Final Acceptance, Monthly Retainer.

🙋‍♀️ Cannot find the Price ID?

After saving a product, click into the product detail page. Scroll to the Pricing section. The Price ID is displayed next to the price you created. It looks like price_1MoBy5LkdIwHu7ixZhnattbh.

Ask for help: Where do I find the Price ID for a Stripe Product in test mode?

Your stack is wired. Every integration the pipeline needs is live and confirmed: Claude Code reads meeting notes via MCP, Notion tracks client state, n8n listens for Stripe events, PandaDoc responds to API calls, and the four payment-gate products are ready in Stripe.

Next up, you will codify the practitioner patterns and draw the end-to-end topology that the build executes from.

Codify Principles, Agent Org, and Topology

Your stack is wired and every integration point is live. Now you need the design layer that tells the stack what to do.

Without explicit principles, your pipeline will drift over time. Without named agent roles, Claude Code won't know which lens to apply at each station. This step produces the three pre-artifacts that the rest of the build executes from: decision records, an agent roster, and a topology diagram.

In this step, get ready to:
  • Write five decision records codifying the practitioner patterns that govern the pipeline.
  • Define the agent organization roster with approximately fourteen specialized roles.
  • Produce the end-to-end topology diagram showing stations, gates, and data flows.
Write five practitioner patterns as decision records

The pipeline needs governing principles that are written down, not assumed. A decision record captures the pattern, the decision, and the rationale so your future self and your agents can reference them without guessing.

  • Create a new page in your Notion workspace (or a markdown file in your project repo) titled Decision Records.
  • Paste the following five decision records into the page:
# Decision Records

## DR-1: Conceptual Agreement Before Proposal

**Pattern:** Conceptual agreement before proposal.

**Decision:** Objectives, metrics, and value are agreed with the economic buyer before anything is written.

**Rationale:** The proposal closes instead of negotiates. If the buyer has already agreed on the outcome and its value, the written document confirms what was discussed rather than opening a new round of back-and-forth.

---

## DR-2: No Payment No Next Station

**Pattern:** No payment, no next station.

**Decision:** Every gate requires written sign-off and cleared payment. The work-pause clause makes this automatic.

**Rationale:** Solo practice protection. The operator cannot absorb unpaid delivery risk. The clause does the enforcing so no confrontation is needed.

---

## DR-3: Bounded Refinement

**Pattern:** Bounded refinement with change-order procedure.

**Decision:** Two rounds refine approved work only. Anything new is a priced change order with new money.

**Rationale:** Standard professional services practice. Prevents scope creep from consuming margin. New requests are welcomed but carry their own fee and timeline.

---

## DR-4: Value First Fee Second

**Pattern:** Value stated before price in every option.

**Decision:** The offer is three options anchored high. Each option leads with the outcome delivered, then states the fee.

**Rationale:** The buyer evaluates the outcome before encountering the number. Anchoring high makes the recommended option feel proportionate.

---

## DR-5: Wow Then Retain

**Pattern:** Retainer pitched only after a proven win.

**Decision:** The retainer is pitched only after the value-versus-fee statement proves the engagement delivered more value than it cost.

**Rationale:** Pitched before a win, the retainer reads as a cash grab. Pitched after, it reads as a continuation of demonstrated value.

What do these records protect?

Each record solves a specific failure mode solo advisors hit:

  • DR-1 stops proposals that get negotiated to death because the buyer never agreed on value upfront.
  • DR-2 stops unpaid work by making the system pause automatically.
  • DR-3 stops scope creep from eating your margin.
  • DR-4 stops fee objections by framing value before the number appears.
  • DR-5 stops the retainer pitch from feeling like a cash grab.
  • Save the page or file.
  • Confirm you can see all five records (DR-1 through DR-5) with their pattern, decision, and rationale filled in.

Not sure where to store these?

If you are using Notion, create the page inside the same workspace as your CRM database. If you prefer a project repo, create a docs/ folder and save as decision-records.md. Either location works as long as you and Claude Code can reference them later.

Help me decide where to store my decision records.

Define the agent organization roster

Each station on the conveyor needs a specialized lens. In the orchestrator-subagent pattern, the orchestrator plans work and delegates bounded subtasks to subagents with specialized instructions. Each role below becomes a system prompt that Claude Code invokes for its station.

  • Create a new page or file titled Agent Organization Roster.
  • Paste the following fourteen role definitions:
# Agent Organization Roster

Approximately fourteen roles, collapsed for solo operation.
Each role is a specialized system prompt invoked by the Orchestrator within Claude Code.

---

## Cross-Station: Orchestrator

**Role:** Principal advisor persona. Routes work to the correct station agent, enforces gate logic, and synthesizes results across stations.

**System prompt focus:** You are the principal advisor managing a seven-station client pipeline. Route each task to the appropriate station agent. Enforce gate requirements (written sign-off + cleared payment) before advancing. Synthesize subagent outputs into client-ready deliverables.

---

## Station 1 (Intake): Meeting-Note Parser

**Role:** Extracts structured data from raw meeting notes.

**System prompt focus:** You parse meeting transcripts from Granola or Pocket. Extract: client name, stated problem, objectives, success metrics, budget signals, and decision-maker identity. Output a structured requirement set.

---

## Station 1 (Intake): Requirements-and-Qualification Agent

**Role:** Normalizes requirements and qualifies whether conceptual agreement has been reached.

**System prompt focus:** You take raw extracted data and normalize it into a structured requirement set. Flag whether objectives, metrics, and value have been agreed with the economic buyer (per DR-1). If not, identify gaps.

---

## Station 2 (Scope): Value-Pricing Agent

**Role:** Produces three-option value-based pricing anchored high.

**System prompt focus:** You take a requirement set and produce three options. Option A is highest value and fee (the anchor). Option B is recommended. Option C is minimum viable. State the outcome before the fee in every option (per DR-4).

---

## Station 2 (Scope): Proposal Agent

**Role:** Populates the proposal/SOW template and sends for signature.

**System prompt focus:** You take the three pricing options and populate the PandaDoc template with client-specific values, acceptance criteria per station, the change-order procedure (DR-3), work-pause clause (DR-2), and deemed-acceptance clause. Prepare the document for e-signature.

---

## Station 3 (Design): Solution Designer

**Role:** Produces a right-sized solution design against the approved option.

**System prompt focus:** You take the signed proposal (selected option) and produce a solution design scoped exactly to the agreed deliverables. Do not exceed the approved scope. Flag anything that would require a change order.

---

## Station 3 (Design): Cost-Model Agent

**Role:** Produces effort, tools, and timeline estimates for the approved design.

**System prompt focus:** You take the solution design and estimate effort (hours), required tools, and a realistic timeline. Your output informs the Build station and validates that the fee covers the cost.

---

## Station 4 (Build): Build Lead

**Role:** Plans the build work against the approved design.

**System prompt focus:** You break the approved design into discrete tasks with dependencies and sequence. Assign each task to the Build Executor. Define done criteria aligned with the station acceptance criteria.

---

## Station 4 (Build): Build Executor

**Role:** Executes build tasks against the plan.

**System prompt focus:** You execute each assigned task to meet the done criteria. Stay within the approved design scope. If you identify a gap or conflict, escalate to Build Lead rather than improvising.

---

## Station 4 (Build): Build Reviewer

**Role:** Reviews build output against design and acceptance criteria.

**System prompt focus:** You compare the build output to the approved design and the acceptance criteria in the signed SOW. Approve, request rework (within bounded refinement), or flag a scope gap for change-order handling.

---

## Station 5 (Demo): Demo-and-Acceptance Agent

**Role:** Presents the deliverable and manages the acceptance process.

**System prompt focus:** You present the completed deliverable to the client. Walk through how it meets each acceptance criterion. Capture written sign-off or specific feedback for refinement rounds.

---

## Station 5 (Demo): Refinement-and-Change-Order Agent

**Role:** Manages bounded refinement and catches new-scope requests.

**System prompt focus:** You manage up to two refinement rounds on approved work only (per DR-3). If the client requests anything outside the approved scope, produce a priced change order with its own fee, timeline, and acceptance criteria. Do not absorb new scope into existing rounds.

---

## Cross-Station: Billing-and-Gate Agent

**Role:** Runs the money layer across all stations.

**System prompt focus:** You manage payment gates. When a station reaches a gate, generate the appropriate Stripe payment link, send it to the client, and monitor for clearance. Enforce the work-pause clause (DR-2): if payment is not cleared within the deemed-acceptance window, block all downstream work. On clearance, advance the CRM state and trigger the next station.

---

## Station 7 (Support): Retainer Agent

**Role:** Pitches and manages the ongoing retainer relationship.

**System prompt focus:** You pitch the tiered care-plan retainer only after the value-versus-fee statement proves the win (per DR-5). Recommend a tier based on engagement complexity. Manage the monthly billing cycle and ongoing support requests.

Why fourteen roles for one person?

You are not fourteen people. Each role is a specialized system prompt that Claude Code switches into when the orchestrator delegates a bounded subtask. The separation exists so the pipeline can scale to a small team later without redesign.

For simple engagements, the three Build roles (Lead, Executor, Reviewer) collapse to one. The orchestrator handles Station 6 (Deliver) directly with the Billing-and-Gate Agent.

  • Save the agent roster page or file.
  • Confirm you can see all fourteen roles listed with their station assignment, role description, and system prompt focus.

Some roles feel redundant?

The Meeting-Note Parser and Requirements-and-Qualification Agent both operate at Station 1, but they handle different tasks. The Parser does raw extraction. The Qualification Agent does normalization and gap analysis. If your engagements are simple, you can merge them into one prompt later. Start with the full roster and collapse after you see the pattern in action.

Help me understand which agent roles I can safely merge.

Produce the end-to-end topology diagram

Before building the automation flows, you need a reference diagram showing how the seven stations, four gates, and integrations connect. This is not a runtime UI. It is the map the build executes from.

  • Create a new page or file titled Pipeline Topology.
  • Paste the following Mermaid diagram (or ask Claude Code to render it for you):
flowchart LR
    %% Data Sources
    MCP["Granola/Pocket MCP"] --> S1

    %% Seven Stations
    S1["Station 1:\nIntake & Discovery"]
    S2["Station 2:\nScope & Proposal"]
    S3["Station 3:\nDesign"]
    S4["Station 4:\nBuild"]
    S5["Station 5:\nDemo & Refine"]
    S6["Station 6:\nDeliver"]
    S7["Station 7:\nSupport & Retainer"]

    %% Station Flow
    S1 --> S2
    S2 --> G1
    G1 --> S3
    S3 --> G2
    G2 --> S4
    S4 --> S5
    S5 --> G3
    G3 --> S6
    S6 --> S7
    S7 --> G4

    %% Payment Gates
    G1{{"Gate 1:\n50% Deposit"}}
    G2{{"Gate 2:\n25% Design Approval"}}
    G3{{"Gate 3:\n25% Final Acceptance"}}
    G4{{"Gate 4:\nMonthly Retainer"}}

    %% Integrations (all stations)
    S1 -.- Notion[("Notion CRM\nState Tracking")]
    S2 -.- Notion
    S3 -.- Notion
    S4 -.- Notion
    S5 -.- Notion
    S6 -.- Notion
    S7 -.- Notion

    %% PandaDoc at Scope
    S2 -.- PD["PandaDoc:\nProposal & SOW"]

    %% Stripe at Gates
    G1 -.- Stripe["Stripe:\nPayment Links"]
    G2 -.- Stripe
    G3 -.- Stripe
    G4 -.- Stripe

    %% n8n connects everything
    N8N["n8n Workflows"] -.- G1
    N8N -.- G2
    N8N -.- G3
    N8N -.- G4
    N8N -.- Notion
    N8N -.- Stripe
    N8N -.- PD

What does this diagram show?

  • Seven stations flow left to right as the engagement progresses.
  • Four diamond-shaped gates sit between stations where payment must clear before work continues.
  • Granola or Pocket MCP feeds meeting data into Station 1.
  • Notion CRM tracks state across all seven stations.
  • PandaDoc connects at Station 2 for proposal and SOW generation.
  • Stripe connects at every gate for payment link generation.
  • n8n workflows wire the gates, CRM updates, Stripe, and PandaDoc together.
  • Save the topology file or Notion page.
  • Render the diagram by pasting it into a Mermaid-compatible viewer (such as mermaid.live in your browser, or a Mermaid plugin in VS Code or Notion).
  • Confirm you can see seven station nodes, four gate diamonds between them, and the integration connections (MCP, Notion, PandaDoc, Stripe, n8n) attached to the correct points.

Diagram not rendering?

If pasting into mermaid.live, make sure you paste only the diagram code (starting with flowchart LR) without the markdown code fence markers. If using a Notion embed or VS Code extension, check that the Mermaid plugin is installed and enabled.

Help me render my Mermaid topology diagram.

✔️ Awesome, I've got everything!

Great. Double check you have saved all three artifacts: decision records (DR-1 through DR-5), the agent roster (fourteen roles), and the topology diagram.

ⓧ I'd like to double check the full code

Here are the three artifacts you should have at this point. Compare yours against these.

Decision Records (decision-records.md or Notion page):

# Decision Records

## DR-1: Conceptual Agreement Before Proposal

**Pattern:** Conceptual agreement before proposal.

**Decision:** Objectives, metrics, and value are agreed with the economic buyer before anything is written.

**Rationale:** The proposal closes instead of negotiates. If the buyer has already agreed on the outcome and its value, the written document confirms what was discussed rather than opening a new round of back-and-forth.

---

## DR-2: No Payment No Next Station

**Pattern:** No payment, no next station.

**Decision:** Every gate requires written sign-off and cleared payment. The work-pause clause makes this automatic.

**Rationale:** Solo practice protection. The operator cannot absorb unpaid delivery risk. The clause does the enforcing so no confrontation is needed.

---

## DR-3: Bounded Refinement

**Pattern:** Bounded refinement with change-order procedure.

**Decision:** Two rounds refine approved work only. Anything new is a priced change order with new money.

**Rationale:** Standard professional services practice. Prevents scope creep from consuming margin. New requests are welcomed but carry their own fee and timeline.

---

## DR-4: Value First Fee Second

**Pattern:** Value stated before price in every option.

**Decision:** The offer is three options anchored high. Each option leads with the outcome delivered, then states the fee.

**Rationale:** The buyer evaluates the outcome before encountering the number. Anchoring high makes the recommended option feel proportionate.

---

## DR-5: Wow Then Retain

**Pattern:** Retainer pitched only after a proven win.

**Decision:** The retainer is pitched only after the value-versus-fee statement proves the engagement delivered more value than it cost.

**Rationale:** Pitched before a win, the retainer reads as a cash grab. Pitched after, it reads as a continuation of demonstrated value.

Agent Organization Roster (agent-roster.md or Notion page):

# Agent Organization Roster

Approximately fourteen roles, collapsed for solo operation.
Each role is a specialized system prompt invoked by the Orchestrator within Claude Code.

---

## Cross-Station: Orchestrator

**Role:** Principal advisor persona. Routes work to the correct station agent, enforces gate logic, and synthesizes results across stations.

**System prompt focus:** You are the principal advisor managing a seven-station client pipeline. Route each task to the appropriate station agent. Enforce gate requirements (written sign-off + cleared payment) before advancing. Synthesize subagent outputs into client-ready deliverables.

---

## Station 1 (Intake): Meeting-Note Parser

**Role:** Extracts structured data from raw meeting notes.

**System prompt focus:** You parse meeting transcripts from Granola or Pocket. Extract: client name, stated problem, objectives, success metrics, budget signals, and decision-maker identity. Output a structured requirement set.

---

## Station 1 (Intake): Requirements-and-Qualification Agent

**Role:** Normalizes requirements and qualifies whether conceptual agreement has been reached.

**System prompt focus:** You take raw extracted data and normalize it into a structured requirement set. Flag whether objectives, metrics, and value have been agreed with the economic buyer (per DR-1). If not, identify gaps.

---

## Station 2 (Scope): Value-Pricing Agent

**Role:** Produces three-option value-based pricing anchored high.

**System prompt focus:** You take a requirement set and produce three options. Option A is highest value and fee (the anchor). Option B is recommended. Option C is minimum viable. State the outcome before the fee in every option (per DR-4).

---

## Station 2 (Scope): Proposal Agent

**Role:** Populates the proposal/SOW template and sends for signature.

**System prompt focus:** You take the three pricing options and populate the PandaDoc template with client-specific values, acceptance criteria per station, the change-order procedure (DR-3), work-pause clause (DR-2), and deemed-acceptance clause. Prepare the document for e-signature.

---

## Station 3 (Design): Solution Designer

**Role:** Produces a right-sized solution design against the approved option.

**System prompt focus:** You take the signed proposal (selected option) and produce a solution design scoped exactly to the agreed deliverables. Do not exceed the approved scope. Flag anything that would require a change order.

---

## Station 3 (Design): Cost-Model Agent

**Role:** Produces effort, tools, and timeline estimates for the approved design.

**System prompt focus:** You take the solution design and estimate effort (hours), required tools, and a realistic timeline. Your output informs the Build station and validates that the fee covers the cost.

---

## Station 4 (Build): Build Lead

**Role:** Plans the build work against the approved design.

**System prompt focus:** You break the approved design into discrete tasks with dependencies and sequence. Assign each task to the Build Executor. Define done criteria aligned with the station acceptance criteria.

---

## Station 4 (Build): Build Executor

**Role:** Executes build tasks against the plan.

**System prompt focus:** You execute each assigned task to meet the done criteria. Stay within the approved design scope. If you identify a gap or conflict, escalate to Build Lead rather than improvising.

---

## Station 4 (Build): Build Reviewer

**Role:** Reviews build output against design and acceptance criteria.

**System prompt focus:** You compare the build output to the approved design and the acceptance criteria in the signed SOW. Approve, request rework (within bounded refinement), or flag a scope gap for change-order handling.

---

## Station 5 (Demo): Demo-and-Acceptance Agent

**Role:** Presents the deliverable and manages the acceptance process.

**System prompt focus:** You present the completed deliverable to the client. Walk through how it meets each acceptance criterion. Capture written sign-off or specific feedback for refinement rounds.

---

## Station 5 (Demo): Refinement-and-Change-Order Agent

**Role:** Manages bounded refinement and catches new-scope requests.

**System prompt focus:** You manage up to two refinement rounds on approved work only (per DR-3). If the client requests anything outside the approved scope, produce a priced change order with its own fee, timeline, and acceptance criteria. Do not absorb new scope into existing rounds.

---

## Cross-Station: Billing-and-Gate Agent

**Role:** Runs the money layer across all stations.

**System prompt focus:** You manage payment gates. When a station reaches a gate, generate the appropriate Stripe payment link, send it to the client, and monitor for clearance. Enforce the work-pause clause (DR-2): if payment is not cleared within the deemed-acceptance window, block all downstream work. On clearance, advance the CRM state and trigger the next station.

---

## Station 7 (Support): Retainer Agent

**Role:** Pitches and manages the ongoing retainer relationship.

**System prompt focus:** You pitch the tiered care-plan retainer only after the value-versus-fee statement proves the win (per DR-5). Recommend a tier based on engagement complexity. Manage the monthly billing cycle and ongoing support requests.

Topology Diagram (topology.mmd or Notion page):

flowchart LR
    %% Data Sources
    MCP["Granola/Pocket MCP"] --> S1

    %% Seven Stations
    S1["Station 1:\nIntake & Discovery"]
    S2["Station 2:\nScope & Proposal"]
    S3["Station 3:\nDesign"]
    S4["Station 4:\nBuild"]
    S5["Station 5:\nDemo & Refine"]
    S6["Station 6:\nDeliver"]
    S7["Station 7:\nSupport & Retainer"]

    %% Station Flow
    S1 --> S2
    S2 --> G1
    G1 --> S3
    S3 --> G2
    G2 --> S4
    S4 --> S5
    S5 --> G3
    G3 --> S6
    S6 --> S7
    S7 --> G4

    %% Payment Gates
    G1{{"Gate 1:\n50% Deposit"}}
    G2{{"Gate 2:\n25% Design Approval"}}
    G3{{"Gate 3:\n25% Final Acceptance"}}
    G4{{"Gate 4:\nMonthly Retainer"}}

    %% Integrations (all stations)
    S1 -.- Notion[("Notion CRM\nState Tracking")]
    S2 -.- Notion
    S3 -.- Notion
    S4 -.- Notion
    S5 -.- Notion
    S6 -.- Notion
    S7 -.- Notion

    %% PandaDoc at Scope
    S2 -.- PD["PandaDoc:\nProposal & SOW"]

    %% Stripe at Gates
    G1 -.- Stripe["Stripe:\nPayment Links"]
    G2 -.- Stripe
    G3 -.- Stripe
    G4 -.- Stripe

    %% n8n connects everything
    N8N["n8n Workflows"] -.- G1
    N8N -.- G2
    N8N -.- G3
    N8N -.- G4
    N8N -.- Notion
    N8N -.- Stripe
    N8N -.- PD

Your design layer is locked in. You have the principles (decision records), the team (agent roster), and the map (topology). Next up, you will build the offer engine that produces three-option pricing and the contract artifacts that make the gates self-enforcing.

Build the Offer Engine, Contract Layer, and Billing Schedule

You have the principles codified and the topology drawn. Now you need the money layer: the engine that prices your work, the contracts that protect your delivery, and the automation that collects payment at every gate.

This step builds three artifacts. The pricing template frames every engagement as three value-anchored options. The proposal template makes gates self-enforcing with work-pause and deemed-acceptance clauses. The n8n billing workflow creates Stripe payment links automatically when a client reaches a gate.

In this step, get ready to:
  • Create a three-option value-based pricing template with token placeholders.
  • Build a one-page proposal/SOW template with self-enforcing clauses.
  • Wire an n8n billing workflow that generates Stripe payment links on gate advance.
Create the three-option value-based pricing template

Decision Record DR-4 (Value First Fee Second) says value is stated before price. The pricing template puts that principle into a repeatable structure that your Value-Pricing Agent will populate for every new engagement.

  • Open PandaDoc and navigate to **Templates** in the left sidebar.
  • Click **Create Template** and select **Blank Template**.
  • Name it Three-Option Value-Based Proposal.

The template needs three columns representing your three options. Each column follows the same structure: outcome first, then deliverables, then acceptance criteria, then fee.

  • Add a table or three-column layout to your template with the following structure:
# Three-Option Value-Based Proposal

Client: [Client.Company]
Objective: [Client.Objective]
Success Metric: [Client.SuccessMetric]

## Option A — Highest Value (Anchored First)
Outcome: [Option.AValue]
Deliverables: (list specific deliverables)
Acceptance Criteria: (measurable per station)
Fee: [Option.AFee]

## Option B — Recommended
Outcome: [Option.BValue]
Deliverables: (list specific deliverables)
Acceptance Criteria: (measurable per station)
Fee: [Option.BFee]

## Option C — Minimum Viable Engagement
Outcome: [Option.CValue]
Deliverables: (list specific deliverables)
Acceptance Criteria: (measurable per station)
Fee: [Option.CFee]

What does this structure do?

The three-column layout anchors high by presenting Option A first. The client sees the highest-value outcome before encountering any fee. By the time they reach Option C, the mid-range Option B feels like the natural choice.

Token placeholders (the bracketed names like Client.Company and Option.AValue) allow your automation to populate each proposal dynamically per client.

  • In PandaDoc, add each bracketed token as a variable in your template. The required tokens are: Client.Company, Client.Objective, Client.SuccessMetric, Option.AValue, Option.AFee, Option.BValue, Option.BFee, Option.CValue, Option.CFee.
  • Add a signature field at the bottom of the template assigned to the "Client" role.
  • Click **Save** in the top right corner.

Why PandaDoc tokens instead of plain text?

When n8n creates a document from this template via the PandaDoc API, it passes a tokens array with name/value pairs. PandaDoc replaces each bracketed token with the real client data. This means one template serves every client without manual edits.

  • Verify your template by clicking **Preview**. You should see the three options laid out with bracketed placeholders visible where dynamic data will appear.

Tokens not appearing in preview?

Make sure each token name in PandaDoc matches the exact format shown above (e.g. Client.Company with the dot separator). PandaDoc treats these as case-sensitive identifiers.

If you're building in Notion instead, create each token as a database property that your n8n workflow will populate.

Why aren't my PandaDoc tokens rendering when I preview the template?

Build the proposal/SOW template with self-enforcing clauses

The pricing template gets a client to say yes. The proposal/SOW template protects your delivery once they do. It carries measurable acceptance criteria, bounded refinement rules, and clauses that pause work automatically on non-payment.

  • In PandaDoc, create a second template. Name it Proposal and SOW — [Client.Company].
  • Add the following sections to the template body:
# Proposal and Statement of Work

## 1. Acceptance Criteria (per station)
- Station 1 (Intake): Requirement set approved by client
- Station 2 (Scope): Proposal signed with deposit cleared
- Station 3 (Design): Solution design approved in writing
- Station 4 (Build): Deliverable matches approved design
- Station 5 (Demo): Client sign-off after refinement rounds
- Station 6 (Deliver): Files/access released on final payment
- Station 7 (Support): Retainer agreement signed

## 2. Change-Order Procedure
New scope identified during any station triggers a written change
order. Each change order carries its own fee, timeline, and
acceptance criteria. Change orders do not absorb into existing
refinement rounds. Work on the change order begins only after
the change-order fee is paid.

## 3. Work-Pause Clause
If a payment gate is not cleared within five (5) business days
of invoice, all work pauses automatically until payment clears.
No notice is required beyond the original invoice. Work resumes
within two (2) business days of payment clearance.

## 4. Deemed-Acceptance Clause
If written sign-off is not received within five (5) business days
of deliverable submission (material defects excepted), the
deliverable is deemed accepted and the corresponding gate
payment becomes due immediately.

## 5. Billing Schedule
- 50% deposit on proposal signature (before delivery work begins)
- 25% on design approval (before build begins)
- 25% at final acceptance (before files/access are released)
- Monthly retainer billed in advance (after project completion)

All percentages are configurable defaults agreed per engagement.

## 6. Bounded Refinement
Two (2) refinement rounds are included per station. Refinement
refines approved work only. Any request outside the approved
scope triggers the Change-Order Procedure (Section 2).

What do these clauses do?

The work-pause clause (Section 3) eliminates the need for awkward payment conversations. If a client doesn't pay within five business days, work stops automatically. The clause does the enforcing so you don't have to.

The deemed-acceptance clause (Section 4) prevents indefinite review cycles. If the client doesn't respond to a deliverable within five business days, it's accepted and the gate payment fires. Material defects are explicitly excepted so the clause stays fair.

The billing schedule (Section 5) maps directly to your four Stripe payment gates. Each percentage triggers a payment link at the corresponding gate.

  • Add the same token placeholders from your pricing template (Client.Company, Client.Objective, Client.SuccessMetric) to the proposal header.
  • Add a signature field assigned to the "Client" role.
  • Save the template.
  • Verify by previewing the template. You should see all seven station criteria, the four clauses, and the billing schedule with bracketed tokens in the header.

Combine both templates into one

For real engagements, you may merge the three-option pricing and the SOW clauses into a single PandaDoc template. Keeping them separate during the build lets you test each independently.

Wire the billing schedule to Stripe via n8n

The templates define the rules. Now you need automation that enforces them. This n8n workflow fires whenever a client reaches a payment gate in your Notion CRM. It calculates the amount owed, generates a Stripe payment link, and writes it back to the client's record.

  • Switch back to your n8n instance.
  • Create a new workflow. Name it Billing Gate — Payment Link Generator.
  • Add a **Notion Trigger** node as the starting point. Configure it to watch your pipeline CRM database for page updates where the **Gate Status** field changes to Pending Payment.

Why trigger on Notion instead of Stripe?

The gate advance happens in your CRM first. When the orchestrator (or you) moves a client to a payment gate, Notion fires the trigger. Stripe only enters the picture when it's time to generate the payment link. This keeps your CRM as the single source of truth for pipeline state.

  • Add a **Notion** node (Get Page) after the trigger. Configure it to read the client record's fields: Client Name, Station, and the engagement fee stored in your CRM.
  • Add a **Code** node to calculate the gate amount. The logic multiplies the total engagement fee by the gate percentage (50% for Gate 1, 25% for Gate 2, 25% for Gate 3).
// Calculate the gate payment amount
const engagementFee = $input.item.json.engagement_fee;
const station = $input.item.json.station;

// Gate percentages (configurable defaults)
const gatePercentages = {
  'Scope': 0.50,    // Gate 1: 50% deposit
  'Design': 0.25,   // Gate 2: 25% on design approval
  'Demo': 0.25      // Gate 3: 25% at final acceptance
};

const percentage = gatePercentages[station] || 0;
const gateAmount = Math.round(engagementFee * percentage);

return {
  gate_amount: gateAmount,
  gate_name: `Gate - ${station}`,
  client_id: $input.item.json.client_id,
  price_id: $input.item.json.price_id
};

What does this code do?

  • `engagementFee` reads the total project fee from the Notion record.
  • `gatePercentages` maps each station name to its billing split (50/25/25 as configurable defaults from DR-2).
  • The output includes the calculated gate_amount, the gate name for metadata, and the price_id you recorded when creating Stripe Products in Step 1.
  • Add an **HTTP Request** node after the Code node. This node creates the Stripe Payment Link. Configure it with the following settings:
  • Set **Method** to POST.
  • Set **URL** to https://api.stripe.com/v1/payment_links.
  • Under **Authentication**, select **Predefined Credential Type** and choose your Stripe credential.
  • Enable **Send Body** and set **Body Content Type** to **Form URLencoded**.
  • Add body parameters using **Fields Below** with these name/value pairs:
Name: line_items[0][price]
Value: {{ $json.price_id }}

Name: line_items[0][quantity]
Value: 1

Name: metadata[gate_name]
Value: {{ $json.gate_name }}

Name: metadata[client_id]
Value: {{ $json.client_id }}

What does this HTTP Request do?

This calls Stripe's Payment Links API at POST /v1/payment_links. The line_items array is required and references one of the Price IDs you created in Step 1. The metadata object tags each payment link with the gate name and client ID so your Stripe Trigger node can match incoming payments back to the right client and gate.

The response returns a url field containing the shareable payment link (e.g. https://buy.stripe.com/...).

  • Add a second **Notion** node (Update Page) after the HTTP Request. Configure it to write the url from the Stripe response back into the client's **Payment Links** field in your CRM.
  • Optionally add a final node (email, Slack, or another channel) to send the payment link to the client.
  • Save the workflow by clicking **Save** in the top right corner of n8n.
  • Test the workflow by manually updating a test record in your Notion CRM. Change the **Gate Status** to Pending Payment and confirm the workflow executes.
  • Check the execution log in n8n. You should see a successful HTTP 200 response from Stripe containing a url field with your generated payment link.
  • Verify the payment link URL was written back to the Notion CRM record's Payment Links field.

Seeing a 403 or 401 from Stripe?

Confirm your n8n Stripe credential uses the Secret Key (starting with sk_test_), not the Publishable Key. Publishable keys (pk_ prefix) do not work with server-side API calls.

If you see a 400 error mentioning line_items, double-check that your Price ID matches one of the four Products you created in Step 1. The Price ID format starts with price_.

Help me debug my n8n HTTP Request to Stripe's payment_links endpoint

✔️ Awesome, I've got everything!

Great. Make sure you've saved both PandaDoc templates and that the n8n billing workflow executed successfully against a test record.

ⓧ I'd like to double check the full workflow

Your n8n billing workflow should have five nodes in this order:

  • **Notion Trigger** — watches for Gate Status changing to Pending Payment.
  • **Notion (Get Page)** — reads client name, station, engagement fee, and price ID.
  • **Code** — calculates gate amount using the 50/25/25 percentage map.
  • **HTTP Request** — POST to https://api.stripe.com/v1/payment_links with line_items and metadata as form-urlencoded body parameters, authenticated via Predefined Credential Type (Stripe).
  • **Notion (Update Page)** — writes the returned payment link URL back to the CRM record.

Your offer engine, contract layer, and billing automation are live. Next up, you'll wire the seven stations of the pipeline together with the agent organization executing each one and the payment gates enforcing progress.

Build the Seven-Station Pipeline with Gate Enforcement

You have your decision records, agent roster, templates, and billing workflow ready. Now it is time to wire the actual pipeline: seven stations that carry a client from meeting note to retained status, with payment gates enforcing the boundaries between each phase.

Each station is powered by one or more agent roles from your roster. The orchestrator routes work between them while the Billing-and-Gate Agent ensures no station advances without cleared payment.

In this step, get ready to:
  • Wire Stations 1-3 (Intake, Scope, and Design) with their agent roles and Gates 1-2.
  • Wire Stations 4-5 (Build and Demo) with the Build team and Gate 3.
  • Wire Stations 6-7 (Deliver and Support) with the Retainer Agent and build the gate enforcement workflow in n8n.
Wire Stations 1-3 (Intake through Design)

The first three stations take a prospect from a raw meeting note to an approved design. Each station has a clear output and a gate that blocks forward movement until payment clears.

Station 1: Intake and Discovery

The Meeting-Note Parser agent reads the client's meeting note via MCP and extracts the structured data your pipeline needs. The Requirements-and-Qualification Agent then normalizes this into a requirement set and flags whether conceptual agreement has been reached.

  • In Claude Code, create the Meeting-Note Parser system prompt. This agent extracts: client name, stated problem, objectives, success metrics, budget signals, and decision-maker from the meeting note.
  • Create the Requirements-and-Qualification Agent system prompt. This agent normalizes the extracted data into a structured requirement set and flags whether conceptual agreement (objectives, metrics, value agreed with economic buyer) is in place per DR-1.
  • Configure the orchestrator to invoke these agents sequentially when a new meeting note arrives via the Granola or Pocket MCP connection.
  • Store the output (normalized requirement set) in your Notion CRM by updating the client record with the extracted fields.

What does Station 1 produce?

A structured requirement set stored in Notion with all the data the Value-Pricing Agent needs to produce options. The conceptual-agreement flag tells the orchestrator whether the engagement is ready for Station 2 or needs another conversation first.

Station 2: Scope and Proposal

Once conceptual agreement is confirmed, Station 2 produces the three-option proposal and sends it for e-signature. On signature, Gate 1 fires.

  • Create the Value-Pricing Agent system prompt. This agent takes the requirement set and produces three options anchored high (Option A highest value/fee, Option B recommended, Option C minimum viable), following DR-4.
  • Create the Proposal Agent system prompt. This agent populates the PandaDoc template with the three options, acceptance criteria, and self-enforcing clauses from your SOW template.
  • In n8n, build a workflow that sends the populated proposal for e-signature. Add an HTTP Request node configured as follows:
Method: POST
URL: https://api.pandadoc.com/public/v1/documents
Authentication: HTTP Header Auth (your PandaDoc API key)
Body (JSON):
{
  "name": "Proposal - {{Client.Company}}",
  "template_uuid": "your-template-uuid-here",
  "recipients": [
    {
      "email": "{{client_email}}",
      "first_name": "{{client_first_name}}",
      "last_name": "{{client_last_name}}",
      "role": "Signer"
    }
  ],
  "tokens": [
    { "name": "Client.Company", "value": "{{client_company}}" },
    { "name": "Client.Objective", "value": "{{client_objective}}" },
    { "name": "Client.SuccessMetric", "value": "{{client_success_metric}}" },
    { "name": "Option.AValue", "value": "{{option_a_value}}" },
    { "name": "Option.AFee", "value": "{{option_a_fee}}" },
    { "name": "Option.BValue", "value": "{{option_b_value}}" },
    { "name": "Option.BFee", "value": "{{option_b_fee}}" },
    { "name": "Option.CValue", "value": "{{option_c_value}}" },
    { "name": "Option.CFee", "value": "{{option_c_fee}}" }
  ]
}

What does this HTTP Request do?

It creates a new PandaDoc document from your proposal template, pre-filling the token placeholders with the client-specific values the Value-Pricing Agent produced. Document creation is asynchronous. PandaDoc returns a document ID immediately, but you must wait for the document to reach document.draft status before sending it.

After the document reaches draft status, a second HTTP Request node sends it for signature via POST https://api.pandadoc.com/public/v1/documents/{DOCUMENT_ID}/send.

  • Add a second HTTP Request node to send the document for e-signature once it reaches draft status.
  • On proposal signature, the orchestrator advances the client's Station field in Notion to the gate position. This triggers the existing billing workflow that generates the Gate 1 (50% deposit) Stripe Payment Link.
  • The conveyor now pauses. No downstream station fires until the deposit payment clears.

Why does the conveyor pause here?

This enforces DR-2 (No Payment No Next Station). The work-pause clause in your SOW gives the client five business days to pay. If they do not pay, no design work begins. The clause does the enforcement. You do not need to send awkward follow-up emails.

Station 3: Design
  • Create the Solution Designer agent system prompt. This agent produces a right-sized solution design based on the approved scope from the signed proposal.
  • Create the Cost-Model Agent system prompt. This agent produces a simple cost model covering effort, tools, and timeline.
  • Configure the orchestrator to invoke these agents only when Gate 1 status shows Cleared in Notion.
  • Store the design and cost model outputs in Notion under the client record.
  • On written design approval from the client, the orchestrator advances to Gate 2. The billing workflow generates the 25% design-approval payment link. The conveyor pauses again until payment clears.

Written sign-off triggers the gate

The deemed-acceptance clause in your SOW means if the client does not respond within five business days of deliverable submission (material defects excepted), the deliverable is deemed accepted and the gate payment becomes due. This removes the stall point.

Wire Stations 4-5 (Build through Demo)

Stations 4 and 5 are where the actual delivery happens. The Build team produces the solution, and the Demo station presents it with bounded refinement. Gate 3 fires only after written sign-off on the final deliverable.

Station 4: Build
  • Create the Build Lead agent system prompt. This agent plans the work against the approved design and acceptance criteria from Station 3.
  • Create the Build Executor agent system prompt. This agent produces the working deliverable.
  • Create the Build Reviewer agent system prompt. This agent checks the deliverable against the design and acceptance criteria before it moves to Demo.
  • Configure the orchestrator to invoke these three roles only when Gate 2 status shows Cleared in Notion. For simple engagements, collapse all three roles to one agent.
  • Output: a working deliverable ready for client review.

Why three Build roles for a solo operator?

The separation exists so the pipeline can scale without redesign. When you run the Build Lead, Executor, and Reviewer as separate system prompts, the orchestrator can invoke them in sequence with distinct instructions. For a simple engagement, the same agent handles all three with combined instructions.

Station 5: Demo and Refine
  • Create the Demo-and-Acceptance Agent system prompt. This agent presents the deliverable to the client and captures feedback.
  • Create the Refinement-and-Change-Order Agent system prompt. This agent enforces DR-3 (Bounded Refinement): two rounds refine approved work only. Any new-scope request produces a priced change order with its own fee, timeline, and acceptance criteria. The change order is not absorbed into existing refinement rounds.
  • Configure the orchestrator to track refinement rounds (maximum two). On each round, the Refinement agent checks whether the feedback is a refinement of approved work or new scope.
  • On written sign-off after refinements complete, the orchestrator advances to Gate 3. The billing workflow generates the 25% final acceptance payment link. The conveyor pauses until payment clears.

What happens when a client requests new scope during refinement?

The Refinement-and-Change-Order Agent catches the request and produces a priced change order. This is a separate document with its own fee, timeline, and acceptance criteria. If the client accepts, a new payment link fires for the change-order amount before any new work starts. The original refinement rounds continue unaffected.

Wire Stations 6-7 (Deliver and Support) with gate enforcement

The final two stations close the engagement and open the recurring relationship. Station 6 releases the work and proves the value. Station 7 pitches the retainer only after the win is proven (DR-5).

Station 6: Deliver
  • Configure the orchestrator to release files, access, and documentation only when Gate 3 status shows Cleared in Notion.
  • The Billing-and-Gate Agent produces the value-versus-fee statement: a closing artifact that restates the client's starting problem, the objective agreed at conceptual agreement, the measurable outcome delivered, and the total fee collected (50% + 25% + 25%).
  • Store the value-versus-fee statement in the client's Notion record. This artifact becomes the setup for the retainer pitch.
Station 7: Support and Retainer
  • Create the Retainer Agent system prompt. This agent pitches the tiered care plan only after the value-versus-fee statement has been delivered and the client has seen the proven win.
  • Gate 4 fires when the client accepts the retainer: a monthly subscription payment link is generated using the recurring Price ID you created in Stripe (interval: month, billed in advance).
  • Update the client's Station field in Notion to Support and Gate Status to Cleared. The client is now in retained status.

Why pitch the retainer after the value statement?

This follows DR-5 (Wow Then Retain). If you pitch a retainer before the win is proven, it reads as a cash grab. The value-versus-fee statement gives the client concrete evidence that continuing the relationship is worth the monthly fee.

Build the gate enforcement workflow in n8n

The gate enforcement workflow is the spine of the pipeline. It listens for successful payments from Stripe and automatically advances the conveyor when a gate clears.

  • In n8n, create a new workflow for gate enforcement.
  • Add a Stripe Trigger node as the workflow trigger. Configure it to listen for the payment_intent.succeeded event.
  • Add an IF node after the Stripe Trigger to filter events. Check that the event's metadata contains your gate name and client ID fields (these were set when the billing workflow created the payment link).
  • Add a Notion node (Update Database Item) that updates the matching client record: set Gate Status to Cleared and advance the Station field to the next station.
  • Add a branch after the Notion update that triggers the next station's workflow. Use an Execute Workflow node to call the appropriate station workflow based on the gate name in the metadata.

What does the gate enforcement workflow do?

The Stripe Trigger node receives a webhook event every time a payment succeeds. The workflow reads the payment's metadata to identify which client and which gate just cleared. It updates Notion and then kicks off the next station.

If no payment arrives within the deemed-acceptance window (five business days), no downstream workflow fires. The work-pause is automatic. This is how DR-2 (No Payment No Next Station) enforces itself without confrontation.

  • Activate the gate enforcement workflow so it runs in production mode (listening for Stripe webhook events in test mode).
  • Verify your n8n instance now has three active workflows: the billing workflow (payment link generation), the PandaDoc document creation workflow (proposal sending), and the gate enforcement workflow (payment clearance to station advancement).

Stripe Trigger not receiving events?

Make sure your n8n instance is accessible via a public URL. Stripe needs to reach the webhook endpoint. If running locally with Docker, use a tunnel service or deploy to a cloud instance.

Confirm your Stripe credentials in n8n include both the Secret Key and the Stripe Signature Secret for webhook verification.

Help me debug my Stripe Trigger webhook connection.

Your seven-station pipeline is now fully wired with agent roles executing each station and payment gates enforced by n8n and Stripe. Next up, you will run a full end-to-end test with a representative client scenario to prove every gate holds.

Validate the Pipeline and Produce Closing Artifacts

Your seven-station pipeline is fully wired with agent roles, payment gates, and n8n workflows connecting everything together.

Now it is time to prove the system works. In this step, you will run one representative client engagement end-to-end through every station, confirm that each gate enforces payment before progress, and produce the closing artifacts that set up the retainer pitch.

In this step, get ready to:
  • Run a full end-to-end test scenario from meeting note through retainer offer.
  • Produce the value-versus-fee statement that sets up the retainer pitch.
  • Create the two-audience founder readout with lessons learned.
Run the end-to-end test scenario

A pipeline that has never run end-to-end is an assumption, not a system. This test proves that every station hands off correctly, every gate blocks on non-payment, and every clause fires when it should.

  • Create a test meeting note in Granola or Pocket (or paste a representative transcript into the MCP-accessible location).
  • Your test note should include: a stated client problem, measurable objectives, budget signals, and a named decision-maker.

What makes a good test note?

Use a realistic scenario. For example: a small SaaS company wanting to automate their onboarding flow, with a budget range of $15,000-$25,000 and a VP of Product as the decision-maker.

The richer the input, the more realistic your pipeline's output will be at each station.

  • Trigger the full conveyor through Claude Code. The Orchestrator should route the note to Station 1 (Intake), where the Meeting-Note Parser and Requirements-and-Qualification Agent extract and normalize the requirements.
  • Confirm Station 2 (Scope) activates: the Value-Pricing Agent produces three options anchored high, and the Proposal Agent populates your PandaDoc template.
  • Self-sign the proposal in PandaDoc to simulate client acceptance.
  • Confirm Gate 1 fires: the 50% deposit payment link is generated in Stripe test mode.

Now simulate the payment that clears Gate 1 and unlocks Station 3.

  • Open the generated payment link in your browser.
  • Enter the Stripe test card number 4242 4242 4242 4242 with any future expiration date and any three-digit CVC.
  • Confirm the payment succeeds and the n8n Gate Enforcement Workflow fires: check your Notion CRM record. The Gate Status for Gate 1 should now read Cleared.
  • Confirm Station 3 (Design) unlocks and the Solution Designer agent activates.

How do I see test payments in Stripe?

In the Stripe Dashboard, make sure the Test mode toggle in the top-right corner is active. The header turns orange when you are viewing test data.

Navigate to Payments in the left menu to see all simulated transactions from your test card.

  • Continue the test through Stations 3-6: approve the design to fire Gate 2, simulate the 25% payment using 4242 4242 4242 4242, confirm Station 4 (Build) unlocks, run the Build through Demo, complete two refinement passes at Station 5, then fire Gate 3 with the final 25% payment.
  • Confirm Station 6 (Deliver) releases the deliverable and produces the value-versus-fee statement.
  • Confirm Station 7 (Support) activates the Retainer Agent with a subscription payment link for the monthly retainer.

With all stations run, validate the four bars that prove your pipeline's rigor.

  • Gate bar: Intentionally leave a gate unpaid. Confirm no downstream n8n workflow fires and the conveyor hard-stops. The work-pause clause is doing its job without any confrontation needed.
  • Acceptance bar: Simulate a stalled sign-off. Confirm that after five business days (adjust your test scenario's timestamps), the deemed-acceptance logic closes the window and the gate payment becomes due.
  • Scope bar: During a refinement round, introduce a new-scope request. Confirm the Refinement-and-Change-Order Agent produces a priced change order with its own fee and timeline. The request is not absorbed into the existing refinement rounds.
  • Value bar: Confirm the closing statement restates the outcome against the fee collected, and the retainer is pitched after the value statement lands (not before).

Why validate all four bars?

Each bar corresponds to a decision record (DR-2, deemed-acceptance in DR-2, DR-3, DR-5). If any bar fails, the pipeline looks rigorous on paper but leaks money or scope in practice.

The gate bar is the most critical. A pipeline that does not hard-stop on non-payment is just a to-do list with extra steps.

🙋‍♀️ Gate not blocking when payment is missing?

Check your n8n Gate Enforcement Workflow. The Stripe Trigger node must be receiving payment_intent.succeeded events. If no event fires, the workflow never updates the Notion gate status and no downstream station triggers.

Also verify that your payment link metadata includes the correct gate name and client ID. The n8n workflow matches on these fields to determine which gate to clear.

Help me debug my gate enforcement workflow.

Produce the value-versus-fee statement

The value-versus-fee statement is the closing artifact that makes the retainer pitch feel earned. It restates the outcome delivered against the fee collected, so the client sees the value before hearing the next offer.

  • Using Claude Code, instruct the Orchestrator to produce the value-versus-fee statement for your test scenario. The statement should include four elements:
  • The client's starting problem (as captured at Intake).
  • The objective agreed at conceptual agreement (as confirmed before the proposal).
  • The measurable outcome delivered (as validated at Demo acceptance).
  • The total fee collected (50% + 25% + 25% = 100% of engagement fee).

The statement should be framed as: this outcome was delivered for this fee, and the retainer continues this value at the monthly rate.

Why does the value statement come before the retainer pitch?

This is DR-5 in action (Wow Then Retain). A retainer pitched before the win reads as a cash grab. Pitched after the value-versus-fee statement, it reads as a continuation of proven value.

The statement gives the client a concrete reference point. They are being asked to continue something that already delivered results.

  • Review the generated statement. Confirm it references specific outcomes from your test scenario, not generic placeholders.
  • Store the value-versus-fee statement in your Notion CRM attached to the test client record.
Create the two-audience founder readout

The founder readout serves two audiences with one artifact. The client sees what was built and gets the retainer offer. The operator (you) sees the system's performance and the revenue path forward.

  • Instruct Claude Code to produce the readout with two clearly separated sections.

Audience 1 (the client) covers:

  • What was built and the outcome delivered.
  • The value-versus-fee summary (from the statement you just produced).
  • The retainer offer and what it covers going forward.

Audience 2 (the operator) covers:

  • The pipeline architecture and how it performed.
  • What worked well and what needs refinement.
  • The revenue path from deposit to retainer.
  • Adoption milestones: day 1 (first proposal signed with deposit), day 30 (first project delivered and paid), day 90 (first retainer signed), day 180 (portfolio on the conveyor with recurring base).

Why track adoption milestones?

Milestones turn a build into a business plan. Day 1 proves the pipeline closes. Day 30 proves it delivers. Day 90 proves it retains. Day 180 proves it scales.

Without milestones, you have a working system with no way to measure whether it is producing revenue growth.

  • Add a lessons-learned section to the operator readout. Record three categories:
  • What the build proved (the pipeline carries a client from note to retainer).
  • What the clauses protected (scope creep via change-order procedure, non-payment via work-pause, stalled approvals via deemed-acceptance).
  • What the agent org handled versus what required your human judgment.

Human judgment is a feature

If your lessons learned show that certain decisions needed human judgment (pricing strategy, client relationship calls, scope negotiation nuance), that is correct. The agent org handles execution and enforcement. You handle strategy and relationships.

  • Store the completed readout in your project repository or Notion workspace.
  • Confirm your Notion CRM test client record shows: all seven stations completed, all four gates cleared, retainer status active, and both closing artifacts (value statement and readout) linked.

Readout feels generic or template-like?

If Claude Code produces boilerplate instead of specific observations, feed it the actual outputs from your test run. Reference the specific proposal values, the gate clearance timestamps, and the refinement rounds. Specificity in equals specificity out.

Help me structure more specific prompts for my readout.

Secret mission

Portfolio Intensity

Your pipeline works for one client. Can it handle three at once? In this extension, you load multiple concurrent clients onto the conveyor, build a tiered care-plan retainer, negotiate a live change order through your clauses, and resolve a stalled payment via the deemed-acceptance window.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

This project uses test mode for Stripe and free tiers for Notion and n8n (self-hosted). No ongoing costs accrue unless you switch Stripe to live mode and collect real payments.

Cost warning

Stripe charges 2.9% + 30 cents per successful transaction on live payments only. Test mode products and payment links generate no charges.

PandaDoc requires a Business plan for API access. Documents in test or draft mode do not incur signature costs. Check your current plan for subscription pricing.

Resources you used:

  • Stripe Products and Prices (test mode): four gate products plus three tiered retainer subscription prices.
  • n8n workflows: billing workflow, gate enforcement workflow, and PandaDoc workflow.
  • PandaDoc documents and templates: proposal/SOW template and any test documents created during the validation run.
  • Notion CRM database: client records, pipeline states, and test data across three concurrent clients.

Keep everything running

No action needed. Choose this if you are ready to take your first live client through the pipeline.

  • Switch Stripe to live mode by swapping your sk_test_ key for your sk_live_ key in n8n credentials.
  • Send your first real proposal through PandaDoc and generate a live deposit payment link.
  • Your n8n workflows, Notion CRM, and agent organization remain operational.

Pause - I'll come back to this later

Shut down running processes to free up resources while keeping your configuration intact.

  • Deactivate your n8n workflows. Open each workflow and click the toggle to deactivate it, or use the dropdown arrow next to the Publish button and select Unpublish.
  • Stripe products remain in test mode but generate no charges until a payment link is used.
  • Notion CRM data stays intact for when you return.
  • PandaDoc templates remain available in your account.

Delete - I don't want to use this again

Remove all project resources and start fresh.

  • Delete all Stripe test data. In the Stripe Dashboard (sandbox mode), click Developers > Overview. Under Test data, click Review test data, then click Delete test data. This removes all test products, prices, payment links, and customer records permanently.
  • Delete n8n workflows. Open each workflow (billing, gate enforcement, PandaDoc) in n8n. From the workflow actions menu, select Delete and confirm the deletion. This also removes execution history.
  • Delete Notion CRM test data. Open your pipeline CRM database in Notion, select all test client records, and delete them. If you want to remove the entire database, right-click the database page and select Delete.
  • Delete PandaDoc test documents. In PandaDoc, navigate to your Documents list, select the test documents created during the validation run, and delete them. Templates can be removed from the Templates section.

That's a Wrap!

That's a Wrap!

Nice work. You just built a complete client operating system that carries a prospect from meeting note to monthly retainer, with payment gates enforcing every milestone.

You've learned how to:

  • Build a seven-station client pipeline with approximately fourteen agent roles orchestrated by Claude Code, and wire four payment gates (50/25/25 plus monthly retainer) to Stripe payment links with n8n automation enforcing no-payment-no-progress.
  • Produce a three-option value-based offer engine with pricing anchored high and value stated before fee, plus a one-page proposal/SOW template with measurable acceptance criteria, a change-order procedure, and self-enforcing work-pause and deemed-acceptance clauses.
  • Validate the full pipeline end-to-end proving gate enforcement, bounded refinement, and the closing sequence. Then produce the value-versus-fee statement and two-audience founder readout with lessons learned.
  • Secret Mission: ran portfolio intensity with concurrent clients on the conveyor, a tiered care-plan retainer with escalation tiers, a live change-order negotiation through the clauses, and stalled-payment resolution via the deemed-acceptance window.

Ready to quiz yourself?