Consulting Industry / Technical Guide

Automate Proposal Generation & Project Intake for Consultancies with n8n + Claude Step-by-Step Guide

A complete walkthrough for building an n8n + Claude pipeline that ingests Typeform/Tally intake plus discovery-call transcripts, pulls comparable past engagements from a Notion vector DB, drafts a full SOW with milestones and effort, and lands a DocuSign-ready PDF in the partner’s review queue in under 12 minutes.

14 min read
Intermediate-Advanced
n8n + Claude API
Updated May 2026
What You’ll Build

Intake form (Typeform/Tally)

Classify scope (Claude)

Past-project retrieval

Effort × rate × buffer

Draft SOW (Claude)

Partner review in Slack

DocuSign send + CRM sync

1. The Problem — Why Proposal Drafting Eats Partner Time

Every consultancy past 8 partners hits the same ceiling: the people best qualified to scope and price a project are the same people most expensive to put in a Word document at 11pm on Sunday. A typical mid-sized firm spends 30 to 50 senior hours on every six-figure proposal — discovery synthesis, comparable-project lookup, effort estimation, SOW writing, partner review, redlines, DocuSign packaging. By the time the proposal lands, the prospect has already received two from competitors and started a procurement clock the firm now has to race.

Real numbers from a 22-partner management consultancy (180 proposals/year)

Avg senior hours per proposal38 hrs
Median proposal cycle (intake → sent)5 days
Proposals lost to “competitor responded faster”22%
Pricing variance for similar scopes (same firm)±34%
Win rate when proposal sent <48h after intake61%

The brutal asymmetry: the partner who costs the firm $700/hr is the only person who knows what a “data strategy assessment for a regional bank” should cost — but 70% of what they do during proposal week is mechanical. They’re not picking pricing, they’re remembering pricing. They’re not architecting an approach, they’re recalling the approach used three engagements ago.

What the automation actually changes

The goal is not to replace partner judgment — it’s to put a 90%-finished SOW on the partner’s desk by 9am the morning after the discovery call. Three hours of partner review beats thirty hours of partner drafting, and prospect-facing turnaround drops from days to hours:

  • Auto-generated: situation summary, objectives, comparable-project context, deliverables list, milestone schedule, effort/rate roll-up, assumptions, exclusions, payment terms.
  • Partner-edited: approach narrative, team composition, commercial structure (fixed vs T&M vs phased), client-specific risks.
  • Always-human: final pricing decision, signature, post-signature kickoff scheduling.
Insight
The biggest win is consistency, not speed. When the same firm prices three near-identical engagements within 12% of each other instead of 34%, the partnership stops fighting itself and starts compounding margin. We use this same pattern across our consulting industry deployments.

2. System Architecture

Seven components, each replaceable. The orchestration layer is self-hosted n8n so the security review can audit every external API call that touches client-confidential intake data. Postgres holds the proposal state machine plus an embedding index for past-project retrieval (pgvector).

The stack

n8n (self-hosted)
Orchestration. Docker on a 4 vCPU / 16GB VM with queue mode. Lives behind the firm VPN.
Claude API
Sonnet for SOW drafting and reasoning, Haiku for cheap classification and tagging.
Typeform / Tally
Intake. Conditional logic so industry, scope and budget bands route the form differently.
Notion + pgvector
Past-project knowledge base. Notion as source of truth, embeddings cached in Postgres.
HubSpot / Salesforce
Source of truth for deal, contact, company, proposal stage, signed value.
DocuSign + Slack
Partner review queue in Slack, e-sign delivery and post-signature kickoff trigger.

Cost estimate (180 proposals/year)

Claude Sonnet (180 SOW drafts, ~14k tok in / 4k tok out)~$430
Claude Haiku (classification + tagging across pipeline)~$90
Embeddings (Voyage AI or OpenAI text-embedding-3-large)~$60
DocuSign Business Pro (5 senders)~$2,100
VM (n8n + Postgres on Hetzner CCX33)~$1,150
Monitoring (Grafana Cloud + Healthchecks)~$290
Total / year~$4,120

For a firm where partner time costs $600–$900/hour fully loaded, the system pays back inside the first six proposals. The same orchestration layer plugs into our broader AI automation services.

1

Intake Form Capture

