בניית אתרים
אפיון חנות אונליין לפני הקמה: קטלוג, וריאציות ותהליך רכישה
איך מגדירים קטלוג, וריאציות, מלאי, אספקה ותהליך רכישה לפני הקמת חנות אונליין, עם דוגמאות אפיון וצ׳קליסט בדיקות למסירה.
לפני שבוחרים צבעים ותבנית, כדאי לדעת מה החנות צריכה למכור ואיך העסק יספק את ההזמנה. אפיון טוב מחבר בין המידע שהלקוח צריך כדי לבחור לבין המידע שהצוות צריך כדי לטפל ברכישה. התוצר אינו רשימת פיצ׳רים ארוכה, אלא החלטות ברורות, דוגמאות מוצר ותרחישי בדיקה.
קודם מגדירים מה הלקוח יכול להשלים באתר
האם מדובר בחנות שבה משלמים ומקבלים אישור הזמנה, בקטלוג שממנו שולחים בקשת הצעת מחיר, או בשילוב של שניהם? זו החלטה עסקית שקודמת לבחירת מערכת. מוצר שמחירו דורש בדיקה אישית אינו חייב לעבור בקופה כאילו היה מוצר מדף.
רשמו גם למי מוכרים: לקוח פרטי, עסק שקונה בכמויות, או שני קהלים עם תהליכים שונים. אין צורך לממש את כל האפשרויות מיד. צריך להחליט מה יקרה בהשקה הראשונה, ומה הלקוח לא יוכל לעשות עדיין. כך אפשר להשוות הצעות הקמה על אותו היקף, במקום להשוות רק את שורת המחיר.
מתחילים בשלושה מוצרים, לא בכל הקטלוג
בחרו מוצר פשוט, מוצר עם אפשרויות ומוצר חריג. למשל, בחנות כלי בית אפשר להשתמש בספל יחיד, מצעים בכמה מידות ובמארז שמכיל כמה פריטים. זו דוגמה להמחשה, לא פרויקט לקוח.
לכל דוגמה רכזו שם, תיאור, תמונות שמותר לכם להשתמש בהן, מחיר מאושר, מזהה מוצר, מצב מלאי, מידות או משקל רלוונטיים ואופן אספקה. ציינו מי אחראי לעדכן כל נתון. מידע שחסר בדוגמה בדרך כלל יחסר גם בזמן העלאת הקטלוג.
מפרידים בין קטגוריה, מאפיין ווריאציה
קטגוריה עוזרת להתמצא בחנות; מאפיין מתאר מוצר; וריאציה היא אפשרות שהלקוח יכול לבחור. לא כל תיאור צריך ליצור אפשרות רכישה חדשה.
לדוגמה, ״מצעים״ יכולה להיות קטגוריה, ״כותנה״ מאפיין, והמידה אפשרות בחירה. אם לכל מידה יש מלאי או מחיר משלה, צריך להגדיר זאת באפיון. לפי התיעוד של WooCommerce, מוצר משתנה מאפשר לנהל נתונים כגון מחיר, תמונה ומלאי לכל וריאציה. צריך להחליט אם המלאי משותף או מנוהל לכל אפשרות, ולא להסתפק בכך שבמסך קיימת רשימת מידות.
שאלות שכדאי לסגור:
- אילו שילובים באמת נמכרים, ואילו אינם קיימים?
- מה רואה הקונה כשאפשרות אזלה?
- האם בחירה משנה את התמונה, המחיר או זמן האספקה?
- האם התוספת היא מוצר עצמאי, חלק ממארז או בקשה שיש לבדוק ידנית?
דוגמה לשורת אפיון שאפשר לבדוק
נמשיך עם המצעים. במקום לכתוב ״בחירת מידה וצבע״, אפשר לנסח:
״דגם כותנה מוצע במידות יחיד וזוגי ובצבעים לבן וכחול. השילוב זוגי־כחול אינו נמכר. לכל שילוב שנמכר יש מזהה ומלאי נפרדים. כשבוחרים מידה וצבע, מוצגים המחיר והתמונה המתאימים. כשמלאי השילוב אפס, אי אפשר להוסיף אותו לעגלה, אלא אם העסק אישר במפורש הזמנה עתידית והגדיר מה יוצג לקונה.״
זו דוגמה מומצאת לאפיון, לא כלל שמתאים לכל חנות. היתרון שלה הוא שאפשר להכין עבורה נתוני מוצר ולבדוק את אותה התנהגות, בלי שהמפתח יצטרך לנחש את מדיניות העסק.
מתכננים את הדרך למוצר
רשמו איך לקוח שלא מכיר את השמות הפנימיים שלכם יחפש מוצר. בחרו קטגוריות לפי שפה מובנת, והוסיפו סינון רק כשיש נתון עקבי בקטלוג. מסנן ״מידה״ לא יעזור אם אותה מידה כתובה בכמה צורות.
חשוב שמוצרים יהיו נגישים דרך קישורים מעמודי קטגוריה, ולא רק דרך תיבת חיפוש. Google מסבירה שמבנה הקישורים מסייע לה להבין את אתר המסחר, ושבדרך כלל הסורק אינו מפעיל חיפוש פנימי כדי למצוא מוצרים. זו המלצת תכנון, לא הבטחת אינדוקס או דירוג.
להרחבה: קישורים פנימיים באתר עסקי.
מאפיינים את הקופה ואת מה שקורה אחריה
כתבו את המסלול הרצוי: בחירת מוצר ואפשרות, הוספה לעגלה, בדיקת פרטי ההזמנה, בחירת אספקה ותשלום, אישור והמשך טיפול. לצד המסלול התקין הגדירו מה קורה כשפריט אזל, כתובת אינה מכוסה, תשלום נכשל או הלקוח חוזר לעמוד.
אל תקבעו הבטחת משלוח לפני שבעל העסק אישר אותה. רכזו את אזורי האספקה, החריגים, התעריפים והאפשרות לאיסוף עצמי כנתוני אפיון לאישור. מדיניות, פרטיות ונגישות דורשות בחינה מתאימה לעסק; אפיון טכני אינו תחליף לכך.
אחרי ההזמנה, הגדירו מי מקבל אותה, איפה מעדכנים סטטוס, איזו מערכת אחראית למלאי ואיך מטפלים בביטול או החזרה. אם יש מערכת קיימת, תעדו איזה מידע אמור לעבור ובאיזה כיוון. ״חיבור למערכת״ בלי פירוט נתונים ומצבי כשל אינו תנאי קבלה.
מלאי ומשלוחים: החלטות שצריך לכתוב, לא להשאיר בעל פה
אם אותו פריט נמכר גם בחנות פיזית, בררו איזו מערכת מחזיקה את הכמות הקובעת. הגדירו מתי האתר מקבל עדכון, מה קורה בזמן ניתוק, ומי מטפל באי־התאמה. ״סנכרון מלאי״ אינו מבטיח לבדו שלא יימכר פריט שאזל; יש לבדוק את החיבור בפועל ואת מגבלותיו.
את כללי האספקה כדאי לרכז בטבלה פשוטה:
| החלטה | מה העסק צריך למסור | מה בודקים לפני פתיחה |
|---|---|---|
| אזור אספקה | רשימת אזורים וחריגים | כתובת מכוסה מקבלת אפשרות מתאימה; כתובת שאינה מכוסה מקבלת הסבר ברור |
| מחיר משלוח | כלל מאושר לפי ההזמנה או המוצר | המחיר מוצג לפני אישור התשלום ומשתנה בהתאם לכלל |
| איסוף עצמי | מיקום, זמינות והנחיות מאושרות | הבחירה אינה משאירה חיוב משלוח שגוי |
| סל מעורב | טיפול בפריטים עם תנאי אספקה שונים | הקונה רואה את האפשרויות והעלות לפני ההזמנה |
| פריט שאזל | חסימת רכישה או הזמנה עתידית מאושרת | המסר והאפשרות בקופה תואמים למדיניות |
אין בטבלה מדיניות משלוחים מוכנה לעסק. היא מגדירה איזה מידע צריך לקבל ממנו ואיך לוודא שהאתר מיישם אותו.
הופכים דרישות לבדיקות קבלה
במקום ״החנות צריכה לעבוד במובייל״, כתבו: ניתן לבחור אפשרות, לקרוא מחיר, לערוך כמות ולהגיע לקופה במסך צר בלי כפתור מוסתר. במקום ״יש מדידה״, הגדירו אילו אירועים נדרשים וכיצד תיבדק רכישה אחת ללא כפילות, בסביבת בדיקה מורשית.
לדוגמה, אפשר לצרף לאפיון את שלושת התרחישים הבאים. אלו תנאים מוצעים לבדיקה בסביבה מתאימה, לא טענה שהחנות כבר נבדקה:
- שינוי וריאציה בעגלה: בוחרים מוצר זמין, מוסיפים לעגלה ומשנים את האפשרות בדרך שהאתר מאפשר. המזהה, המחיר והתמונה צריכים להישאר תואמים למוצר שהוזמן.
- תשלום שלא הושלם: משתמשים במצב בדיקה של ספק התשלום, אם הוא זמין ומורשה. העסק צריך לדעת מהו סטטוס ההזמנה, מה הלקוח רואה והאם נשלח אישור; אין לסמן תשלום כאילו התקבל.
- חזרה לעמוד האישור: לאחר הזמנת בדיקה מאושרת, מרעננים את העמוד ובודקים שלא נוצרת הזמנה נוספת. בנפרד, בודקים שמדידת הרכישה אינה נספרת שוב. הזמנה ומדידה הן שתי מערכות שונות.
בדיקות תשלום אינן מחייבות חיוב אמיתי בכל שלב. יש לתאם עם הגורם המקים ועם ספק התשלום את סביבת הבדיקה וההרשאות. אין להזין פרטי לקוחות אמיתיים רק כדי למלא תרחיש.
צ׳קליסט קצר למסירה לבונה:
- שלוש דוגמאות מוצר מלאות עם בעל אחריות לנתונים.
- מפת קטגוריות, מאפיינים ואפשרויות רכישה.
- כללי מלאי, מחיר ואספקה שאושרו בעסק.
- מסלול הזמנה ומצבי כשל עם תוצאה צפויה.
- רשימת חיבורים, נתונים ותלות בגישה.
- בדיקות מחשב ומובייל והבחנה בין רכישה, קליק ומדידה.
- מה כלול בהשקה הראשונה ומה נשמר לשלב הבא.
אין צורך להוסיף כל יכולת ביום הראשון. חשוב לדעת מה חייב לפעול כדי שהלקוח יוכל לבחור והעסק יוכל לספק, ומה אפשר לדחות בלי לפגוע במסלול הזה.
איך נראה מסמך שאפשר למסור לבונה?
המסמך לא צריך להיות ארוך כדי להיות שימושי. לכל דרישה כדאי לתת מקום לארבע תשובות: מה הוחלט, מי מספק את הנתונים, מה עדיין פתוח ואיך תיראה תוצאה תקינה.
למשל: ״איסוף עצמי כלול בהשקה; בעל העסק מוסר כתובת והנחיות; טרם הוחלט אם נדרש תיאום; בבדיקה בחירת איסוף תסיר את עלות המשלוח ותציג את ההנחיות המאושרות.״ כך שאלה פתוחה לא הופכת בטעות להבטחת שירות.
אפשר לצרף גיליון מוצרים ותיקיית תמונות במקום להעתיק הכול למסמך. חשוב שהקבצים יהיו מזוהים ושהגרסה שסוכמה תהיה ברורה. אם צריך חיבור למערכת קיימת, מוסיפים איש קשר מקצועי ותיעוד זמין, לא סיסמאות בתוך מסמך האפיון.
לפני בחירת פתרון, בקשו מהספק לציין מה נתמך כפי שהוא, מה דורש התאמה ומה תלוי בשירות נוסף. החלטות אלה עשויות לשנות את היקף העבודה; אין סיבה להניח מראש שכל פיצ׳ר זמין בכל מערכת.
מגיעים לשיחת האפיון עם חומר שאפשר לעבוד איתו
אספו את הדוגמאות וההחלטות במסמך אחד, וסמנו שאלות פתוחות במקום לנחש. כך ניתן לדון בהיקף, בתלויות ובתנאי הקבלה לפני ההקמה.
למידע על אתרי קטלוג וחנויות אונליין ב-Leadify, או כדי לפנות עם פרטי הפרויקט, הכינו את הקטלוג הקיים, הדוגמאות והשאלות הפתוחות. זו נקודת פתיחה שימושית לשיחה על חנות שמתאימה לאופן שבו העסק באמת עובד.
מקורות מקצועיים
הצעד הראשון
יש לכם מטרה. בואו נהפוך אותה למערכת דיגיטלית שעובדת.
השאירו פרטים לשיחת היכרות ממוקדת. בלי התחייבות ובלי הצעה גנרית לפני שהבנו מה צריך.