SaaS וצוותי מוצר
המוצר שלך יודע דברים שאף כלי שיווקי לא יכול לראות
מי סיים את ההטמעה ומי נתקע בשלב שלוש. מי הזמין עמית. מי פגע במגבלה פעמיים השבוע. מי לא פתח את הדבר שבועיים. כל אחד מאלה הוא טריגר טוב יותר מכל דבר שנגזר מפתיחת מייל, וכולם נמצאים במרחק שתי שורות קוד מלהיות כזה.
אירועים הם כל האינטגרציה
POST /v1/events עם הטוקן שלך: שם שבחרת, איש קשר, מטען, מפתח אידמפוטנטיות. זה כל החיבור. אין SDK לעדכן, אין מסך מיפוי, ואין אוצר מילים שלנו שאתה צריך לתרגם את המוצר שלך אליו.
כל אירוע נרשם ביומן הרקורד-בלבד של איש הקשר, ומשם הוא שלושה דברים בבת אחת. טריגר, כך שפאנל מתחיל כשהוא מגיע. תנאי, כך שסגמנט יכול לומר "עשה את זה בשבועיים האחרונים" או, שימושי יותר, "לא עשה". וגם מטרה, כך שרצף מסתיים ברגע שמישהו עושה את הדבר שאליו דחפו אותו.
השלישי הזה הוא מה שהופך הודעות מחזור-חיים לסבירות לקבל. התזכורת לסיים את הקמת החשבון שלך אמורה להפסיק להתקיים בשנייה שהחשבון הוקם, וברוב הכלים זה לא קורה, כי הרצף והמוצר לא מדברים זה עם זה.
- ⚡טריגר
api_event—signup.completed, תוכניתfree. - 2שליחת מיילהדבר האחד שכדאי לעשות קודם. לא סיור באחד־עשר פיצ'רים.
- 3המתן יומיים
wake_atעל הריצה. שום דבר לא נוסף לתור, שום דבר לא צריך לפרוק אם תשכתב את זה מחר. - ?תנאיהאם
project.createdהגיע? לא → הענף של העזרה. כן → היעד למטה. - 4ענף העזרההודעה אחת, שמציעה את הדבר הספציפי שהם לא עשו. ואז המתנה נוספת.
- 5יעד
project.createdמגיע. הריצה מסתיימת. בלי עוד מיילים של onboarding, אף פעם, לאדם הזה.
שמות האירועים שלךההגדרה שלך ל-activation
חמישה משפכים
מחזור החיים, בסדר שבו הוא באמת קורה
1 · הפעלה
טריגר: הרשמה. שתיים או שלוש הודעות, כל אחת על פעולה אחת, ולכל אחת יעד שמסיים את הרצף כשהפעולה מתרחשת. המשפך הכי שווה שתבנה, וזה שהכי שווה לשכתב שלוש פעמים.
2 · העצירה
טריגר: segment_enter — נרשמו, אין אירוע משמעותי במשך שבעה ימים. הודעה אחת ששואלת במקום להגיד, ואחת שמציעה דבר ספציפי. ואז להפסיק. הודעה רביעית למישהו שהתעלם משלוש היא הודעה לאף אחד.
3 · רגע ההרחבה
טריגר: אירוע שמסמן שהם מפיקים ערך — הגיעו למגבלה, הזמינו עמית שלישי, ייצאו נתונים בפעם השנייה. זה הרגע היחיד שבו הודעת שדרוג מתקבלת בברכה, וזה רגע שהמוצר שלך יכול לתאר במדויק.
4 · חידוש וגבייה חוזרת
טריגר: date_field לפני החידוש, או אירוע תשלום. הודעה, תזכורת, ואם תשלום נכשל — רצף קצר שמפסיק ברגע שהוא מצליח. צמתי יעד הם לא רשות בגבייה חוזרת; הם ההבדל בין תזכורת להטרדה.
5 · השבת לקוחות
טריגר: segment_enter — ביטלו או לא פעילים שישים יום. שתי הודעות, כנות, ואז תג ושקט. מה השתנה מאז שעזבו היא הודעה טובה יותר מהנחה.
וזה הפנימי
notify_team מודיע לבן אדם כשחשבון ששווה טיפול אנושי חוצה קו. משפך לא חייב להסתיים במייל ללקוח; לפעמים הפעולה הנכונה היא לומר למישהו אצלך להרים טלפון.

