תעשיית הייעוץ / מדריך טכני

אוטומציית הכנת הצעות וקליטת פרויקטים בחברת ייעוץ עם n8n ו-Claude, מדריך שלב אחר שלב

מדריך מלא לבניית pipeline ב-n8n עם Claude שקולט טפסי Typeform או Tally בתוספת תמלולי שיחות discovery, מושך פרויקטים דומים מ-Notion עם vector DB, מחשב שעות מול תעריפים, מנסח SOW מלא ושולח PDF מוכן ל-DocuSign לתור הסקירה של השותף תוך פחות מ-12 דקות.

קריאה של 14 דקות
בינוני – מתקדם
n8n + Claude API
עודכן: מאי 2026
מה תבנה

טופס קליטה (Typeform/Tally)

סיווג scope (Claude)

שליפת פרויקטים קודמים

שעות × תעריף × buffer

טיוטת SOW (Claude)

סקירת שותף ב-Slack

שליחת DocuSign וסנכרון CRM

1. הבעיה, למה ניסוח הצעות אוכל את זמן השותפים

נו, כל חברת ייעוץ שעוברת 8 שותפים מגיעה לאותה תקרה. האנשים הכי מוסמכים לתחום ולתמחר פרויקט הם בדיוק אותם אנשים שהכי יקר להושיב מול קובץ Word ב-23:00 ביום ראשון. תכל'ס, חברה ישראלית בינונית בסגנון BDO או דלויט מבזבזת בערך 30 עד 50 שעות בכירים על כל הצעה בת שש ספרות. סינתזה של discovery, חיפוש פרויקטים דומים, אומדן שעות, ניסוח SOW, סקירת שותף, redlines ואריזה ל-DocuSign. עד שההצעה נוחתת, הלקוח כבר קיבל שתיים ממתחרים והפעיל שעון רכש שהחברה מוצאת את עצמה רודפת אחריו.

מספרים אמיתיים מחברת ייעוץ ניהולי בת 22 שותפים בתל אביב (180 הצעות בשנה)

ממוצע שעות בכירים להצעה 38 שעות
חציון מחזור הצעה (קליטה ועד שליחה) 5 ימים
הצעות שאבדו כי "המתחרה הגיב מהר יותר" 22%
סטיית תמחור ל-scope דומה (אותה חברה) ±34%
אחוז זכייה כשההצעה נשלחת תוך 48 שעות מהקליטה 61%

חוסר הסימטריה האכזרי. השותף שעולה לחברה $700 בשעה במלואו הוא היחיד שיודע כמה צריכה לעלות "הערכת אסטרטגיית דאטה לבנק אזורי". אבל 70% ממה שהוא עושה בשבוע ההצעה הוא מכני. הוא לא בוחר תמחור, הוא נזכר בתמחור. הוא לא מתכנן גישה, הוא מנסה לשלוף את הגישה משלוש משימות אחורה.

מה האוטומציה באמת משנה

המטרה היא לא להחליף שיקול דעת של שותף. המטרה היא להניח על שולחן השותף SOW מוכן ב-90% עד 9 בבוקר אחרי שיחת ה-discovery. שלוש שעות סקירה גוברות על שלושים שעות ניסוח, וזמן התגובה ללקוח יורד מימים לשעות:

  • נוצר אוטומטית: סיכום מצב, יעדים, הקשר מפרויקטים דומים, רשימת תוצרים, לוח אבני דרך, גלגול שעות לפי תעריף, הנחות, החרגות, תנאי תשלום.
  • השותף עורך: נרטיב הגישה, הרכב הצוות, מבנה מסחרי (פיקס מול T&M מול שלבים), סיכוני לקוח ספציפיים.
  • תמיד אנושי: החלטת התמחור הסופית, חתימה, תזמון kickoff אחרי החתימה.
תובנה
הניצחון הגדול הוא עקביות, לא מהירות. ברגע שאותה חברה מתמחרת שלוש משימות כמעט זהות בטווח של 12% במקום 34%, השותפות מפסיקה להיאבק בעצמה ומתחילה לצבור שולי רווח. אנחנו משתמשים באותו דפוס בכל פתרונות האוטומציה לחברות ייעוץ שלנו.

2. ארכיטקטורת המערכת

