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

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

Make (לשעבר Integromat) ו-Zapier הם הדבק בין שיג ושיח לכמעט כל תוכנה שניתן לציין. ברגע שמחברים אותם, המגבלה היחידה היא הדמיון.

למה יש צורך בשכבת אינטגרציה

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

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

Make ו-Zapier פותרים את זה כי הם פועלים כשכבת ביניים. הם מקבלים נתונים משיג ושיח ומנתבים אותם למאות אפליקציות אחרות. וובהוק אחד בשיג ושיח יכול להפעיל רצף שמעדכן גיליון Google, שולח הודעת Slack, יוצר איש קשר ב-HubSpot, ומוסיף שורה ל-Airtable. הכל בבת אחת.

איך החיבור עובד בפועל

ההגדרה פשוטה יותר ממה שנדמה. היא מסתכמת במנגנון ליבה אחד: וובהוק.

בשיג ושיח, לכל תהליך בוט יש שלב Action. שלב ה-Action יכול לשלוח בקשת וובהוק, GET או POST, לכתובת URL חיצונית. Make ו-Zapier שניהם נותנים כתובת URL ייחודית לוובהוק כשיוצרים תרחיש או zap חדש. מעתיקים את הכתובת, מדביקים אותה בשלב ה-Action של שיג ושיח, ופתאום הצ'אטבוט יכול לדבר עם אלפי אפליקציות.

ראשית, יש לפתוח את Make או Zapier וליצור אוטומציה חדשה. בחירת טריגר וובהוק. הפלטפורמה מייצרת כתובת URL מותאמת אישית. זו תיבת הדואר הנכנס. בכל פעם ששיג ושיח שולח נתונים לכתובת הזו, האוטומציה מופעלת.

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

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

דוגמה אמיתית

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

תהליך שיג ושיח אוסף את השם, האימייל והמטרה שלהם. בשלב ה-Action, נשלח וובהוק POST עם מטען JSON שממפה את השדות המותאמים האישיים. Make או Zapier מקבלים את המטען. האוטומציה עושה אז שלושה דברים במקביל. היא יוצרת שורה ב-Google Sheets עם פרטי הליד. היא מפרסמת הודעה לערוץ ה-Slack של הצוות. היא מוסיפה את האימייל לקהל ה-Mailchimp מתויג כליד חם.

שלושה דברים קורים תוך שניות. המשתמש אף פעם לא עוזב את הצ'אט. הצוות מקבל התראות מיידיות. ה-CRM נשאר מעודכן. וזה נעשה בלי לכתוב קוד backend.

בדיקה לפני השקה

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

בשיג ושיח, יש להשתמש בתכונת Test בשלב ה-Action כדי לשלוח וובהוק לדוגמה. חזרה ל-Make או Zapier ובדיקת היומן. האם הנתונים נראים נכון? האם שמות השדות תואמים? האם מבנה ה-JSON נקי?

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

מה קורה כשדברים משתבשים

ממשקי API נופלים. פורמטים של נתונים משתנים. וובהוקים נכשלים בזמן קצוב. הדברים האלה קורים, ויש לתכנן אותם.

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

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

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

מקרי שימוש נפוצים שבאמת מזיזים את המחט

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

רישום ב-Google Sheets פופולרי מסיבה טובה. זה חינם, קל, ונותן מסלול ביקורת נקי של כל שיחה.

התראות Slack שומרות על הצוות בעניינים. כשליד בעל ערך גבוה ממלא טופס בצ'אט, צוות המכירות יודע על זה מיד.

רצפי שיווק באימייל הם המקום שבו ה-ROI האמיתי נמצא. לכידת ההסכמה בשיג ושיח, שליחת הנתונים ל-Mailchimp, ConvertKit או ActiveCampaign, והפעלת רצף טיפוח אוטומטית.

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

בחירת משימה אחת והתחלה

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

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

ניתן למצוא את Make ב-make.com ואת Zapier ב-zapier.com. לשניהם יש רמות חינמיות, כך שאפשר להתנסות בלי להתחייב. שיג ושיח.au/blog למדריכים נוספים.

הכלים נמצאים שם. הדבר היחיד שנותר הוא לחבר אותם.

#שיג_ושיח #אוטומציה_ללא_קוד #תהליכי_צ׳אטבוט