המדריך המלא לפתרונות סליקה עבור חברות SaaS – חלק ב'

לאחר הפידבק המעולה שקיבל חלק א', הגיע הזמן לחלק השני והסופר-מעניין: כיצד חברות SaaS שכולנו מכירים גובות? כמיטב המסורת, גם הפעם אני מכוון למקסימום תכלס ומינימום פילוסופיה. עבור כל חברה שתופיע כאן אני מפרט את ה-setup שהקימה כל חברה (כולל טיב הסנכרון עם ה-ERP ועם סיילספורס), יתרונות וחסרונות, טיפים עבור הטמעה דומה ומה השיפורים המתוכננים אם קיימים כאלה. אני מודה מקרב לב לקולגות שחלקו עמי את המידע הזה וסבלו את השאלות החודרניות והמציקות שלי: עומר כהן (JFrog), איתן גדון (Spotinst), דיוויד ססלי ורון דוידסון (WalkMe), כפיר ליפמן (Monday.com), רותם לנדא (Yotpo) ואבי ישראל (Similar Web).

כעת, בלי פטפטת מיותרת, קבלו את מה שהגעתם בשבילו.

מדלן

ה-Setup הבסיסי

למדלן יש כרגע לקוחות משלמים רק בישראל, לכן התקשרנו עם ויזה כאל (עמלת סליקה של 0.9%) כ-Payment Processor, אותם חיברנו לגייטווי שלנו – פייפלוס (גם מספקים את הטוקניזציה). את פייפלוס חיברנו לפריוריטי, שם הלוגיקה שלנו שיושבת על מודול חוזי שירות ומודול הוראות קבע שלהם (עולים יחד בערך 600 ש"ח לחודש).

איך זה עובד מנקודת המבט של הלקוח? הלקוח מקבל חוזה לחתימה דיגיטלית (משתמשים ב-PandaDoc, אינטגרציה עם Insightly), חותם על החוזה ומשם נוצרת משימה למנהלת החשבונות לפתוח את החוזה בפריוריטי.

עם קבלת המשימה, מנהלת החשבונות פותחת בפריוריטי רשומה מסוג חוזה שירות, חודשי/רבעוני/שנתי, שכולל את המק"טים והמחיר, יחד עם תאריך תחילת מתן השירות והאם להנפיק ללקוח חשבונית עסקה או חשבונית מס (על חשבוניות עסקה לא משלמים מע"מ). היא מזינה גם את פרטי כרטיס האשראי, וכמו כל דבר בפריוריטי, מדובר בשילוב של ענן והתקנה מקומית. יש קובץ exe של פייפלוס שיושב על המחשב של כל משתמש בפריוריטי, וכשרוצים להזין פרטי כרטיס אשראי לוחצים על כפתור בפריוריטי שקורא לתוכנה המקומית של פייפלוס, מזינים פרטי כרטיס אשראי שנשמרים אצל פייפלוס (תקשורת דרך האינטרנט) ופייפלוס מחזירה טוקן שנשמר אוטומטית בשדה תחת הלקוח בפריוריטי. עדיין לא סיימנו – צריך להגדיר אצל הלקוח שאמצעי התשלום שלו הוא כרטיס אשראי. פשוט, אה? :/

ואיך הגבייה נעשית? טיפה מורכב. מדי חודש, לאחר ה-15 לחודש (כלומר לאחר תאריך החיוב האחרון שנהוג בכרטיס אשראי), אנחנו פועלים בסדר הפעולות הבא:

  1. צעד ראשון: מריצים פרוצדורה שפותחת תשלומים. תשלום זה למעשה אובייקט בן של חוזה שירות, כשלכל רשומה מסוג תשלום יש את טווח התאריכים שבגינו התשלום (למשל, 10.1.18 עד 9.2.18), סכום כולל ותכולת המק"טים. זה למעשה שלב ביניים, כי..
  2. שלב שני: מריצים תוכנית שפותחת חשבונית עסקה או חשבונית מס בגין כל תשלום שעדיין לא פתחו חשבונית בגינו.
  3. שלב שלישי: מריצים תוכנית שמחייבת את החשבוניות הפתוחות עם תאריך פירעון של עד סוף החודש הנוכחי, עבור כל הלקוחות שיש פרטי כרטיס אשראי שלהם במערכת.
  4. שלב רביעי: שולחים לכל הלקוחות את החשבוניות שהופקו בשלב השני, באמצעות מייל (אפשר לחבר את פריוריטי לתיבת מייל בארגון, למשל billing@….co.il)

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

