אוטומציית ניקוד לידים מ-Trial ל-Paid עם n8n ו-Claude — מדריך שלב אחר שלב

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

שישה רכיבים, כל אחד ניתן להחלפה. שכבת התזמור היא n8n self-hosted כדי שצוות ה-security יוכל לבדוק כל קריאת API חיצונית שנוגעת בנתוני prospects. Postgres מחזיק גם את ה-event store וגם את היסטוריית הציונים.

המחסנית

הערכת עלות (5,000 הרשמות בחודש)

ב-ACV של $9k–$30k, עסקה סגורה אחת נוספת מה-pipeline הזה משלמת על כל המחסנית לשנה שלמה. אותה שכבת תזמור משתלבת בשירותי האוטומציה ה-AI הרחבים שלנו.

ה-pipeline צריך כל הרשמה, ללא קשר למשטח שדרכו היא הגיעה. ב-SaaS טיפוסי זה אומר שלושה מקורות: המוצר עצמו (webhook של ספק ה-auth), ספק החיוב כשמוסיפים כרטיס (Stripe) וטפסי השיווק (HubSpot Forms, Default.com או landing page מותאם).

מקורות Webhook

• Auth0 / Cognito / Clerk: פולט אירוע user.created עם email, IP הרשמה, ושם חברה אופציונלי מהטופס.
• Stripe: customer.created בזרימות trial-with-card. נורה בערך 2-5 דקות אחרי הרשמת auth.
• App POST: לאירועי PQL שה-auth webhook לא יכול ללכוד (workspace_created, integration_connected). השתמש ב-payload חתום HMAC.
• מילוי טפסים: בקשות הדגמה, הורדות תוכן, שליחות מעמוד תמחור. תייחס אליהן כהרשמות מהשורה הראשונה.

הגדרת n8n Webhook node

Webhook node יחיד ב-n8n מקבל את ה-schema המאוחד; Switch node במורד הזרם מתפצל לפי source. אימות HMAC קורה לפני שה-workflow עושה משהו אחר.

{
  "source": "auth0" | "stripe" | "app" | "form",
  "event_id": "evt_01HXYZ...",
  "received_at": "2026-05-03T09:14:22Z",
  "signature": "sha256=...",
  "user": {
    "email": "[email protected]",
    "first_name": "Alex",
    "last_name": "Chen",
    "company_name_provided": "Acme Corp",
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0 ...",
    "utm": {
      "source": "google",
      "campaign": "pql-q2-2026",
      "term": "workflow automation"
    }
  },
  "workspace_id": "ws_92ad3c"
}

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

קסקדת העשרה (כשל מהיר, כשל זול)

1. בדיקת MX של דומיין — אם לדומיין ה-email אין MX record, סמן invalid ועצור.
2. סינון email פרטי — gmail.com, yahoo.com, qq.com וכו' מקבלים consumer_email. אל תעשיר (בזבוז credits) אבל עדיין נקד.
3. Clearbit Reveal על IP ההרשמה — נותן שם חברה ודומיין גם אם נרשמו עם email פרטי.
4. Clearbit Person + Company על email העבודה — תפקיד, סניוריות, גודל חברה, ענף, גיוס, מחסנית טכנולוגית.
5. Apollo כ-fallback כש-Clearbit מחזיר <30% כיסוי שדות.
6. Bright Data LinkedIn scraper כמוצא אחרון לסניוריות חסרה בחברות קטנות.

SQL: cache העשרה למניעת חיוב כפול

-- Reuse company-level enrichment for any user from the same domain
-- within 30 days. Saves ~40% of Clearbit credits at scale.

WITH cached AS (
  SELECT enrichment_payload
  FROM   enrichment_cache
  WHERE  domain = $1
    AND  enriched_at > now() - interval '30 days'
  ORDER  BY enriched_at DESC
  LIMIT  1
)
SELECT
  CASE
    WHEN EXISTS (SELECT 1 FROM cached)
    THEN (SELECT enrichment_payload FROM cached)
    ELSE NULL
  END AS payload;

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

5 ממדי הניקוד

System prompt לניקוד ICP