The pipeline needs a single normalized intake regardless of how the prospect arrived. In a typical mid-sized consultancy that means three sources: a Typeform/Tally form embedded on the website, a Calendly-booked discovery call followed by a structured note in HubSpot, and a partner-initiated intake (the partner already has a relationship and creates the proposal request manually). All three converge on the same n8n webhook.

Intake fields that actually matter

  • Client basics: company name, industry NAICS code, region, headcount band, ARR or revenue band.
  • Project ask: 2-paragraph problem statement, desired outcome in client’s own words, deadline driver (board meeting, fiscal year, regulator, none).
  • Scope signals: phase requested (assessment, design, implementation, run), data they’ll provide, named stakeholders, internal vs external sponsor.
  • Commercial signals: budget band (declared or inferred), procurement process, prior consulting spend, MSA status with our firm.
  • Discovery transcript: if a Zoom or Gong recording exists, attach the transcript and timestamps. This is gold for the SOW drafter.

n8n webhook node config

A single n8n Webhook node accepts the union schema; a Switch node downstream branches on source. HMAC verification happens before the workflow does anything else, and PII is encrypted at rest the moment it lands in Postgres.

n8n Webhook payload — normalized intake schemaJSON
{
  "source": "typeform" | "tally" | "hubspot_note" | "partner_initiated",
  "intake_id": "intake_01HXYZ...",
  "received_at": "2026-05-03T09:14:22Z",
  "signature": "sha256=...",
  "client": {
    "company_name": "Apex Regional Bank",
    "naics": "522110",
    "region": "EMEA / DACH",
    "headcount_band": "1000-5000",
    "revenue_band_usd": "500M-1B",
    "msa_in_place": false
  },
  "ask": {
    "problem_statement": "We need to evaluate our data strategy ahead of...",
    "desired_outcome": "A 12-month roadmap with prioritized initiatives and...",
    "deadline_driver": "board_meeting_2026-08-15",
    "phase_requested": ["assessment", "design"]
  },
  "commercial": {
    "budget_band_usd": "250k-500k",
    "procurement": "RFP",
    "prior_spend_with_firm_usd": 0
  },
  "discovery": {
    "call_recording_url": "https://gong.io/...",
    "transcript_text": "...",
    "stakeholders": [
      { "name": "Sarah Mueller", "title": "CDO", "role": "sponsor" },
      { "name": "Thomas Bauer", "title": "Head of Data", "role": "champion" }
    ]
  }
}
Watch Out
A partner-initiated intake will often have a half-filled form and a long Slack thread. Handle missing fields with explicit nulls and a _completeness_score the orchestrator uses to decide whether to ask Claude to flag gaps in the partner review step instead of fabricating answers.
2

Project Classification

Before retrieving comparable past projects, the system needs to know what kind of project this is. Claude Haiku reads the intake and the discovery transcript and returns a structured taxonomy: practice area, project type, phase mix, complexity tier, and a list of suspected disqualifiers. This pass costs cents and slashes the retrieval surface for the next step. Same pattern we use across financial services automation.

The classification dimensions

practice_area
Strategy, ops, technology, finance/risk, people, or a multi-practice blend.
project_type
Assessment, target operating model, transformation, M&A diligence, audit.
phase_mix
Diagnose, design, build, run — and the rough split across them.
complexity_tier
T1 / T2 / T3 — drives base hours, partner involvement, peer review.
disqualifiers
Conflicts, sanctioned regions, sub-minimum-fee asks, scope we don’t do.

Classifier system prompt

Claude Haiku — project classifierTXT
You classify a consulting intake into a strict taxonomy.
Read intake.ask and discovery.transcript_text only.
Never invent fields not present in the input.

PRACTICE AREAS (pick one or "blend"):
- strategy, operations, technology, finance_risk, people

PROJECT TYPES (pick one):
- assessment, target_operating_model, transformation,
  ma_diligence, regulatory_response, capability_audit, other

COMPLEXITY TIERS:
- T1: single practice, single region, <10 stakeholders, <90 days
- T2: blend, single region, 10-30 stakeholders, 90-180 days
- T3: blend, multi-region or regulated, 30+ stakeholders, 180+ days

DISQUALIFIERS to flag:
- conflict_of_interest_with_existing_client
- sanctioned_jurisdiction
- below_min_fee_50k
- scope_outside_practice (legal opinions, audit attest)

