פוסט אורח שפורסם בבלוג של n8n במסגרת Verified Node Spotlight על ידי ניקולס פריי (Nicolas Fry), מנכ"ל TurboDocx, מתאר תרחיש שבו העסקה נסגרה והחוזה מוכן, אך הוא שוכב בתיבת הדואר האלקטרוני במשך שלושה ימים וממתין לאישור שליחה, ולאחר חתימתו קובץ ה-PDF מגיע לתיקיית ההורדות במקום לכונן המשותף. לפי פריי, מערכת n8n מסוגלת לשלוף את נתוני העסקה, להפיק את המסמך, לנתב אותו לאישור ולתייק אותו, אך עד כה לא היה קיים בה רכיב מובנה (native node) לשלב החתימה עצמו. בשל כך, תהליכי עבודה אוטומטיים נעצרו בנקודה זו ודרשו טיפול ידני לסיום התהליך. המדריך מציג תהליך עבודה הסוגר פער זה באמצעות שימוש ברכיב המאומת של TurboDocx. בתהליך זה, שורה ב-Excel המסומנת בסטטוס Ready to send מומרת לחוזה מופק, מנהל מאשר את שליחתו ב-Slack, המסמך נשלח לחתימה, וכאשר הלקוח חותם – קובץ ה-PDF החתום נשמר ב-SharePoint והשורה בטבלה מתעדכנת אוטומטית.
מבנה תהליך העבודה: שליחה ותיוק
לפי המדריך, לוח העבודה (canvas) ב-n8n מחולק לשני חלקים עיקריים הפועלים בנפרד:
חלק א' (שליחה): חלק זה מופעל בכל 15 דקות. רכיב Schedule Trigger מתחיל את הריצה. לאחר מכן, רכיב Microsoft Excel קורא את טבלת החוזים ומסנן אך ורק שורות המסומנות בסטטוס Ready to send. צומת Loop Over Items מטפל בכל חוזה בנפרד. בשלב הבא, רכיב TurboDocx מפיק את ההסכם מתוך תבנית וממיר אותו לקובץ PDF. רכיב Slack שולח הודעה עם לחצני Approve & send או Reject בערוץ הייעודי וממתין לתגובה. צומת If מבצע פיצול על פי ההחלטה: חוזים מאושרים נשלחים לחתימה באמצעות TurboDocx, השורה ב-Excel מסומנת כ-Sent או Rejected, והודעת עדכון נשלחת לצוות ב-Slack.
חלק ב' (תיוק): חלק זה מופעל כאשר מישהו חותם על המסמך. טריגר TurboDocx Trigger מופעל בעקבות אירוע החתימה ומוריד את קובץ ה-PDF החתום. רכיב Microsoft SharePoint מעלה את הקובץ ישירות לתיקיית החוזים בארגון, השורה ב-Excel מסומנת כ-Signed, ו-Slack מפרסם הודעת עדכון לצוות על השלמת החתימה.
פריי מפרט את חלוקת התפקידים בין המערכות: n8n מנהלת את התזמון, הלולאה, הפיצול והעברת הנתונים בין Excel, Slack ו-SharePoint. מנגד, TurboDocx מטפלת בשני השלבים ש-n8n אינה מבצעת באופן מובנה: הפיכת תבנית Word לחוזה מוגמר, ואיסוף חתימה אלקטרונית בעלת תוקף משפטי.
דרישות מקדימות להקמת התהליך
כדי להקים את תהליך העבודה, המדריך מציין מספר דרישות מקדימות:
- מופע של n8n: מופע ענן (Cloud) או התקנה עצמאית (self-hosted).
- הרכיב של TurboDocx: התקנה ישירה מלוח הרכיבים (Node panel) בתוך n8n או באמצעות ייבוא תבנית התהליך.
- חשבון ב-TurboDocx: המסלול החינמי כולל הפקה של 5 מסמכים ואיסוף של 5 חתימות בחודש, כמות המספיקה לבנייה ולבדיקה. בנוסף, מוזכר המוצר TurboQuote, כלי CPQ של החברה המשלב תמחור והצעות מחיר באותו מנוע מסמכים וחתימות.
- חשבון Microsoft 365 הכולל Excel ו-SharePoint, עם הרשאות מוגדרות ב-n8n.
- סביבת עבודה ב-Slack עם ערוץ אישורים מוגדר, כגון contract-approvals#.
שלבי יישום התהליך ב-n8n
שלב 1: הגדרת תור החוזים ב-Excel. כל שורה בטבלה מייצגת חוזה בודד, ועמודת Status משמשת כתור המשימות. התהליך מאתר שורות בסטטוס Ready to send ומעדכן את המצב ככל שהחוזה מתקדם. יש ליצור טבלה בקובץ Excel המאוחסן ב-SharePoint או ב-OneDrive עם העמודות הבאות: Status (העובר בין Ready to send, ל-Sent או Rejected, ולבסוף Signed), פרטי הלקוח (Client Name, Company, Email), שדות Amount ו-Start Date, וכן Document ID ו-Signed At המתמלאים אוטומטית על ידי התהליך. ברכיב Microsoft Excel מגדירים פעולת Lookup לפי עמודת Status עם הערך Ready to send ומפעילים את האפשרות Return All Matches. המאמר מדגיש כי ניתן להחליף את Excel בכל מערכת אחרת שיש לה רכיב מתאים ב-n8n המסוגל לקרוא ולעדכן רשומות, כגון מערכות CRM (דוגמת Salesforce, HubSpot, Pipedrive או Zoho CRM), בסיסי נתונים וגיליונות (Google Sheets, Airtable, Postgres או n8n Data Table), או כלי ניהול משימות (monday.com או ClickUp). בשימוש במערכת CRM ניתן גם לוותר על תזמון ה-15 דקות ולהפעיל את התהליך מיד בעת מעבר עסקה לשלב Closed Won. כמו כן, ניתן להחליף את Slack ב-Microsoft Teams, ואת SharePoint ב-Google Drive, Dropbox או OneDrive.
שלב 2: הכנת תבנית החוזה. העבודה מתחילה מקובץ Word רגיל (docx.) שאושר על ידי הגורמים המשפטיים. החלקים המשתנים מוחלפים במשתני מיזוג כגון {clientName}, {amount} ו-{startDate}. בנוסף, מגדירים שני עוגנים עבור החתימה: {client_sig} לסימון מיקום החתימה של הלקוח, ו-{client_date} לסימון מיקום תאריך החתימה. לאחר מכן מעלים את הקובץ ל-TurboDocx ומעתיקים את מזהה התבנית (template ID). הסעיפים המשפטיים נותרים קבועים ורק השדות הריקים מתעדכנים.
שלב 3: הפקת החוזה. ברכיב Generate Agreement Docx ב-n8n מזינים את פרטי החיבור ומדביקים את מזהה התבנית. לאחר מכן ממפים כל משתנה לעמודה התואמת ב-Excel (למשל clientName לעמודת Client Name). הרצת בדיקה מייצרת חוזה מעוצב בהתאם לתבנית בתוך שניות בודדות.
שלב 4: אישור ב-Slack. רכיב Slack משתמש באפשרות Send and Wait for Response לפרסום פרטי החוזה בערוץ האישורים עם כפתורי Approve & send ו-Reject, וממתין לתגובה. ההודעה מוגדרת כך שתציג למאשר את שם הלקוח, שווי החוזה וקישור למסמך. צומת If מפצל את הזרימה: אישור מעביר את החוזה לחתימה, בעוד דחייה מעדכנת את השורה ב-Excel ל-Rejected ושולחת עדכון לצוות.
שלב 5: שליחה לחתימה אלקטרונית. החוזה המאושר מועבר לרכיב Send Agreement for E-Signature (TurboSign: Send Signature). פרטי השם והדוא"ל של החותם ממופים משורת ה-Excel. המערכת ממקמת את שדות החתימה והתאריך במדויק במיקומי העוגנים שהוגדרו מראש בתבנית. החותם מקבל הודעת דוא"ל ויכול לחתום מכל מכשיר, ובמקביל השורה ב-Excel מתעדכנת ל-Sent.
שלב 6: שמירת החוזה החתום ב-SharePoint. חלק ב' מתחיל ברכיב TurboDocx Trigger, שה-webhook שלו נרשם אוטומטית עם הפעלת התהליך. ברכיב Microsoft SharePoint בוחרים את האתר ואת תיקיית היעד. עם ביצוע החתימה, קובץ ה-PDF מועלה לתיקייה, השורה ב-Excel מסומנת כ-Signed, ו-Slack שולח הודעה על סיום התהליך.
בדיקה מקצה לקצה ופתרון תקלות
לפני החלת התהליך מול לקוחות, המדריך ממליץ לבצע הרצה מלאה לבדיקה עצמית: הפעלת התהליך, הוספת שורה ב-Excel עם דוא"ל אישי בסטטוס Ready to send, אישור ב-Slack, חתימה מתיבת הדואר, ובדיקה שקובץ ה-PDF הגיע ל-SharePoint והשורה סומנה כ-Signed.
בנוסף, המדריך מונה חמישה תרחישי תקלות ואת דרכי פתרונן:
- חוזים חתומים אינם מתוייקים: יש לוודא שהתהליך במצב מופעל (activated), כיוון שה-webhook של החתימה נרשם רק בעת הפעלה.
- שורות אינן נאספות מ-Excel: מסנן הסטטוס דורש התאמה מדויקת של הטקסט, ולכן יש לוודא שאין שגיאות כתיב או רווחים מיותרים בערך Ready to send.
- לא מופיעה הודעה ב-Slack: יש לוודא שאפליקציית Slack צורפה לערוץ האישורים.
- החתימה ממוקמת במיקום שגוי: יש לוודא את האיות המדויק של העוגנים בתבנית Word ({client_sig} ו-{client_date}).
- שגיאת HTTPS callback URL במופע self-hosted: טריגר החתימה מחייב כתובת HTTPS ציבורית. בעוד n8n Cloud כולל זאת כברירת מחדל, בהתקנה עצמאית יש להציב את המערכת מאחורי כתובת HTTPS (או מנהרה) ולהגדיר את משתנה הסביבה WEBHOOK_URL.
יתרונות, מגבלות וכיווני המשך
המאמר מדגיש שלושה יתרונות מרכזיים במבנה זה: הניסוח המשפטי מוגן משינויים כיוון שהסעיפים מנוהלים בתבנית המקורית; שום חוזה אינו נשלח ללא אישור אנושי ב-Slack; ואף מסמך חתום אינו אובד מכיוון שהוא נשמר בתיקיית SharePoint מרכזית.
לצד זאת, המדריך מציין כי בגרסתו הנוכחית התהליך מיועד לחותם יחיד ואינו תומך בניהול שינויים (redlines) או במשא ומתן חוזר. חוזים הדורשים תיקון צריכים לעבור עדכון בתבנית לפני סימונם מחדש כ-Ready to send.
לסיום, מוצעות מספר אפשרויות להרחבת התהליך בעתיד: הפעלה מבוססת שינוי שלב עסקה ב-CRM במקום תזמון קבוע, שילוב רכיבי בינה מלאכותית של OpenAI או Anthropic לניסוח סקירות עסקיות מתוך סיכומי שיחות לפני הפקת המסמך, ניתוב חוזים לפי שווי כספי למאשרים שונים, ושימוש באותו שלב חתימה עבור הצעות מחיר למכירות תוך הפניה לתבנית הצעות המחיר של CPQ.