שימור מנויים + ציות רגולטורי
אמזון שילמה 2.5 מיליארד דולר עבור תהליך ביטול שדרש 6 קליקים. אובר ניצבת מול 21 תובעים כלליים של מדינות בגין 23 מסכים לביטול. ה-FTC מחדשת את חקיקת הכללים בנושא ברירת מחדל שלילית. בינתיים, צוות השימור שלכם ממטב את שיעור ההצלה מבלי לדעת אילו משתמשים הוא דוחף החוצה מהדלת.
אנו בונים מערכות שימור מנויים שיודעות להבחין בין משתמש בר-שכנוע (Persuadable) לבין כלב ישן (Sleeping Dog), מנתבות כל אחד אל החוויה הנכונה, ומפיקות תיעוד ציות ברמת ביקורת עבור כל תחום שיפוט שבו אתם פועלים.
2.5 מיליארד דולר
פשרת התבנית האפלה של אמזון
FTC, ספטמבר 2025
75%
מנטישת לקוחות SaaS היא וולונטרית
דוח נטישה של Recurly, 2025
21 מדינות
הצטרפו לתביעת ה-FTC נגד מנויי אובר
תלונה מתוקנת של ה-FTC, דצמבר 2025
כל חברת מנויים עוקבת אחר "שיעור הצלה". האחוז מהמשתמשים שמתחילים את תהליך הביטול ואינם משלימים אותו. שיעור הצלה של 30% נשמע כמו ניצחון. אבל שיעור הצלה הוא מדד יוקרה שמערבב יחד ארבעה דפוסי התנהגות שונים לחלוטין של משתמשים.
יבטלו אלא אם יקבלו את ההתערבות הנכונה. הדרכה רלוונטית על תכונה או התאמת תוכנית משנה את דעתם. אלה המשתמשים היחידים שבהם תהליך הצלה יוצר ערך אמיתי.
יישארו ללא קשר. הם לחצו על ביטול כדי לבחון אפשרויות או בטעות. מתן הנחה של 20% מבזבז רווחיות על משתמש שמעולם לא התכוון לעזוב. שיעור ההצלה שלכם סופר אותם כ"מוצלים".
יבטלו לא משנה מה תציעו. הם כבר קיבלו את ההחלטה. תהליך הצלה בן 4 עמודים רק מכעיס אותם, מייצר פניות תמיכה, ויוצר את אותה חוויה "מבוכית" שמשכה את תשומת ליבו של ה-FTC לאמזון.
מחדשים כרגע והיו ממשיכים לחדש. אבל תהליך ההצלה שלכם פונה אליהם במייל "נשמח אם תישארו" או בהצעת הנחה, ועכשיו הם נזכרים שהם משלמים 49$ לחודש עבור משהו שלא השתמשו בו שלושה חודשים. מערכת השימור שלכם בדיוק יצרה נטישה שלא הייתה קיימת אחרת.
חברת SaaS מסוג B2B עם 200 אלף מנויים ונטישה וולונטרית חודשית של 3% מונה כ-6,000 משתמשים בעלי כוונת ביטול בחודש. מחקרים בתעשייה מצביעים על כך שכ-10-20% מהם הם כלבים ישנים, משתמשים שהיו ממשיכים לשלם אילו הושארו לנפשם.
אם תהליך ההצלה שלכם פונה לכל 6,000 המשתמשים (וזה בדיוק מה שעושים ProsperStack, Chargebee Retention וכל כלי מדף), אתם דוחפים 600-1,200 משתמשים בחודש לעבר ביטול שלא התכוונו לבצע. ב-ARPU של 50$, זהו 360 אלף-720 אלף דולר בהכנסות שנתיות שנהרסות בידי מערכת השימור שלכם עצמה.
Telenor, חברת התקשורת הנורווגית, גילתה זאת בדרך הקשה. קמפייני השימור שלהם גרמו לנטישה גבוהה ב-2% בקבוצת הטיפול. הם גילו זאת רק משום שהריצו מבחן holdout כראוי. רוב חברות ה-SaaS לעולם אינן עושות זאת.
כלל ה-Click-to-Cancel של ה-FTC בוטל ביולי 2025, אך האכיפה האיצה, לא האטה. ROSCA, סעיף 5 לחוק ה-FTC, וחוקי החידוש האוטומטי של המדינות מספקים את כל הסמכות שהרגולטורים צריכים. ה-FTC חידש את חקיקת הכללים בנושא ברירת מחדל שלילית בינואר 2026 באמצעות ANPRM (הערות עד אפריל 2026). האכיפה ברמת המדינה מתרחבת באמצעות קואליציות כמו כוח המשימה לחידוש אוטומטי של קליפורניה (CART).
| חברה | שנה | קנס | מה הם עשו | בסיס משפטי |
|---|---|---|---|---|
| Amazon Prime | ספטמבר 2025 | 2.5 מיליארד דולר | "תהליך איליאד": תהליך ביטול בן 4 עמודים, 6 קליקים, 15 אפשרויות. 35 מיליון צרכנים נרשמו ללא הסכמה ברורה. | ROSCA + סעיף 5 לחוק ה-FTC |
| Epic Games | דצמבר 2023 | 245 מיליון דולר | רכישות בלחיצת כפתור אחת ללא אישור. נעילת חשבונות כאשר משתמשים הגישו ביטולי חיוב. | סעיף 5 לחוק ה-FTC + ROSCA |
| Vonage | נובמבר 2022 | 100 מיליון דולר | מנגנון ביטול נסתר. המשך חיוב לאחר שמשתמשים ביקשו ביטול. | ROSCA + חוק ה-FTC |
| Uber | 2025 (מתמשך) | טרם נקבע | Uber One: עד 23 מסכים ו-32 פעולות לביטול. רישום אוטומטי של משתמשים לפני תום הניסיון החינמי. | ROSCA + חוק ה-FTC (21 מדינות הצטרפו) |
| Chegg | ספטמבר 2025 | 7.5 מיליון דולר | נתיב ביטול מרובה קליקים ולא אינטואיטיבי. המשך חיוב לאחר השלמת הביטול. | ROSCA |
| HelloFresh | אוגוסט 2025 | 7.5 מיליון דולר | כשל בגילוי תנאי המנוי. היעדר מנגנון ביטול קל לצרכני קליפורניה. | ARL של קליפורניה |
| JustAnswer | ינואר 2026 | טרם נקבע | צ'אטבוט בינה מלאכותית בשם "Pearl" שימש לנעילת צרכנים בחיובים חוזרים. פעולת האכיפה הגדולה הראשונה נגד סוכן בינה מלאכותית. | חוק ה-FTC (נוהגים מטעים) |
ROSCA אינו דורש הוכחה של תבנית אפלה ספציפית. ה-FTC צריך רק להראות שהביטול היה "לא פשוט". זהו רף משפטי נמוך יותר ממה שרוב החברות מבינות. אם תהליך הביטול שלכם כולל יותר שלבים מתהליך ההרשמה שלכם, יש לכם חשיפה. אם סוכן הבינה המלאכותית שלכם מוסיף חיכוך שיחתי לפני שהוא מאפשר ביטול, יש לכם חשיפה.
כלל ה-"One Save" של קליפורניה מגביל הצעות שימור לאחת לכל ביטול. ניו יורק דורשת ביטול מקוון בלבד עבור הרשמות מקוונות. למרילנד יש תזמון גילוי ספציפי. קונטיקט דורשת הודעות טרום-חידוש. אם אתם משרתים לקוחות במספר מדינות, החוק המחמיר ביותר בבסיס המנויים שלכם הוא רצפת הציות שלכם.
ארבע יכולות, משולבות. כל אחת מטפלת בפער ספציפי שכלי שימור מהמדף אינם יכולים למלא.
אנו בונים מודלי uplift המתחברים לזרם האירועים של מערכת החיוב שלכם ומסווגים כל משתמש בעל כוונת ביטול לאחד מארבעה פלחים: בר-שכנוע, ודאי, אבוד, או כלב ישן.
הגישה הטכנית: אנו מעריכים את האפקט הטיפולי הממוצע המותנה (CATE) עבור כל משתמש. המודל עונה על השאלה "האם משתמש ספציפי זה יישאר בגלל ההתערבות שלנו, או ללא קשר אליה?" חיזוי נטישה רגיל אינו יכול לענות על שאלה זו. הוא חוזה מי יעזוב, לא מי יעזוב בגלל מה שאתם עושים.
השילוב מתרחש דרך ה-API הקיים של החיוב שלכם. עבור Stripe, אנו מאזינים לאירועי customer.subscription.updated ו- customer.subscription.deleted webhook. עבור Chargebee ו-Recurly, זרמי אירועים מקבילים. אין צורך בהגירת חיוב.
מדוע לא בדיקות A/B בלבד? ה-AI Autopilot של ProsperStack ו-Chargebee Retention ממטבים איזו הצעה עובדת הכי טוב בממוצע. מידול uplift מגלה לכם איזו הצעה עובדת עבור איזה משתמש. ההבדל: בדיקות A/B אינן יכולות לזהות כלבים ישנים. רק מודל סיבתי עם holdout כראוי יכול.
פלחים שונים מקבלים חוויות שונות. ברי-שכנוע רואים תזכורת ערך מותאמת אישית או התאמת תוכנית, מוגבלים להצעה אחת בהתאם לכלל ה-"One Save" של קליפורניה. אבודים וכלבים ישנים מקבלים יציאה בלחיצה אחת ללא חיכוך. ודאיים רואים סקר קצר (ללא הצעה, ללא הנחה).
אנו מעצבים תהליכים אלו כך שיעמדו ברגולציה המחמירה ביותר החלה על בסיס המנויים שלכם. תקן ROSCA ("ביטול פשוט") הוא הרצפה הפדרלית. ה-ARL של קליפורניה מוסיף את מגבלת ה-One Save ודרישות הודעת טרום-חידוש. ניו יורק מוסיפה חובות ביטול מקוון בלבד. אנו בונים ארכיטקטורת תהליך אחת המטפלת בכל תחומי השיפוט באמצעות ניתוב מבוסס מיקום-מנוי.
מדוע לא חברה גדולה יותר? Accenture ו-Deloitte בונות פלטפורמות מנויים. הן מטמיעות את Zuora או SAP Billing. הן אינן בונות מנועי פילוח סיבתי או מבקרות תהליכי ביטול לאיתור תבניות אפלות. ההתקשרויות שלהן נעות בין 500 אלף ל-5 מיליון דולר ומספקות הגירת פלטפורמה, לא אינטליגנציית שימור. אנו בונים את 20% מהמערכת שמניעים 80% מתוצאת השימור.
משולב בצינור ה-CI/CD שלכם. כל שינוי בתהליך הביטול שלכם נסרק לפני שהוא מגיע לפרודקשן. ניתוח DOM בודק דפוסים מבניים: כפתורי ביטול נסתרים, תיבות הרשמה מסומנות מראש, גודל כפתורים לא פרופורציונלי. סיווג NLP בודק טקסט לאיתור confirmshaming, דחיפות מזויפת, שאלות מתחכמות, ומסגור מטעה.
הממצאים ממופים לדרישות רגולטוריות ספציפיות. "תווית כפתור זו משתמשת בשפת confirmshaming האסורה תחת תקדים ROSCA (השוו תלונת תהליך איליאד של אמזון, פסקה 47)" הוא ממצא בר-פעולה. "לתהליך זה יש בעיות ציות אפשריות" אינו כזה. אנו מפיקים את הראשון.
פער הממשל: כרגע, צוות השיווק שלכם מבצע בדיקות A/B לשינויים בתהליך הביטול. הצוות המשפטי שלכם בודק רבעונית (אם בכלל). הפער בין שני קצבים אלו הוא המקום שבו שוכן סיכון האכיפה. תהליך איליאד של אמזון התקיים במשך שנים מכיוון שאף מערכת אוטומטית לא סימנה אותו כבעיה רגולטורית. ביקורת אוטומטית סוגרת את הפער הזה.
אם אתם מפעילים בינה מלאכותית שיחתית בתהליך השימור שלכם (או מתכננים זאת), אנו בונים את שכבת האילוצים ששומרת אותה חוקית. תביעת JustAnswer (ינואר 2026) הוכיחה שצ'אטבוטים מבוססי בינה מלאכותית ניצבים מול אותה אחריות לתבניות אפלות כמו עיצובי ממשק ידניים.
ארבעה גבולות קשיחים: תקציב אינטראקציה מרבי (2-3 תורות לפני ביטול חובה בלחיצה אחת), מסווג שפה אסורה החוסם confirmshaming ומניפולציה רגשית בזמן אמת, הפעלה מותנית-פלח (הסוכן מפעיל רק ברי-שכנוע), ותיעוד שיחה מלא עם תיוג ציות לבדיקה משפטית.
בעיית פריצת התגמול: מודל שפה גדול (LLM) שעבר כוונון עדין לשימור ילמד להשהות, להאשים, ולתמרן מכיוון שטקטיקות אלו ממקסמות את אות התגמול קצר-הטווח. ללא אילוצים מפורשים, סוכן הבינה המלאכותית שלכם ימציא מחדש באופן עצמאי כל תבנית אפלה שעליה נתבעה אמזון. אנו בונים את מעקות הבטיחות שמונעים זאת.
שלושה שלבים. הראשון מפיק ערך באופן עצמאי מהאחרים. כל שלב בונה על תשתית החיוב הקיימת שלכם.
אנו מבקרים את חוויית הביטול הקיימת שלכם מול ROSCA, ARL של קליפורניה, וכל ARL מדינתי שבו יש לכם מנויים. אתם מקבלים דוח סיכון ציות עם ממצאים ספציפיים הממופים לרגולציות ספציפיות, לא "בעיות אפשריות" מעורפלות.
במקביל, אנו מתכננים ומפעילים מבחן holdout. 10-15% מהמשתמשים בעלי כוונת ביטול מנותבים ליציאה נטולת חיכוך ללא ניסיון הצלה. זה יוצר את נתוני הנגד הדרושים לשלב 2. בלעדיהם, מדדי שיעור ההצלה שלכם אינם ניתנים למדידה. רוב החברות מעולם לא הריצו מבחן זה מכיוון שצוות השימור שלהן מתוגמל על שיעור הצלה, ו-holdout מוריד מספר זה.
באמצעות נתוני ה-holdout משלב 1, אנו מאמנים את מודל ה-uplift. קלטים: ותק מנוי, סוג תוכנית, דפוסי שימוש, היסטוריית תמיכה, ואותות כוונת ביטול. פלט: סיווג פלח לכל משתמש עם ציוני ביטחון.
לאחר מכן אנו בונים את תהליך הביטול מודע-הפלחים. זה משתלב עם פלטפורמת החיוב הקיימת שלכם (Stripe Customer Portal API, Chargebee Retention, או אירועי Recurly) באמצעות שכבת middleware המנתבת משתמשים בהתבסס על הפלח שלהם. התהליכים מעוצבים לפי תחום שיפוט לציות רגולטורי.
סריקת תבניות אפלות אוטומטית המשולבת ב-CI/CD. כל שינוי בתהליך הביטול מבוקר לפני פריסה לפרודקשן. מטריצת הרגולציה מתעדכנת כשחוקי המדינות משתנים (חוק ההוגנות הדיגיטלית של האיחוד האירופי, צפוי ב-2027, יוסיף דרישות חובה לכפתור ביטול).
מודל ה-uplift מאומן מחדש רבעונית ככל שהתנהגות המנויים שלכם משתנה. התפלגויות הפלחים משתנות ככל שהמוצר שלכם מתפתח, התמחור משתנה, או תנאי השוק משתנים. מודל שאומן על נתוני רבעון 1 עלול לסווג משתמשים שגוי עד רבעון 4. ניטור מתמשך תופס את הסחיפה הזו.
הסתייגות כנה: פילוח סיבתי דורש נפח ביטולים מספיק כדי לאמן מודלים אמינים. אם למוצר שלכם יש פחות מ-500 ביטולים וולונטריים בחודש, מודל ה-uplift לא יתכנס בדיוק שימושי. עבור מוצרים בנפח נמוך יותר, אנו מתמקדים בשלב 1 (ביקורת ציות) ובשלב 3 (ניטור), ומשתמשים בהיוריסטיקות פילוח מבוססות-כללים במקום במודלים סיבתיים. לא נמכור לכם מודל סטטיסטי שהנתונים שלכם אינם יכולים לתמוך בו.
ענו על שבע שאלות לגבי תהליך הביטול הנוכחי שלכם. קבלו ציון סיכון, אזורי חשיפה ספציפיים, וצעדים מעשיים שאתם יכולים לנקוט לפני שתתקשרו לכל אחד.
חוק החידוש האוטומטי של קליפורניה (Bus. & Prof. Code Section 17600-17606) ו-ROSCA חופפים אך אינם זהים. קליפורניה דורשת מנגנון ביטול מקוון "נגיש מיידית", הודעות טרום-חידוש 15-45 ימים לפני החיוב, ונכון ליולי 2025, מגבלת "One Save" על הצעות שימור במהלך הביטול. ROSCA דורש שהביטול יהיה "פשוט" ושהצרכנים יספקו "הסכמה מדעת מפורשת" לחיובים חוזרים.
אילוץ העיצוב המעשי: תהליך הביטול שלכם יכול להציג הצעת שימור אחת (כדי לעמוד בכלל ה-One Save של קליפורניה) אך חייב לאחר מכן לספק השלמת ביטול בפעולה אחת (כדי לעמוד בתקן הפשטות של ROSCA). אנו בונים תהליכים שבהם מסך ההצעה כולל כפתור "לא תודה, בטל עכשיו" הממוקם בבולטות שמשלים את הביטול בלחיצה אחת. הצעת השימור עצמה אסור שתשתמש בשפת confirmshaming, בטיימרי ספירה לאחור, או במסגור מטעה.
עבור פעילויות רב-מדינתיות, אנו ממפים את בסיס המנויים שלכם לפי כתובת חיוב ומיישמים את התקן המחמיר ביותר החל לכל תחום שיפוט. ה-GBL 527-a של ניו יורק דורש מנגנוני ביטול מקוון בלבד דומים, בעוד שלמרילנד ולקונטיקט יש דרישות תזמון גילוי משלהן. אנו מתחזקים מטריצת רגולציה הממפה כל מרכיב בתהליך הביטול לדרישות מדינתיות ופדרליות ספציפיות, כך שלצוות המשפטי שלכם יש תיעוד ברמת ביקורת עבור כל תחום שיפוט.
מידול uplift מעריך את האפקט הסיבתי של התערבות שימור על כל משתמש בנפרד. תקן הזהב הוא נתוני ניסוי מבוקר אקראי (RCT) שבו חלק מהמשתמשים המבטלים רואים הצעת הצלה ולאחרים מתאפשר לבטל ללא התערבות. אם מעולם לא הרצתם מבחני holdout, אנו מתחילים שם.
שלב 1 של כל התקשרות כולל תכנון ופריסה של holdout כראוי: 10-15% מהמשתמשים בעלי כוונת ביטול מנותבים ליציאה נקייה ונטולת חיכוך ללא ניסיון הצלה. זה רץ במשך 4-8 שבועות בהתאם לנפח הביטולים שלכם. ה-holdout נותן לנו את נתון הנגד שאנו צריכים כדי להבחין בין ברי-שכנוע לכלבים ישנים. בלעדיו, כל מדד שיעור הצלה שהצוות שלכם מדווח חסר משמעות מכיוון שאינכם יכולים לדעת אם המשתמש נשאר בגלל ההצעה שלכם או למרותה.
עבור חברות עם נתוני ביטול היסטוריים אך ללא holdout, אנו יכולים להשתמש בשיטות מעין-ניסיוניות כמו התאמת ציון נטייה (propensity score matching) או משתנים אינסטרומנטליים, אך אלו מפיקים אומדנים חלשים יותר. אנו שקופים לגבי מגבלה זו.
קלטי הנתונים שאנו צריכים ממערכת החיוב שלכם: תאריך תחילת המנוי, סוג התוכנית, מחזור החיוב, אירועי שימוש (כניסות, שימוש בתכונות, פניות תמיכה), חותמת זמן של תחילת הביטול, הצעת הצלה שהוצגה (אם בכלל), והתוצאה הסופית. רוב זה זמין דרך ה-API של Stripe (customer.subscription.updated אירועי webhook) או ייצואי אירועים של Chargebee.
ProsperStack הוא כלי ביטול מוצק. ה-AI Autopilot שלו ממטב איזו הצעה להציג באמצעות בדיקות A/B, והוא משתלב באופן נקי עם Stripe, Chargebee ו-Recurly. אם המטרה היחידה שלכם היא מיטוב הצעות, ProsperStack עשוי להיות מספיק.
במקום שבו הוא נכשל: ProsperStack מתייחס לכל משתמש מבטל כמועמד לשימור. הוא אינו יכול להבחין בין בר-שכנוע (יישאר עם ההצעה הנכונה) לבין כלב ישן (ינטוש מכיוון שתהליך ההצלה הזכיר לו שהוא משלם). בדיקות A/B מגלות לכם איזו הצעה עובדת הכי טוב בממוצע על פני כל המבטלים. מידול uplift מגלה לכם איזו הצעה עובדת הכי טוב עבור כל משתמש בנפרד, וחשוב מכך, אילו משתמשים לא צריכים לראות שום הצעה כלל.
ההבדל חשוב כלכלית. אם 15% מהמבטלים שלכם הם כלבים ישנים ותהליך ההצלה שלכם פונה אל כולם, אתם מייצרים נטישה שלא הייתה קורית אחרת. ב-100 אלף מנויים עם נטישה וולונטרית חודשית של 3%, זהו בערך 450 מנויים בחודש שאתם דוחפים החוצה מהדלת. ב-ARPU של 50$, זהו 270 אלף דולר בהכנסות שנתיות שנאבדות למערכת השימור שלכם עצמה.
ל-ProsperStack גם אין שכבת ביקורת ציות. הוא אינו בודק האם שפת תהליך הביטול שלכם מהווה confirmshaming תחת ROSCA, האם תזמון ההצעה שלכם עומד בכלל ה-One Save של קליפורניה, או האם הטקסט שנוצר על ידי הבינה המלאכותית שלכם חוצה את קווי ה-FTC. אנו בונים את שכבות האינטליגנציה הסיבתית והציות שיושבות מתחת לכלים כמו ProsperStack, או שאנו מחליפים את התהליך כולו כאשר הכלי הקיים אינו יכול לתמוך בניתוב מודע-פלחים.
תביעת ה-FTC מינואר 2026 נגד JustAnswer קבעה שצ'אטבוטים מבוססי בינה מלאכותית המשמשים לנעילת צרכנים במנויים ניצבים מול אותה בחינה כמו עיצוב ממשק מניפולטיבי. הסיכון אמיתי: סוכן הצלה מבוסס-LLM הממוטב לשימור יטה באופן טבעי לעבר confirmshaming, דחיפות מזויפת, ומניפולציה רגשית מכיוון שטקטיקות אלו עובדות בטווח הקצר.
אנו בונים שכבות אילוצים לסוכני שימור מבוססי בינה מלאכותית עם ארבעה גבולות קשיחים. ראשית, תקציב אינטראקציה מרבי: הסוכן מקבל N תורות (בדרך כלל 2-3) להציג אפשרויות שימור מבוססות-ערך. לאחר N, הוא חייב להציג כפתור ביטול בלחיצה אחת ללא חיכוך נוסף. שנית, מסווג שפה אסורה שאומן על שפת אכיפה של ה-FTC ועל פסיקת ROSCA והחוסם ביטויי confirmshaming, טענות מחסור מלאכותיות, ומסגור מבוסס-אשמה בזמן אמת. שלישית, הפעלה מותנית-פלח: הסוכן מפעיל רק ברי-שכנוע. אבודים מקבלים יציאה מיידית נטולת חיכוך. כלבים ישנים לעולם אינם נוצרים איתם קשר. רביעית, תיעוד שיחה מלא עם תיוג ציות. כל אינטראקציית סוכן נשמרת, מסווגת לפי רמת סיכון ציות, וזמינה לבדיקה משפטית.
זה אינו אופציונלי. פשרת אמזון כוללת דרישת מפקח עצמאי למשך 10 שנים. התלונה המתוקנת של אובר מצטטת באופן ספציפי את מספר המסכים והפעולות הנדרשים לביטול. הרגולטורים סופרים קליקים. אם סוכן הבינה המלאכותית שלכם מוסיף שלבים, הוא מוסיף אחריות.
התקשרות טיפוסית רצה בשלושה שלבים על פני 14-20 שבועות. שלב 1 (ביקורת תהליך ביטול ותכנון Holdout, 3-4 שבועות, 25 אלף-40 אלף דולר): אנו מבקרים את חוויית הביטול הקיימת שלכם מול ROSCA, ARL של קליפורניה, ודרישות מדינתיות החלות. אנו מתכננים ומפעילים מבחן holdout. התוצרים כוללים דוח סיכון ציות עם צעדי תיקון ספציפיים ומבחן holdout הרץ בפרודקשן.
שלב 2 (פילוח סיבתי ובניית תהליך, 8-12 שבועות, 75 אלף-150 אלף דולר): אנו בונים את מודל ה-uplift באמצעות נתוני holdout, משתלבים עם מערכת החיוב שלכם דרך API, ומעצבים תהליכי ביטול מודעי-פלחים. עבור Stripe, השילוב מתרחש דרך מטפלי webhook על אירועי customer.subscription.updated ו- customer.subscription.deleted . עבור Chargebee או Recurly, זרמי אירועים מקבילים. התוצרים כוללים מנוע פילוח פרוס ותהליך ביטול מעוצב מחדש.
שלב 3 (ניטור ציות, מתמשך, 8 אלף-15 אלף דולר לחודש): סריקת תבניות אפלות אוטומטית המשולבת בצינור ה-CI/CD שלכם. עדכוני מטריצת רגולציה. דוחות ציות רבעוניים.
סך ההשקעה בשנה הראשונה עבור חברת SaaS בשוק הביניים (100 אלף-500 אלף מנויים): 150 אלף-250 אלף דולר. להקשר, Chegg שילמה 7.5 מיליון דולר בתוספת 10 שנות ניטור ציות בגלל טעות בכך. HelloFresh שילמה 7.5 מיליון דולר. עלות הציות היא חלק קטן מעלות האכיפה.
אתם שומרים על הפלטפורמה הקיימת שלכם. אנו בונים מעליה, לא לצידה. עבור Stripe Billing, השילוב מתרחש דרך ה-Customer Portal API וזרמי אירועי webhook. הפורטל של Stripe כבר תומך בתהליכי ביטול עם קופוני שימור אופציונליים, אך הוא מנתב כל מבטל דרך אותה חוויה. אנו מוסיפים שכבת middleware בין אירוע תחילת הביטול לתהליך הפורטל הבודקת את פלח ה-uplift של המשתמש ומנתבת בהתאם.
עבור Chargebee, השילוב משתמש ב-Retention API שלהם (תשתית Brightback הקודמת) בתוספת webhook אירועים מותאמים אישית. Chargebee Retention מטפל בממשק תהליך הביטול באופן מקורי, ולכן אנו מגדירים ניתוב הצעות מבוסס-פלח בתוך המערכת שלהם היכן שאפשר ומרחיבים עם לוגיקה מותאמת אישית היכן שצריך.
עבור Recurly, השילוב דומה: פילוח מונע-webhook עם ניתוב תהליך ביטול מותאם אישית. החוזק של Recurly הוא נטישה לא-וולונטרית (dunning וניסיונות תשלום חוזרים), ולכן שכבת השימור הוולונטרי שאנו בונים משלימה את ה-dunning הקיים שלהם. בכל המקרים, החיוב, עיבוד התשלומים, וניהול המנויים שלכם נשארים במקומם. אנו מוסיפים את שכבת האינטליגנציה שמחליטה מה כל משתמש מבטל צריך לראות ואת שכבת הציות שמבטיחה שמה שהם רואים חוקי.
הבסיס הטכני מאחורי דף פתרון זה, זמין כמסמך לבן אינטראקטיבי.
בינה מלאכותית סיבתית לשימור מנויים, יישור RLHF עבור סוכני שימור, צינורות זיהוי תבניות אפלות, וניתוח רגולטורי של ביטול ה-Click-to-Cancel של ה-FTC.
ביקורות ציות מתחילות ב-25 אלף דולר. פעולות אכיפה מתחילות ב-7.5 מיליון דולר.
כל חודש שתהליך הביטול שלכם רץ ללא מבחן holdout וללא ביקורת ציות, אתם גם הורסים הכנסות (כלבים ישנים) וגם צוברים חשיפה רגולטורית (ROSCA, ARLs מדינתיים). החשבון לתיקון זה פשוט.