OUTPUT — strict JSON, no prose:
{
  "practice_area": "strategy" | "operations" | ...,
  "project_type": "assessment" | ...,
  "phase_mix": { "diagnose": 0.4, "design": 0.6, "build": 0, "run": 0 },
  "complexity_tier": "T1" | "T2" | "T3",
  "estimated_duration_weeks": int,
  "disqualifiers": [],
  "rationale": "2-3 sentences citing specific intake language"
}
Insight
Persist the rationale string into HubSpot as a custom field on the deal. Partners build trust in the classifier much faster when they can see “tagged T2 because cross-functional data + risk scope, EMEA regional footprint, 14-week duration mentioned in transcript.”
3

Past-Project Retrieval

The single biggest leverage point in the whole pipeline is comparable-project context. A consultancy doing 200 engagements a year has a private gold-mine of pricing, scope, team-mix, and post-mortem data — almost always trapped in Notion pages, SharePoint folders, or a forgotten engagement-history Excel. The retrieval layer turns that into structured context Claude can read.

What gets indexed

  • Engagement abstracts: 1-page summary per past project — client industry, scope, deliverables, team mix, duration, fixed vs T&M, signed value.
  • SOW excerpts: the approach narrative, milestone structure, and exclusions sections — the parts most reused.
  • Post-mortems: what was scoped vs what was actually delivered, hour overruns, change-order count. Critical for buffer calibration.
  • Win/loss notes: if the proposal was sent and lost, why. Pricing? Approach? Team match? Timing?

Embedding pipeline (Notion → pgvector)

A nightly n8n workflow pulls every Notion page tagged engagement, splits it into 800-token chunks with 100-token overlap, embeds them, and upserts into a Postgres pgvector table. The retrieval call at proposal time runs hybrid search: cosine similarity on the embeddings plus a structured filter on practice area, complexity tier, and region.

Postgres — pgvector schema for past-project chunksSQL
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE engagement_chunks (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  engagement_id   text NOT NULL,
  notion_page_id  text NOT NULL,
  chunk_text      text NOT NULL,
  chunk_kind      text NOT NULL,  -- abstract|sow|postmortem|winloss
  practice_area   text,
  project_type    text,
  complexity_tier text,
  region          text,
  signed_value_usd numeric,
  signed_at       date,
  embedding       vector(1536),
  updated_at      timestamptz DEFAULT now()
);

CREATE INDEX idx_chunks_embedding
  ON engagement_chunks
  USING hnsw (embedding vector_cosine_ops);

CREATE INDEX idx_chunks_filters
  ON engagement_chunks (practice_area, complexity_tier, region);

Retrieval query

Postgres — hybrid retrieval at proposal timeSQL
-- Pull the 8 most similar abstracts and 4 SOW excerpts
-- filtered by practice + complexity. The intake embedding
-- is computed once per proposal and reused.

WITH abstracts AS (
  SELECT engagement_id, chunk_text, signed_value_usd,
         signed_at, embedding <=> $1::vector AS dist
  FROM   engagement_chunks
  WHERE  chunk_kind = 'abstract'
    AND  practice_area = $2
    AND  complexity_tier = $3
  ORDER  BY embedding <=> $1::vector
  LIMIT  8
),
sow_excerpts AS (
  SELECT engagement_id, chunk_text,
         embedding <=> $1::vector AS dist
  FROM   engagement_chunks
  WHERE  chunk_kind = 'sow'
    AND  practice_area = $2
  ORDER  BY embedding <=> $1::vector
  LIMIT  4
)
SELECT * FROM abstracts
UNION ALL
SELECT engagement_id, chunk_text, NULL, NULL, dist FROM sow_excerpts;
Insight
Index the post-mortems separately and surface them only to the partner review step, never to Claude during drafting. Past hour overruns and change orders are dynamite for buffer calibration but radioactive if a draft accidentally inherits a client-specific complaint.
4

Effort Estimation

Effort estimation is the step where most consultancies want a deterministic algorithm, not an LLM guess. The right pattern: Claude proposes a phase-by-role hour grid using the comparable-project context, then a deterministic n8n function multiplies by the firm’s blended rate card and applies a tiered buffer. The partner sees both the model’s hours and the post-buffer total, with the math fully transparent.

The estimation grid

