לחבר את monday.com לוואטסאפ: מה באמת צריך לבנות

הבקשה נשמעת כמו דבר אחד - "שוואטסאפ יעבוד עם monday" - והיא למעשה שני פרויקטים נפרדים עם בעיות שונות לגמרי. שווה להפריד אותם לפני שמתמחרים, כי אחד מהם פשוט והשני הוא כל העבודה.

שני הכיוונים

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

למה צריך שירות ביניים

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

הארכיטקטורה היא תמיד שלושה חלקים:

monday (webhook)
   →
שירות ביניים (מיפוי + אינדקס + תור)
   →
WhatsApp Cloud API

ובכיוון ההפוך, אותו שירות מקבל את ה-webhook של Meta וכותב חזרה ל-monday דרך ה-API.

הכיוון היוצא: תבניות, ולא טקסט חופשי

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

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

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

מה מפעיל את השליחה

ל-monday יש webhooks על שינויים בלוח. שתי הערות:

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

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

הכיוון הנכנס: כאן כל העבודה

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

הבעיה: וואטסאפ מזהה לפי מספר, monday לא

Meta שולחת את מספר הטלפון. ב-monday, המספר יושב בעמודה שמישהו מילא ידנית - 052-1234567, 0521234567, +972521234567, ולפעמים שניים באותו תא.

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

הפתרון: אינדקס משלך, לא סריקת לוחות

זו הנקודה הטכנית החשובה ביותר במאמר.

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

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

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

מה לכתוב חזרה - ומה לא

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

מה שכן שווה לכתוב ל-monday:

• סטטוס - נענה, ממתין, לא נמסר
• חותמת זמן של ההודעה האחרונה
• קישור לשיחה המלאה במקום שבו היא נשמרת

הלוח הוא ממשק העבודה של הצוות. התמליל שייך למקום שבו אפשר לחפש ולשמר אותו כראוי.

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

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

• אידמפוטנטיות בשני הכיוונים. webhooks נשלחים מחדש; אותה הודעה לא נשלחת פעמיים ואותה תשובה לא נרשמת פעמיים.
• נרמול ל-E.164 בשני הצדדים, ושמירת הצורה המנורמלת.
• תור שגיאות שאדם רואה. תשובת לקוח שלא הצליחה להגיע ללוח היא ליד אבוד.
• מה קורה כשאין התאמה. הודעה ממספר לא מוכר צריכה ליצור פריט חדש בלוח ייעודי ולסמן לטיפול - לא להיעלם, ולא ליצור פריט בלוח הלא נכון.

צ'קליסט

1. למפות את סט התבניות לפני הקוד, ולהגיש אותן לאישור מוקדם - זה לוקח זמן.
2. לבדוק על הלוח האמיתי איך webhooks מתנהגים מול אוטומציות פנימיות.
3. לבנות אינדקס מספר-לפריט; לא לסרוק לוחות.
4. לנרמל ל-E.164 בשני הצדדים.
5. לכתוב סטטוס וקישור ל-monday, לא את השיחה.
6. להחליט מה קורה עם מספר לא מוכר.
7. לאמת את ה-webhook של monday ואת זה של Meta.