לכן כשמחליטים לפתוח חנות או פורטל הזמנות ללקוחות עסקיים, השאלה הראשונה לא צריכה להיות:
"איך מעבירים את כל העסק למערכת חדשה?"
אלא:
"איך נותנים ללקוח חוויית B2B טובה, בלי ליצור מערכת שנייה שמנהלת שוב את אותם נתונים?"
זו הבחנה חשובה.
מערכת B2B אינה חייבת להחליף את ריווחית. במקרים רבים נכון יותר להשאיר את ריווחית כמערכת העסקית המרכזית, ולחבר אליה שכבה שמטפלת במה שהלקוח רואה ועושה: קטלוג, מחיר אישי, הזמנה, הזמנה חוזרת, אזור אישי ושירות עצמי.
כדי לעשות את זה נכון צריך להבין מה נשאר בריווחית, מה עובר למערכת B2B, ובאיזה כיוון המידע זורם.
מה ריווחית כבר מנהלת?
ריווחית אונליין כוללת יכולות עסקיות כמו לקוחות, פריטים, מסמכי מכירה, דוחות ובמסלולים הרלוונטיים גם מלאי, מחסנים ומחירונים.[1]
מבחינת מערכת B2B, אלה בדיוק חלק מהנתונים הקריטיים.
לדוגמה:
- מי הלקוח?
- אילו פריטים קיימים?
- איזה מחירון משויך ללקוח?
- אילו מסמכים כבר הופקו?
- אילו הזמנות קיימות?
- מהו המידע העסקי שכבר נשמר בכרטיס הלקוח?
אם הנתונים האלה כבר מתוחזקים בריווחית, בדרך כלל אין סיבה שבעל העסק יצטרך לעדכן אותם ידנית פעם נוספת רק כדי שהחנות תעבוד.
זו נקודת המוצא של אינטגרציה טובה:
המידע העסקי צריך להישאר במקום שבו העסק כבר מנהל אותו.
אז למה בכלל צריך API?
API הוא המנגנון שמאפשר למערכת אחת לעבוד עם מערכת אחרת בצורה מתוכנתת.
במקום שעובד ייצא מריווחית, ייצא קובץ, ייכנס לחנות ויעדכן נתונים ידנית — מערכת חיצונית יכולה לבקש את הנתונים שריווחית מאפשרת לחשוף ולהחזיר אליה פעולות מתאימות.
ריווחית מפרסמת API רשמי עבור ריווחית אונליין. בתיעוד הרשמי היא מציינת בין הדוגמאות יכולות כמו הפקת מסמכים, יצירת פריטים, יצירת כרטיסי לקוח ומשיכת דוחות מידע.[2]
בתיעוד ה-API עצמו אפשר למצוא, בין היתר:[3]
- קבלת רשימת לקוחות.
- קבלת רשימת פריטים.
- קבלת רשימת מחירונים.
- קבלת רשימת מסמכים ופרטי מסמך.
- יצירת מסמך חדש, כולל הזמנה וסוגי מסמכים נוספים.
כלומר, מבחינה ארכיטקטונית יש לריווחית נקודת חיבור רשמית שמאפשרת לבנות מערכות שמשתלבות בה במקום לעבוד במנותק ממנה.
העיקרון החשוב ביותר: להחליט מי "מקור האמת"
כששתי מערכות מנהלות את אותו מידע, מתחילות שאלות לא נעימות.
לדוגמה:
בריווחית המחיר של מוצר מסוים הוא 80 ₪.
בחנות מישהו עדכן אותו ידנית ל-85 ₪.
איזה מחיר נכון?
או:
לקוח עודכן בריווחית ועבר למחירון אחר, אבל בחנות נשאר המחירון הישן.
איזו מערכת קובעת?
זו הסיבה שאחד המושגים החשובים באינטגרציה הוא Source of Truth — מקור האמת.
עבור עסק שבנה את העבודה שלו סביב ריווחית, הגישה ההגיונית במקרים רבים היא:
ריווחית נשארת מקור האמת עבור הנתונים העסקיים שהיא מנהלת.
ומערכת ה-B2B משתמשת בנתונים האלה כדי ליצור חוויית לקוח טובה יותר.
זה אינו אומר שכל שדה חייב להגיע מריווחית. מערכת B2B יכולה להחזיק מידע שריווחית לא נועדה לנהל, למשל תמונות עשירות, תוכן שיווקי או הגדרות חוויית משתמש.
ההבחנה היא בין:
נתון עסקי מרכזי
לבין
מידע שמעשיר את חוויית המכירה.
איך נראה תהליך נכון בפועל?
ניקח דוגמה פשוטה של לקוח עסקי שרוצה לבצע הזמנה.
שלב 1 — הלקוח קיים בריווחית
כרטיס הלקוח כבר כולל את הנתונים העסקיים הרלוונטיים.
ב-API של ריווחית קיימות פעולות לקבלת לקוחות, ונתוני לקוח יכולים לכלול גם שדות כמו שיוך למחירון ואחוז הנחה.[4]
שלב 2 — מערכת ה-B2B מכירה את הלקוח
המערכת מחברת בין המשתמש שנכנס לפורטל לבין הלקוח העסקי המתאים.
מכאן היא יכולה לדעת איזה מידע להציג לו בהתאם ללוגיקה של המערכת.
שלב 3 — המוצרים מגיעים מהמערכת העסקית
מערכת ה-B2B יכולה לקבל מריווחית את הפריטים והנתונים המתאימים דרך ה-API.
היא יכולה גם להוסיף שכבת תצוגה משלה — לדוגמה תמונות, תיאור עשיר, מפרטים או סידור קטלוג — בלי לטעון שריווחית עצמה צריכה להפוך למערכת ניהול תוכן.
שלב 4 — הלקוח רואה את המחיר הרלוונטי לו
אם העסק עובד עם מחירונים או הנחות לקוח, מערכת B2B יכולה להשתמש בנתונים שמקורם בריווחית כדי לחשב או להציג את המחיר בהתאם ללוגיקה שהוגדרה.
המטרה היא להימנע ממצב שבו צריך לתחזק מחיר אחד בריווחית ומחיר אחר באתר.
שלב 5 — הלקוח מבצע הזמנה
מנקודת המבט שלו זה תהליך פשוט:
מוצרים ← סל ← אישור הזמנה.
אבל מאחורי הקלעים צריך להחליט מה קורה להזמנה לפני שהיא מגיעה לריווחית.
וזה שלב שחשוב מאוד לתכנן נכון.
למה לא כדאי שההזמנה "תתקיים" רק ברגע שה-API מצליח?
נניח שהלקוח לחץ על "בצע הזמנה".
באותו רגע יש תקלה זמנית בתקשורת, שירות חיצוני אינו זמין או שהבקשה נכשלת.
אם כל קיום ההזמנה תלוי רק בתשובה המיידית ממערכת ה-ERP, עלול להיווצר מצב בעייתי:
הלקוח חושב שהוא הזמין — אבל למערכת המקומית אין תיעוד מסודר של מה שניסה להזמין.
לכן בארכיטקטורה עמידה, הגישה הבטוחה יותר היא שהמערכת שמול הלקוח שומרת קודם את ההזמנה אצלה, ורק לאחר מכן מנסה להעביר אותה למערכת החיצונית.
כך אפשר להחזיק:
- מספר הזמנה מקומי.
- תוכן ההזמנה.
- סטטוס העברה.
- היסטוריית ניסיונות.
- אפשרות לניסיון חוזר.
- הגנה מפני שליחה כפולה.
ב-NextStore זהו עיקרון מפורש: ההזמנה נשמרת מקומית לפני השליחה לריווחית, ולאחר מכן נשלחת אוטומטית עם מנגנון למניעת מסמכים כפולים וניסיון חוזר במקרה של כשל.
זה לא שינוי במי שמנהלת את העסק.
זו שכבת אמינות סביב הפעולה של הלקוח.
האם צריך לסנכרן הכול "בזמן אמת"?
לא בהכרח.
זו אחת הנקודות שבהן כדאי להיות מדויקים.
ה-API של ריווחית מאפשר למערכות לבצע פעולות ולקבל מידע דרך הממשק הרשמי.
אבל מזה לא נובע שכל מערכת שמשתמשת ב-API בהכרח מציגה כל נתון בכל רגע בזמן אמת.
יש כמה מודלים אפשריים:
- קריאה ישירה בכל פתיחת מסך
- כל פעולה באתר פונה למערכת המקור.
- סנכרון תקופתי
- המערכת שומרת עותק מקומי ומתעדכנת בפרקי זמן.
- מודל משולב
- חלק מהמידע נשמר מקומית, ובנקודות קריטיות מבוצעת בדיקה נוספת מול המקור.
הבחירה תלויה בעומס, ביצועים, מגבלות API, רגישות הנתון וחוויית המשתמש.
לכן כשבוחנים מערכת B2B, כדאי לשאול לא רק:
"האם יש אינטגרציה לריווחית?"
אלא:
"איזה מידע מתעדכן, באיזו תדירות, ומה קורה אם ריווחית אינה זמינה באותו רגע?"
לא כל מידע צריך לחזור לריווחית
גם כאן חשוב לא לבלבל בין מערכת עסקית לבין חוויית ecommerce.
נניח שאתם רוצים לתת למוצר:
- מספר תמונות.
- תיאור שיווקי עשיר.
- מפרט טכני.
- קובץ PDF.
- מוצרים משלימים.
- תגית כמו "מומלץ".
- מבנה תצוגה מסוים בדף המוצר.
לא בהכרח נכון שכל השדות האלה ינוהלו ב-ERP.
ייתכן שה-ERP ימשיך להיות מקור האמת עבור:
- מק״ט.
- שם בסיסי.
- מחיר.
- לקוח.
- מחירון.
- מלאי.
- מסמכים.
ושכבת ה-B2B תוסיף מעליו תוכן שמטרתו לעזור ללקוח לבחור ולקנות.
זו הפרדה בריאה בין שני תפקידים:
מערכת עסקית מנהלת את העסק; שכבת המסחר מנהלת את חוויית הקנייה.
ומה לגבי מידע פיננסי ללקוח?
מערכת B2B יכולה להיות יותר ממקום שבו מכניסים מוצרים לסל.
אם המידע קיים במערכת העסקית ונגיש לאינטגרציה, פורטל לקוחות יכול להפוך גם לנקודת שירות עצמי.
לדוגמה, לקוח עסקי עשוי לרצות לבדוק:
- הזמנות קודמות.
- מסמכים.
- יתרה.
- כרטסת.
- חובות פתוחים.
הערך כאן פשוט:
במקום שהלקוח יתקשר בכל פעם כדי לשאול "מה היתרה שלי?" או לבקש מידע שכבר קיים במערכת — אפשר לחשוף לו את המידע המתאים בצורה מבוקרת.
ב-NextStore האזור האישי כולל יתרה, כרטסת, חובות פתוחים והיסטוריית הזמנות, כחלק מהשכבה שהלקוח העסקי עובד מולה.
וכמה משתמשים יכולים להיות לאותו לקוח?
זו עוד הבחנה חשובה בין כרטיס לקוח עסקי לבין המשתמש שמבצע פעולה באתר.
בחברה אחת יכול להיות יותר מאדם אחד שמבצע הזמנות.
למשל:
- מנהל רכש.
- קניין.
- עובד בסניף נוסף.
לכן מערכת B2B טובה צריכה לחשוב על שתי ישויות שונות:
הלקוח העסקי
ו-
המשתמש האנושי שפועל בשם הלקוח.
ב-NextStore אפשר לפתוח כמה משתמשים לאותו לקוח עסקי; משתמש מנהל יכול לראות את הזמנות החברה, בעוד שקניין פועל עם המשתמש שלו.
גם כאן, המטרה אינה ליצור לקוח חדש בריווחית לכל עובד.
החברה נשארת הלקוח העסקי, והפורטל מנהל את זהות המשתמשים שעובדים בשמה.
לריווחית כבר יש מערכת B2B — אז למה בכלל לשקול שכבה נוספת?
זו שאלה חשובה, והתשובה צריכה להתחיל בעובדות.
ריווחית עצמה מציעה כיום מערכת הזמנות אונליין B2B.[5]
לפי האתר הרשמי שלה, המערכת מאפשרת ללקוחות להיכנס לאתר הזמנות, לראות מחיר רלוונטי, לבצע הזמנה, ובמסלולים המתאימים גם לשלם אונליין ולקבל מסמך. ריווחית מציינת גם מלאי, מבצעים, מעקב אחר הזמנה וסנכרון עם ריווחית אונליין.[5]
והמערכת ממשיכה להתפתח. בעדכוני ריווחית פורסמו בין היתר OTP לכניסת לקוח, שמירת סל, שינויי תצוגת קטגוריות, מיקום פריט ותהליך עסקה ממתינה במסלולים מסוימים.[6]
לכן לא נכון לטעון שכל עסק שעובד עם ריווחית צריך מערכת חיצונית.
אבל חשוב גם להפריד בין שתי שאלות שונות:
האם העסק צריך דרך דיגיטלית לקבל הזמנות?
לבין:
איזו חוויית B2B מלאה העסק רוצה לתת ללקוח שלו?
ריווחית יכולה לפתור את עצם ההזמנה.
NextStore מיועדת לעסק שרוצה לבנות חוויית B2B מלאה סביב הלקוח.
מתי פתרון הזמנות בסיסי יכול להספיק?
אם כל מה שאתם צריכים הוא לאפשר ללקוחות להיכנס, לראות מוצרים ומחירים ולבצע הזמנה — כדאי בהחלט לבדוק גם את פתרון ה-B2B של ריווחית.
אין סיבה להוסיף שכבה נוספת רק כדי לומר שיש לעסק "עוד מערכת".
אבל ברגע שהמטרה רחבה יותר — חנות במותג שלכם, כמה משתמשים לכל לקוח עסקי, הזמנה חוזרת נוחה, אזור אישי פיננסי, קטלוג עשיר יותר וחוויית לקוח שניתנת להרחבה — כבר לא מדובר רק בקליטת הזמנה.
כאן נכנסת שכבת B2B ייעודית כמו NextStore, שנועדה להרחיב את הצד שהלקוח העסקי עובד מולו, בזמן שריווחית ממשיכה לנהל את המידע העסקי מאחור.
מתי NextStore הופכת לרלוונטית?
NextStore מתאימה במיוחד לעסקים שלא מחפשים רק טופס הזמנה דיגיטלי, אלא חוויית B2B מלאה ללקוח.
למשל, כאשר חשוב לכם שלקוח מחובר:
- יראה את המחיר האישי שלו.
- יוכל להזמין שוב מתוך היסטוריית הרכישות שלו.
- יעבוד מתוך "המוצרים שרכשתי".
- ישמור מועדפים.
- יעבוד באמצעות כמה משתמשים תחת אותה חברה.
- יבדוק בעצמו יתרה, כרטסת וחובות פתוחים.
- יזמין מתוך חנות שנושאת את המותג שלכם.
במקרים כאלה, ריווחית ממשיכה לעשות את מה שהיא טובה בו — לנהל את הנתונים העסקיים — ו-NextStore מוסיפה את שכבת המסחר, השירות העצמי וחוויית הלקוח מעליה.
השאלה כבר אינה:
"האם אני צריך מערכת הזמנות?"
אלא:
"איזו חוויה אני רוצה לתת ללקוחות העסקיים שלי?"
איך NextStore בנויה ביחס לריווחית?
ב-NextStore העיקרון הוא שריווחית נשארת מערכת הליבה ומקור הנתונים עבור הלקוחות, הפריטים, המחירים והמידע העסקי הרלוונטי.
מעליה פועלת חנות B2B ממותגת.
לקוח מחובר יכול לראות את המחיר שלו לפי הנתונים שמגיעים מריווחית. לפי המימוש הנוכחי, המחיר יכול להיגזר מהמחירון המשויך ללקוח או מאחוז ההנחה שלו כאשר לפריט אין מחיר במחירון, והמחיר נבדק שוב לפני ההזמנה.
הלקוח יכול גם:
- לבצע הזמנה חוזרת.
- לעבוד מתוך "המוצרים שרכשתי".
- לשמור מועדפים.
- להשתמש באזור אישי.
- לעבוד באמצעות כמה משתמשים תחת אותו לקוח עסקי.
הנתונים העסקיים ממשיכים להגיע מריווחית, והזמנות חדשות חוזרות לריווחית לאחר שהן נשמרו קודם במערכת המקומית.
לכן המודל אינו:
ריווחית או NextStore.
אלא:
ריווחית כמערכת העסקית + NextStore כחוויית הלקוח העסקי.
ומה אסור לעשות באינטגרציה כזו?
יש כמה טעויות ארכיטקטוניות שכדאי לזהות מראש.
1. לנהל מחירונים ידנית בשתי מערכות
אם ריווחית היא המקום שבו העסק קובע מחירים ללקוחות, יצירת מנגנון נפרד שלא מסונכרן איתה מייצרת מהר מאוד פערים.
2. ליצור לקוחות כפולים
אם כל משתמש פורטל הופך ללקוח חדש במערכת העסקית, מאבדים את ההבחנה בין החברה לבין האנשים שקונים בשמה.
3. להניח שה-API תמיד זמין
כל אינטגרציה חיצונית יכולה להיכשל זמנית.
צריך לתכנן מראש מה קורה להזמנה כאשר ההעברה נכשלת.
4. לא לתעד סטטוס סנכרון
אם מערכת מעבירה הזמנה, חשוב שאפשר יהיה לדעת אם היא:
- נשמרה.
- נשלחה.
- נכשלה.
- נשלחה שוב.
5. להציג "זמן אמת" בלי לדעת מה באמת מתעדכן בזמן אמת
קיום API אינו הבטחה שכל מסך וכל נתון במערכת B2B מתעדכן מיידית.
צריך להבין את מודל הסנכרון האמיתי.
ומה כדאי לבדוק לפני שבוחרים מערכת B2B לריווחית?
במקום להתחיל מרשימת פיצ׳רים, כדאי לענות על כמה שאלות.
איפה ינוהלו המחירים?
אם בריווחית — ודאו שמערכת ה-B2B משתמשת במקור הזה ולא דורשת תחזוקה כפולה.
איפה ינוהלו הלקוחות?
צריך להיות ברור מי הלקוח העסקי ומהו רק משתמש של אותו לקוח.
מה קורה אם ריווחית אינה זמינה בזמן ההזמנה?
זו שאלה חשובה במיוחד.
מה מתעדכן אוטומטית ומה בסנכרון תקופתי?
אל תסתפקו במילה "אינטגרציה".
מה קורה לאחר שהלקוח ביצע הזמנה?
האם היא נשמרת? האם יש מספר מקומי? האם אפשר לראות שההעברה הצליחה?
מה הלקוח יכול לעשות בעצמו?
רק להזמין, או גם לראות מידע נוסף?
איזה מידע מנוהל מחוץ לריווחית?
לדוגמה תוכן עשיר, תמונות, PDF או הגדרות חוויית לקוח.
האם צריך שירות API פעיל של ריווחית?
כדי שמערכת חיצונית תעבוד דרך ה-API הרשמי של ריווחית, נדרשת גישה לשירות ה-API.
ריווחית מפרסמת את מודול ה-API כחלק משירותי ריווחית אונליין,[1] והתיעוד שלה מסביר גם כיצד מוצאים את ה-API Token מתוך המערכת.[7]
המחיר והתנאים של השירות הם של ריווחית ועלולים להשתנות, ולכן כדאי לבדוק אותם ישירות מולה בעת ההקמה.
ב-NextStore שירות API פעיל של ריווחית הוא דרישה לחיבור.
האם חיבור API אומר שצריך לתת למערכת החיצונית את הסיסמה לריווחית?
לא בהכרח.
ריווחית מספקת API Token ייעודי לחיבור API, ואפשר להציג אותו מתוך הגדרות המערכת לפי ההנחיות הרשמיות שלה.[7]
מבחינה אבטחתית, מערכת אינטגרציה טובה צריכה להתייחס ל-Token כמידע סודי:
- לא להציג אותו ללקוחות.
- לא לרשום אותו בלוגים.
- לא לשתף אותו בקוד.
- לשמור אותו בצורה מאובטחת.
ה-Token הוא מפתח גישה למערכת העסקית, ולכן צריך לטפל בו כמו סוד מערכת.
השורה התחתונה
חיבור מערכת B2B לריווחית אינו אמור להתחיל בשאלה:
"איך מוציאים את העסק מריווחית?"
אלא בשאלה:
"איך נותנים ללקוח שכבה דיגיטלית טובה יותר בלי לשבור את מערכת העבודה שכבר קיימת?"
כאשר האינטגרציה בנויה נכון:
ריווחית ממשיכה לנהל את המידע העסקי.
מערכת ה-B2B מציגה אותו ללקוח בדרך שמתאימה למסחר עסקי.
וההזמנות חוזרות חזרה לתהליך התפעולי של העסק.
עבור עסק שעובד עם ריווחית ורוצה יותר מפורטל הזמנות בסיסי, זה בדיוק המודל ש-NextStore נבנתה עבורו:
ריווחית ממשיכה לנהל את העסק. NextStore מנהלת את חוויית הלקוח העסקי.
כך העסק לא צריך לבחור בין ריווחית לבין חוויית B2B מתקדמת — הוא יכול להשתמש בשתיהן, כל אחת בתפקיד שלה.
רוצים לבדוק אם NextStore מוסיפה לכם ערך?
כבר עובדים עם ריווחית ורוצים להבין אם NextStore מוסיפה לכם ערך מעבר למערכת ההזמנות הקיימת?
אפשר לצפות בדמו או לבצע בדיקת התאמה קצרה לעסק.
לתמחור NextStore