Claude returns hours as a 2-D matrix: rows are project phases (diagnose, design, build, run), columns are roles (partner, principal, manager, senior consultant, analyst, specialist). The grid is filled in based on the closest 2-3 comparable engagements found in retrieval, with explicit reasoning for any deviation.

Phase / RolePartnerPrincipalManagerSr. Cons.Analyst
Diagnose (4 wk)2860110160120
Design (8 wk)52120240340220
Subtotal hours80180350500340
Subtotal $$72k$108k$140k$135k$54k

Deterministic effort calculator (n8n Function node)

n8n Function — effort × rate × bufferJS
// Inputs:
//   $json.grid           = phase × role hour matrix from Claude
//   $json.classification = { complexity_tier, project_type, ... }
//   $env.RATE_CARD       = role -> blended hourly rate USD

const RATES = JSON.parse($env.RATE_CARD);

// Buffer policy by complexity tier
const BUFFER = {
  T1: 0.12,   // 12% on simple, single-practice work
  T2: 0.18,   // 18% on blends or regional spans
  T3: 0.25    // 25% on regulated / multi-region T3s
}[$json.classification.complexity_tier];

// Risk add-on for known scope-creep triggers
const RISK_ADDONS = {
  data_migration: 0.05,
  regulatory_response: 0.07,
  multi_vendor_integration: 0.06
};

let baseHours = 0, baseDollars = 0;
for (const phase of Object.keys($json.grid)) {
  for (const role of Object.keys($json.grid[phase])) {
    const h = $json.grid[phase][role];
    baseHours   += h;
    baseDollars += h * RATES[role];
  }
}

const riskAddon = ($json.classification.risk_factors || [])
  .reduce((acc, k) => acc + (RISK_ADDONS[k] || 0), 0);

const totalBuffer = BUFFER + riskAddon;
const buffered = baseDollars * (1 + totalBuffer);
const fixedFee = Math.ceil(buffered / 1000) * 1000;

return [{ json: {
  base_hours: baseHours,
  base_dollars: Math.round(baseDollars),
  buffer_pct: Number(totalBuffer.toFixed(3)),
  fixed_fee_usd: fixedFee,
  effective_blended_rate: Math.round(fixedFee / baseHours)
}}];
Security
Rate cards are commercially sensitive — keep them in environment variables on the n8n VM, never in workflow JSON. Rotate on every senior departure. The model never sees rates, only hours; the multiplication happens in deterministic code so a prompt-injection in the intake can’t bias pricing downward.
5

Claude SOW Drafter

This is the heaviest call in the pipeline. Claude Sonnet receives the intake, the discovery transcript, the classification, the past-project context, and the effort grid — and produces a complete SOW draft with situation, objectives, approach, deliverables, milestones, team, fees, assumptions, and exclusions. The output is structured so it can render directly into the firm’s branded Word template.

SOW system prompt

Claude system prompt — SOW drafterTXT
You are an SOW drafter for a mid-sized management consultancy.
Your output will be reviewed and edited by a partner before sending.
Your job is to land a 90%-finished draft, not a perfect one.

INPUTS PROVIDED:
- intake (problem statement, stakeholders, constraints)
- discovery transcript (verbatim, optional)
- 8 past-project abstracts ranked by similarity
- 4 SOW excerpts from comparable engagements
- effort grid (phases x roles x hours) and fixed_fee_usd
- firm voice guide (tone, banned terms, preferred section names)

WRITING RULES:
- Use only language the partner would use in front of the client
- No filler, no superlatives, no "synergy" or "leverage" as verbs
- Every claim about us must be defensible from past projects
- Every assumption must be falsifiable in the assumptions section
- Cite past engagements by anonymized type, never by client name

OUTPUT — strict JSON in this order:
{
  "situation": "1 paragraph, mirrors client's own framing",
  "objectives": ["3-5 bullets, outcome language"],
  "approach": "3-5 paragraphs, named methodology where applicable",
  "deliverables": [{ "name": "...", "description": "...", "phase": "..." }],
  "milestones": [{ "week": int, "label": "...", "exit_criteria": "..." }],
  "team": [{ "role": "...", "allocation_pct": int, "rationale": "..." }],
  "fees": {
    "structure": "fixed" | "tm" | "phased",
    "amount_usd": int,
    "payment_schedule": [...]
  },
  "assumptions": ["..."],
  "exclusions": ["..."],
  "risks_for_partner_review": ["flagged uncertainties"]
}

