דלגו לתוכן
Cold Email

קמפיין נפח בלי לשרוף את התשתית

איך שולחים הרבה ונשארים בתיבה

ניב אלטמרק, CTO · Cold Email

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

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

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

01

למי זה מתאים, ומתי לא

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

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

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

בשוק קטן הכיוון הפוך: לצמצם, לדייק, ולהעלות את איכות הפנייה.

02

בניית הרשימה

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

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

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

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

קמפיין הוא הצומת של השלושה. לא סכום שלהם.

03

הזווית

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

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

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

04

ההצעה

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

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

מה שלא עובד בנפח: אודיט חינם, ייעוץ חינם, ופגישה. את הראשונים שניים השוק כבר מכיר ויודע שאחריהם בא פיץ'. השלישי מבקש את המשאב שהנמען הכי מגן עליו.

05

מבנה הרצף

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

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

מי שלא סירב במפורש שווה מגע נוסף בהמשך, עם זווית אחרת לגמרי.

06

העלאה ושליחה

זה החלק שמחזיק את כל השאר.

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

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

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

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

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

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

07

איפה זה נשבר

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

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

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

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

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

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

רוצים שנרים את זה אצלכם

אנחנו בונים את התשתית, מחלקים את הרשימה, מריצים ומתחזקים.

לקביעת שיחה