נבדק על 6 חודשים של הרשמות היסטוריות עם תווית closed-won מול churned. ניתן לכוונן פר חברה על ידי עריכת בלוק ה-ICP בראש.

You are an ICP scoring engine for a B2B SaaS workflow automation tool.

ICP definition (highest fit):
- Industry: SaaS, fintech, e-commerce ops, agencies
- Size: 50-2000 employees, >$5M ARR
- Tech stack: uses Slack, HubSpot/Salesforce, AWS or GCP
- Role: ops, RevOps, marketing ops, growth eng (IC level OK
  if they're the documented buyer for tooling)

DISQUALIFY signals:
- Personal Gmail/Yahoo with no company match
- Competitor employee (check enriched company against our
  competitor list in context)
- Student / agency-doing-research signals
- <5 employees (free tier suffices)

OUTPUT — strict JSON, no prose:
{
  "score": 0-100,
  "tier": "hot" | "warm" | "cold" | "disqualify",
  "dimensions": {
    "industry_match": 0-20,
    "company_size_band": 0-20,
    "tech_stack_signals": 0-20,
    "role_seniority": 0-20,
    "intent_signals": 0-20
  },
  "reasoning": "2-3 sentences citing the strongest signals",
  "recommended_action": "ae_dm" | "sdr_queue" | "drip_only" | "discard"
}

Rules:
- score = sum of dimensions
- tier mapping: >=80 hot, 50-79 warm, <50 cold
- if disqualify_reason present, tier = "disqualify" regardless
- never invent enrichment fields not in the input

n8n HTTP Request ל-Claude

{
  "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": 600,
    "system": "{{ $json.icpSystemPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": "Enriched signup:n{{ JSON.stringify($json.enriched) }}nnEarly product events (last 1h):n{{ JSON.stringify($json.events) }}"
      }
    ]
  }
}

משתמש Trial שמגיע ל-first-value, מזמין חבר צוות ומחבר אינטגרציה ב-48 השעות הראשונות ממיר בקצב של בערך פי 7 לעומת הרשמה פסיבית. לכוד את האירועים האלה לתוך אותו Postgres event store והזן אותם בחזרה ל-Claude בקצב re-score של 6 ושל 24 שעות.

אירועי ה-Activation שמזיזים ציונים

• first_value_reached — המשתמש השלים את פעולת ה-"aha" המרכזית (משתנה לפי מוצר).
• team_invited — הסיגנל החזק ביותר של כוונת קנייה. רב-מושבים = משלם.
• integration_connected — הם הביאו את הנתונים שלהם פנימה. עלות המעבר עלתה.
• pricing_page_visited — intent מאוחר ב-trial. תן re-score בתוך 30 דקות.
• api_token_created — champion הנדסי אמיתי, ההערכה רצינית.

Schema של Event store

CREATE TABLE product_events (
  id            uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  workspace_id  text NOT NULL,
  user_email    text NOT NULL,
  event_name    text NOT NULL,
  event_value   jsonb,
  occurred_at   timestamptz NOT NULL,
  ingested_at   timestamptz DEFAULT now()
) PARTITION BY RANGE (occurred_at);

CREATE INDEX idx_events_workspace_event
  ON product_events (workspace_id, event_name, occurred_at DESC);

-- Activation feature view used by the re-score job
CREATE MATERIALIZED VIEW activation_features AS
SELECT
  workspace_id,
  user_email,
  bool_or(event_name = 'first_value_reached')    AS hit_first_value,
  bool_or(event_name = 'team_invited')           AS invited_team,
  bool_or(event_name = 'integration_connected')  AS connected_integration,
  count(*) FILTER (WHERE event_name = 'pricing_page_visited') AS pricing_views,
  max(occurred_at)                                AS last_active_at
FROM product_events
WHERE occurred_at > now() - interval '14 days'
GROUP BY workspace_id, user_email;

ברגע שציון נחת, הניתוב דטרמיניסטי. tier ה-hot צריך אדם מול ה-prospect בתוך 5 דקות; tier ה-warm מזין את תור ה-SDR עם פתיחה אישית ש-Claude כבר ניסח; tier ה-cold לא נוגע באדם עד שהוא מקבל ציון גבוה יותר.

מטריצת ניתוב