NEVER output: fabricated client logos, made-up case studies,
unverified statistics, or any past client name.

n8n HTTP Request to Claude

n8n HTTP Request — SOW drafter callJSON
{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $credentials.anthropic.apiKey }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-sonnet-4-5",
    "max_tokens": 6000,
    "system": "{{ $json.sowSystemPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": [
          { "type": "text",
            "text": "Intake:n{{ JSON.stringify($json.intake) }}" },
          { "type": "text",
            "text": "Classification:n{{ JSON.stringify($json.classification) }}" },
          { "type": "text",
            "text": "Past-project context:n{{ $json.retrievalText }}" },
          { "type": "text",
            "text": "Effort grid:n{{ JSON.stringify($json.grid) }}nFixed fee: ${{ $json.fixed_fee_usd }}" },
          { "type": "text",
            "text": "Discovery transcript (verbatim):n{{ $json.intake.discovery.transcript_text }}" }
        ]
      }
    ]
  }
}
Insight
The single most-edited section across every firm we’ve deployed this for is “approach.” Don’t fight it — that’s the section where the partner’s IP lives. Optimize the boring sections (deliverables, milestones, assumptions, exclusions) to a 95% acceptance rate, and let the partner spend their review time where it actually moves win rate.
6

Partner Review Queue

A draft sitting in an email inbox is a draft that misses the 48-hour window. The review queue lives in Slack — a #proposal-review channel where each new draft posts as a Block Kit message with the headline numbers, a preview link to a rendered Google Doc, and three buttons: Approve, Edit, Re-draft. Routing rules pick the right partner based on practice area + client industry + an availability roster.

Routing matrix

TierReviewerSLAApproval mode
T1 (<$100k)Lead partner only4 working hoursSingle approver
T2 ($100k–$500k)Lead partner + practice peer8 working hoursLead + peer ack
T3 (>$500k)Lead partner + risk + managing partner1 working dayThree-way sign-off
MSA renewalAccount partner only2 working hoursSingle approver

Slack review payload

Slack — incoming webhook (Block Kit)JSON
{
  "channel": "#proposal-review",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text",
                "text": ":memo: T2 SOW draft — Apex Regional Bank" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn",
          "text": "*Practice*nStrategy + Data" },
        { "type": "mrkdwn",
          "text": "*Fee*n$278,000 fixed" },
        { "type": "mrkdwn",
          "text": "*Duration*n14 weeks (Diagnose + Design)" },
        { "type": "mrkdwn",
          "text": "*Closest comparable*nEU regional retail bank, 2025-Q3, won at $312k" }
      ]
    },
    {
      "type": "section",
      "text": { "type": "mrkdwn",
                "text": "*Flagged for partner review:* T&M vs fixed structure (data migration risk), CDO requested by name in transcript but is sponsor not champion." }
    },
    {
      "type": "actions",
      "elements": [
        { "type": "button",
          "text": { "type": "plain_text", "text": "Open in Google Docs" },
          "url": "https://docs.google.com/document/d/{{docId}}" },
        { "type": "button",
          "text": { "type": "plain_text", "text": "Approve & send" },
          "style": "primary", "action_id": "approve_sow" },
        { "type": "button",
          "text": { "type": "plain_text", "text": "Re-draft with notes" },
          "action_id": "redraft_sow" }
      ]
    }
  ]
}

“Re-draft with notes” opens a modal in Slack where the partner types one line of guidance — “make T&M not fixed”, “drop the analytics workstream”, “add a 4-week pilot phase before commit” — which gets fed back to Claude as a follow-up turn on the same conversation. This pattern is borrowed from how AEs claim hot leads in our SaaS trial-to-paid scoring guide.

7

DocuSign + CRM Sync & Kickoff

Once the partner clicks Approve, n8n renders the SOW JSON into a branded Word template, generates a PDF, posts it to a DocuSign envelope keyed to the firm’s existing template, sends the envelope to the named client signers, and updates HubSpot — all in one workflow. The post-signature webhook fires the kickoff trigger: a Notion engagement page is created, the staffed team gets a calendar invite, and the engagement-history index gets a new row ready for future retrieval.

DocuSign envelope payload