שבעה רכיבים, כל אחד ניתן להחלפה. שכבת התזמור היא n8n self-hosted כדי שצוות ה-security יבדוק כל קריאת API חיצונית שנוגעת בנתוני קליטה חסויים של לקוח. Postgres מחזיק את state machine של ההצעה בתוספת אינדקס embeddings לשליפת פרויקטים קודמים (pgvector).

המחסנית

n8n (self-hosted)
תזמור. Docker על VM של 4 vCPU / 16GB עם queue mode. חי מאחורי VPN של החברה.
Claude API
Sonnet לניסוח SOW ולנימוקים, Haiku לסיווג ותיוג בזול.
Typeform / Tally
קליטה. לוגיקה מותנית לפי ענף, scope ו-budget bands שמנתבת את הטופס אחרת.
Notion + pgvector
בסיס ידע של פרויקטים קודמים. Notion כמקור האמת, embeddings ב-Postgres.
HubSpot / Salesforce
מקור האמת ל-deal, איש קשר, חברה, שלב הצעה ושווי חתום.
DocuSign + Slack
תור סקירת שותף ב-Slack, שליחת חתימה אלקטרונית וטריגר kickoff אחרי חתימה.

הערכת עלות (180 הצעות בשנה)

Claude Sonnet (180 טיוטות SOW, ~14k tok in / 4k tok out) ~$430
Claude Haiku (סיווג ותיוג לאורך ה-pipeline) ~$90
Embeddings (Voyage AI או OpenAI text-embedding-3-large) ~$60
DocuSign Business Pro (5 שולחים) ~$2,100
VM (n8n + Postgres על Hetzner CCX33) ~$1,150
ניטור (Grafana Cloud + Healthchecks) ~$290
סה"כ / שנה ~$4,120

בחברה שזמן שותף עולה לה $600 עד $900 בשעה במלואו, המערכת מחזירה את עצמה כבר אחרי שש הצעות. אותה שכבת תזמור משתלבת בשירותי האוטומציה ה-AI הרחבים שלנו.

1

לכידת טופס קליטה

ה-pipeline צריך קליטה מנורמלת אחת בלי קשר לאיך הלקוח הגיע. בחברת ייעוץ בינונית ישראלית טיפוסית, נגיד באזור הרצליה פיתוח, יש שלושה מקורות. טופס Typeform או Tally משובץ באתר, שיחת discovery שנקבעה ב-Calendly עם פתק מובנה ב-HubSpot אחריה, וקליטה שיזם השותף עצמו (יש לו כבר קשר עם הלקוח והוא יוצר את ההצעה ידנית). שלושתם מתכנסים לאותו webhook של n8n.

שדות קליטה שבאמת חשובים

  • בסיס לקוח: שם חברה, קוד NAICS של הענף, אזור גיאוגרפי, רצועת מספר עובדים, רצועת ARR או הכנסות.
  • בקשת פרויקט: בעיה בשתי פסקאות, התוצאה הרצויה במילים של הלקוח עצמו, מה דוחף את התאריך (ישיבת דירקטוריון, סוף שנת כספים, רגולטור, כלום).
  • סיגנלי scope: השלב המבוקש (הערכה, עיצוב, יישום, run), נתונים שיספקו, בעלי עניין מזוהים, גורם נותן חסות פנימי או חיצוני.
  • סיגנלים מסחריים: רצועת תקציב (מוצהרת או מוסקת), תהליך רכש, הוצאת ייעוץ קודמת, סטטוס MSA איתנו.
  • תמלול discovery: אם יש הקלטת Zoom או Gong, צרף את התמלול עם חותמות זמן. זה זהב לשלב ניסוח ה-SOW.

הגדרת n8n Webhook node

Webhook node יחיד ב-n8n מקבל את ה-schema המאוחד. Switch node במורד הזרם מתפצל לפי source. אימות HMAC קורה לפני שה-workflow עושה משהו אחר, וה-PII מוצפן ברגע שהוא נוחת ב-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" }
    ]
  }
}
שים לב
קליטה שיזם השותף תהיה לרוב עם טופס מלא בחצי ושרשור Slack ארוך. תטפל בשדות חסרים עם nulls מפורשים ועם _completeness_score שהמתזמר יחליט לפיו אם לבקש מ-Claude לסמן פערים בשלב סקירת השותף, במקום להמציא תשובות.
2

