תפסיק לבנות מחדש את החנות של כל לקוח: מערכת אונבורדינג ניתנת לחזרה

סיכום

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

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

1. נהלו את תהליך הקליטה כשער, לא כצ'אט

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

שלח תקציר של עמוד אחד לפני שאתה נוגע בכל כלי. הפוך את השאלות האלה לחובה:

• כמה מק"טים אתה מתכנן למכור ב-90 הימים הראשונים?
• פיזי, דיגיטלי או מעורב?
• מי ממלא הזמנות — אתה, ספק או צד שלישי?
• מהי ערך ההזמנה הממוצע?
• האם אתה מוכר בין מדינות או ארצות? היכן יש לך נוכחות מס?
• האם תציע מנויים, הזמנות מוקדמות או חבילות מרובות פריטים?
• מהו התכונה היחידה שהחנות הזו חייבת להחזיק בחודש הראשון?

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

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

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

2. בנה מטריצת פלטפורמות לפי פרופיל לקוח, לא מתוך הרגל

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

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

פרופיל לקוח	קטגוריית פלטפורמה	מתי היא מנצחת
ספירת מק"טים נמוכה, השקה מהירה, בעלים לא טכני	בונה Drag-and-Drop מתארח	מהירות, מערכת אפליקציות, אירוח מובנה
אתר תוכן קיים, שליטה בעיצוב חשובה	תוסף חנות בקוד פתוח ל-CMS הנוכחי	שמירה על האתר, הוספת מסחר
ספירת מק"טים גבוהה, קטלוג מורכב, תוכניות צמיחה	פלטפורמה מתארחת ניתנת להרחבה עם API חזק	אינטגרציות מותאמות אישית, רב-ערוצי
חנות פיזית בנוסף לחנות מקוונת	בונה משולב קופה	סנכרון מלאי בין ערוצים
תקציב מוגבל, מעט מוצרים	חנות מקוונת מוטבעת קלה	עלות חודשית נמוכה, תשלום פשוט

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

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

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

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

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

פעל לפי הסדר הזה:

1. שאל מה מחזור המזומנים של הלקוח. הפקדות שבועיות או יומיות? חלק מהמעבדים מסלקים מהר יותר, וחלק מחזיקים כספים זמן רב יותר עבור סוגי עסקים מסוימים.
2. בדוק את האינטגרציה של השער עם קטגוריית הפלטפורמה שבחרת. האם הוא תומך במנויים אם התקציר דורש זאת? האם הוא תומך במדינות בתקציר שלך?
3. בדוק את קטגוריית המוצרים של הלקוח מול רשימת ההגבלות של המעבד לפני הבנייה. קטגוריות בסיכון גבוה זוכות לחשבונות קפואים, לא למיילי אזהרה.
4. אם ללקוח כבר יש אמצעי תשלום שהלקוחות שלו סומכים עליו — ארנק מוכר היטב, לדוגמה — כלול אותו גם אם זה מוסיף עמלה. אמון ממיר טוב יותר מהפרש עמלות.
5. תיעד איזה שער, איזה חשבון ואיזה לוח זמנים לתשלומים הלקוח אישר. שים זאת בקובץ הפרויקט עם תאריך.

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

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

4. הרץ בדיקות תאימות לפני שאתה מעצב

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

תאימות היא שער השקה, לא אדמיניסטרציה. לפני כל עבודת עיצוב, ודא:

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

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

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

5. תקן את חוזה נתוני המוצר

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

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

• מק"ט פנימי וברקוד
• שם מוצר והתיאור שירוץ באתר
• מחיר ומחיר השוואה
• משקל ומידות למשלוח
• ארץ מקור, ואם בינלאומי, קוד מערכת הרמונית
• ספק וזמן אספקה
• פרופיל משלוח (מחלקת מוביל ואזורים)
• שם קובץ תמונת מוצר וטקסט חלופי
• קטגוריית מס

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

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

6. הרץ את אותו סקריפט בדיקות ביניים על כל חנות

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

אתה צריך סקריפט בדיקות. אותו סדר, אותם שלבים, כל לקוח:

1. בצע הזמנת בדיקה אמיתית עם אמצעי תשלום לבדיקה.
2. וודא שמייל האישור מגיע ללקוח.
3. בצע החזר וודא שהלקוח רואה אותו.
4. החל קוד הנחה ובדוק את החישוב.
5. בדוק קופה כאורח וקופה מחובר בנפרד.
6. הוסף מוצר לעגלה מטלפון נייד, לא רק מתצוגה מקדימה של דסקטופ.
7. בדוק כתובת משלוח בינלאומית אם הלקוח שולח בינלאומית.
8. בדוק חישוב מס עבור מדינת הבית של הלקוח ומדינה אחת נוספת.
9. גרום לתשלום שנדחה וודא שהודעת השגיאה מופיעה.
10. וודא שהמלאי יורד כשמתבצעת מכירה.

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

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

7. הפסק לתת לפלטפורמה להיות ההחלטה הראשונה

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

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

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

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

8. תנאי את ההשקה בקטלוג מינימלי בר-קיימא

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

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

תנאי את ההשקה בתנאים האלה, כולם בינאריים:

• תקציר הקליטה מלא ומאושר.
• קובץ חוזה נתוני המוצר מלא עבור כל מוצר בהשקה.
• ערימת התשלומים מאושרת והזמנת הבדיקה עברה.
• רשימת התאימות מלאה.
• סקריפט בדיקות הביניים עבר.

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

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

סיכום: התהליך שלך הוא המוצר

אתה לא מוכר אתרים. אתה מוכר נתיב צפוי מ'אני רוצה חנות' ל'החנות חיה ומעבדת הזמנות.' הנתיב הזה צריך ברירות מחדל, לא אלתורים.

בפעם הבאה שלקוח כותב ביום שישי ב-16:53, אתה לא צריך לפתור שום דבר מחדש. אתה מריץ את התקציר, בודק את המטריצה, סוקר את ערימת התשלומים, מריץ את רשימת התאימות, מאשר את נתוני המוצר ומבצע את סקריפט הבדיקות. ואז אתה עונה למייל עם תוכנית במקום ניחוש.

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