סנכרון עם ERP

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

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

סנכרון עם סיילספורס

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

יתרונות וחסרונות

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

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

שיפורים מתוכננים

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

חברה ג'

ה-Setup הבסיסי

לחברה מיליוני דולרים MRR, כאשר 90% מהלקוחות משלמים בכרטיס אשראי – מהווים 60% מההכנסות. הגיוני, לקוחות גדולים מעדיפים העברות בנקאיות.

החברה משתמשת ב-Chargify בשילוב מעניין עם Invoiced.com בשביל לוגיקה, ובStripe US & Stripe UK בשביל טוקניזציה וגייטווי – החברה האמריקאית מחייבת לקוחות אמריקאיים והחברה הבריטית לקוחות משאר העולם, גם מישראל. כשמוכרים ללקוח ישראלי, לא שולחים ללקוח את החשבונית שהופקה כי היא לא כוללת מע"מ, אז מנפיקים אחת חדשה  ב-ERP ושולחים ללקוח.

איך זה עובד מבחינת חווית לקוח? שתי דרכים:

  • מבחינת Self-Service הלקוח רואה דף הרשמה אחד שבו הוא בוחר מסלול, מחזור חיוב חודשי או שנתי ומזין את פרטי כרטיס האשראי, כאשר החברה מאחורי הקלעים שומרת את פרטים אצל הגייטווי האמריקאי או הבריטי – יחד עם יצירת המנוי אצל Chargify. הכל באמצעות API ולא Hosted page.
  • עסקאות של 8,000 דולר ומעלה נסגרות מול נציג Inside Sales.
  • אגב, פעם היו מוכרים גם חבילות שמחייבות בהתאם לשימוש בפועל והיו מדווחים ל-Chargify על השימושים בפועל מדי יום (נקרא Metered Usage).

איך הבק אופיס תומך בזה?

במצב של Self-Service, אז Chargify מתפעלים את הכל: מנפיקים הצהרת חיוב (למה הם ולא Stripe, שגם להם יש יכולת להוציא חשבונית? כי יש להם יכולות לוגיקה עמוקות יותר, למשל במקרה של תוספות למסלול מקורי), שולחים ללקוח, מנסים לגבות באמצעות הגייטווי, שולחים תזכורות ללקוחות שלא שילמו וכו'.

במצב של מגע ידני, נציג המכירות פותח בעצמו לקוח חדש בסיילספורס עם הזדמנות, מנהל תהליך מכירה ולבסוף סוגר עסקה (יופי!). עם סגירת העסקה, נשלח מייל בצורה אוטומטית לקבוצת נמענים, אחת מהם היא אשת הבילינג. אשת הבילינג מקימה את הלקוח בצורה ידנית ב-Charfiy עם פרטי המסלול, כשסוג אמצעי התשלום בתרחיש כזה הוא העברות בנקאיות או צ'קים. מה זה אומר מבחינה מעשית? ש-Chargify עדיין תוציא ללקוח חשבונית מדי חודש/רבעון/שנה – אבל לא תנסה לגבות אותן בכרטיס אשראי (כי אין). אז כשלקוח משלם את החשבונית, צריך לסמן באופן ידני ב-Chargify שחשבונית XX שולמה כדי שלא יישלחו תזכורות בנוגע לחשבונית הזו. אם לקוח רוצה לשנות את שיטת החיוב לחיוב באמצעות כרטיס אשראי עליו ליצור קשר ואשת הבילינג משנה את סוג החיוב ב-Chargify. כמו-כן, כדי שהלקוח יקבל גישה לאזור הבילינג גם כשהוא עובד מול המוצר של החברה (בממשק האדמין), אז אשת הבילינג מזינה לתוך Chargify גם את מזהה הלקוח שלו במערכות הפנימיות כדי שיהיה קישור בין המערכות.

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

  1. בזמנו Chargify לא היו מוציאים חשבוניות, אלא Statement, והיו לקוחות שדרשו חשבונית לפני שהם משלמים. היום המצב מעט טוב יותר ויש יכולת להפיק חשבונית, אבל זה לא מושלם. משיחות עם Chargify נאמר שהם מתכננים לבצע מקצה שיפורים נרחב בנושא הזה בזמן הקרוב.
  2. אצל Invoiced יש אפשרות שיחד עם החשבונית יישלח לינק לדף תשלום עם אפשרות לזכור פרטים לחיובים הבאים, וזה כולל אפשרות לשלם ב-WIRE (הכסף נכנס ישר לחשבון הבנק) או כרטיס אשראי.

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

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