DocuSign — envelopes:createJSON
{
  "method": "POST",
  "url": "https://eu.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes",
  "headers": {
    "authorization": "Bearer {{ $credentials.docusign.access_token }}",
    "content-type": "application/json"
  },
  "body": {
    "templateId": "{{ $env.SOW_TEMPLATE_ID }}",
    "templateRoles": [
      {
        "email": "{{ $json.intake.discovery.stakeholders[0].email }}",
        "name":  "{{ $json.intake.discovery.stakeholders[0].name }}",
        "roleName": "Client Signer",
        "tabs": {
          "textTabs": [
            { "tabLabel": "ProjectName",
              "value": "{{ $json.sow.project_name }}" },
            { "tabLabel": "FixedFee",
              "value": "${{ $json.fixed_fee_usd }}" },
            { "tabLabel": "DurationWeeks",
              "value": "{{ $json.sow.duration_weeks }}" }
          ]
        }
      },
      {
        "email": "{{ $json.partner.email }}",
        "name":  "{{ $json.partner.name }}",
        "roleName": "Firm Signer"
      }
    ],
    "status": "sent",
    "emailSubject": "{{ $json.firm.name }} — SOW for {{ $json.intake.client.company_name }}",
    "customFields": {
      "textCustomFields": [
        { "name": "deal_id_hubspot", "value": "{{ $json.deal_id }}" },
        { "name": "intake_id",       "value": "{{ $json.intake_id }}" }
      ]
    }
  }
}

HubSpot deal upsert + post-signature kickoff

HubSpot — deal upsert payloadJSON
{
  "method": "PATCH",
  "url": "https://api.hubapi.com/crm/v3/objects/deals/{{ $json.deal_id }}",
  "headers": {
    "authorization": "Bearer {{ $credentials.hubspot.token }}",
    "content-type": "application/json"
  },
  "body": {
    "properties": {
      "dealstage":            "proposal_sent",
      "amount":               "{{ $json.fixed_fee_usd }}",
      "closedate":            "{{ $json.sow.expected_close_date }}",
      "skru_proposal_id":     "{{ $json.proposal_id }}",
      "skru_complexity_tier": "{{ $json.classification.complexity_tier }}",
      "skru_practice_area":   "{{ $json.classification.practice_area }}",
      "skru_buffer_pct":      "{{ $json.buffer_pct }}",
      "skru_docusign_env_id": "{{ $json.envelope_id }}"
    }
  }
}

Post-signature kickoff (DocuSign Connect webhook)

DocuSign Connect fires envelope-completed the moment all parties sign. The webhook lands back in n8n and triggers a downstream workflow: create the Notion engagement page from a template, send the kickoff calendar invite via Google Calendar, post a #wins message in Slack, move the HubSpot deal stage to closed_won, and append a new row to the engagement-history index so this project is searchable in future retrievals from day one.

Insight
Indexing a freshly-signed engagement on day one is the highest-leverage move in the whole pipeline. Every proposal you send next month gets to learn from the one you just won — and the firm’s institutional memory compounds without anyone having to remember to write it down.

Common Failures & Fixes

Three failure modes show up in nearly every consulting deployment. Plan for them on day one — they are cheap to design around and expensive to retrofit.

Failure 1: Approach narrative drifts toward generic

Symptom: The approach section reads like a stock methodology slide. Partners reject 80% of drafts and rewrite from scratch — defeating the point of the system.

Fix: Force the prompt to ground every approach paragraph in a specific past engagement chunk by ID. Reject any sentence that uses “leverage”, “synergy”, “best-in-class” or “world-class” via a regex post-processor. Have each practice lead write a 200-word “voice exemplar” used as a few-shot anchor for their practice area.

Failure 2: Pricing leaks downward over time

Symptom: The retrieval surface includes proposals you sent but never won, and Claude starts pricing toward the discount band because the comparable set is biased downward.

Fix: Index proposals with a outcome field — won, lost, withdrawn — and weight retrieval toward won engagements 3:1. Re-embed quarterly as the firm’s pricing power shifts. Surface a “comparable price band” in the Slack review payload so the partner sees if the draft is at the bottom of the historical range.

Failure 3: Discovery transcript leaks confidential data into context

Symptom: A discovery call mentions a competitor product or a third-party vendor by name, and Claude either echoes that name in the SOW or pattern-matches into a comparable engagement that involved that competitor.

