חשבונאות WooCommerce לעסקים היא ברובה ספר ההוראות של Shopify שלך, ששורד את המסע ללא פגע. שלוש הנקודות שבהן הוא לא שורד הן בדיוק המקום שבו ההתקשרות חורגת מהצעת המחיר.
מייל ההפניה יושב בתיבת הדואר הנכנס שלך. לאחת מלקוחות Shopify שלך יש חברה ש"מנהלת את החנות שלה בוורדפרס - WooCommerce, אני חושב?" - ומכיוון שסגרת את הספרים שלו עד ה-10 בכל חודש השנה, הוא אמר לה שאתם העסק שמבין במסחר אלקטרוני.
זה מגיע לך. יש לך גיליון עלייה למטוס של Shopify שאחד העובדים יכול להריץ בפחות משעה: חיבורים, תבנית מיפוי סטנדרטית, מילוי היסטורי, תשלום אחד שעוקב מקצה לקצה. אז אתה פותח את המערכת של הלקוח החדש בציפייה ל-Shopify עם לוגו אחר.
במקום זאת אתה מוצא: Stripe *וגם* PayPal *וגם* שער "קנה עכשיו שלם אחר כך" שמעולם לא התאמת. אין חנות אפליקציות - דף תוספים עם 31 ערכים, ארבעה מהם דורשים עדכונים. ואין חברת פלטפורמה שמארחת אף אחד מהם - הלקוח שוכר שרת מחברת אירוח שגם לא שמעת עליה מעולם, והאחיין שלה "מטפל בדברים של האתר".
המסקנה המפתה היא זו שרוב העסקים נושאים בשקט: *לקוחות WooCommerce הם פשוט לקוחות Shopify עם צעדים נוספים - אותו ספר הוראות, יותר סבלנות.* זה השקר, והוא יקר, כי זה אומר שכל הפתעה ספציפית ל-WooCommerce נוחתת באמצע ההתקשרות במקום בהצעת המחיר. האמת היא ש-WooCommerce שונה עבור עסקי חשבונאות בשלוש דרכים ספציפיות ומבניות - ולכל אחת מהן יש תשובה סטנדרטית שתוכל לקבוע כמדיניות לפני שיחת הפתיחה.
למה חשבונאות WooCommerce לעסקים היא עבודה שונה
אף אחת משלוש ההבדלים אינה קשורה לחשבונאות. הכנסות, עמלות, חשבונות נגד החזרים, התחייבויות מס - זהים ללקוחות Shopify שלך. מה שמשתנה הוא מאיפה הנתונים מגיעים ומי שולט במכונה שמייצרת אותם.
1. אין מסלול תשלום יחיד
לקוח Shopify טיפוסי מריץ Shopify Payments, ורוב הכסף שלהם מגיע דרך זרם תשלום אחד עם לוגיקת עמלות אחת. זיכרון השריר של ההתאמה שלך בנוי על זה.
ל-WooCommerce אין שער בית. הצ'ק-אאוט מורכב: Stripe לכרטיסים, PayPal כי לקוחות מצפים לכך, אולי Klarna או מעבד אזורי שהלקוח הוסיף במהלך מבצע לפני שנתיים. כל שער מרכז תשלומים בלוח זמנים משלו, מנכה עמלות משלו, ומעדכן החזרים בלוח זמנים משלו. אין דבר כזה "תשלום WooCommerce" - ישנם שלושה או ארבעה זרמי הפקדה לא קשורים שפוגעים באותו חשבון עובר ושב.
תשובת הצד המשרדי: סליקה לפי שער, מוצהרת כמדיניות קבועה. חשבון סליקה אחד ושורת הוצאות עמלה אחת עבור כל שער פעיל בחנות, שנוצר לפני שהסנכרון של העסקה הראשונה מתבצע — לעולם לא "עמלות סוחר" משותפות. זוהי אותה ארכיטקטורת סליקה שאתם כבר סומכים עליה; ההבדל של Woo הוא שאתם מריצים אותה במקביל, במספר ערוצים בו זמנית. עוד על המדיניות בהמשך.
2. הלקוח הוא הבעלים של התשתית
Shopify היא פלטפורמה מארחת: זמן פעולה, אבטחה ומסד הנתונים של המכירות הם בעיה של Shopify. חנות WooCommerce היא תוכנה שהלקוח מריץ על אירוח שהלקוח בחר. ליבת וורדפרס, WooCommerce, גרסאות PHP, תעודות SSL ו-30 תוספים נוספים כולם חיים בתשתית שאין לחברה שלכם כל נראות אליה — וכל זה יושב לפני מקור הנתונים שלכם.
זה לא הופך אתכם למחלקת ה-IT שלהם. זה הופך את התשתית לשאלת היקף, באותה דרך שבה "האם זה QuickBooks Online או Desktop?" היא שאלת היקף עבור לקוחות Shopify.
התשובה מצד החברה: גישה ועדכון היגיינה שייכים למייל הקליטה שלכם, לא לחודש השלישי. הוסיפו ארבע שאלות לרשימת הבדיקה לפני שיחה: מי מארח את האתר, ומי מתחזק אותו? האם HTTPS מופעל? (כלי הסנכרון יסרבו להתחבר בלעדיו.) האם מטבע החנות תואם למטבע הבית של חברת QuickBooks? ומי מחזיק בגישת wp-admin עם הרשאות להתקנת תוסף? חמש דקות של קליטה; זה מבטל את כל הקטגוריה של הפתעות "האתר היה מושבת / התעודה פגה / האחיין עדכן משהו".
3. שכבת הסנכרון היא תוסף שהלקוח מתקין
עבור לקוחות Shopify, כלי הסנכרון הם התקנת אפליקציה מחנות אפליקציות בפלטפורמה שמבטיחה את הסביבה. עבור WooCommerce, כלי הסנכרון הוא תוסף וורדפרס, המותקן ב-wp-admin של הלקוח, מדבר עם ה-REST API של החנות שלו. החיבור שעליו אתם סומכים עבור ספרים נקיים חי בתוך המערכת מהבדל #2.
תשובת הצד המשרדי: רשימת המעקב שלכם כוללת את ה-wp-admin שלהם. לא כעול — כשלב מודרך של עשר דקות שאתם מריצים בשיחת הפתיחה, עם הלקוח (או מי שמחזיק בניהול) נוהג. זרימת ההתקנה והחיבור קצרה וסטנדרטית, והליכה משותפת בה פירושה שאתם יודעים בדיוק מה רץ בחנות שלהם. החלק הבא מכסה זאת.
פער העלייה למטוס: מה משתנה מגיליון הריצה של Shopify שלך
אם בנייתם את תהליך ההצטרפות של Shopify בחמישה שלבים, שמרו אותו. השלד שורד: הכנה לפני שיחה, חיבורים, מיפוי מול תרשים החברה הסטנדרטי שלכם, מילוי היסטורי, בדיקת התאמה ראשונה. הנה השינוי של Woo, שלב אחר שלב.
הכנה לפני שיחה כוללת את שאלות התשתית. אירוח, HTTPS, התאמת מטבע, גישת wp-admin — ארבע השאלות מהסעיף הקודם. כל השאר במייל לפני השיחה (הזמנת רואה חשבון QBO, איזו חברת QuickBooks, טווח התאריכים למילוי) ללא שינוי.
הוסיפו שאלת קליטה חמישית בזמן שאתם שם: האם הלקוח מוכר סיטונאית? זו השאלה שמשנה את צורת ההתקשרות הכי הרבה פעמים. חנות Woo המריצה B2B לצד קמעונאות מייצרת חייבים, חשיפה לאשראי והזמנות פטורות ממס שקובץ D2C טהור לעולם אינו מייצר — והתשובה מחליטה אם אתם ממפים לחשבון מעבר או לחשבון AR לפני שאתם ממפים משהו. שאלו גם מה הם מריצים איתו: Wholesale Suite ותוספים כמוהו מחזיקים בתפקידים, כללי תמחור ומגבלות אשראי שמסבירים מדוע הזמנה נתונה נרשמה כפי שנרשמה, ואתם תרצו שזה יהיה גלוי ב-wp-admin ליד תוסף הסנכרון במקום לגלות זאת בחודש השלישי.
שלב החיבור עובר ל-wp-admin. במקום לחיצת יד של התקנת אפליקציה בכתובת URL בפלטפורמה מארחת, הלקוח מתקין תוסף. עם LedgerPort, הרצף בשיחה נראה כך:
-
התקנה. בממשק הניהול של וורדפרס של הלקוח: תוספים » הוסף תוסף חדש, חפש את LedgerPort, התקן כעת, הפעל. אשף ההגדרות נפתח אוטומטית כשכבת-על במסך מלא.
-
חיבור. האשף מבקש לחיצה אחת כדי להתחיל את זרימת החיבור.
-
אישור. הלקוח מופנה ל-app.ledgerport.com, נכנס, בוחר את העסק ומאשר — ואז נוחת בחזרה בממשק הניהול של וורדפרס שלו. אין סיסמאות שעוברות ידיים, וזה שווה להגיד בקול רם בשיחה, בדיוק כפי שהיית עושה עבור הענקת OAuth של QuickBooks.
-
הקצאה פועלת מעצמה. LedgerPort יוצר מפתח WooCommerce REST API עם גישת קריאה ורושם webhooks עבור הזמנות, החזרים, מוצרים ולקוחות. אם שלב כלשהו נכשל, הכל מתבטל אוטומטית — החנות לעולם לא נשארת מוגדרת חלקית. כאשר זה מצליח, הלקוח נוחת בלוח מחוונים מחובר.
הנה החלק להראות ללקוח — ולבן הדוד הסקפטי של ה-IT — לפני שאתם ממשיכים: כל מה שהתוסף הקצה גלוי בהגדרות WooCommerce של החנות, תחת Webhooks. עם שם, ברשימה, ניתן לביקורת.
שקיפות זו היא התשובה הכנה לדאגת היגיינת הגישה מהבדל #2. התוסף מחזיק גישת קריאה, טביעת הרגל שלו ניתנת לבדיקה ב-wp-admin, וניתוק מוחק את מפתח ה-API ואת ה-webhooks שהוא יצר — שום דבר לא נשאר בחנות של לקוח שאתם כבר לא משרתים.
מיפוי, מילוי היסטורי ואימות הם אותו שריר. תרשים המסחר האלקטרוני הסטנדרטי שלכם חל; מיפוי מוצרים וחשבונות פועל מתפריט LedgerPort שכעת חי בסרגל הצד של ה-wp-admin של הלקוח — לוח מחוונים, מיפויים, סנכרון ידני, יומני ביקורת — כך שבדיקת בריאות הסנכרון לעולם לא דורשת כניסה למשהו חדש. מילוי היסטורי ושלב אימות סינון יומן הביקורת לשגיאה עובדים בדיוק כפי שהם עובדים בקבצי Shopify שלכם.
הפרש נטו לריצת העבודה: ארבע שאלות קלט והתקנה מודרכת של עשר דקות. זה כל חלק ה"צעדים נוספים" של השקר — וזה החצי הקטן יותר של הסיפור.
התאמת שערים כמדיניות קבועה
החצי הגדול יותר הוא הבדל #1, מכיוון שהוא חוזר על עצמו בכל סגירה, לא רק בעת עלייה למערכת. כתבו זאת כפוליסה מחייבת — שלוש שורות:
חשבון פינוי אחד לכל שער, ללא יוצאים מן הכלל. Stripe Clearing, PayPal Clearing, אחד לכל מסילה נוספת — כל אחד מהם נכס שוטף אחר בקובץ QBO של הלקוח, שנוצר בעת העלייה למערכת. חשבון פינוי משותף בין שערים בונה מחדש את הפאזל המדויק שהוזמנתם לפתור.
שורה אחת של עמלה לכל שער. לא ניתן לבדוק עמלות משולבות. בנפרד, שיעור היעילות של כל שער הופך לבדיקה חודשית של שתי דקות: סטארייפ פועל בדרך כלל בסביבות 3%, והחודש שהוא קורא 4.1%, משהו קרה ששווה שתי דקות.
יתרות סליקה הן בדיקת הבריאות. כל חשבון סליקה צריך להחזיק רק כסף במעבר - כמה ימי מכירות. יתרה מתגנבת פירושה שעמלות או החזרים לא נרשמים במסילה ספציפית זו, וזה אומר לך איזה מהם.
אנו בכוונה לא מחדשים את המכניקה כאן - ארכיטקטורת סיכום-יומי ויומן-תשלומים מכוסה, עם מספרים שעובדו, במדריכי בעלי החנויות שלנו ל סנכרון WooCommerce עם QuickBooks ו מבני הנהלת חשבונות של WooCommerce. שני הפוסטים הללו שימושיים גם במדויק כחינוך לקוחות: שלח אותם לבעל החנות לפני ההתחלה והשיחה "למה אתה פשוט לא יכול להתאים את ההפקדות?" כבר התקיימה.
מה שחשוב למשרד הוא שהמדיניות הזו היא תצורה, לא משמעת. LedgerPort מזהה אוטומטית כל שער פעיל בחנות ונותן לכל אחד שורה משלו - חשבון סליקה, שיטת תשלום QBO, טיפול בהחזרים - עם ברירת מחדל לכל דבר שאינו מוגדר. הזוטר שלך מגדיר אותו פעם אחת בעת ההצטרפות מול התרשים הסטנדרטי של המשרד, והארכיטקטורה לכל שער מבצעת את עצמה מאז.
חסרי שירות ודביקים
עכשיו הטיעון לבניית המשרד, כי הוא חזק יותר עבור WooCommerce מאשר כמעט בכל מקום אחר במסחר אלקטרוני.
רוב כלי הנהלת החשבונות למסחר אלקטרוני הם Shopify-first. רוב התוכן, רוב השיווק של רואי חשבון, רוב המיצוב "אנחנו מדברים מסחר אלקטרוני" - Shopify-first. WooCommerce מפעילה נתח דומה של חנויות מקוונות בעולם, ובכל זאת בעל חנות Woo שמחפש רואה חשבון שמבין תשלומי שערים וסנכרון מבוסס פלאגינים מוצא כמעט אף אחד. הכלים המובנים של Woo שכן קיימים פותרים בעיקר בעיה אחרת - סנכרון דו-כיווני לכל הזמנה לעסקים מונעי חשבוניות, ש MyWorks עושה בצורה אמיתית - לא את ההתאמה ברמת התשלום שהסגירה חודשית תלויה בה.
עבור משרד, מחסור כזה עושה שני דברים. זה הופך את ערוץ ההפניות לנדיב באופן לא פרופורציונלי: משרתים לקוח WooCommerce אחד היטב והופכים ל"משרד שיכול לטפל בחנויות וורדפרס" בקהילות שבהן המשפט הזה נדיר. וזה הופך את הלקוחות לדביקים - בעל חנות שספריו סוף סוף מתאימים לבנק, שנוצרו על ידי משרד שידע לשאול על האירוח שלה לפני שבן דודה שלה שבר אותו, לא הולך לחפש גנרליסט כדי לחסוך 50 דולר בחודש.
זה טיעון התשתית זהה שעשינו בלמה לקוחות מסחר אלקטרוני הורסים את שולי הרווח של המשרד — השוליים נקבעים על ידי כלים, לא סוג לקוח — עם שדרוג אחד: ב-WooCommerce, התחרות לא קראה את הפוסט הזה. ומכונת הפורטפוליו עוברת בשלמותה: תוכנית השותפים של CPA מיישמת את תצורת תרשים תבנית האב שלך על פני לקוחות בין אם הם מריצים Shopify או WooCommerce, תחת כניסה אחת למשרד, כך שלקוח ה-Woo השישי שלך יורש את ההחלטות שקיבלת על הראשון שלך.
ההפניה השנייה
דמיינו את הדבר הבא. עוד חנות וורדפרס, עוד תשלום מורכב — Stripe, PayPal, ומשהו נורדי הפעם. המייל שלכם כבר שואל את ארבע שאלות התשתית. שיחת ההתחלה שלכם כוללת התקנת תוסף של עשר דקות שכבר הרצתם בעבר. תבנית המיפוי שלכם כבר כוללת שורות ניקוי לכל שער תשלום, וסוף החודש אצל הלקוח הזה הוא אותו סגירה של סקירה-לא-בנייה מחדש שאתם מריצים על קבצי ה-Shopify שלכם.
אותה תוכנית פעולה בסופו של דבר — רק לא זו שהשקר הבטיח. שלוש מדיניות, שאומצו פעם אחת, והבדל הפלטפורמה מפסיק להיות סיבה לשלוח את ההפניה הלאה.
יש לכם את שלוש ההבדלים ואת התשובות הקבועות שלהם; הדרך המהירה ביותר לבחון אותם היא על קובץ לקוח אמיתי. קבעו שיחת onboarding של CPA → ואנו נריץ את לקוח ה-WooCommerce הראשון שלכם איתכם — ארבע שאלות הקליטה, התקנת ה-wp-admin, הגדרת ניקוי לכל שער תשלום, וסגירה ראשונה שמתחברת לכל אחד מזרמי ההפקדה הללו.
