התחילו בדרישת החנות
חזית חנות מותאמת אישית היא בחירת מסירה, לא מטרה בפני עצמה. רשמו את ההתנהגות שהעסק אינו יכול להשיג היום: מגדיר מוצרים, מסע קנייה מערכתי, פורטל לקוחות או שילוב עם מערכת גב-משרדית. לאחר מכן בדקו האם שינוי תבנית או אפליקציה ממוקדת יכולים לענות על כך.
Headless Shopify מפרידה בין חזית החנות הפונה ללקוח לבין מערכת המסחר האחורית. Shopify מציעה את Storefront API שלה וכלי Hydrogen לגישה זו. גמישות זו גם אומרת שצוות חייב לתחזק את אפליקציית חזית החנות. היא אינה מסירה אוטומטית מגבלות תשלום או תוכנית. סקרו את התיעוד של Shopify ל-headless מול התכונות והתוכנית שבתחום.
השוו שלושה היקפים
- עבודת תבנית: שינויי מרצ'נדייזינג, תוכן, ניווט ופריסה המתאימים לחנות הקיימת. העריכו את האפליקציות הקיימות ואת ביצועי התבנית לפני הכנסת זמן ריצה נוסף.
- עבודת שילוב: מלאי, הזמנות, רשומות לקוחות או מימוש שנעים בין Shopify למערכת עסקית אחרת. תהליכי עבודה רבים כאלה יכולים לשמר את חזית החנות הנוכחית.
- חזית חנות מותאמת אישית: מסע לקוח שונה מספיק כדי להצדיק פיתוח אפליקציה נפרד, תצוגות מקדימות, אירוח ותחזוקה שוטפת.
דוגמה: טיפול במלאי והעברת הזמנות
נניח שסיטונאי צריך שהזמנות יועתקו למערכת המימוש שלו ושרמות המלאי יוחזרו לחנות. התוצר הראשון צריך להיות מיפוי של מזהי מוצרים, בעלות על מלאי ומצבי הזמנות. הגדירו מה קורה אם הזמנה נערכת, מבוטלת או מעובדת פעמיים, וכיצד הצוות מיישב העברות שנכשלו. החלפת חזית החנות אינה פותרת כשלעצמה את הבעיות הללו.
מה להכין
הביאו כתובת URL של חנות, את התבנית הנוכחית ורשימת האפליקציות, שווקי יעד, דוגמאות קטלוג והמערכות המעורבות. ספקו גישה לסביבת ארגז חול היכן שזמינה ובעל עסק שיכול להחליט כיצד המלאי וההזמנות צריכים להתנהג. הימנעו משיתוף אישורי גישה חיים בפנייה הראשונית.
הצעה שימושית מפרידה בין חוויית הלקוח לבין הגירת נתונים, שילוב פלטפורמה, אנליטיקה, בדיקות קבלה ותחזוקה. עליה לזהות מגבלות תשלום, דרישות מנוי או B2B הזקוקות לאימות תוכנית, וכל תלות צד-שלישי שעלולה להשפיע על המסירה.
עבור WooCommerce, העריכו בנפרד את אירוח WordPress, מחסנית התוספים ותהליך השדרוג; זהו אינו יישום Shopify בר-החלפה. ראו פיתוח Shopify ו-WooCommerce עבור פונקציונליות החנות, ו שירותי שילוב API עבור חיבור המערכת העסקית.
