מדריך: אוטומציית קליטת לקוחות ובדיקת ניגודי עניינים במשרד עו"ד עם n8n ו-Claude (2026)

צוואר הבקבוק שאף משרד לא רוצה להודות בו

ברוב המשרדים בגודל בינוני, פנייה חדשה ממתינה 26 שעות עד שיחזור, מתמחה מעתיק את אותם פרטי קשר ל-Clio בפעם השלישית באותו בוקר, ושותף מגלה — שלושה שבועות לתוך ייצוג — שהצד שכנגד הוא לקוח לשעבר. כל אחת מהתקלות האלה ניתנת למניעה באותו workflow.

המדריך הזה עובר על pipeline פרודקשן לקליטת לקוחות ובדיקת ניגוד עניינים, הבנוי על n8n, Claude (דרך Bedrock עם BAA חתום), ומערכת ה-practice management הקיימת שלכם. זו אותה ארכיטקטורה שהמהנדסים שלנו מטמיעים אצל משרדי בוטיק ליטיגציה ואצל משרדים כלליים של 80 עו"ד — ראו את שירות אוטומציית AI למשרדי עו"ד לגרסה המוצרית.

1
חיבור כל ערוץ נכנס לתור אחד

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

אנחנו משתמשים בשלושה triggers במקביל: webhook של Gravity Forms (או Formidable), node IMAP שמתשאל את `intake@` כל 60 שניות, ו-webhook של Twilio Voice Intelligence לתעתיקי שיחות אחרי שעות העבודה. כל trigger כותב לאותה טבלת Postgres בשם `intakes_raw` עם `source`, `received_at` ועמודת `payload` מסוג JSONB. nodes בהמשך לעולם לא מסתעפים לפי source.

{
  "node": "Postgres Insert",
  "table": "intakes_raw",
  "columns": {
    "source":      "={{$json.source}}",
    "received_at": "={{$now.toISO()}}",
    "payload":     "={{JSON.stringify($json)}}",
    "channel_id":  "={{$json.channel_id || null}}",
    "status":      "queued"
  },
  "options": { "returnFields": "id" }
}

2
חילוץ PII וסיווג סוג התיק עם Claude

קריאה אחת ל-Claude עושה כעת תפקיד כפול: חילוץ PII מובנה וגם סיווג סוג תיק עם אוצר מילים מצומצם. השתמשו בתבנית tool-calling עם JSON schema קשיח כך ש-n8n לעולם לא יצטרך לפרסר טקסט חופשי — וכך תקבלו פלט בצורה דטרמיניסטית עבור שלב בדיקת הניגוד.

שבעת סוגי התיקים שאליהם אנחנו מנתבים: personal injury, family, criminal, real estate, business, IP, immigration. הוספנו דלי `other` שמתריע לעו"ד התורן במקום לנתב אוטומטית — סיווג שגוי שקט גרוע יותר מבדיקה ידנית.

You are an intake analyst at a US law firm. Given the
inbound message, extract PII and classify the matter.

Output ONLY valid JSON matching this schema:
{
  "client":   {"full_name": str, "email": str|null,
               "phone": str|null, "dob": str|null},
  "adverse":  [{"full_name": str, "role": str}],
  "matter":   "personal_injury" | "family" | "criminal" |
              "real_estate" | "business" | "ip" |
              "immigration" | "other",
  "summary":  str (max 280 chars, NO legal opinion),
  "urgency_signals": [str],
  "confidence": float (0-1)
}

NEVER summarize legal merit. NEVER cite statutes.
If matter is unclear, return "other" and confidence < 0.6.

3
בדיקת ניגוד עניינים אמיתית (לא רק התאמת שמות)

בדיקת ניגוד היא המקום שבו רוב האוטומציות נופלות בכנות: הן מתשאלות את ה-Contacts endpoint של Clio עם `?query=Smith` וזהו. ניגודים אמיתיים מסתתרים בלקוחות לשעבר, בצדדים שכנגד מתיקים סגורים, בישויות תאגידיות קשורות ובמשלמים מחשבונות נאמנות. משכו את כולם ל-mirror ב-Postgres מדי לילה, ואז תשאלו עם `pg_trgm` להתאמה מטושטשת בשמות, פלוס מעבר בהתאמה מדויקת על email/phone/EIN.

שתי השאילתות למטה רצות במקביל מול `clients_mirror` ו-`adverse_mirror`. כל מה שמעל 0.62 דמיון עולה לבודק; כל מה שמעל 0.85 עוצר לחלוטין עד אישור שותף.

-- Requires: CREATE EXTENSION IF NOT EXISTS pg_trgm;
WITH candidate AS (
  SELECT $1::text AS name, $2::text AS email, $3::text AS phone
)
SELECT
  c.id, c.full_name, c.matter_status,
  similarity(c.full_name, candidate.name) AS name_score,
  (c.email = candidate.email) AS email_hit,
  (regexp_replace(c.phone,'D','','g')
    = regexp_replace(candidate.phone,'D','','g')) AS phone_hit
