פתרונות / SaaS
בנה SaaS אמיתי, לא הדגמה של אחד
ריבוי דיירים מהשולחן הראשון, תוכניות ושימוש מדורג מהקופה הראשונה, תכונה שערים שהחיוב שומר על כנה. תאר את המוצר שלך - Kliv בונה סביבו את המכונות ברמה של החברה.
התיק לבנייתו
למה לבנות את זה במקום להרכיב את הערימה?
דרך ברירת המחדל לבניית SaaS היא הרכבה: ספק אישור, SDK לחיוב, מסד נתונים, שירות דוא״ל, כלי דגל תכונה - חמישה ספקים לפני השורה הראשונה של המוצר האמיתי שלך. התפרים ביניהם הופכים לבסיס הקוד שלך: מטפלי webhook מתיישבים בין חיוב לגישה, עבודות סנכרון המעתיקות משתמשים בין מערכות, ומחלקת הבאגים של 2 בצהריים שבה ספק החיוב אומר בתשלום והאפליקציה אומרת נעולה. Kliv שולחת את המארז כמערכת אחת - שכירות, חיוב, זכויות, דואר אלקטרוני, נתונים - כך שהתפרים שהיית מבלה חודשים בכתיבה אינם קיימים.
השלדה לא מובדלת; המוצר שלך לא. אף אחד לא בוחר את האפליקציה שלך עבור דף הכניסה שלה או אימייל החשבוניות שלה - למרות שהם ישאירו דף שבור. השקיעו את התיאור בדומיין שלכם, הדבר שרק אתם מכירים, ותנו לחלקים שכל שיתוף SaaS להגיע כבר מורכבים. כאשר התמחור שלך משתנה - רמה חדשה, תוספת מדודה, עסקה ארגונית - זה משפט בשיחה, לא ארכיטקטורה מחדש.
האנטומיה של המערכת
ממה בעצם מורכב SaaS
הסר את המוצר ולכל SaaS יש את אותו השלד: דיירים, מושבים, תוכניות, שערים, מונים, חשבוניות. Kliv שולחת את השלד; אתה מתאר את המוצר סביבו. הנה מה שהמערכת יודעת ביום הראשון.
ארגונים
כל לקוח הוא ארגון - המשתמשים, הנתונים והחיובים שלו בתוך קיר אחד. חברה א׳ אינה יכולה לקרוא חברה ב׳, במאגר המידע.
חברים ותפקידים
הלקוחות שלך הם חברות, לא כניסות - בעלים, מנהלים וחברים, כל אחד רואה מה התפקיד שלו מאפשר.
תוכניות ומחירים
הקטלוג: שכבות, נסיונות, ביטולי נעילה חד-פעמיים, הרחבות מדודות - דף התמחור שלך כנתונים שהמערכת אוכפת.
זכויות
הקשר בין כסף לתכונות - מה פותח המנוי של הארגון הזה, נבדק בכל מקום שזה חשוב.
מונים ושימוש
השימוש נספר כנגד הפעילות של הלקוח המחובר - גלוי לו, ניתן לחיוב על ידך.
מנויים וחשבוניות
המצב המסחרי של כל דייר - בניסיון, פעיל, עבר מועד - עם החשבוניות להוכחה.
מי רואה מה
כללים שמסד הנתונים אוכף
- שורות של דייר שייכות לדייר - קריאות חוצות ארגון אינן אפשריות במסד הנתונים, לא מסוננים באפליקציה.
- הזכאויות עוקבות אחר החיוב בזמן אמת: שדרוג פותח תכונות כעת, ביטול מצמצם אותן בלוח הזמנים.
- המונה והחשבונית הם אותה מערכת - מה שנמדד הוא החיוב, בלי שום דבר להתאים.
- תשלום שנכשל מתחיל לדרבן - ניסיונות חוזרים והודעות אימייל לשחזור - לפני ששער כלשהו נסגר על לקוח משלם.
זה החלק של SaaS שאף אחד לא בחר לבנות וכולם צריכים: זהות, שכירות, כסף והכללים המחייבים אותם. כשהיא מגיעה כמערכת אחת, התיאור שלך אמור להיות על המוצר שלך.
החלקים הקשים של SaaS, כבר נפתרו
אלה לא תוספות - הם אותם קטעי פלטפורמה, מורכבים.
ריבוי דיירים כברירת מחדל
כאשר לקוחות נרשמים לאפליקציה שלך, כל אחד מקבל את הארגון שלו. חברה א׳ לעולם לא יכולה לראות את הנתונים של חברה ב׳ - בידוד נאכף על כל שאילתה ברמת מסד הנתונים, לא בקוד האפליקציה שמישהו צריך לזכור לכתוב. נתוני המנהל שלך חיים מאחורי קיר נפרד פנימי בלבד.
צוותים ומושבים בתוך המוצר שלך
הלקוחות שלך אינם משתמשים בודדים - הם חברות. כניסה, תפקידים ושיתוף לפי ארגון הם חלק מאותה מערכת זהות, כך ש״כל אחד באותה חברה רואה את הפרויקטים של החברה שלהם״ הוא משפט, לא ספרינט.
טען באופן שבו SaaS נטען בפועל
מינויים עם נסיונות ופרופורציה הוגנת, ביטולי נעילה חד פעמיים ותמחור מבוסס שימוש עם מונים. ״תוכנית פרו ב-$20 לחודש, פלוס 2¢ לדוח שנוצר״ הוא תיאור אחד - Kliv יוצר עבורך את המוצרים, המחירים והמונים.
תכונות שעוקבות אחר הכסף
צרף תכונות לתוכניות ולדפי שער, נתונים ופונקציונליות בהן. שדרג, שדרג לאחור או בטל - הגישה מתבצעת באופן אוטומטי, ברגע שהחיוב משתנה. אין קוד זכאות, אין סנכרון לילי.
מכור גם גישה לתוכן
למאגר הקבצים המובנה יש כללי גישה משלו: פרטי, משותף לכל ארגון או מאחורי מנוי. קובצי PDF, סרטונים והורדות מובחרים פותחים את הנעילה באותן זכויות כמו שאר האפליקציה שלך.
חיוב בשירות עצמי, באפליקציה שלך
לקוחות מעדכנים כרטיסים, מחליפים תוכניות וקוראים חשבוניות בדף חיוב בתוך המוצר שלך - וכאשר תשלום נכשל, Kliv מנסה אותו מחדש ומשלחת להם אימייל עד שהוא יתאושש.
דרכים לטעון
שלוש דרכים לטעינה של SaaS
דפי תמחור מתפתחים - שכבות מתפצלות, מטרים מופיעים, עסקה ארגונית רוצה חשבונית. הקטלוג צריך לעמוד בקצב ללא ארכיטקטורה מחדש.
מנוי מדורג
29-99 דולר לחודש
הצוות שבוחר ב-Starter או Pro
שכבות תכונות המצורפות לתוכניות: Starter מקבל את הליבה, Pro פותח את הדיווח, ה-API, הצוות כולל.
- פותחים
- תכונות עוקבות אחר התוכנית - שדרוג פותח אותן מיד, שדרוג לאחור מצטמצם בלוח הזמנים, שום דבר לא משתנה ביד.
- חיוב
- חודשי או שנתי עם ניסויים ויחס יחסי הוגן; כרטיסים שנכשלו מקבלים ניסיונות חוזרים והודעות אימייל לשחזור לפני שהגישה מצטמצמת.
- החזרים
- מוגן באישור - החזר הוא החלטה, לא תאונה.
מבוסס שימוש
0.05 דולר לריצה
הלקוח שהחשבון שלו צריך לעקוב אחר ערכו
תוכנית בסיס בתוספת מד: עיבוד, הודעות, קריאות API - לא משנה מה יחידת הערך במוצר שלך.
- פותחים
- השימוש נספר כנגד הפעילות המחוברת של הלקוח, הנראית בדף החיוב שלו לפני נחיתת החשבונית.
- חיוב
- חיובים נמדדים מצטברים ומחויבים במחזור של המנוי - המונה והחשבונית מסכימים כי מדובר באותה מערכת.
- החזרים
- פריטי שורה שנויים במחלוקת נפתרים באמצעות אותו תהליך אישור.
ביטול נעילה חד פעמי
500 דולר חד פעמי
הלקוח שרוצה את התוסף, לא עוד מנוי
מודול לכל החיים, חבילת כניסה, עסקה לאימוץ מוקדם - נמכר פעם אחת, ליד המנויים.
- פותחים
- הרכישה מעניקה זכאות קבועה המתקיימת לצד כל תוכנית שהלקוח מפעיל.
- חיוב
- חיוב אחד, קבלה אחת - אותו קטלוג, אותו עמוד חיוב.
- החזרים
- אותה זרימה מגודרת לאישור.
לפני ההשקה
השבוע הראשון, לפני ההשקה
ל-SaaS יש יותר מכונות להוכיח מכל אתר חוברות - וזו בדיוק הסיבה שהשבוע הראשון חשוב.
עצב את המוצר
תאר את זה: מה המוצר עושה, מיהו לקוח, השכבות ומה כל אחד פותח. Kliv בונה את התצוגה המקדימה הראשונה עם ארגונים, תוכניות ושערים שכבר אמיתיים.
הפוך אותו לשלך
הדומיין שלך, המותג שלך, שפת המוצר שלך - ודף תמחור שנוצר מאותו קטלוג שהקופה אוכפת.
חוט את הדבר האמיתי
חבר את Stripe, קבע את המחירים האמיתיים ואת משך הניסיון, צרף תכונות לתוכניות, והזמן את הצוות שלך לתצוגת המפעיל.
נסה לשבור את זה
הירשם כלקוח מבחן. נסה לקרוא נתונים של ארגון אחר - ראה את מסד הנתונים מסרב. כשל בכרטיס, הוריד תוכנית, ראה את השערים הבאים.
אז תעשה חזרות שנה
ב-Sandbox, עם כסף מדומה וזמן מדומה, הפעל את השנה הראשונה של ה-SaaS שלך לפני ההשקה: ניסויים ממירים או יפוג, לקוח משתדרג במרץ, כרטיס נכשל ביוני ומתאושש, ביטול סוגר את התכונות הנכונות בתאריך הנכון. אתה מפרסם עסק שכבר רץ - לא תקווה שיצליח.
לבנות או לקנות
למה לא פשוט להדביק את הערימה?
| הערימה המודבקת | עם Kliv | |
|---|---|---|
| שכירות | תכונת הארגון של ספק אישור בתוספת מסנני שורות שאתה כותב וסוקר מחדש לנצח. | ארגונים שנאכפים במסד הנתונים - קריאות חוצות דיירים בלתי אפשריות, לא מסוננות. |
| גישה לחיוב ↔ | מטפלי Webhook מיישבים את ספק החיוב עם הרעיון של האפליקציה שלך מי שילם. | הזכאויות עוקבות אחר החיוב באופן מקורי - אין תפר להתאמה. |
| תמחור שימוש | שירות מדידה, שירות חיוב ועבודת פיוס ביניהם. | המונה והחשבונית הם אותה מערכת. |
| מייל מחזור חיים | עוד ספק, עוד שפת תבנית, עוד webhook. | קבלות, דרישה ותזכורות ניסיון מובנות - בתבניות שלך. |
| זמן למוצר | חודשים של מארז לפני הפיצ׳ר המובחן הראשון. | השלדה היא היום הראשון; התיאור שלך מושקע על המוצר. |
שכירות
הערימה המודבקת: תכונת הארגון של ספק אישור בתוספת מסנני שורות שאתה כותב וסוקר מחדש לנצח.
עם Kliv: ארגונים שנאכפים במסד הנתונים - קריאות חוצות דיירים בלתי אפשריות, לא מסוננות.
גישה לחיוב ↔
הערימה המודבקת: מטפלי Webhook מיישבים את ספק החיוב עם הרעיון של האפליקציה שלך מי שילם.
עם Kliv: הזכאויות עוקבות אחר החיוב באופן מקורי - אין תפר להתאמה.
תמחור שימוש
הערימה המודבקת: שירות מדידה, שירות חיוב ועבודת פיוס ביניהם.
עם Kliv: המונה והחשבונית הם אותה מערכת.
מייל מחזור חיים
הערימה המודבקת: עוד ספק, עוד שפת תבנית, עוד webhook.
עם Kliv: קבלות, דרישה ותזכורות ניסיון מובנות - בתבניות שלך.
זמן למוצר
הערימה המודבקת: חודשים של מארז לפני הפיצ׳ר המובחן הראשון.
עם Kliv: השלדה היא היום הראשון; התיאור שלך מושקע על המוצר.
שאלות נפוצות
איך בעצם נאכף בידוד דיירים?
במסד הנתונים, עם כללים ברמת השורה. כל לקוח הוא ארגון והשורות שלו נושאות את הגבול הזה - באג בדף לא יכול להדליף נתונים של דייר אחר, כי השאילתה עצמה חוזרת ריקה.
האם אני יכול לשלב מנוי עם שימוש מדורג?
כן - זו תוכנית אחת, לא שתי מערכות: שכבת Pro עם $0.05 לעיבוד למעלה. המנוי מחייב את הבסיס, המונה מחייב את השימוש, והלקוח רואה את שניהם בחשבונית אחת.
מה קורה כאשר לקוח מבטל או משדרג לאחור?
הזכויות מצטמצמות בלוח הזמנים שהפוליסה שלך קובעת - מיד או בסיום התקופה - והנתונים נשארים. לקוח חוזר אוסף את הארגון שלו במקום שבו עמד, מה שהופך את הזכייה בחזרה לאירוע חיוב, לא להעברה.
האם לקוחות יכולים לנהל את החיוב שלהם בעצמם?
כן - דף חיוב בתוך המוצר שלך: עדכון כרטיסים, החלפת תוכניות, קריאת חשבוניות. כאשר תשלום נכשל, דרישה חוזרת לבצע את החיוב ומשלחת דוא״ל ללקוח לפני שהגישה של מישהו מצמצמת.
האם אוכל לשנות את התמחור לאחר ההשקה?
כן - הקטלוג הוא נתונים. להוסיף נדבך, לפצל תוכנית, להציג מד; מחירים חדשים חלים על קופות חדשות, ומינויים קיימים שומרים על התנאים שהם קנו עד שתחליט אחרת.
האם מדובר בריבוי דירות אמיתי, או חשבונות עם דגלי תכונה?
שכירות אמיתית: כל ארגון לקוח הוא גבול ממדרגה ראשונה במסד הנתונים, עם משתמשים משלו, תפקידים ושורות משלו - אותה ארכיטקטורת ריבוי דיירים ש-Kliv עצמה פועלת עליה.