להפסיק להקליד את אותו לקוח פעמיים
כשעסקה נסגרת ב-CRM, מישהו פותח את מערכת החשבונות ומקליד את אותם פרטים מחדש. זה מקור קבוע לטעויות, לכפילויות, ולמצב שבו אף אחד לא בטוח איזו מערכת מחזיקה את הפרטים הנכונים.
לא כל נתון צריך לזוז באותה מהירות
בחרו סוג נתון וראו באיזו תדירות הגיוני שיתעדכן - ולמה.
לא מחליפים את מערכת החשבונות, מפסיקים את הכפילות
המטרה היא לא להחליף את מערכת החשבונות אלא להפסיק את ההקלדה הכפולה, ולתת לצוות המכירות והשירות ראות על מצב החוב בלי לפנות להנהלת חשבונות בכל פעם. מה שעובר בפועל ומה שנשאר ידני נקבע לפי המערכת הספציפית ולפי מה שרואה החשבון מאשר.
תרחישים אפשריים
לקוח שנפתח ב-CRM נוצר גם במערכת החשבונות.
עסקה שנסגרת מייצרת מסמך חיוב בלי הקלדה חוזרת.
מצב חוב ויתרות מוצגים בכרטיס הלקוח, לפי הרשאה.
התראה לאיש מכירות על לקוח בחריגת אשראי.
סטטוס תשלום מתעדכן חזרה ל-CRM.
דוח הנהלה שמשלב צנרת מכירות עם גבייה בפועל.
מניעת פתיחת אותו לקוח פעמיים בשתי המערכות.
התאמת מספר עוסק או ח.פ. כמזהה ייחודי בין המערכות.
מה עשוי לעבור בין המערכות
פרטי לקוח, מספר עוסק או ח.פ., מסמכי חיוב, סטטוס תשלום ויתרות - בהתאם למה שהמערכת חושפת ולמה שיוגדר בפרויקט.
מתי הנתונים עוברים
פתיחת לקוח ומסמכי חיוב לרוב בזמן אמת; יתרות וסטטוס תשלום מספיק בתזמון יומי. אין צורך בעדכון מיידי של נתון שממילא משתנה פעם ביום.
אפשרויות מימוש
תלוי במערכת: יש מערכות ישראליות עם API פתוח, אחרות דורשות מוצר ביניים, ויש כאלה שמאפשרות רק ייצוא קבצים. הבדיקה הזו קודמת לכל תכנון. חשבונית ירוקה ו-SmartBee, לדוגמה, חושפות שתיהן API ציבורי ומתועד - אין ביניהן לבין Zoho קונקטור מוכן מהמדף, אז החיבור נבנה מותאם דרך Zoho Flow או קריאה ישירה ל-API, לא כתוסף שמותקן ומופעל.
מה Alevectis מבצעת
כי זה קובע אם מדובר בחיבור אמיתי או בייצוא קבצים.
כדי להגדיר מה מותר לייצר אוטומטית ומה דורש אישור אנושי.
ואת כללי מניעת הכפילות בין הרשומות.
ובודקים על נתוני בדיקה לפני שנוגעים במסמכים אמיתיים.
כדי שהחיבור יישאר מובן גם למי שיבוא אחרינו.
מוצרי Zoho שמעורבים בחיבור הזה
מה שנפגש עם מערכת החשבונות בפועל. מה שמסומן כקישור נפתח לעמוד מלא.
שאלות שצריך לענות עליהן לפני שמתחילים
- איזו מערכת חשבונות מותקנת, ומה היא חושפת?
- מה מותר לייצר אוטומטית, ומה דורש אישור אנושי?
- מי המקור הקובע לפרטי הלקוח - CRM או החשבונות?
- מי מורשה לראות מצב חוב בכרטיס הלקוח?
שאלות נפוצות
לא. המטרה היא לא להחליף את מערכת החשבונות אלא להפסיק את ההקלדה הכפולה, ולתת לצוות המכירות והשירות ראות על מצב החוב בלי לפנות להנהלת חשבונות בכל פעם.
אין קונקטור מוכן מהמדף בין Zoho לבין חשבונית ירוקה או SmartBee - שתי המערכות חושפות API ציבורי ומתועד, ואת החיבור בונים מותאם דרך Zoho Flow או ה-API הרשמי שלהן. הבדיקה הראשונה היא תמיד מה המערכת שלכם בפועל חושפת ומאשרת, לא הנחה שהחיבור כבר קיים.
הנפקת מסמכי חיוב בישראל כפופה להוראות ניהול ספרים ולדרישות רשות המסים, כולל נושא החשבוניות הדיגיטליות. אנחנו לא קובעים איזו מערכת עומדת בדרישות ואיזו לא - זו הכרעה של רואה החשבון שלכם, ואנחנו בונים את החיבור לפי מה שהוא אישר.
לא, ואין סיבה שכן. פתיחת לקוח ומסמכי חיוב בדרך כלל צריכים לזוז בזמן אמת. יתרות וסטטוס תשלום מספיק שיתעדכנו בתזמון יומי - הם ממילא לא משתנים כל דקה, ועדכון תכוף מדי רק מעמיס על שתי המערכות בלי תועלת אמיתית.
נדרש כלל מיפוי שנקבע מראש - בדרך כלל מספר עוסק או ח.פ. כמזהה ייחודי, וקביעה איזו מערכת היא המקור הקובע לכל שדה. בלי זה נוצרות כפילויות שאף דוח לא מתאושש מהן.
זה נקבע לפי הרשאה כחלק מהפרויקט, לא נפתח אוטומטית לכולם. בדרך כלל איש המכירות והשירות שמטפלים בלקוח רואים יתרה, בלי גישה למסמכים הפיננסיים המלאים.
תלוי במערכת החשבונות עצמה: יש מערכות ישראליות עם API פתוח, אחרות דורשות מוצר ביניים, ויש כאלה שמאפשרות רק ייצוא קבצים. הבדיקה הזו קודמת לכל הערכת זמן.
מקלידים את אותו לקוח בשתי מערכות?
בשיחת פתרון טכנית נבדוק מה המערכת שלכם חושפת ומה אפשר לחבר - בלי הבטחות לפני שראינו את המערכת.