FROM clients_mirror c, candidate
WHERE c.full_name % candidate.name        -- pg_trgm operator
   OR c.email = candidate.email
   OR c.phone IS NOT NULL
ORDER BY name_score DESC
LIMIT 25;

4
תיעדוף דחיפות: התיישנות וזימוני בית משפט

פנייה לגבי תאונת דרכים שמגיעה 11 חודשים אחרי האירוע היא טיקט שונה מהותית מפנייה שלושה שבועות אחרי. הציפו את הסיגנלים האלה לפני שהתיק מגיע לתור של עו"ד. Claude כבר מחזיר `urgency_signals` בשלב 2 — מנוע חוקים קטן ב-n8n הופך את אלה לעדיפות נומרית שמניעה מיקום בתור וטיימר SLA.

אנחנו משתמשים בארבעה דליים: P0 (התיישנות בעוד פחות מ-60 יום, דיון בעוד פחות מ-14 יום), P1 (התיישנות פחות מ-180 יום, משמורת/צו הרחקה), P2 (דדליין פעיל מעל 180 יום), P3 (אין לחץ זמן). P0 מתריע לעו"ד התורן ב-SMS דרך Twilio; כל היתר נופלים לערוץ Slack עם יעדי תגובה.

const signals = $input.item.json.urgency_signals || [];
const text    = signals.join(' ').toLowerCase();

const has = (kw) => kw.some(k => text.includes(k));

let priority = 'P3';
if (has(['hearing tomorrow','court today','arraignment',
         'arrested','served papers'])) priority = 'P0';
else if (has(['restraining','custody','eviction',
              'deportation','statute'])) priority = 'P1';
else if (has(['accident','injury','contract breach',
              'closing date'])) priority = 'P2';

return [{
  json: { ...$input.item.json, priority,
          sla_minutes: { P0: 15, P1: 60, P2: 240, P3: 1440 }[priority] }
}];

5
יצירת התיק והקצאה לפי תחום ועומס עבודה

עכשיו הפנייה — שעברה ניקוי, סיווג ותיעדוף — מגיעה לשלב יצירת התיק. ה-Clio v4 REST API מקבל איש קשר, תיק ורשימת צדדים קשורים בשלוש קריאות עוקבות — עטפו אותן ב-Sub-Workflow של n8n עם מדיניות retry אחת, כדי שכשל חלקי יחזיר את יצירת איש הקשר. משתמשי PracticePanther ו-MyCase פועלים באותה צורה עם ה-endpoints שלהם.

ההקצאה היא שאילתה משוקללת מול טבלת `attorneys`: פילטר לפי תחום, מיון לפי כמות תיקים פתוחים בעולה, שובר שוויון לפי חותמת זמן הישנה ביותר של הקצאה אחרונה. הימנעו מ-round-robin בלבד — הוא מתעלם מקיבולת. הימנעו ממיון לפי קיבולת בלבד — הוא מרכז עבודה אצל מי שזה עתה סגר תיק.

POST https://app.clio.com/api/v4/matters
Authorization: Bearer {{$credentials.clio_oauth.access_token}}
Content-Type: application/json

{
  "data": {
    "client":            { "id": {{$json.client_id}} },
    "description":       "{{$json.summary}}",
    "practice_area":     { "id": {{$json.practice_area_id}} },
    "responsible_attorney": { "id": {{$json.attorney_id}} },
    "status":            "Pending",
    "custom_field_values": [
      { "custom_field": {"id": 12345},
        "value": "{{$json.priority}}" },
      { "custom_field": {"id": 12346},
        "value": "{{$json.intake_id}}" }
    ]
  }
}

6
יומן ביקורת append-only ודגל תקשורת חסויה

ABA Model Rule 1.6 דורש מהמשרד להפעיל מאמצים סבירים למניעת חשיפה לא מורשית. באוטומציה זה אומר: כל פנייה מייצרת רשומה בלתי-ניתנת-לשינוי של מה חולץ, מה נשלח ל-Claude, אילו מועמדי ניגוד עלו, ומי ראה את התוצאה. השתמשו בטבלת Postgres עם הרשאות `INSERT` בלבד וב-snapshot WORM יומי ל-S3 Object Lock.

כל שורה מתויגת `privileged: true` כברירת מחדל ומוחרגת מכל דשבורד דיווח. דיווח מבצע join מול view מצטבר שמסיר את עמודת ה-`payload` לחלוטין.

CREATE TABLE intake_audit (
  id              bigserial PRIMARY KEY,
  intake_id       uuid NOT NULL,
  occurred_at     timestamptz NOT NULL DEFAULT now(),
  actor           text NOT NULL,             -- 'n8n' | 'claude' | user
  event           text NOT NULL,             -- 'extract'|'classify'|...
  payload_hash    text NOT NULL,             -- sha256 of payload
  conflict_hits   jsonb,
  privileged      boolean NOT NULL DEFAULT true,
  matter_id       bigint
);