סיווג פרויקט

לפני שמושכים פרויקטים דומים, המערכת צריכה לדעת מה סוג הפרויקט הזה. Claude Haiku קורא את הקליטה ואת תמלול ה-discovery, ומחזיר טקסונומיה מובנית: תחום ייעוץ, סוג פרויקט, תמהיל שלבים, רמת מורכבות ורשימת חשד לפסילות. הקריאה הזאת עולה אגורות, וחותכת את שטח החיפוש לשלב הבא בצורה אגרסיבית. אותו דפוס בעבודה שלנו באוטומציות לשירותים פיננסיים.

מימדי הסיווג

practice_area
אסטרטגיה, תפעול, טכנולוגיה, פיננסים/סיכונים, אנשים, או blend בין-תחומי.
project_type
הערכה, target operating model, טרנספורמציה, M&A diligence, audit.
phase_mix
אבחון, עיצוב, build, run, וההתפלגות הגסה ביניהם.
complexity_tier
T1 / T2 / T3, קובע שעות בסיס, מעורבות שותף וסקירת עמית.
disqualifiers
ניגודי עניינים, אזורים תחת סנקציות, בקשות מתחת למינימום, scope שלא עושים.

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"
}
תובנה
תשמור את ה-rationale כשדה מותאם על ה-deal ב-HubSpot. השותפים סומכים על המסווג מהר יותר כשהם רואים "תויג T2 כי scope של data + risk חוצה תחומים, טביעת רגל אזורית EMEA, ומשך של 14 שבועות הוזכר בתמלול".
3

שליפת פרויקטים קודמים

תכל'ס, נקודת המינוף הכי גדולה ב-pipeline כולו היא הקשר מפרויקטים דומים. חברה שעושה 200 משימות בשנה, נגיד אחת מ-BIG4 ישראליות, יושבת על מכרה זהב פרטי של תמחור, scope, תמהיל צוות ו-post-mortems. כמעט תמיד הוא לכוד בדפי Notion, תיקיות SharePoint או קובץ אקסל היסטוריה שכבר אף אחד לא נוגע בו. שכבת השליפה הופכת את זה להקשר מובנה ש-Claude יודע לקרוא.

מה נכנס לאינדקס

  • תקצירי משימות: סיכום של עמוד אחד לכל פרויקט. ענף הלקוח, scope, תוצרים, תמהיל צוות, משך, פיקס מול T&M, שווי חתום.
  • קטעי SOW: נרטיב הגישה, מבנה אבני הדרך וסעיפי החרגות. אלה החלקים שהכי ממוחזרים.
  • Post-mortems: מה תוקצב מול מה שבאמת סופק, חריגות בשעות, מספר change orders. קריטי לכיול ה-buffer.
  • פתקי win/loss: אם ההצעה נשלחה ואבדה, למה. תמחור? גישה? התאמת צוות? תזמון?

צינור embedding (Notion ל-pgvector)

workflow לילי של n8n מושך כל דף Notion שמתויג engagement, חותך אותו לחתיכות של 800 טוקנים עם חפיפה של 100, מכניס ל-embedding ועושה upsert בטבלת pgvector ב-Postgres. קריאת השליפה בזמן ההצעה מריצה חיפוש היברידי. דמיון cosine על ה-embeddings בתוספת פילטר מובנה על תחום ייעוץ, רמת מורכבות ואזור.

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);

שאילתת השליפה

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;
תובנה
תאנדקס את ה-post-mortems בנפרד, ותחשוף אותם רק לשלב סקירת השותף. אף פעם לא ל-Claude בזמן הניסוח. חריגות שעות ו-change orders מהעבר זה דינמיט לכיול buffer, אבל רדיואקטיבי אם טיוטה תורשת בטעות תלונה ספציפית של לקוח.
4

הערכת שעות

הערכת שעות זה השלב שרוב חברות הייעוץ דווקא רוצות בו אלגוריתם דטרמיניסטי, לא ניחוש של LLM. הדפוס הנכון: Claude מציע גריד שעות לפי שלב מול תפקיד בעזרת ההקשר מהפרויקטים הדומים, ואז פונקציית n8n דטרמיניסטית מכפילה לפי כרטיס התעריפים של החברה ומחילה buffer מדורג. השותף רואה גם את שעות המודל וגם את הסכום אחרי ה-buffer, עם המתמטיקה גלויה במלואה.