Payload התראת Slack (tier ה-hot)

{
  "channel": "#hot-trials",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text",
                "text": ":fire: Hot trial — score 87" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn",
          "text": "*Alex Chen*nDirector RevOps, Acme Corp" },
        { "type": "mrkdwn",
          "text": "*Stack*nSlack, Salesforce, Snowflake" }
      ]
    },
    {
      "type": "section",
      "text": { "type": "mrkdwn",
                "text": "*Why hot:* came from /integrations/salesforce, invited 2 teammates, connected Slack within 11 min of signup." }
    },
    {
      "type": "actions",
      "elements": [
        { "type": "button", "text": { "type": "plain_text",
          "text": "Claim" }, "style": "primary", "action_id": "claim_lead" },
        { "type": "button", "text": { "type": "plain_text",
          "text": "Open in HubSpot" }, "url": "https://app.hubspot.com/contacts/.../{{contactId}}" }
      ]
    }
  ]
}

כפתור ה-Claim פוגע ב-webhook חזרה ל-n8n שנועל את הליד ל-AE הזה ל-24 שעות ומוציא אותו מ-round-robin של ה-SDR. זה הדפוס שאנחנו משתמשים בו מחדש באוטומציות לתעשיית הייעוץ שלנו, שם שותפים זקוקים למגע ראשון בלידי enterprise.

HubSpot או Salesforce נשארים מקור האמת לכל מה שצוות המכירות רואה. ה-workflow ב-n8n עושה upsert לאיש קשר, מצמיד אותו לרשומת חברה (התאמה לפי דומיין), מעדכן lifecycle stage ודוחף את הציון ואת הנימוק לשדות מותאמים. dedupe רץ על email + דומיין כדי לטפל במקרה הערכה רב-בעלי-עניין בצורה נקייה.

HubSpot upsert (דרך v3 API)

{
  "method": "PATCH",
  "url": "https://api.hubapi.com/crm/v3/objects/contacts/[email protected]?idProperty=email",
  "headers": {
    "authorization": "Bearer {{ $credentials.hubspot.token }}",
    "content-type": "application/json"
  },
  "body": {
    "properties": {
      "firstname": "Alex",
      "lastname":  "Chen",
      "jobtitle":  "Director, RevOps",
      "lifecyclestage": "salesqualifiedlead",
      "skru_icp_score":      "87",
      "skru_icp_tier":       "hot",
      "skru_icp_reasoning":  "{{ $json.score.reasoning }}",
      "skru_signup_source":  "auth0",
      "skru_first_event":    "team_invited"
    }
  }
}

SQL ל-Dedupe

-- Idempotent contact write keyed on lower(email).
-- Aggregates same-domain stakeholders into one company score.

INSERT INTO contacts (email, domain, first_seen_at, latest_score, latest_tier)
VALUES ($1, $2, now(), $3, $4)
ON CONFLICT (email) DO UPDATE
  SET latest_score = EXCLUDED.latest_score,
      latest_tier  = EXCLUDED.latest_tier,
      updated_at   = now();

-- Promote the company tier to the highest stakeholder tier in the last 30d
UPDATE companies c
SET    rolled_up_tier = sub.max_tier
FROM (
  SELECT domain,
         CASE WHEN max(score_rank) = 4 THEN 'hot'
              WHEN max(score_rank) = 3 THEN 'warm'
              ELSE 'cold' END AS max_tier
  FROM (
    SELECT domain,
           CASE latest_tier WHEN 'hot' THEN 4
                            WHEN 'warm' THEN 3
                            WHEN 'cold' THEN 2
                            ELSE 1 END AS score_rank
    FROM contacts
    WHERE updated_at > now() - interval '30 days'
  ) ranked
  GROUP BY domain
) sub
WHERE c.domain = sub.domain;

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

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

כשל 1: ניפוח ציונים על ICPs מ-email פרטי

סימפטום: יועץ עם כתובת Gmail מצהיר על תפקיד ברמת VP בטופס, מקבל העשרה מול חברה לא נכונה (הדומיין של מעסיק קודם ב-LinkedIn) ונוחת כ-hot.

