workflow ב-HubSpot שווה בדיוק כמו הכלל שמחליט מי נכנס אליו. enrollment triggers הם התנאים שמושכים רשומה לתוך workflow - והדיוק שלהם הוא מה שמפריד בין אוטומציה שעוזרת לצוות שלכם לבין אוטומציה ששולחת אימייל לאנשים הלא נכונים או בשקט לא עושה כלום. רוב בעיות ה-workflow לא נמצאות בפעולות; הן נמצאות ב-trigger שרחב מדי, צר מדי, או מבוסס על הפרופרטי הלא נכון. הנה המבט המקצועי על הגדרת enrollment triggers כך שהרשומות הנכונות יזרמו פנימה והלא נכונות יישארו בחוץ.
מה זה בדיוק enrollment trigger?
זה אוסף התנאים שרשומה צריכה לעמוד בהם כדי להיכנס ל-workflow - השער שמחליט מי מקבל את האוטומציה ומי לא. כל workflow צריך אחד (אלא אם אתם מכניסים רשומות ידנית). trigger יכול להתבסס על ערך של פרופרטי ("Lifecycle stage הוא Lead"), על שליחת טופס, על חברות בליסט, על צפייה בדף, או על שילוב. הדיוק של התנאי הזה קובע הכל במורד הזרם: רחב מדי ואתם מכניסים אנשים שלא צריכים לקבל את האימיילים או הפעולות; צר מדי וה-workflow יושב בטל בזמן שהרשומות שרציתם חומקות לכם. דוגמה מהשטח: workflow של טיפוח שמופעל על ידי "Email ידוע" מכניס כמעט את כולם - רחב הרבה יותר מדי. כשהוא מופעל על ידי "Lifecycle stage הוא Lead וגם שליחת טופס היא בקשת הדגמה", הוא מכניס בדיוק את האנשים שה-workflow נבנה עבורם.
איך בוחרים את תנאי ה-trigger הנכונים?
תתחילו ממי שאתם באמת רוצים ב-workflow, ואז תכתבו את התנאים הצרים ביותר שלוכדים בדיוק אותם. המשמעת היא להגדיר קודם את קהל המטרה במילים פשוטות - "לידים חדשים שביקשו הדגמה ועדיין לא לקוחות" - ואז לתרגם את זה לתנאים, כולל ההחרגות. ההחרגות חשובות בדיוק כמו ההכללות: trigger שמוסיף "וגם Lifecycle stage אינו Customer" מונע מכם לשלוח אימיילים של גישוש לאנשים שכבר קנו. תשלבו תנאים עם AND/OR בזהירות, כי הלוגיקה היא המקום שבו טעויות מתחבאות. דוגמה מהשטח: workflow של חידוש קשר שמיועד לאנשי קשר קרים צריך להיות מופעל על "תאריך מעורבות אחרון הוא לפני יותר מ-90 יום וגם Marketing contact הוא אמת וגם לא הוסר מרשימת התפוצה" - כל סעיף שומר רשומה לא נכונה בחוץ, והשמטה של ולו אחד מהם שולחת דואר למישהו שלא צריך לקבל אותו.
מה לגבי re-enrollment - האם רשומות צריכות להיכנס יותר מפעם אחת?
תחליטו בכוונה אם רשומה יכולה להיכנס מחדש, כי ברירת המחדל והכוונה שלכם לעיתים קרובות שונות. כברירת מחדל, רשומה נכנסת פעם אחת ולא תיכנס שוב גם אם היא עומדת ב-trigger מחדש. עבור חלק מה-workflows זה נכון - סדרת ברוכים-הבאים צריכה לרוץ פעם אחת. עבור אחרים, כמו תזכורת task חוזרת או התראה מבוססת-סטטוס, אתם רוצים re-enrollment כך שה-workflow יופעל בכל פעם שהתנאי מתקיים מחדש. HubSpot מאפשרת לכם להפעיל re-enrollment ולציין אילו תנאים מפעילים אותו. לטעות בזה זה באג נפוץ ושקט: workflow שאמור לחזור ולא חוזר, או כזה שאמור לרוץ פעם אחת ומסתובב בלולאה. דוגמה מהשטח: workflow של "הקצה task כש-deal נתקע" צריך re-enrollment פעיל, כך שיופעל שוב בפעם הבאה ש-deal משתתק - בלעדיו, הוא רץ רק פעם אחת לכל deal ומפסיק להיות שימושי.
איך שומרים על דיוק ה-triggers לאורך זמן?
תבדקו לפני שאתם מפעילים, תסקרו את מספרי ההכנסה אחרי, ותחזרו אל ה-triggers כשמודל הדאטה שלכם משתנה. לפני ההפעלה, תבדקו את ה-trigger מול הדאטה הנוכחית שלכם - HubSpot מראה כמה רשומות עומדות כרגע בתנאים, וזה תופס trigger שבטעות מכניס אלפים או אף אחד. אחרי שהוא חי, תעקבו אחרי מספרי ההכנסה למשך זמן; קפיצה פתאומית או קו שטוח בדרך כלל אומרים שה-trigger לא בסדר. ותחזרו אל ה-triggers בכל פעם שאתם משנים שם פרופרטי, משנים הגדרה של lifecycle, או מבנים מחדש דאטה, כי trigger שמצביע על פרופרטי שמשמעותו השתנתה יכניס בשקט את הרשומות הלא נכונות. זה בדיוק הסדר שאנחנו עוקבים אחריו עם לקוחות: להגדיר את הקהל, לכתוב תנאים צרים עם החרגות, לקבוע re-enrollment בכוונה, ואז לבדוק ולנטר.
נקודת המבט של IV-Lead
רוב האוטומציה השבורה ב-HubSpot מתחקה בחזרה אל ה-enrollment trigger, לא אל הפעולות - תנאי שרחב מדי, חסר החרגה, או טועה לגבי re-enrollment. הפתרון הוא תמיד אותה משמעת: לקרוא בשם קודם לקהל המדויק, לתרגם אותו לתנאים הצרים ביותר כולל מה להשאיר בחוץ, להחליט על re-enrollment בכוונה, ולבדוק מול דאטה אמיתית לפני שעולים לאוויר. trigger מדויק הוא ההבדל בין אוטומציה שהצוות שלכם סומך עליה לבין אוטומציה שבשקט שולחת דואר לאנשים הלא נכונים - והאמון הוא כל הפואנטה של לעבור לאוטומציה מלכתחילה.
חוששים שה-workflows שלכם מכניסים את הרשומות הלא נכונות? תקבעו אודיט פורטל של 30 דקות - נסקור את ה-triggers שלכם ונראה לכם איפה האוטומציה דולפת. לתמונה הרחבה, ראו איך אנחנו בונים אוטומציה שאפשר לסמוך עליה דרך הטמעה ואופטימיזציה של HubSpot.
שאלות נפוצות
מה ההבדל בין enrollment trigger לבין פעולת workflow?
ה-trigger מחליט מי נכנס ל-workflow; הפעולות הן מה שקורה להם ברגע שהם בפנים. רוב בעיות ה-workflow חיות ב-trigger - רשומה שלא צריכה להיות שם, או כזו שחסרה - אז כדאי לדייק את ה-trigger לפני שמכווננים פעולות.
למה ה-workflow שלי לא מכניס אף אחד?
בדרך כלל תנאי ה-trigger צרים מדי או מפנים לפרופרטי שערכו השתנה, כך שאף רשומה באמת לא עומדת בהם. תבדקו את מספר ההכנסה החי ש-HubSpot מראה כשאתם מגדירים את ה-trigger - אם הוא אפס, התנאים לא תואמים לדאטה האמיתית שלכם.
מתי כדאי להפעיל re-enrollment?
תפעילו אותו כשרשומה צריכה לעבור את ה-workflow בכל פעם שהיא עומדת בתנאי מחדש - כמו תזכורות חוזרות או התראות על שינוי סטטוס. תשאירו אותו כבוי לסדרות חד-פעמיות כמו ברוכים-הבאים, שבהן אתם לא רוצים שאותה רשומה תרוץ פעמיים.
אפשר להחריג רשומות מ-workflow?
כן, ובדרך כלל כדאי - תוסיפו תנאים כמו "Lifecycle stage אינו Customer" או "לא הוסר מרשימת התפוצה" ל-trigger שלכם. החרגות חשובות בדיוק כמו הכללות, כי הן מונעות מהאוטומציה להגיע לאנשים שלא צריכים לקבל אותה.