גריד הערכת שעות

Claude מחזיר שעות כמטריצה דו-ממדית. שורות הן שלבי הפרויקט (אבחון, עיצוב, build, run), עמודות הן תפקידים (שותף, principal, מנהל, יועץ בכיר, אנליסט, מומחה). הגריד מלא לפי 2-3 הפרויקטים הדומים שנמצאו בשליפה, עם נימוק מפורש לכל סטייה.

שלב / תפקיד שותף Principal מנהל יועץ בכיר אנליסט
אבחון (4 שב') 28 60 110 160 120
עיצוב (8 שב') 52 120 240 340 220
סך שעות 80 180 350 500 340
סך $ $72k $108k $140k $135k $54k

חישוב שעות דטרמיניסטי (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)
}}];
אבטחה
כרטיסי תעריפים זה מידע מסחרי רגיש. תחזיק אותם במשתני סביבה ב-VM של n8n, אף פעם לא ב-JSON של ה-workflow. תסובב בכל עזיבה של בכיר. המודל אף פעם לא רואה תעריפים, רק שעות. הכפל קורה בקוד דטרמיניסטי כדי ש-prompt injection בקליטה לא יוכל להטות תמחור כלפי מטה.
5

מנסח SOW של Claude

זאת הקריאה הכי כבדה ב-pipeline. Claude Sonnet מקבל את הקליטה, את תמלול ה-discovery, את הסיווג, את ההקשר מהפרויקטים הקודמים ואת גריד השעות, ומפיק טיוטת SOW מלאה עם מצב, יעדים, גישה, תוצרים, אבני דרך, צוות, תעריפים, הנחות והחרגות. הפלט מובנה כך שהוא ירונדר ישירות לתבנית Word של החברה עם המיתוג שלה.

System prompt למנסח SOW

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 אל 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 }}" }
        ]
      }
    ]
  }
}
תובנה
בכל חברה שפרסנו, הסעיף שהכי עורכים אותו הוא "גישה". אל תילחם בזה, שם נמצא ה-IP של השותף. תבנה את הסעיפים המשעממים (תוצרים, אבני דרך, הנחות, החרגות) להגיע לשיעור קבלה של 95%, ותן לשותף להשקיע את זמן הסקירה איפה שזה באמת מזיז אחוזי זכייה.
6

תור סקירת שותף

טיוטה שיושבת בתיבת אימייל היא טיוטה שמפספסת את חלון 48 השעות. תור הסקירה חי ב-Slack, בערוץ #proposal-review. כל טיוטה חדשה מתפרסמת כהודעת Block Kit עם המספרים הראשיים, קישור preview ל-Google Doc מרונדר ושלושה כפתורים: אישור, עריכה, ניסוח מחדש. כללי ניתוב בוחרים את השותף הנכון לפי תחום ייעוץ, ענף הלקוח ולוח זמינות.

מטריצת ניתוב

Tier סוקר SLA מצב אישור
T1 (<$100k) שותף מוביל בלבד 4 שעות עבודה מאשר יחיד
T2 ($100k–$500k) שותף מוביל + עמית מתחום 8 שעות עבודה מוביל + ack של עמית
T3 (>$500k) שותף מוביל + סיכון + שותף מנהל יום עבודה אישור משלושה כיוונים
חידוש MSA שותף האקאונט בלבד שעתיים עבודה מאשר יחיד

Payload סקירת Slack

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" פותח מודאל ב-Slack שבו השותף מקליד שורת הנחיה. "תעשה T&M ולא פיקס", "תוריד את workstream האנליטיקה", "תוסיף שלב פיילוט של 4 שבועות לפני התחייבות". ההנחיה חוזרת ל-Claude כסבב המשך באותה שיחה. הדפוס הזה מושאל מאיך ש-AEs תופסים hot leads במדריך ניקוד הלידים שלנו ל-SaaS.

7

DocuSign, סנכרון CRM ו-kickoff