פתרון: הגבל כל הרשמת email פרטי לציון מקסימלי של 60 בחוקי ה-prompt וחייב אישור SDR ידני לפני קידום ל-hot. תעד את החוק ב-system prompt כדי שהמחרוזת של הנימוקים תסביר למה.

כשל 2: הרשמות מתחרים מועשרות ומנותבות

סימפטום: PM אצל מתחרה ישיר נרשם, מנותב ל-AE שקובע פגישת discovery לפני שהוא קולט.

פתרון: תחזק טבלת Postgres competitor_domains והזרק אותה להקשר ה-prompt של Claude. סווג אוטומטית כ-disqualify עם התראה נפרדת לשיווק מוצר במקום למכירות.

כשל 3: קסקדות rate-limit בעומסי הרשמה

סימפטום: השקה ב-Product Hunt שולחת 3,000 הרשמות ב-90 דקות. Clearbit עושה rate-limit, התור של n8n נסתם, לידים hot נוחתים ב-Slack באיחור של 4 שעות.

פתרון: הרץ n8n ב-queue mode עם לפחות 4 worker processes. עטוף קריאות חיצוניות ב-retry-with-jitter (3 ניסיונות, 250ms-2s). חמם מראש את cache ההעשרה מ-30 הימים האחרונים של דומייני הרשמה לפני כל קמפיין מתוכנן.

פרטיות: GDPR, CCPA, CASL ו-SOC 2

נתוני prospects ב-B2B עדיין נופלים תחת GDPR (האיחוד האירופי), CCPA (קליפורניה) ו-CASL (קנדה). PCI לא רלוונטי כי שום נתון תשלום לא זורם ב-pipeline הניקוד — Stripe מטפל בזה במשטח שלו. תייחס לציות כאילוץ עיצוב, לא כצ'קליסט בסוף.

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

• רואה: email עסקי, שם, תפקיד, מעסיק, firmographics ציבוריים בסגנון LinkedIn, שמות אירועי מוצר + ספירות, מקור UTM.
• לא רואה: טקסטים בתוך המוצר, תוכן קבצים, נתוני תשלום, IP (רק המדינה הנגזרת ממנו), session tokens.

פרטים ספציפיים ל-GDPR

בסיס חוקי לפרוספקטינג B2B באיחוד האירופי הוא אינטרס לגיטימי, אבל זה דורש מבחן איזון בתיק וכיבוד מיידי של בקשות התנגדות. ממש endpoints של DSR (גישה, מחיקה, ניידות) שמטהרים את איש הקשר ב-Postgres, ב-cache ההעשרה וב-HubSpot בעסקה אחת. CASL בקנדה מחמיר יותר — צריך הסכמה מפורשת לפני שליחת רצפי warm/cold לכתובות קנדיות; דגל וחסום לפי המדינה המועשרת.

בקרות SOC 2 Type 2 שזה עומד בהן

• Audit trail: כל ציון, hash של prompt וכתיבה ל-CRM נרשמים בטבלת ביקורת עם reviewer (אם יש), חותמת זמן ו-IP מקור.
• ניהול שינויים: workflows של n8n חיים ב-git עם CI deploy, אין עריכות point-and-click בפרודקשן.
• בקרות גישה: credentials של n8n מבוסס תפקידים, secrets בגיבוי vault, אין מפתחות API משותפים פר אדם.

תוצאות נמדדות — אחרי 90 יום

מספרים מ-deployment אמיתי ב-SaaS ורטיקלי בשלב Series A (1,800 הרשמות בחודש, צוות SDR של 3 אנשים, 4 AEs) אחרי הרבעון המלא הראשון על ה-pipeline החדש. ללא שינוי בנפח ה-Trial בתקופת הבדיקה — העלייה מגיעה אך ורק מתעדוף ומהירות.

המדד הראשי בתוך צוות ה-SDR הוא דיוק על tier ה-hot: 91% מהלידים שקיבלו ציון hot הפכו ל-opportunities. זה המספר שמאפשר להנהלת המכירות לסמוך על הציון מספיק כדי לשנות התנהגות בפועל. בלעדיו, AEs חוזרים לעבוד על הרשימות הישנות שלהם לפי תחושת בטן.

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

שאלות נפוצות