Fix: Run a Haiku pre-pass on the transcript to extract a redaction map, replace third-party names with [VENDOR_X] placeholders before any retrieval call, and only un-redact in the final partner-facing draft. Keep the original transcript in encrypted Postgres for audit, but never let the original text reach Claude past the first redaction pass.

Confidentiality, NDAs, ISO 27001 & Data Retention

Consulting work runs on client trust, and every intake is implicitly under NDA whether or not paper has been signed. The pipeline must be defensible to a CISO during procurement and to a partner two years later when the same client asks “what did you do with our data?” Treat confidentiality as a design constraint, not a checklist.

What Claude sees (and doesn’t)

  • Sees: structured intake fields, redacted discovery transcript, classification output, anonymized past-project context, effort grid.
  • Doesn’t see: client logos, signed engagement values from past clients, the firm rate card, individual stakeholder personal data beyond name + title, any document the prospect sent before the NDA was countersigned.

NDA workflow integration

An intake without a countersigned NDA is held in a quarantine state — n8n classifies and notifies the partner but does not pull any past-project context or run the SOW drafter. The moment the NDA envelope completes in DocuSign Connect, the workflow unlocks and runs the full pipeline. This protects the firm from inadvertently using a prospect’s confidential problem statement to retrieve another client’s engagement.

ISO 27001 controls this satisfies

  • A.5.30 ICT readiness: n8n self-hosted with hot standby, Postgres point-in-time recovery, runbooks in git.
  • A.8.10 Information deletion: intake data purged 90 days after deal close-lost; engagement data retained per signed contract.
  • A.8.11 Data masking: Haiku redaction pass before any third-party API call; no production PII in dev/staging.
  • A.5.14 Information transfer: all third-party calls over TLS 1.3, vault-backed credentials, full audit log.
  • A.8.16 Monitoring: every prompt hash, retrieval query, and CRM write logged in an immutable audit table.

Data retention schedule

Data classRetentionTrigger to purge
Intake (deal lost)90 daysHubSpot stage → closed_lost
Discovery transcripts180 daysEngagement closed or 180 days post-intake
SOW drafts (not sent)30 daysCron purge of orphan drafts
Engagement abstracts (won)7 yearsPer signed MSA / contract
Audit log7 yearsPer ISO 27001 + tax retention
Security
Use Anthropic’s enterprise tier with zero-data-retention enabled and EU residency for European clients. Never embed past-project chunks that contain a former client’s name or named deliverable IDs — the embedding itself can be inverted by a sophisticated adversary. Anonymize before indexing, not after retrieval.

Measured Results — Six Months In

Numbers from a real implementation at a 22-partner management consultancy (180 proposals/year, $40M revenue, three practice areas) after six months on the new pipeline. No change in proposal volume during the test period — the lift comes entirely from cycle compression, win-rate quality, and partner time freed for client-facing work.

Proposal cycle
5d → 2hr
intake to partner-ready draft
Win rate
+28%
vs 6-month pre-period
Partner drafting time
-85%
38 hrs → 5.4 hrs avg
Avg deal size
+18%
consistent buffer policy

The headline metric inside the partnership is pricing variance: similar-scope engagements now price within 12% of each other rather than 34%. That’s the number that lets the managing partner sit in front of the board with a defensible margin story. Without it, every quarterly review turns into a hunt for the partner who underpriced again.

Implementation Timeline & Cost

DIY Path
90 – 130 hours
  • n8n self-host + queue mode setup: 8–12 hrs
  • Intake schema + HMAC verify across sources: 6–8 hrs
  • Notion → pgvector embedding pipeline: 14–18 hrs
  • Classification + retrieval prompt tuning: 12–16 hrs
  • Effort grid + buffer policy + rate card vault: 10–14 hrs
  • SOW drafter prompt + voice exemplars per practice: 18–24 hrs
  • Slack review queue + multi-approver routing: 10–14 hrs
  • DocuSign template wiring + post-sign kickoff: 8–12 hrs
  • HubSpot/Salesforce sync + audit log: 6–8 hrs
  • ISO 27001 evidence pack + partner training: 8–12 hrs
With SEOKRU
5-week deployment
  • Week 1: Voice capture per practice + index past 24 months of engagements
  • Week 2: Intake form + classification + retrieval calibration
  • Week 3: SOW drafter + effort grid + Slack review
  • Week 4: DocuSign + CRM + post-signature kickoff
  • Week 5: Soft launch on 5 live proposals + partner feedback loop
  • Includes: prompt tuning, ISO 27001 evidence pack, monthly precision report