ברגע שהשותף לוחץ אישור, n8n מרנדר את ה-SOW JSON לתבנית Word ממותגת, מייצר PDF, מעלה אותו למעטפת DocuSign מקושרת לתבנית הקיימת של החברה, שולח את המעטפת לחותמים שצוינו אצל הלקוח, ומעדכן את HubSpot. הכל ב-workflow אחד. ה-webhook אחרי החתימה מפעיל את טריגר ה-kickoff. עמוד engagement נוצר ב-Notion, הצוות שאויש מקבל הזמנה ליומן, ואינדקס היסטוריית המשימות מקבל שורה חדשה מוכנה לשליפה עתידית.

Payload מעטפת DocuSign

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 }}" }
      ]
    }
  }
}

Upsert של HubSpot deal ו-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 }}"
    }
  }
}

Kickoff אחרי חתימה (DocuSign Connect webhook)

DocuSign Connect יורה envelope-completed ברגע שכל הצדדים חותמים. ה-webhook נוחת חזרה ב-n8n ומפעיל workflow במורד הזרם: יצירת עמוד Notion engagement מתבנית, שליחת הזמנה ליומן Google דרך Calendar, פוסט #wins ב-Slack, העברת deal ב-HubSpot ל-closed_won, והוספת שורה לאינדקס היסטוריית המשימות כדי שהפרויקט יהיה ניתן לחיפוש בשליפות עתידיות מהיום הראשון.

תובנה
אינדוקס משימה שזה עתה נחתמה ביום הראשון הוא המהלך עם המינוף הכי גבוה ב-pipeline כולו. כל הצעה שתשלחו בחודש הבא תלמד מההצעה שזכיתם בה אתמול, והזיכרון המוסדי של החברה יצבור עוצמה בלי שאף אחד יצטרך לזכור לכתוב את זה איפשהו.

כשלים נפוצים ופתרונות

שלושה מצבי כשל מופיעים כמעט בכל deployment בחברת ייעוץ. תכנן עליהם מהיום הראשון, הם זולים לעיצוב מסביב ויקרים לתיקון בדיעבד.

כשל 1: נרטיב הגישה גולש לכלליות

סימפטום: סעיף הגישה נקרא כמו שקופית מתודולוגיה גנרית. שותפים פוסלים 80% מהטיוטות וכותבים מחדש מאפס, וזה מבטל את כל הפואנטה של המערכת.

פתרון: תכפה על ה-prompt לעגן כל פסקת גישה ב-chunk ספציפי של פרויקט קודם לפי ID. תפסול כל משפט שמשתמש ב-"leverage", "synergy", "best-in-class" או "world-class" עם regex post-processor. תבקש מכל ראש תחום לכתוב 200 מילים של "voice exemplar" שמשמש כעוגן few-shot לתחום שלו.

כשל 2: התמחור דולף כלפי מטה לאורך זמן

סימפטום: שטח השליפה כולל הצעות ששלחת ולא זכית בהן, ו-Claude מתחיל לתמחר לכיוון רצועת ההנחה כי קבוצת ההשוואה מוטה כלפי מטה.

פתרון: תאנדקס הצעות עם שדה outcome. won, lost, withdrawn. תיתן משקל לשליפה מוטה לטובת הצעות שזכו ביחס 3:1. תעשה re-embed כל רבעון כשעוצמת התמחור של החברה משתנה. תחשוף "רצועת מחיר השוואתית" ב-payload סקירת Slack כדי שהשותף יראה אם הטיוטה בתחתית הטווח ההיסטורי.

כשל 3: תמלול ה-discovery מדליף נתונים חסויים להקשר

סימפטום: שיחת discovery מזכירה מתחרה או ספק צד שלישי בשם, ו-Claude או מהדהד את השם ב-SOW או מתאים pattern למשימה השוואתית שכללה את אותו מתחרה.

פתרון: תריץ pre-pass של Haiku על התמלול כדי לחלץ מפת הסתרה, תחליף שמות צד שלישי ב-placeholders של [VENDOR_X] לפני כל קריאת שליפה, ותחזיר אותם רק בטיוטה הסופית מול השותף. תשמור את התמלול המקורי ב-Postgres מוצפן לטובת ביקורת, אבל אף פעם אל תיתן לטקסט המקורי להגיע ל-Claude אחרי המעבר הראשון של ההסתרה.

