«پیراهن آبان، رنگ سرمه‌ای، سایز بزرگ.» این عبارت ظاهراً سفارش کاملی است، اما هنوز معلوم نیست «بزرگ» همان L است یا نامی که فروشنده برای اندازه دیگری به کار می‌برد. شاید رنگ سرمه‌ای در سایز L تمام شده باشد و موجودی کنار نام آبان، جمع همه رنگ‌ها و اندازه‌ها باشد. حتی با داشتن عکس و قیمت، ممکن است مشتری چیزی را انتخاب کند که نمی‌توان دقیقاً همان را از قفسه برداشت.
مدیریت تنوع محصول در فروشگاه‌ساز، از مشخص‌کردن واحد قابل خرید شروع می‌شود. در این کارگاه، یک کاتالوگ کوچک فرضی می‌سازیم: یک مدل پیراهن، سه رنگ، سه سایز و چند ترکیب که وضعیت متفاوت دارند. همه نام‌ها، قیمت‌ها و موجودی‌های نمونه ساختگی و آموزشی‌اند. هدف، یادگیری مدل اطلاعات است؛ این جدول‌ها تصویر پنل یکتابات نیستند و وجود منو یا قابلیت خاصی را در آن فرض نمی‌کنند.
سه مفهوم را روی سه برگه جدا بنویسید
برگه اول «محصول مادر» است: هویتی که چند نسخه مشترک را کنار هم نگه می‌دارد. در مثال ما نام آن «پیراهن آستین‌بلند آبان» است. توضیح مدل، نوع یقه و ویژگی‌های مشترک روی این برگه قرار می‌گیرند. مشتری ممکن است ابتدا با نام آبان آشنا شود، اما انبار نمی‌تواند صرفاً یک «آبان» بسته‌بندی کند؛ باید نسخه دقیق آن انتخاب شده باشد.
برگه دوم «ویژگی انتخابی» است. رنگ و سایز در این مثال دو ویژگی‌اند. سفید، سرمه‌ای و زرشکی مقدارهای ویژگی رنگ هستند؛ S، M و L مقدارهای ویژگی سایز. خود واژه «رنگ» یک کالا نیست و «سرمه‌ای» هم به‌تنهایی واحد قابل خرید را تعیین نمی‌کند. برای انتخاب نسخه نهایی باید همه ویژگی‌هایی که آن نسخه را از بقیه جدا می‌کنند مشخص شوند.
برگه سوم «تنوع قابل شناسایی» است: مثلاً آبان سرمه‌ای سایز M. این نسخه می‌تواند شناسه، قیمت، عکس و وضعیت عرضه مشخص داشته باشد. تفکیک گروه محصول از نسخه‌های آن در مستندات گروه‌بندی تنوع‌های محصول گوگل هم دیده می‌شود: نسخه‌ها شناسه مستقل دارند و با شناسه گروه مشترک مرتبط می‌شوند. این منبع را برای مفهوم گروه‌بندی می‌خوانیم، نه به‌عنوان اثبات اتصال یکتابات به سرویس‌های گوگل.
یک سؤال ساده مرزها را روشن می‌کند: «آیا بدون دانستن این مقدار می‌توان کالای درست را برداشت و تحویل داد؟». اگر پاسخ منفی است، احتمالاً با ویژگی انتخابی مهمی روبه‌رو هستید. در پیراهن، رنگ و سایز چنین‌اند. عبارت «مناسب استفاده روزمره» معمولاً توضیح مشترک است، نه گزینه‌ای که برایش موجودی جدا تعریف کنیم. اضافه‌کردن همه صفت‌ها به فهرست انتخاب، تصمیم مشتری را پیچیده می‌کند.
کارت مادر: چه چیزهایی برای همه نسخه‌ها مشترک است؟
برای کارگاه فرضی، شناسه گروه را AB24 می‌گذاریم. نام عمومی «پیراهن آستین‌بلند آبان» است؛ همه نسخه‌های این گروه یقه معمولی، جلوی دکمه‌دار و برش یکسان دارند. درباره جنس، فقط اطلاعات واقعی و تأییدشده محصول خودتان را وارد کنید. در این نمونه، ترکیب درصدی پارچه یا ادعای عملکردی تعریف نمی‌کنیم، چون برای فهم مدل تنوع لازم نیست.
ویژگی‌هایی که در همه نسخه‌ها یکسان‌اند، یک بار در توضیح مادر ثبت می‌شوند. اطلاعات متفاوت روی ردیف نسخه می‌آیند. اگر بعضی رنگ‌ها نوع آستر، جنس یا دوخت دیگری دارند، نباید توضیح مشترک آن تفاوت را پنهان کند. ابتدا بررسی کنید هنوز با نسخه‌های یک مدل روبه‌رو هستید یا دو محصول واقعاً متفاوت را به‌زور زیر یک نام جمع کرده‌اید.
مدل جدیدی که طول، برش و کاربرد متفاوت دارد لزوماً یک «رنگ دیگر» از مدل قبلی نیست. برای مثال فرضی، پیراهن کوتاه‌آستین با الگوی متفاوت را با اضافه‌کردن مقدار «تابستانی» به رنگ‌های آبان وارد نکنید. چنین تصمیمی هم نام ویژگی را بی‌معنا می‌کند و هم عکس و توضیح را ناسازگار می‌سازد. گروه‌بندی باید شباهت واقعی محصول را بازتاب دهد، نه فقط تمایل به کوتاه‌کردن فهرست فروشگاه.
ماتریس امکان: از نه ترکیب احتمالی به هفت نسخه واقعی
سه رنگ و سه سایز، از نظر ترکیبی نه حالت می‌سازند. اما در کاتالوگ فرضی ما، زرشکی فقط در سایز M تولید شده است. بنابراین زرشکی S و زرشکی L کالای تعریف‌شده ندارند. از هفت نسخه واقعی باقی‌مانده، سرمه‌ای L فعلاً موجودی قابل فروش ندارد. در نتیجه شش نسخه قابل خرید داریم، نه نه نسخه و نه هفت نسخه آماده فروش.
| رنگ | سایز | وضعیت ترکیب |
|---|---|---|
| سفید | S | تعریف‌شده و قابل خرید |
| سفید | M | تعریف‌شده و قابل خرید |
| سفید | L | تعریف‌شده و قابل خرید |
| سرمه‌ای | S | تعریف‌شده و قابل خرید |
| سرمه‌ای | M | تعریف‌شده و قابل خرید |
| سرمه‌ای | L | تعریف‌شده؛ فعلاً ناموجود |
| زرشکی | S | در این مدل تولید نشده |
| زرشکی | M | تعریف‌شده و قابل خرید |
| زرشکی | L | در این مدل تولید نشده |
این جدول پیش از ورود داده به هر ابزار تهیه می‌شود. اگر نرم‌افزاری از روی همه مقدارها ترکیب تولید می‌کند، خروجی را با واقعیت تطبیق دهید؛ تولید یک ردیف، محصول فیزیکی ایجاد نمی‌کند. ترکیب‌های ساختگی نباید صرفاً چون در جدول ظاهر شده‌اند قابل سفارش باشند. شکل جلوگیری از انتخاب آن‌ها به امکانات واقعی ابزار شما بستگی دارد و باید در مسیر مشتری بررسی شود.
تفاوت «تولید نشده» و «فعلاً ناموجود» برای پاسخ‌گویی مهم است. در اولی، وعده بازگشت موجودی بی‌معناست مگر اینکه تصمیم تازه‌ای برای عرضه گرفته شود. در دومی، نسخه وجود دارد ولی الان قابل تحویل نیست. اگر زمان تأمین معلوم نیست، همان نامعلوم‌بودن را بیان کنید. تبدیل هر دو وضعیت به دکمه‌ای با عنوان «به‌زودی» تعهدی می‌سازد که ممکن است مبنایی نداشته باشد.
شناسه نسخه را از نام قابل نمایش جدا نگه دارید
برای هر نسخه واقعی، یک شناسه داخلی یا SKU می‌سازیم. در الگوی پیشنهادی این مقاله، AB24 بخش مدل، WH نشانه سفید، NV نشانه سرمه‌ای و BR نشانه زرشکی است. بخش آخر سایز را نشان می‌دهد. بنابراین AB24-NV-M فقط به پیراهن آبان سرمه‌ای سایز M اشاره می‌کند. این قرارداد داخلی نمونه است؛ استاندارد اجباری نام‌گذاری برای همه فروشگاه‌ها نیست.
در راهنمای رسمی Shopify برای SKU نیز بر یکتابودن شناسه نسخه‌ها و ثابت‌ماندن معنای اختصارها تأکید شده است. این اصل برای برگه کاتالوگ ما کاربرد دارد، اما محدودیت فنی یک سامانه را نباید به همه ابزارها تعمیم داد. قالب مجاز شناسه، طول و نحوه جست‌وجوی آن را در محیط واقعی خودتان بررسی کنید.
شناسه را طوری نسازید که قیمت یا تعداد موجودی درون آن باشد. قیمت تغییر می‌کند و موجودی هم کم و زیاد می‌شود؛ هویت نسخه نباید با هر فروش عوض شود. همین‌طور نام تأمین‌کننده‌ای که احتمال تغییر دارد، لزوماً جزء مناسبی برای شناسه نیست. در دفتر داخلی می‌توانید فیلد تأمین‌کننده داشته باشید، بدون اینکه هر بار تغییر همکاری به تعویض همه کدها منجر شود.
نام قابل نمایش برای مشتری همچنان فارسی و روشن است: «پیراهن آبان، سرمه‌ای، سایز M». مجبورکردن مشتری به حفظ‌کردن کد، جای طراحی انتخاب روشن را نمی‌گیرد. کد در پشت صحنه رابطه میان ردیف کاتالوگ، عکس و بسته را حفظ می‌کند. اگر قرار است در پیام تأیید هم دیده شود، کنار نام خوانا بیاید، نه به‌جای آن.
کد معرفی محصول در یک مسیر بازاریابی هم الزاماً همان SKU نیست. مقاله آشنایی با کد یکتا درباره شروع معرفی محصول از طریق کد توضیح می‌دهد. در این کارگاه، دغدغه ما یک مرحله دقیق‌تر است: پس از معرفی مدل، کدام رنگ و اندازه انتخاب شده است؟ حتی اگر یک کد عمومی چند نسخه را معرفی کند، سفارش نهایی باید نسخه انتخاب‌شده را بدون ابهام ثبت کند.
کاتالوگ کوچک کامل: هفت ردیف واقعی
اکنون ردیف‌های واقعی گروه AB24 را می‌نویسیم. قیمت‌ها در این جدول فرضی‌اند و برای تمرین اختلاف قیمت میان نسخه‌ها انتخاب شده‌اند. سه سایز سفید هرکدام ۶۹۰ هزار تومان و نسخه‌های سرمه‌ای و زرشکی هرکدام ۷۲۰ هزار تومان قیمت دارند. قیمت‌داشتن سرمه‌ای L به معنی قابل خرید بودن آن نیست؛ وضعیت عرضه را در جدول بعد جداگانه مشخص می‌کنیم.
| شناسه نسخه | انتخاب دقیق | قیمت هر عدد |
|---|---|---|
| AB24-WH-S | سفید، سایز S | ۶۹۰٬۰۰۰ تومان |
| AB24-WH-M | سفید، سایز M | ۶۹۰٬۰۰۰ تومان |
| AB24-WH-L | سفید، سایز L | ۶۹۰٬۰۰۰ تومان |
| AB24-NV-S | سرمه‌ای، سایز S | ۷۲۰٬۰۰۰ تومان |
| AB24-NV-M | سرمه‌ای، سایز M | ۷۲۰٬۰۰۰ تومان |
| AB24-NV-L | سرمه‌ای، سایز L | ۷۲۰٬۰۰۰ تومان؛ غیرقابل سفارش فعلی |
| AB24-BR-M | زرشکی، سایز M | ۷۲۰٬۰۰۰ تومان |
دو ترکیب تولیدنشده را در این جدول به‌عنوان کالای قابل فروش وارد نکرده‌ایم. آن‌ها در ماتریس امکان ثبت شدند تا محدودیت مدل معلوم باشد. این جداسازی کمک می‌کند فهرست نسخه‌های واقعی با فهرست تمام حالت‌های قابل تصور اشتباه نشود. اگر بعداً زرشکی L واقعاً عرضه شد، ردیف تازه‌ای با اطلاعات کامل می‌سازیم؛ قبل از آن، تنها وجود نام L مجوز فروش آن رنگ نیست.
برای توضیح مشترک هر ردیف لازم نیست نام مدل را با چند شکل متفاوت تکرار کنید. نام گروه در کارت مادر است و نام کامل مشتری از گروه، رنگ و سایز ساخته می‌شود. در عین حال، هنگام خروجی‌گرفتن برای بسته‌بندی، نام کامل را همراه شناسه نگه دارید. کسی که فقط جدول ارسال را می‌بیند نباید برای فهمیدن AB24 مجبور به بازکردن چند فایل دیگر شود.
موجودی را در همان سطحی ثبت کنید که انتخاب می‌شود
| شناسه نسخه | تعداد قابل فروش | وضعیت عرضه |
|---|---|---|
| AB24-WH-S | ۲ عدد | قابل خرید |
| AB24-WH-M | ۴ عدد | قابل خرید |
| AB24-WH-L | ۱ عدد | قابل خرید |
| AB24-NV-S | ۳ عدد | قابل خرید |
| AB24-NV-M | ۲ عدد | قابل خرید |
| AB24-NV-L | ۰ عدد | فعلاً ناموجود |
| AB24-BR-M | ۱ عدد | قابل خرید |
جمع تعدادها ۱۳ عدد است، اما این عدد به مشتری سرمه‌ای L کمکی نمی‌کند. درخواستی که دقیقاً به آن نسخه مربوط است، با موجودی سفید یا سرمه‌ای M پاسخ داده نمی‌شود. همچنین «یک مدل موجود» و «شش تنوع قابل خرید» و «سیزده عدد کالا» سه گزارش متفاوت‌اند. در فایل و گزارش خود، نام هر عدد را بنویسید تا تعداد مدل با تعداد واحد فیزیکی اشتباه نشود.
این جدول روش همگام‌سازی موجودی بین کانال‌ها را تعریف نمی‌کند. اگر اطلاعات را دستی نگه می‌دارید، زمان بازبینی و مسئول اصلاح آن باید معلوم باشد. اگر ابزار دیگری موجودی را مدیریت می‌کند، رفتار واقعی آن را بررسی کنید. یک فایل منظم به‌تنهایی تضمین نمی‌کند که فروش هم‌زمان دو نفر به یک نسخه بدون تعارض انجام شود؛ آن مسئله به فرایند ثبت و تأیید سفارش هم مربوط است.
نام رنگ و سایز را یک‌دست کنید، اما تفاوت واقعی را حذف نکنید
برای همین نمونه، «سرمه‌ای» را مقدار رسمی انتخاب می‌کنیم. اگر در فایل قدیمی «نفتی»، «آبی تیره» و «سرمه‌ای» دیده می‌شود، پیش از یکی‌کردن نام‌ها خود کالاها را بررسی کنید. شاید سه نام برای یک رنگ باشند و شاید سه رنگ متفاوت. یکسان‌سازی داده نباید با حدس انجام شود. نام‌هایی که واقعاً مترادف‌اند می‌توانند در یادداشت داخلی ثبت شوند، ولی مقدار اصلی باید ثابت بماند.
برای سایز هم یک نوشتار مشخص داشته باشید. اگر برچسب کالا M است، در یک محل «مدیوم»، در جای دیگر «متوسط» و در سفارش فقط «۲» ننویسید، مگر اینکه نگاشت روشنی تعریف کرده باشید. مشتری می‌تواند نام آشنای خودش را به کار ببرد، اما پاسخ فروشگاه باید انتخاب نهایی را با همان نام ثبت‌شده برگرداند. این کار به‌ویژه هنگام انتقال سفارش از گفت‌وگو به بسته‌بندی اهمیت دارد.
یکسان‌بودن برچسب سایز در دو مدل، تضمین یکسان‌بودن اندازه نیست. راهنمای اندازه‌گیری و مشخصات تناسب باید به مدل مربوط باشد. موضوع این مقاله ساخت جدول سایزبندی نیست؛ نکته داده‌ای آن این است که شناسه آبان M را با مدل دیگری که آن هم M دارد ادغام نکنید. گروه محصول بخشی از هویت نسخه است و حذف آن، معنای سایز را ناقص می‌کند.
برای عکس‌ها هم آدرس دقیق در کاتالوگ داشته باشید
هر ردیف باید معلوم کند کدام تصویر به همان نسخه تعلق دارد. برای مثال فرضی، نام فایل نمای اصلی سرمه‌ای M را AB24-NV-M-front.jpg می‌گذاریم. نمای پشت با پسوند back و نمای جزئیات با detail مشخص می‌شود. این نام‌ها فایل واقعی ضمیمه مقاله نیستند؛ قرارداد پیشنهادی برای پوشه عکس‌های فروشگاه‌اند. برای هفت ردیف واقعی می‌توان همین الگو را به‌صورت یکسان اجرا کرد.
پیش از استفاده مشترک از یک تصویر، بررسی کنید چه تفاوتی را باید نشان دهد. عکس سفید نمی‌تواند تصویر انتخاب سرمه‌ای باشد. اگر عکس یک سایز نماینده شکل مدل است، توضیح آن نباید این تصور را بسازد که همه اندازه‌ها دقیقاً همان نسبت را دارند. برای تفاوتی مثل جیب، طول یا طرح، تصویر اختصاصی اهمیت بیشتری پیدا می‌کند. معیار، اطلاعاتی است که مشتری از عکس برداشت می‌کند، نه صرفاً تعداد فایل‌ها.
برای کاتالوگ نمونه، هر رنگ حداقل نمای واقعی خودش را دارد و هر نسخه به تصویر مناسبش ارجاع می‌دهد. اگر تصویر یک نسخه هنوز آماده نیست، وضعیت نقص تصویر را داخل فهرست کار نگه دارید. عکس نسخه دیگر را صرفاً برای پُرکردن خانه خالی جایگزین نکنید. فهرست ناقصِ صادقانه برای اصلاح، از کاتالوگ ظاهراً کامل با تصویر اشتباه قابل اتکاتر است.
نام عکس، شناسه نسخه و رنگ نمایش‌داده‌شده را با هم کنترل کنید. ممکن است فایل با نام درست ذخیره شده باشد اما تصویر داخل آن اشتباه باشد. بازکردن تصویر و دیدن خود محصول ضروری است. همچنین پس از تعویض عکس، نسخه‌ای را که مشتری واقعاً می‌بیند بررسی کنید؛ انتخاب فایل درست در پوشه لزوماً به معنی نمایش درست در تمام محل‌های استفاده نیست.
انتخاب مشتری را از یک مسیر واقعی عبور دهید
فرض کنیم مشتری ابتدا رنگ سرمه‌ای را انتخاب می‌کند. در آن لحظه باید بتواند بفهمد S و M قابل خریدند و L فعلاً نیست. اگر ابزار انتخاب وابسته را پشتیبانی کند، می‌توان از آن برای نمایش وضعیت درست استفاده کرد؛ اگر نه، متن و تأیید انسانی باید همان تمایز را روشن کنند. در هر حالت، نباید مشتری تا آخر پرداخت پیش برود و تازه آنجا متوجه شود ترکیب دلخواهش قابل تحویل نیست.
حالا مسیر را برعکس کنید: مشتری ابتدا L را می‌خواهد. در مثال ما فقط سفید L قابل خرید است؛ سرمه‌ای L ناموجود و زرشکی L اصلاً تولیدنشده است. پاسخ «این مدل سه رنگ دارد» برای این درخواست کافی نیست. پاسخ دقیق می‌گوید کدام رنگ در همان سایز قابل انتخاب است. به این ترتیب فهرست کلی رنگ‌های مدل با گزینه‌های معتبر انتخاب فعلی اشتباه نمی‌شود.
اگر مشتری بعد از انتخاب سرمه‌ای M به زرشکی تغییر نظر داد، انتخاب جدید باید دوباره کامل شود. در مثال حاضر زرشکی M معتبر است، ولی در محصول دیگری ممکن است نباشد. حفظ خودکار انتخاب قبلی بدون بررسی اعتبار ترکیب می‌تواند سفارش غلط بسازد. این یکی از رفتارهایی است که باید در ابزار واقعی آزموده شود؛ نمی‌توان از ظاهر مرتب چند گزینه نتیجه گرفت که همه حالت‌های تغییر انتخاب درست مدیریت می‌شوند.
قیمت هم باید همراه همان انتخاب خوانا بماند. نمایش «از ۶۹۰ هزار تومان» برای مدل، جای نشان‌دادن مبلغ سرمه‌ای M یعنی ۷۲۰ هزار تومان را نمی‌گیرد. بعد از انتخاب نسخه، مبلغ همان نسخه باید در خلاصه سفارش مشخص باشد. اگر تغییری در قیمت رخ داده، پیش از پرداخت آن را روشن کنید؛ نام مدل مشترک به معنی قیمت یکسان همه نسخه‌ها نیست.
از انتخاب به سفارش: یک ردیف باید قابل بسته‌بندی باشد
سفارش فرضی ما دو عدد آبان سفید M و یک عدد آبان سرمه‌ای M است. ردیف اول با شناسه AB24-WH-M، تعداد دو و قیمت واحد ۶۹۰ هزار تومان ثبت می‌شود؛ مبلغ ردیف یک میلیون و ۳۸۰ هزار تومان است. ردیف دوم با شناسه AB24-NV-M، تعداد یک و قیمت واحد ۷۲۰ هزار تومان ثبت می‌شود. جمع کالاها دو میلیون و ۱۰۰ هزار تومان خواهد بود.
اگر ارسال فرضی این سفارش ۸۰ هزار تومان باشد و هزینه دیگری تعریف نشده باشد، مبلغ کل دو میلیون و ۱۸۰ هزار تومان است. این جمع سه عدد پیراهن را پوشش می‌دهد، ولی دو ردیف انتخاب متفاوت دارد. ادغام آن‌ها در یک ردیف با عنوان «آبان، تعداد سه» جزئیات بسته‌بندی را از بین می‌برد، حتی اگر مبلغ نهایی درست باقی بماند.
خلاصه پیشنهادی برای تأیید همین سفارش فرضی: «۲ عدد پیراهن آبان سفید سایز M، هر عدد ۶۹۰٬۰۰۰ تومان؛ ۱ عدد آبان سرمه‌ای سایز M به قیمت ۷۲۰٬۰۰۰ تومان. جمع کالاها ۲٬۱۰۰٬۰۰۰ تومان و ارسال ۸۰٬۰۰۰ تومان است. مبلغ نهایی ۲٬۱۸۰٬۰۰۰ تومان. لطفاً رنگ، سایز و تعداد هر ردیف را بررسی کنید.»
برای برگه بسته‌بندی، علاوه بر این متن خوانا، شناسه هر نسخه را نگه دارید. فرد آماده‌کننده باید بتواند برچسب کالا، رنگ واقعی و سایز را با ردیف سفارش تطبیق دهد. اگر فقط شناسه را ببیند، اشتباه احتمالی برچسب کشف نمی‌شود؛ اگر فقط نام را ببیند، نام‌های مشابه مشکل‌ساز می‌شوند. این دو اطلاعات مکمل یکدیگرند.
فرض کنیم مشتری یکی از دو پیراهن سفید M را به سفید L تغییر دهد. نسخه تازه باید در یک ردیف مستقل ثبت شود و تعداد سفید M به یک کاهش پیدا کند. قیمت این دو در مثال برابر است، اما برابرماندن مبلغ به معنی بی‌اهمیت‌بودن تغییر نیست. برگه آماده‌سازی قبلی دیگر معتبر نیست و باید مشخص باشد کدام نسخه سفارش آخرین تأیید را دارد.
چه چیزی تنوع نیست؟ متن هدیه، انتخاب تصادفی و بسته ترکیبی
متن کوتاه کارت هدیه معمولاً ویژگی نسخه فیزیکی پیراهن نیست. اگر برای هر متن دلخواه یک SKU بسازید، تعداد ردیف‌ها بی‌دلیل زیاد می‌شود. می‌توان این اطلاعات را، با توجه به امکانات واقعی ابزار، در مشخصات همان سفارش نگه داشت. اگر شخصی‌سازی خود کالا را تغییر می‌دهد، باید شرایط آماده‌سازی و تأیید آن جداگانه روشن باشد؛ این موضوع را در یک گزینه مبهم به نام «سایر» پنهان نکنید.
«رنگ تصادفی» هم نباید راهی برای پُرکردن اطلاعات ناقص سفارش باشد. اگر واقعاً محصولی با انتخاب تصادفی عرضه می‌کنید، مشتری باید از ابتدا این ماهیت را بداند. در سفارش معمول رنگ و سایز، نبود انتخاب به معنی اجازه انتخاب فروشنده نیست. مقدار پیش‌فرضی که مشتری آن را ندیده نیز نباید بدون تأیید جای خواسته او بنشیند.
بسته‌ای شامل دو پیراهن ممکن است یک پیشنهاد فروش جداگانه باشد، اما اجزای آن همچنان باید مشخص باشند. «پک آبان» بدون تعیین رنگ و سایز هر جزء قابل بسته‌بندی دقیق نیست. در این مقاله روش محاسبه موجودی اجزای پک را طراحی نمی‌کنیم؛ فقط توجه می‌کنیم که نام یک بسته ترکیبی، نیاز به شناسایی نسخه‌های داخل آن را حذف نمی‌کند.
کاتالوگ قبلی را بدون گم‌کردن سابقه مرتب کنید
اگر اکنون اطلاعات پراکنده دارید، همه محصول‌ها را یک‌باره تغییر ندهید. یک خانواده کوچک را انتخاب کنید و نسخه‌ای از اطلاعات فعلی برای مراجعه نگه دارید. نام‌ها، شناسه‌ها، عکس‌ها و سفارش‌های مرتبط را کنار هم ببینید. سپس ردیف‌های تکراری واقعی را از ردیف‌هایی که فقط نام مشابه دارند جدا کنید. شباهت نوشتاری به‌تنهایی دلیل ادغام دو کالا نیست.
یک جدول نگاشت داخلی بسازید: شناسه قدیمی، شناسه نهایی و دلیل تغییر. این جدول قرار نیست برای مشتری منتشر شود؛ کمک می‌کند کدی که در سفارش قبلی یا برچسب قدیمی آمده هنوز قابل فهم باشد. برای نسخه‌ای که فروش آن متوقف شده، نگه‌داشتن سابقه معمولاً از استفاده دوباره همان شناسه برای محصول دیگر روشن‌تر است. کد قدیمی نباید معنای تازه‌ای پیدا کند که سفارش گذشته را مبهم کند.
در ادغام ردیف‌های یک نسخه، قیمت‌های واحد را جمع نزنید؛ نرخ معتبر باید جدا تعیین شود. جمع‌زدن موجودی نیز فقط وقتی درست است که ردیف‌ها واحدهای فیزیکی مجزا را نشان دهند. شاید دو ردیف، ثبت تکراری همان سه پیراهن باشند؛ در این حالت موجودی سه است، نه شش. اگر دو محموله مستقلِ سه‌تایی باشند، جمع شش درست است. تشخیص به کالای واقعی و سوابق نیاز دارد، نه فقط مرتب‌سازی فایل.
پس از اصلاح نمونه کوچک، یک نفر دیگر انتخاب مشتری را امتحان کند و یک نفر بسته فرضی را از روی خلاصه آماده کند. اگر هر دو به یک نسخه رسیدند، الگو برای ادامه مناسب‌تر است. اگر هنوز برای تشخیص رنگ یا سایز سؤال لازم شد، قبل از گسترش کاتالوگ همان ابهام را برطرف کنید. این آزمون درباره وضوح داده است و ادعای مطالعه واقعی روی کاربران یا نتیجه آماری ندارد.
بعد از اولین فروش، هویت نسخه را ثابت نگه دارید
فرض کنیم قیمت سفید M در آینده تغییر کند. شناسه AB24-WH-M همچنان به همان نسخه اشاره می‌کند، اما سفارش قبلی باید قیمت زمان تأیید خودش را حفظ کند. برای همین، در سوابق سفارش نام نسخه، رنگ، سایز، تعداد و مبلغ تأییدشده را نگه دارید. مراجعه صرف به کاتالوگ امروز برای بازسازی سفارش دیروز ممکن است عدد اشتباه بدهد. این پیشنهادِ طراحی سوابق است، نه ادعای وجود ثبت تاریخچه خودکار در هر سامانه.
اگر فقط اشتباه املایی نام را اصلاح می‌کنید، لزوماً محصول تازه‌ای ساخته نشده است. اما اگر آبان سرمه‌ای با برش متفاوتی جایگزین شده، باید درباره هویت نسخه تصمیم دوباره بگیرید. مشتری تکراری ممکن است بر اساس خرید قبل همان کد را درخواست کند. استفاده بی‌توضیح از شناسه قدیمی برای کالایی با ویژگی متفاوت، رابطه میان سابقه خرید و سفارش جدید را مخدوش می‌کند.
برای تغییرات مهم، یک یادداشت کوتاه با تاریخ، موضوع تغییر و ردیف‌های درگیر داشته باشید. لازم نیست هر اصلاح نشانه‌گذاری به گزارش مفصل تبدیل شود. مواردی مثل تغییر تعریف رنگ، جایگزینی عکس مدل تازه یا توقف دائمی یک سایز اهمیت بیشتری دارند. با این یادداشت می‌توان فهمید چرا تصویر سفارش قدیمی با ویترین امروز متفاوت است، بدون اینکه اطلاعات قبلی پاک یا بازنویسی شود.
هنگام توقف عرضه، تکلیف نمایش و سابقه را جدا کنید. شاید نسخه دیگر نباید قابل خرید باشد، ولی برای رسیدگی به سفارش گذشته هنوز به هویت آن نیاز دارید. حذف یا بایگانی را با توجه به رفتار واقعی ابزار انتخاب کنید و پیش از اقدام، اثر آن بر سوابق را بررسی کنید. هیچ نام وضعیت عمومی، به‌تنهایی تضمین نمی‌کند اطلاعات سفارش‌های قبلی حفظ می‌شود.
قبل از استفاده در یکتابات، این مرز را روشن نگه دارید
معرفی رسمی فروشگاه ساز یکتابات از معرفی محصولات و ویژگی‌ها، ثبت اطلاعات سفارش و بررسی رسید توسط مدیر در مسیر فروش اینستاگرام، تلگرام و پیام‌رسان بله صحبت می‌کند. کاتالوگ این مقاله ورودی منظم برای فکرکردن به چنین مسیری است. از آن نباید وجود ساختار خاص SKU، انتخاب وابسته رنگ و سایز یا همگام‌سازی موجودی را در یکتابات نتیجه گرفت.
نیاز خود را با مثال هفت‌ردیفی مطرح کنید: چگونه نسخه دقیق در معرفی و سفارش مشخص می‌شود؟ ترکیب تولیدنشده چطور از انتخاب خارج می‌شود؟ آیا قیمت متفاوت هر نسخه قابل نمایش است؟ اگر تصویر یا وضعیت تغییر کند، مشتری در مسیر واقعی چه می‌بیند؟ پاسخ را در نسخه و پلن مورد استفاده بررسی کنید و فقط رفتاری را مبنای کار قرار دهید که واقعاً تأیید شده است.
اگر ابزار همه این تمایزها را به شکل دلخواه شما نمایش نمی‌دهد، باید شیوه معرفی یا تأیید سفارش را متناسب کنید. ممکن است به عرضه‌های جداگانه با نام روشن یا مرحله بررسی انسانی نیاز باشد. هدف این نیست که داده خوب را در هر شکلی جا بدهیم؛ هدف این است که مشتری بتواند انتخاب معتبر انجام دهد و همان انتخاب تا بسته‌بندی حفظ شود.
آزمون پایان کارگاه: کاتالوگ به این شش درخواست چه می‌گوید؟
- «سرمه‌ای L می‌خواهم»: نسخه شناخته می‌شود، اما فعلاً قابل خرید نیست؛ سفید L بدون رضایت مشتری جایگزین نمی‌شود.
- «زرشکی S دارید؟»: پاسخ روشن می‌کند این ترکیب در مدل تعریف نشده است، نه اینکه زمان تأمین نامشخصی وعده بدهد.
- «دو سفید M و یک سرمه‌ای M»: دو ردیف مستقل با سه واحد کالا و جمع فرضی درست ساخته می‌شود.
- «رنگ را عوض کردم»: اعتبار ترکیب، عکس و قیمت دوباره بررسی می‌شود؛ انتخاب قبلی بی‌دلیل باقی نمی‌ماند.
- «همان مدل سفارش قبلی»: شناسه قبلی هنوز به همان محصول و نسخه اشاره می‌کند، حتی اگر عرضه آن متوقف شده باشد.
- «این عکس مال کدام است؟»: تصویر به ردیف مشخص وصل است و رنگ یا جزئیات نسخه دیگری را به‌جای آن نشان نمی‌دهد.
پاسخ درست به این درخواست‌ها نشان می‌دهد کاتالوگ شما فقط فهرستی از نام‌ها نیست؛ انتخاب‌های واقعی و محدودیت‌هایشان در آن ثبت شده‌اند. محصول مادر معرفی را منظم می‌کند، شناسه نسخه ابهام پشت صحنه را کم می‌کند و نام خوانا انتخاب مشتری را قابل بررسی نگه می‌دارد. نقطه پایان، زیادشدن تعداد گزینه‌ها نیست؛ روشن‌بودن همان گزینه‌هایی است که واقعاً می‌توانید تحویل دهید.
دیدگاهتان را بنویسید