אף אחד לא נשר בכוונה. הם פשוט מפסיקים לפתוח את זה.
למה מפתח באמת עשוי לאהוב את זה
החלקים שחשובים כשאתה זה שמשלב
בלי נקודות קצה פרטיות
כל מסך אפשרי לבנייה מה-API הציבורי, כי אין סוג אחר. אם תרצה להטמיע דוח קמפיין באדמין שלך, שום דבר לא עומד בדרכך ושום דבר לא צריך להיות מפוענח בדיעבד.
מפתחות אידמפוטנטיות בכל מקום
בכל נתיב שמשנה מצב. לוגיקת הניסיון החוזר שלך, התור שלך עם לפחות-פעם-אחת והרשת הבעייתית שלך כולם הופכים לבעיה של מישהו אחר — במדויק, בעיה של אינדקס ייחודי.
סמלץ לפני שאתה משגר
POST /v1/simulate מריץ דמו של איש קשר דרך משפך ומחזיר את המסלול וכל הודעה שהוא היה שולח. שים את זה ב-CI אם בא לך: משפך הוא גרף, וגרף אפשר לבדוק.
שרת MCP
כוון סוכן אל /mcp ותן לו לכתוב ולבדוק משפכים. כלים שמסוגלים לשלוח דורשים אישור מפורש ומוגבלים במכסה, כך שפרומפט שנקרא לא נכון לא יכול להפוך לחמישים אלף מיילים.
Webhooks יוצאים
חתום, עם ניסיונות חוזרים בהשהיה מתגברת, לפחות פעם אחת. אותו אוצר מילים של אירועים שהדוחות משתמשים בו, כך שהמחסן שלך והדשבורד שלך לא יחלוקו על מה ש-"נשלח" אומר.
מחיקה שבאמת מגיעה
בקשת מחיקה מסירה את איש הקשר ואת היסטוריית ההודעות שלו כאן, ומתפשטת לכל שירות אח שהחזיק עותק. בקשה אחת, תוצאה אחת, ומשהו שאפשר להצביע עליו כששואלים.
איפה הגבול יושב
ClickSomo מחזיק רשימת תפוצה ואת מה שהרשימה הזאת עשתה. זה לא מסד הנתונים של המשתמשים שלך והוא לא מנסה להיות כזה: איש קשר לעולם לא נושא אישור התחברות, לא מתחבר, ולא הופך לחשבון. המשתמשים שלך חיים במוצר שלך; אנשי הקשר חיים כאן, והשניים מחוברים בכתובת מייל ובאירועים שאתה בוחר לשלוח.
ההפרדה הזאת מכוונת, והיא הסיבה שמודל ההסכמה עובד. אתה הבקר על הנתונים של המשתמשים שלך; אנחנו מעבדים מטעמך. עיצוב שבו כלי שיווק הופך בשקט למאגר הזהויות הוא עיצוב שאי אפשר לפרוק אחר כך, וזה בדיוק הכישלון שהזה נבנה להימנע ממנו.
הגרסה המעשית: שלח את האירועים, שלח את התכונות שאתה רוצה לפלח לפיהן, ותשאיר את כל השאר איפה שהוא. אם אתה מוצא את עצמך דוחף לכאן את כל הסכמה שלך, סביר שהסגמנט שאתה מנסה לבנות הוא בעצם שאילתה במסד הנתונים שלך שצריכה להגיע כתכונת בוליאן אחת במקום.