סודיות, NDA, ISO 27001 ושמירת נתונים

עבודת ייעוץ רצה על אמון של לקוחות, וכל קליטה היא תחת NDA במשתמע, גם אם נייר עוד לא נחתם. ה-pipeline חייב להיות ניתן להגנה מול CISO בזמן רכש, ומול שותף שנתיים אחר כך כשאותו לקוח שואל "מה עשיתם עם הנתונים שלנו?". תייחס לסודיות כאילוץ עיצוב, לא כצ'קליסט.

מה Claude רואה (ולא רואה)

  • רואה: שדות קליטה מובנים, תמלול discovery לאחר הסתרה, פלט סיווג, הקשר אנונימי מפרויקטים קודמים, גריד שעות.
  • לא רואה: לוגואים של לקוחות, שווי חתום של משימות מלקוחות קודמים, כרטיס התעריפים של החברה, נתונים אישיים של בעלי עניין מעבר לשם ותפקיד, שום מסמך שהלקוח שלח לפני שה-NDA נחתם.

שילוב NDA ב-workflow

קליטה בלי NDA חתום מצד שני נשמרת בסטטוס הסגר. n8n מסווג ומיידע את השותף, אבל לא מושך שום הקשר מפרויקטים קודמים ולא מריץ את מנסח ה-SOW. ברגע שמעטפת ה-NDA נסגרת ב-DocuSign Connect, ה-workflow משתחרר ומריץ את ה-pipeline במלואו. זה שומר על החברה מפני שימוש בלתי מכוון בהצהרת בעיה חסויה של לקוח כדי לשלוף משימה של לקוח אחר.

בקרות ISO 27001 שזה עומד בהן

  • A.5.30 מוכנות ICT: n8n self-hosted עם hot standby, Postgres עם point-in-time recovery, runbooks ב-git.
  • A.8.10 מחיקת מידע: נתוני קליטה נמחקים 90 יום אחרי deal closed-lost, נתוני engagement נשמרים לפי החוזה החתום.
  • A.8.11 מסכת נתונים: מעבר הסתרה של Haiku לפני כל קריאה ל-API צד שלישי, ללא PII בייצור ב-dev/staging.
  • A.5.14 העברת מידע: כל הקריאות לצד שלישי מעל TLS 1.3, credentials בגיבוי vault, audit log מלא.
  • A.8.16 ניטור: כל hash של prompt, שאילתת שליפה וכתיבה ל-CRM נרשמים בטבלת ביקורת בלתי משתנה.

לוח שמירת נתונים

סוג נתון שמירה טריגר למחיקה
קליטה (deal אבד) 90 יום שלב HubSpot ל-closed_lost
תמלולי discovery 180 יום סגירת engagement או 180 יום אחרי קליטה
טיוטות SOW (לא נשלחו) 30 יום cron purge של טיוטות יתומות
תקצירי engagement (זכינו) 7 שנים לפי MSA / חוזה חתום
Audit log 7 שנים לפי ISO 27001 ושמירת מס
אבטחה
תשתמש ב-tier ה-enterprise של Anthropic עם zero-data-retention מופעל ועם residency של האיחוד האירופי ללקוחות אירופיים. אף פעם אל תאמבד chunks של פרויקט קודם שמכילים שם של לקוח לשעבר או IDs של תוצרים מזוהים. ה-embedding עצמו ניתן להפיכה על ידי יריב מתוחכם. תאנונימז לפני האינדוקס, לא אחרי השליפה.

תוצאות נמדדות, אחרי חצי שנה

מספרים מ-deployment אמיתי בחברת ייעוץ ניהולי בת 22 שותפים בתל אביב, עם 180 הצעות בשנה והכנסות של 40 מיליון דולר בשלושה תחומי ייעוץ, אחרי שישה חודשים על ה-pipeline החדש. ללא שינוי בנפח ההצעות בתקופת הבדיקה. העלייה מגיעה אך ורק מקיצור מחזור, איכות אחוזי הזכייה וזמן שותפים שמשתחרר לעבודה מול לקוחות.