עכשיו מגיעים לנקודה כואבת בעבודה עם Chargify, והיא העובדה שהם לא יודעים לעבוד עם יותר מגייטווי אחד. החברה נתקלה בזה כשרצתה להתחיל לעבוד עם Stripe UK ורצתה שחוזים עם לקוחות בריטים ייסלקו שם. אי אפשר לעשות זאת, ולכן כל החברה הבריטית עובדת עם Invoiced כמתווך אל סטרייפ UK. האלטרנטיבה הייתה לפתוח חשבון נוסף ב-Chargify שיהיה מחובר סטרייפ UK ויטפל בלקוחות בריטים, אבל העדיפו שגיול הלקוחות יהיה במקום אחד (שימו לב כמה חשוב לחברות שהגיול יהיה במקום אחד).

מבחינת עלויות,  משלמים ל-Chargify בערך 1,300 דולר לחודש. זו תכנית Legacy, כיום יש תמחור חדש שהיה מגדיל את העלות ל-3,000-4,000 דולר לחודש, אבל החברה גם כך עוברת ל-Zuora.

עבור גייטווי משלמים לסטרייפ ארה"ב 2.5% מעסקה, פלוס 30 סנט. אצל סטרייפ UK משלמים 1.4% מהעסקה, פלוס 30 סנט. קחו בחשבון שהחברה סולקת בערך מיליון דולר בחודש.

חיבור ל-ERP

אין ל-Chargify התממשקות טובה עם Netsuite (עברו מפריוריטי בתחילת 2018), מעבירים פעם בחודש פעולת יומן מרכזת עבור העסקאות שהצליחו לגבות, בלי להפיק תעודה (כלומר חשבונית וקבלה). כשסוגרים חודש, מבצעים חישוב של מה צריכה להיות היתרה המאזנית של סעיף הכנסות נדחות ומעבירים פקודת יומן מול סעיף הכנסות – וכך מקבלים את ההכנסות GAAP בדוח רווח והפסד. למעשה, תמונת ראי של מה שאני עושה במדלן.

חיבור לסיילספורס

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

יתרונות וחסרונות