REVOKE UPDATE, DELETE ON intake_audit FROM PUBLIC;
GRANT  INSERT, SELECT  ON intake_audit TO n8n_writer;

כשלים נפוצים בפרודקשן

• בעיית "Smith". שמות משפחה חוזרים. תמיד דרשו לפחות מזהה משני אחד — DOB, אימייל או כתובת — לפני ניקוי ניגוד. ייצוגי "John Smith" שנוקו והתבררו כ-John Smith הלא נכון אחראים לכ-40% מתביעות הרשלנות הקשורות לניגודי עניינים.
• פג תוקף OAuth שקט. Tokens של Clio ו-PracticePanther מתחדשים כל 7 ימים. בלי monitor חיצוני, המשרד מגלה את הכשל כשהקליטה פשוט מפסיקה ליצור תיקים; עומק התור הוא הקנרי שלכם.
• תא קולי כקליטה. תעתיקי Twilio של תאי קוליים באיכות ירודה מייצרים לעיתים קרובות שמות זבל. תמיד כפו `confidence < 0.7` על סיווג Claude כשהמקור הוא `phone` כדי לעבור לבדיקה אנושית.
• הזיית תחום משפטי בתיקים חדשניים. Claude יסווג בביטחון "סכסוך סימן מסחרי על non-fungible token" כ-IP כשבעצם זה אולי ליטיגציה מסחרית. הדלי `other` קיים בדיוק לזה — שמרו עליו רחב.
• כתיבת audit-log באותו transaction של Clio create. timeout של Clio API מבטל את ה-insert של הביקורת ואתם מאבדים את ה-breadcrumb. כתיבות audit הן תמיד transaction נפרד שרץ לפני קריאת ה-API לצד שלישי.

עמדת פרטיות ורגולציה

אוטומציה משפטית חיה ומתה על שרשרת ה-BAA. ארכיטקטורת ברירת המחדל שאנחנו מספקים משתמשת ב-Claude דרך AWS Bedrock עם BAA חתום, n8n self-hosted ב-AWS בתוך VPC שהמשרד שולט בו, ו-Postgres על RDS עם הצפנה במנוחה ובהעברה. אין יציאה של נתוני לקוחות מחשבון ה-AWS של המשרד למעט הקריאה המוצפנת ל-Bedrock עצמה, שמכוסה על ידי תנאי Bedrock של Anthropic תחת zero-data-retention.

ללקוחות באיחוד האירופי, אותה ארכיטקטורה נפרסת ל-`eu-central-1` ומוסיפה זרימות data subject access של GDPR על טבלת הביקורת. למשרדים שעוסקים בעבודה הנוגעת ב-ITAR, אנחנו ממליצים על פריסה מבודדת רשת שמשתמשת ב-LLM on-prem (Llama 3.1 70B) במקום Claude — מבנה ה-workflow ב-n8n זהה, רק node המודל משתנה.

חיסיון עו"ד-לקוח נשמר בכך שכל פנייה נחשבת חסויה מרגע קבלתה. דוקטרינת work-product משתרעת על אובייקטי בדיקת הניגוד; זו הסיבה ש-conflict_hits נמצא בטבלת הביקורת החסויה ולא במערכת לוגינג גנרית.

לצד ה-SEO והתוכן של בניית סמכות סביב היכולות האלה, ראו את שירותי ה-SEO שלנו.

תוצאות מפריסה אופיינית

משרד כללי בן 22 עו"ד במערב התיכון של ארה"ב פרס את ה-pipeline הזה בתחילת 2026. המספרים למטה הם מ-90 הימים הראשונים אחרי ה-go-live מול 90 הימים שלפני.

לוח זמנים להטמעה

פרויקט אופייני נמשך ארבעה שבועות מ-kickoff עד go-live. ה-discovery עמוס בכוונה בהתחלה; ה-audit של Clio API תופס חצי מהבעיות שהיו צפות אחרת בשבוע 4.

• שבוע 1 — Discovery + audit ל-Clio API. מיפוי ערוצי הקליטה הקיימים, audit למאגר הלקוחות הקיים לכפילויות, ולידציה של גישה ל-Clio (או PracticePanther) API, חתימת BAA של Bedrock.
• שבוע 2 — n8n + הנדסת system prompt ל-Claude. הקמת n8n self-hosted, בניית ארבעת ה-workflows המרכזיים, איטרציה על system prompt של הסיווג מול 200 התיקים הסגורים האחרונים של המשרד.
• שבוע 3 — בדיקת ניגוד + ניתוב תיקים. Mirror של נתוני Clio ל-Postgres, בניית שאילתות pg_trgm, כיול ספי הדמיון מול test cases של ניגודים מוכרים, הגדרת טבלת הקצאת עו"ד.
• שבוע 4 — Audit log + go-live. פריסת טבלת audit עם snapshots של WORM, הליכה על ABA Rule 1.6 עם ה-COO או היועץ המשפטי של המשרד, soft-launch על תחום אחד, הרחבה לכל המשרד עד סוף השבוע.

שאלות נפוצות