מחזור הצעה
5י' ל-2ש'
קליטה לטיוטה מוכנה לשותף
אחוז זכייה
+28%
מול 6 חודשים קודמים
זמן ניסוח של שותף
-85%
מ-38 ש' ל-5.4 ש' בממוצע
גודל deal ממוצע
+18%
מדיניות buffer עקבית

המדד הראשי בתוך השותפות הוא סטיית התמחור. משימות עם scope דומה כעת מתומחרות בטווח של 12% אחת מהשנייה, במקום 34%. זה המספר שמאפשר לשותף המנהל לשבת מול הדירקטוריון עם סיפור שולי רווח שניתן להגנה. בלעדיו, כל סקירה רבעונית הופכת לציד אחר השותף שתמחר נמוך מדי שוב.

לוח זמנים ועלות יישום

מסלול DIY
90 עד 130 שעות
  • הקמת n8n self-host + queue mode: 8 עד 12 שעות
  • schema קליטה + אימות HMAC לכל המקורות: 6 עד 8 שעות
  • צינור embedding מ-Notion ל-pgvector: 14 עד 18 שעות
  • כיוון prompts לסיווג ושליפה: 12 עד 16 שעות
  • גריד שעות + מדיניות buffer + vault לכרטיס תעריפים: 10 עד 14 שעות
  • prompt למנסח SOW + voice exemplars לכל תחום: 18 עד 24 שעות
  • תור סקירת Slack + ניתוב רב-מאשרים: 10 עד 14 שעות
  • חיווט תבנית DocuSign + kickoff אחרי חתימה: 8 עד 12 שעות
  • סנכרון HubSpot/Salesforce + audit log: 6 עד 8 שעות
  • חבילת ראיות ISO 27001 + הדרכת שותפים: 8 עד 12 שעות
עם SEOKRU
פריסה ב-5 שבועות
  • שבוע 1: לכידת voice לכל תחום + אינדקס 24 חודשים אחורה של משימות
  • שבוע 2: טופס קליטה + סיווג + כיול שליפה
  • שבוע 3: מנסח SOW + גריד שעות + סקירת Slack
  • שבוע 4: DocuSign + CRM + kickoff אחרי חתימה
  • שבוע 5: השקה רכה על 5 הצעות חיות + לולאת משוב שותף
  • כולל: כיוון prompts, חבילת ראיות ISO 27001, דוח דיוק חודשי
קבל יישום מותאם ←

שאלות נפוצות