Get a Custom Implementation →

FAQ

We're a 12-person boutique — is this overkill for our volume?
Probably not. The economics of this pipeline aren’t about volume, they’re about partner time per proposal. A 12-person firm where two partners are drafting at midnight sees the same -85% on partner drafting time as a 200-person firm; the absolute hours saved are smaller but they fall on the most senior people in the building. The lighter setup also matters — boutiques can skip the multi-approver routing and ISO 27001 evidence pack and stand up the core in two weeks. Same pattern shows up across our AI automation services for small partnerships.
Does this replace our partners?
No. It changes what they spend their proposal week on. Partners stop drafting and start reviewing — they keep full control of approach, team mix, commercial structure, and the final pricing call. In every deployment we’ve run, partner involvement on each individual proposal goes up in quality (they’re reviewing better drafts, faster) while going down in raw hours. Headcount stays flat or grows; what changes is how much client-facing time the partnership has each week.
What about Salesforce instead of HubSpot?
Same architecture, different sync node. n8n has first-class Salesforce nodes (REST and Bulk 2.0). The proposal stage maps to Opportunity Stage; the SOW JSON, fee, buffer, and DocuSign envelope ID land in custom fields on Opportunity. The only Salesforce-specific gotcha is the validation rules engine — disable validation rules for AI-routed deals or you’ll fight your own automation. Most of our consulting deployments at firms with mature compliance functions live on Salesforce, the same way our financial services automation work usually does.
Can it draft fixed-fee, T&M, and phased commercials?
Yes — the fees object in the SOW JSON has a structure field that branches the rendered template. Fixed-fee uses a milestone-tied payment schedule. T&M renders rate cards by role with weekly cap language. Phased renders a small fixed-fee diagnose phase with a not-to-exceed estimate for design and a separate SOW required to commit to build. The classifier flags which structure a partner usually picks for that practice + complexity tier and pre-fills it; the partner can override in the Slack review modal.
How do you handle conflicts of interest?
Two layers. First, the classifier injects the firm’s current client list into context with an instruction to flag any intake where the prospect’s industry or named competitors overlap with an existing client. Second, the routing layer never sends a flagged draft to a partner who is already conflicted; the conflict-check workflow loops in the firm’s risk lead before any partner sees the intake. The whole pre-draft path is logged in the audit table for procurement defensibility.
How does this compare to Loopio, Responsive, or Qvidian?
RFP-response tools are built for filling out the buyer’s questionnaire — they’re great for security questionnaires and DDQ rounds. They are not built for drafting a partner-grade SOW from a discovery transcript. The n8n + Claude approach gives you an auditable draft with reasoning, prompt-level control over voice per practice, and the ability to pull from your own engagement history rather than a generic answer library. For a single-practice boutique, an off-the-shelf tool may be enough. For a multi-practice firm where the SOW is the product, the flexibility gap widens.
What if the partner edits the draft heavily? Does the system learn?
Yes, but slowly and on purpose. Every partner edit is captured as a diff against the original draft and tagged by edit type (rewrite, restructure, tone, factual fix, scope correction). The diffs feed a monthly retraining loop on the few-shot exemplars, and a review meeting flags any prompt-level changes worth shipping. We deliberately do not auto-fine-tune on partner edits — the risk of one partner’s voice drifting the whole firm’s output is real, and the fix should be deliberate.
Does this work for tax and audit firms or only management consultancies?
Mostly works, with two caveats. Tax and audit firms have stricter independence rules and often need a conflicts pre-clearance step that takes hours, not seconds — the workflow accommodates this by parking the draft until the independence team signs off, instead of running classification at intake. Audit-attest engagements have a heavily regulated SOW format that can’t be model-drafted; for those, the system does intake, classification, and effort estimation only, and the partner takes over from the approach section. Advisory and tax-consulting work fits the original pattern cleanly.

Want this built for your firm?

SEOKRU deploys this exact system in 5 weeks. We capture each practice’s voice from past engagements, index your last 24 months into the retrieval layer, wire intake → classify → retrieve → estimate → draft → review → DocuSign → CRM, and run the precision report monthly. You keep ownership of every component — workflows, prompts, embeddings, Postgres, the lot.

Talk to a consulting automation engineer