ההבדל בין מערכת ללקוח אחד לבין מוצר SaaS לא נמצא במסכים — אותם מסכים יכולים לשרת את שניהם. ההבדל נמצא במה שמתחת: מי רואה מה, מי משלם על מה, ומה קורה כשהתשלום לא עובר. מסמך ההיקף הזה עובר על ההגדרות שצריך לסגור לפני שמתחילים לפתח, בסדר שבו הן תלויות זו בזו. הוא לא מדריך קוד ולא מדריך מחירים — הוא רשימת ההחלטות שבלעדיהן הצעת פיתוח ל-SaaS מתמחרת מוצר אחר מזה שתצטרכו.
לקוח, משתמש ומנוי — שלוש ישויות, לא אחת
הטעות הנפוצה ביותר בהגדרה ראשונה של SaaS היא לחשוב על "המשתמש" כעל מי שנרשם, משתמש ומשלם. במוצר שנמכר לעסקים אלה שלוש ישויות נפרדות, ולכל אחת מחזור חיים משלה:
| ישות | מה היא | מה שייך לה | דוגמה |
|---|---|---|---|
| לקוח (חשבון / Tenant) | הגוף שרוכש את השירות ושהנתונים שייכים לו | הנתונים, ההגדרות, המסלול, אמצעי התשלום, החשבוניות | משרד רואי חשבון עם 12 עובדים |
| משתמש | אדם שמתחבר ופועל בתוך לקוח, עם תפקיד | זהות, תפקיד, העדפות, היסטוריית פעולות | רואת חשבון במשרד; מנהל המשרד; מתמחה עם הרשאת צפייה |
| מנוי | ההסכם המסחרי בין הלקוח למוצר, בזמן נתון | מסלול, מחזור חיוב, מצב (ניסיון, פעיל, בפיגור…), תאריכי התחלה וסיום | מסלול "משרד", חיוב שנתי, פעיל עד 31.12 |
יכולות ליבה: הזדהות, הפרדת לקוחות, הרשאות וחיוב
ארבע היכולות הבאות הן מה שהופך אוסף מסכים למוצר שאפשר למכור לכמה לקוחות. כל אחת היא החלטה שצריכה תשובה בכתב לפני הפיתוח, כי כולן נמצאות בבסיס המערכת ולא בשכבה שאפשר להחליף:
| יכולת | ההחלטות שצריך לקבל | מה קורה אם דוחים את ההחלטה |
|---|---|---|
| הזדהות | סיסמה, קוד חד-פעמי, התחברות דרך Google/Microsoft, או הזדהות ארגונית (SSO) של הלקוח? אימות דו-שלבי חובה למי? איך מזמינים משתמש ללקוח? | לקוח עסקי גדול ראשון ידרוש SSO; הוספה בדיעבד נוגעת בכל מסך כניסה ובמודל המשתמש |
| הפרדת לקוחות | כל הלקוחות במסד נתונים אחד עם מזהה לקוח בכל רשומה, או מסד נפרד לכל לקוח? איך מוודאים שכל שאילתה מסוננת? מה עם קבצים, חיפוש ודוחות? | זו ההחלטה היחידה שאי אפשר לתקן בלי לבנות מחדש; דליפה בין לקוחות היא סוף המוצר |
| הרשאות | אילו תפקידים יש בתוך לקוח (בעלים, מנהל, משתמש, צופה)? מי יוצר תפקידים — אתם או הלקוח? יש הרשאות ברמת רשומה? מי אצלכם רואה נתוני לקוח לצורכי תמיכה, ואיך זה נרשם? | בלי מודל הרשאות, כל בקשה של לקוח ל"שהמתמחה לא יראה את השכר" היא פיתוח חדש |
| מסלולים וחיוב | אילו מסלולים, מה כל אחד מתיר (משתמשים, רשומות, יכולות)? חיוב חודשי, שנתי, לפי משתמש או לפי שימוש? דרך ספק סליקה או בחשבונית ידנית? מי מפיק חשבונית מס? | מסלול שלא נאכף בקוד הוא מסלול שלא קיים; חיוב ידני לא גדל מעבר לכמה עשרות לקוחות |
ליכולות האלה מתווספת תמיכה — לא כפיצ'ר אלא כתהליך: איך לקוח מדווח על בעיה, מי אצלכם רואה מה כדי לטפל בה, ואיך מתעדים כניסה לנתוני לקוח. במוצר שנמכר לעסקים, לקוח ישאל על זה לפני החתימה.
שדרוג, ביטול וכשל תשלום: מחזור המנוי כטבלת מצבים
רוב הלוגיקה של SaaS לא נמצאת במצב "פעיל" — היא נמצאת במעברים. הטבלה הבאה היא תרשים מצבים מקורי שנכתב למסמך הזה: לכל מצב, מה המשתמשים רואים, מה המערכת עושה, ולאן אפשר לעבור. היא נקודת פתיחה — המוצר שלכם יוסיף או יוריד מצבים — אבל כל שורה בה חייבת תשובה לפני הפיתוח.
| מצב | איך מגיעים אליו | מה המשתמשים רואים | מה המערכת עושה | לאן עוברים |
|---|---|---|---|---|
| ניסיון | לקוח חדש נרשם | המוצר המלא או מסלול מוגבל, עם ימים שנותרו | מתזמנת תזכורות; חוסמת יכולות מחוץ למסלול | פעיל (הוזן אמצעי תשלום) · פג תוקף (לא הוזן) |
| פעיל | תשלום ראשון הצליח, או חידוש הצליח | המוצר לפי המסלול | מחייבת במחזור; אוכפת מגבלות מסלול; מפיקה חשבונית | שינוי מסלול · ביטול מתוזמן · בפיגור (חיוב נכשל) |
| שינוי מסלול (שדרוג / הורדה) | הלקוח בחר מסלול אחר | שדרוג: היכולות מיד. הורדה: היכולות עד סוף התקופה, ואזהרה אם חורגים מהמגבלה החדשה | מחשבת חיוב יחסי או דוחה לחידוש; בודקת שהנתונים הקיימים נכנסים במסלול החדש (למשל 15 משתמשים במסלול של 10) | פעיל (במסלול החדש) |
| בפיגור (כשל תשלום) | חיוב מחזורי נכשל | הודעה בתוך המוצר; המוצר ממשיך לעבוד בתקופת חסד | מנסה שוב לפי מדיניות (למשל 3 ניסיונות בשבועיים); שולחת הודעות; מתעדת כל ניסיון | פעיל (חיוב הצליח) · מושהה (כל הניסיונות נכשלו) |
| מושהה | תקופת החסד הסתיימה בלי תשלום | כניסה למסך תשלום בלבד; הנתונים לא נמחקים ולא נגישים | חוסמת גישה; שומרת נתונים לתקופה מוגדרת; מתריעה לפני מחיקה | פעיל (שולם) · מבוטל (עברה תקופת השמירה) |
| ביטול מתוזמן | הלקוח ביקש לבטל | המוצר עובד עד סוף התקופה ששולמה; אפשרות לבטל את הביטול; ייצוא נתונים זמין | מפסיקה חיוב עתידי; שומרת את תאריך הסיום; מציעה ייצוא | פעיל (ביטול בוטל) · מבוטל (הגיע תאריך הסיום) |
| מבוטל | תאריך סיום הגיע, או תקופת שמירה אחרי השהיה נגמרה | אין גישה; הודעה על מחיקת נתונים ומועדה | מוחקת או מאנונימת נתונים לפי המדיניות וההסכם; שומרת רשומות חיוב כנדרש בחוק | ניסיון / פעיל (הלקוח חזר — לקוח חדש או שחזור?) |
לכל מעבר בטבלה יש בדיקה שחייבת לעבור לפני השקה: שדרוג באמצע תקופה מחייב נכון; הורדה עם נתונים מעל המגבלה לא מוחקת כלום בלי אישור; תשלום שנכשל לא חוסם מיד; ביטול לא מוחק מיד; ולקוח מושהה שמשלם חוזר לכל הנתונים שלו. אלה תרחישי הקבלה של SaaS — לא רק "המסך נפתח".
מה נכלל בגרסה מסחרית ראשונה?
גרסה ראשונה של SaaS מתמודדת עם לחץ כפול: היא צריכה להיות קטנה כדי לצאת, אבל כמה דברים בה לא ניתנים לדחייה כי הם יושבים בבסיס. החלוקה הבאה מפרידה בין מה שחייב להיות בנוי נכון מהתחלה, מה שיכול להיות ידני בהתחלה, ומה שאפשר לדחות:
| חייב להיות בנוי נכון מהתחלה | יכול להיות ידני בהתחלה | אפשר לדחות |
|---|---|---|
| הפרדת לקוחות בכל שכבה — נתונים, קבצים, חיפוש, דוחות | יצירת לקוח חדש (אתם מקימים אותו במקום הרשמה עצמית) | מסלולים מרובים — מתחילים במסלול אחד או שניים |
| מודל לקוח–משתמש–מנוי, גם אם המסכים לניהולו פשוטים | חיוב — חשבונית ידנית לעשרות הלקוחות הראשונים, כל עוד מצב המנוי נרשם במערכת | ניהול תפקידים עצמאי על ידי הלקוח — בהתחלה שניים-שלושה תפקידים קבועים |
| הזדהות מאובטחת והזמנת משתמשים ללקוח | שינוי מסלול — מבוצע על ידכם לפי בקשה, לא בלחיצת כפתור | SSO ארגוני — עד שלקוח משלם דורש אותו |
| רישום פעולות (מי עשה מה, מתי) — לפחות על פעולות מסחריות ומחיקות | תמיכה — תיבת מייל ואדם, לא מערכת כרטיסים | אוטומציה מלאה של כשל תשלום — כל עוד יש תהליך ידני מתועד |
| גיבוי ושחזור שנבדקו בפועל | דוחות ללקוח — ייצוא לקובץ לפני לוח בקרה | API ללקוחות, אינטגרציות, מרקטפלייס |
איך מתעדפים את שאר התכולה — מסכי המוצר עצמם — בגרסה ראשונה, במדריך נפרד להיקף של MVP. ההיגיון שם חל גם כאן, בתוספת העמודה הראשונה בטבלה למעלה, שב-SaaS אינה ניתנת למשא ומתן. איך מגדירים היקף ל-MVP
תנאי מסירה ותפעול: גיבוי, תמיכה, ניטור ועלויות שימוש
מוצר SaaS לא נמסר — הוא מופעל. ביום ההשקה מתחילה התחייבות מתמשכת מול לקוחות משלמים, ולכן "מסירה" של SaaS כוללת גם את מה שמאפשר להפעיל אותו. אלה התנאים שצריכים להיות מוגדרים ובנויים לפני הלקוח המשלם הראשון:
- גיבוי ושחזור: באיזו תדירות מגבים, לכמה זמן שומרים, והאם שחזור של לקוח אחד (לא כל המערכת) נבדק בפועל. לקוח עסקי ישאל "מה קורה אם מחקנו בטעות" — צריכה להיות תשובה שהודגמה.
- ניטור והתראות: מי יודע שהמערכת נפלה לפני שהלקוח מתקשר, ומה הוא עושה. גם זמינות וגם שגיאות עסקיות — חיובים שנכשלו, הודעות שלא נשלחו.
- תמיכה: ערוץ, שעות, זמן תגובה שאתם מוכנים לכתוב בהסכם, ומה מותר לאיש התמיכה לראות ולעשות בתוך נתוני לקוח — ואיך זה נרשם.
- עדכוני גרסה: איך גרסה חדשה עולה בלי להפיל לקוחות באמצע עבודה, ואיך מודיעים על שינוי שמשפיע עליהם.
- עלויות שימוש: אחסון ומסד נתונים שגדלים עם הנתונים, ספק סליקה שגובה אחוז מכל עסקה, שירותי מייל/SMS לפי כמות, ושירותי צד שלישי לפי קריאות. המבנה ידוע מראש; הערכים תלויים בהנחות על מספר הלקוחות והשימוש, ולכן לא מופיעים כאן.
מה עולה להחזיק מוצר חי לאורך זמן — תחזוקה, עדכונים, תשתית — ואיך בונים לזה תקציב, במדריך נפרד על עלויות תחזוקה. כמה עולה לתחזק מוצר אחרי ההשקה
דוגמה מסומנת: מוצר לניהול חניונים
מה אנחנו עושים בשלב הזה
כשמערכת צריכה לשרת כמה לקוחות נפרדים, אנחנו מתחילים במיפוי של בדיוק חמש ההגדרות שבמסמך הזה — לקוח/משתמש/מנוי, הפרדה, הרשאות, מסלולים וחיוב, תנאי תפעול — לפני שמדברים על מסכים. התוצר הוא מסמך היקף שמפריד בין מה שנבנה נכון מהתחלה, מה שידני בהתחלה ומה שנדחה. מה משתנה במערכת כשהיא משרתת כמה לקוחות, ואיך זה נכנס לשירות פיתוח התוכנה שלנו — במקטע הייעודי בעמוד השירות. פיתוח תוכנה — כשהמערכת משרתת כמה לקוחות
ואם המוצר עדיין לפני הלקוח המשלם הראשון, הגרסה הראשונה שלו היא MVP — עם העמודה הראשונה מהטבלה למעלה בפנים. כך אנחנו מגדירים ובונים גרסה ראשונה. פיתוח MVP — איך מגדירים ובונים גרסה ראשונה