כנראה שלא. הכלכלה של ה-pipeline הזה היא לא על נפח, היא על זמן שותף לכל הצעה. בוטיק של 12 איש שבו שני שותפים מנסחים בחצות רואה את אותם 85%- בזמן ניסוח של שותף, כמו חברה של 200 איש. השעות הכוללות שנחסכות קטנות יותר, אבל הן נופלות על האנשים הכי בכירים בבניין. גם ההקמה הקלילה משנה. בוטיקים יכולים לדלג על ניתוב רב-מאשרים ועל חבילת ראיות ISO 27001, ולהקים את הליבה תוך שבועיים. אותו דפוס מופיע בשירותי האוטומציה ה-AI שלנו לשותפויות קטנות.
לא. זה משנה במה הם משקיעים את שבוע ההצעה. השותפים מפסיקים לנסח ומתחילים לסקור. הם שומרים שליטה מלאה על גישה, תמהיל צוות, מבנה מסחרי וקריאת התמחור הסופית. בכל deployment שהרצנו, מעורבות השותף בכל הצעה ספציפית עולה באיכות (הוא סוקר טיוטות טובות יותר מהר יותר), ויורדת בשעות ברוטו. מצבת השותפים נשארת זהה או גדלה. מה שמשתנה זה כמה זמן מול לקוחות יש לשותפות בכל שבוע.
אותה ארכיטקטורה, node סנכרון אחר. ל-n8n יש nodes ראשיים ל-Salesforce (REST ו-Bulk 2.0). שלב ההצעה ממופה ל-Opportunity Stage. ה-SOW JSON, התעריף, ה-buffer ומזהה מעטפת DocuSign יורדים לשדות מותאמים על ה-Opportunity. ה-gotcha היחיד הספציפי ל-Salesforce הוא מנוע ה-validation rules. בטל אותם ל-deals מנותבי AI אחרת תילחם באוטומציה של עצמך. רוב ה-deployments שלנו בחברות ייעוץ עם פונקציית ציות בשלה חיים על Salesforce, באותה צורה שעבודת האוטומציות לשירותים פיננסיים שלנו לרוב חיה.
כן. אובייקט ה-fees ב-SOW JSON מכיל שדה structure שמסתעף בתבנית המרונדרת. פיקס משתמש בלוח תשלום צמוד לאבני דרך. T&M מרנדר כרטיסי תעריף לפי תפקיד עם שפת תקרה שבועית. שלבים מרנדר שלב אבחון פיקס קטן עם הערכת not-to-exceed לעיצוב, ו-SOW נפרד נדרש להתחייבות ל-build. המסווג מסמן איזה מבנה השותף בדרך כלל בוחר לאותו תחום ורמת מורכבות, וממלא מראש. השותף עוקף בתוך מודאל סקירת Slack.
שתי שכבות. ראשית, המסווג מזריק להקשר את רשימת הלקוחות הנוכחית של החברה, עם הוראה לסמן כל קליטה שבה ענף הלקוח או מתחרים מזוהים חופפים ללקוח קיים. שנית, שכבת הניתוב לעולם לא שולחת טיוטה מסומנת לשותף שכבר בניגוד עניינים. ה-workflow של בדיקת הקונפליקט מערב את ראש הסיכון של החברה לפני ששותף בכלל רואה את הקליטה. כל המסלול לפני הניסוח נרשם בטבלת ה-audit להגנה ברכש.
כלי תגובה ל-RFP בנויים למלא שאלון של קונה. הם מצוינים לשאלוני אבטחה ולסבבי DDQ. הם לא בנויים לנסח SOW ברמת שותף מתמלול discovery. גישת n8n + Claude נותנת טיוטה ניתנת לביקורת עם נימוקים, שליטה ברמת ה-prompt על voice לכל תחום, והיכולת למשוך מהיסטוריית המשימות שלך עצמך, במקום מספריית תשובות גנריות. לבוטיק של תחום אחד, כלי מהמדף יכול להספיק. לחברה רב-תחומית שבה ה-SOW הוא המוצר, פער הגמישות מתרחב.
כן, אבל לאט ובמכוון. כל עריכת שותף נלכדת כ-diff מול הטיוטה המקורית ומתויגת לפי סוג עריכה (כתיבה מחדש, ארגון מחדש, טון, תיקון עובדה, תיקון scope). ה-diffs מזינים לולאת אימון חודשית על דוגמאות few-shot, וישיבת סקירה מסמנת כל שינוי ברמת ה-prompt ששווה לשחרר. אנחנו במכוון לא עושים auto-fine-tune על עריכות שותף. הסיכון שה-voice של שותף אחד יסחף את כל הפלט של החברה הוא אמיתי, והתיקון צריך להיות מודע.
ברובו עובד, עם שני סייגים. חברות מס וביקורת בארץ, בעיקר רואי-חשבון BIG4 כמו KPMG ו-EY, עם כללי עצמאות מחמירים יותר וצריכות שלב conflicts pre-clearance שלוקח שעות, לא שניות. ה-workflow מתאים את עצמו ומחנה את הטיוטה עד שצוות העצמאות נותן אישור, במקום להריץ סיווג בקליטה. משימות audit-attest רוצות פורמט SOW מוסדר בכבדות שלא ניתן לניסוח על ידי מודל. בשבילן המערכת עושה רק קליטה, סיווג והערכת שעות, והשותף משתלט מסעיף הגישה. עבודת ייעוץ ויעוץ מס מתאימה לדפוס המקורי בצורה נקייה.

רוצה שזה ייבנה לחברה שלך?

SEOKRU פורסת את המערכת הזו בדיוק ב-5 שבועות. אנחנו לוכדים את ה-voice של כל תחום מהמשימות הקודמות, מאנדקסים את 24 החודשים האחרונים שלך לשכבת השליפה, מחווטים קליטה עד סיווג, שליפה, הערכה, ניסוח, סקירה, DocuSign וסנכרון CRM, ומריצים דוח דיוק חודשי. אתם שומרים בעלות על כל רכיב. workflows, prompts, embeddings, Postgres, הכל.

דבר עם מהנדס אוטומציה לחברות ייעוץ