متغيرات المنتج

متغيرات المنتج هي النسخ المختلفة من منتج واحد. فالقميص منتج واحد، والأزرق الصغير والأزرق المتوسط والأسود المتوسط ثلاث نسخ منه. والمقاس واللون والخامة هي الخيارات المعتادة، لكن المحل يستطيع أن يستخدم أي شيء آخر، من الطول إلى النكهة إلى سعة الذاكرة.

والمهم هو ما يحفظه النظام لكل نسخة بدلًا من حفظه للمنتج كله. يأتي المخزون أولًا، فإذا كان لديك أربعة قمصان زرقاء مقاس متوسط ولا شيء في الكبير، وجب أن تقول الصفحة ذلك قبل أن يدفع الزبون لا بعده. ثم يأتي السعر، لأن المقاس الكبير يكلف أكثر عادةً وبعض الخامات تكلف أكثر بكثير. والثالث هو الصورة، فالزبون الذي اختار الأسود يريد أن يرى الأسود، والصفحة التي تظل تعرض الأزرق تخسر البيعة.

ويخطئ أصحاب المحلات في هذا بطريقتين، وكلتاهما سهلة الوقوع. فبعضهم ينشئ منتجًا منفصلًا لكل لون، فيمتلئ الكتالوج بنسخ متشابهة ويظهر القميص نفسه إحدى عشرة مرة في نتائج البحث. وبعضهم يضع كل شيء تحت منتج واحد برقم مخزون واحد، ثم يبيع مقاسًا نفد قبل يومين. والخطأ الثاني أغلى لأنه ينتهي باسترجاع للمبلغ واعتذار، وقد أعادت لينكي سوفت لنظم المعلومات بناء أكثر من كتالوج بدأ بهذه الطريقة.

وكل نسخة تحتاج كودًا خاصًا بها، وهو الرمز القصير الذي يناديه الموظفون في المخزن. ويعطي ستوريك كل نسخة كودها ورصيدها وسعرها، فيقرأ الكاشير والموقع الرقم نفسه. وهذا هو المقصود كله، لأن البيعة التي تتم في المحل يجب أن تنقص المخزون الظاهر على الموقع خلال ثوانٍ.

وهناك تكلفة يقلل الناس من شأنها، فاثنا عشر لونًا في خمسة مقاسات تعني ستين نسخة، ولا بد لأحد أن يصورها ويعدّها ويسعّرها كلها. لذلك اسأل نفسك قبل ضبط الخيارات كم تركيبة تبيع فعلًا، فكثير من المحلات تكتشف أن ست نسخ من الستين تحمل معظم الأرباح. وحين تخطط لينكي سوفت لبناء تطبيق ويب لمحل، نطلب أولًا مبيعات العام الماضي حسب المقاس واللون، لأن هذه القائمة هي التي تحدد شكل الكتالوج كله. سؤال ممل يوفر شهورًا.