נקודות כואבות אצל Chargify, לפי סדר חשיבות:

  • הממשק החסר מול NetSuite ומול סיילספורס. הם עובדים על שיפור של זה, אבל כרגע זה המצב.
  • חוסר היכולת לעבוד מול מספר גייטויס – בדרך כלל נושא חשוב אצל חברות שחצו את רף החצי מיליון דולר סליקה בחודש.
  • אין אפשרות לעשות מספר מנויים שונים (שמתחילים בזמן שונה, מוצרים שונים וכו') לאותו לקוח.
  • אין אפשרות לבצע פעולות קטנות שנדרשות במהלך חיי המנוי, למשל: לתת חודש מתנה באמצע המנוי ללקוח שרוצים לצ'פר/לפצות.

בצד היתרונות אצל Chargify (ללא חשיבות לסדר):

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

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

שיפורים מתוכננים

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

המשך הסקירה דורש ביצוע רכישה

המדריך המלא ניתן לרכישה בלינק הבא תמורת 349 ש"ח (כרגע רק באמצעות פייפאל). פשוט להזין פרטי תשלום ולחכות למייל מ-CFO Desk שהנושא שלו הוא SaaS Billing Guidebook – Part 2 Purchase. המייל יכיל לינק לפורטל אישי שיאפשר לכם הורדת המסמך המלא.

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

למה החלטתי לגבות תשלום על הצפייה בחלק ב'?

אני רואה בשני החלקים יחד מין עבודת סמינריון שנשאבתי אליה תוך כדי הכתיבה; חלק א' מיועד לאינדיווידואלים סקרנים וחלק ב' לחברות שבוחנות הטמעת פתרון סליקה כולל. חלק א' מכיל המון מידע וטיפים שימושיים, בעוד שחלק ב' מפרט לכם עד לפרטי פרטים את הארכיטקטורה שחברות ה-SaaS המובילות בישראל הקימו. אם להיות כנה, חלק ב' הוא פשוט טוב ומעמיק מדי מכדי שאני אתן אותו בחינם.

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

מה התוכן הנוסף שקיים במסמך המלא?

סקירה מפורטת של ה-setup אצל שמונה חברות SaaS, כולל: עבודה עם בלוסנאפ במודל Reseller אצל שתי חברות שונות (עם הטמעות שונות), עבודה עם בלוסנאפ במודל Payment Facilitator, טיבי סנכרון שונים עם סיילספורס, הטמעה מלאה ועמוקה של Zuora+NetSuite (ה-מודל של איך צריך להקים סליקה אצל חברת SaaS בוגרת שמוכרת לאנטרפרייז), שילוב של Sap Business One עם סטרייפ שילוב של פיתרון לוגיקה עם פייפאל ועוד. בסוף הסקירה, הוספתי Cheat Sheet שמסכם את ה-setup של כל חברה שמוזכרת במסמך. דוגמא:

סליקה בחברות SaaS – דוגמה לסיכום

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

מהו האורך של המסמך המלא?

למעלה מ-6,500 מילים, 24 עמודים.

האם אתה תעדכן את המסמך?

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

האם אתמוך בכם במהלך ההטמעה של פתרון הסליקה בו תבחרו ואהיה זמין לשאלות?

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

האם המחיר צפוי להשתנות?

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

האם המחיר כולל מע"מ?

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

האם קיימת הנחה לעמותות / חברות בתחילת דרכן / חיות אחרות?

לא.

האם יהיה אפשר לקבל החזר כספי?

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

האם אתה צפוי לדרוש תשלום על חומרים נוספים באתר?

כנראה שלא. כבר הרבה זמן שאני מהרהר באפשרויות המוניטיזציה של מה שבניתי כאן עד כה. זה כמובן נחמד להיות מוערך על ידי קולגות, סטודנטים ואחרים, אבל זה גם נחמד לעשות מזה כסף. עד כה, הרוב הגדול של הפוסטים באתר היו בגדר מאמרי דעה או מאמרים מקצועיים ברמת ה-Nice to know אז לא היה היגיון בלבקש תשלום עבורם. המסמך הנוכחי הוא ממש עבודת סמינריון מקיפה שעשיתי על הנושא, כאילו שאני עצמי הולך להטמיע בקרוב פיתרון סליקה שלם. מאחר וההיקף והעומק של התוצאה הסופית חורגים בהרבה מאלה של פוסט סטנדרטי, וגם שהערך של המסמך עבור חברות הוא עצום לדעתי – הגיוני לבקש תשלום על כך. קשה לי כרגע לחשוב על נושא אחר שעומד בשני הקריטריונים של עומק וערך לקונה אז קשה לי לדמיין מסמך נוסף שיהיה בתשלום, אבל לכו תדעו. הלוואי שיהיה :)

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

¯\_(ツ)_/¯

נ.ב – השקתי ניוזלטר

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

5 תגובות כתיבת תגובה

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

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

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

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

    הרושם שלי כרגע הוא שאתה יודע הרבה דברים אבל אתה גם לא הגון במיוחד.

    אולי אתה מרגיש בנוח עם איך שזה עכשיו, אני אני לדוגמה, לא.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *