اطلاع‌رسانی موجودشدن کالا زمانی مفید است که مشتری را برای همان محصول قابل‌خریدی که درخواست کرده، در زمان مناسب به فروشگاه برگرداند. گذاشتن یک دکمه «خبرم کن» به‌تنهایی کافی نیست: باید گونه انتخابی کالا، موجودی قابل‌فروش، اجازه دریافت پیام و وضعیت ارسال به هم متصل باشند. در غیر این صورت ممکن است مشتری برای اندازه اشتباه پیام بگیرد یا پس از کلیک دوباره با ناموجودی روبه‌رو شود.
این راهنما برای صاحبان فروشگاه اینترنتی و مدیران محصول است که می‌خواهند قابلیت خبرم کن را به‌صورت قابل‌آزمایش سفارش دهند. تمرکز مقاله بر تجربه کالای موقتاً ناموجود و منطق ارسال اعلان است؛ نه پیش‌بینی تقاضا، خرید انبار یا یک کمپین تبلیغاتی عمومی. هدف، وعده فروش بیشتر با عدد ساختگی نیست؛ ساخت مسیری است که علاقه مشتری را ثبت کند و هنگام بازگشت واقعی موجودی، اطلاعات درست بدهد.
اول روشن کنید ناموجودی چه معنایی دارد
کالایی که موقتاً تمام شده با محصولی که تولیدش متوقف شده یکسان نیست. برای حالت اول می‌توان درخواست اطلاع‌رسانی گرفت، اما برای حالت دوم ادامه جمع‌آوری درخواست بدون برنامه تأمین، انتظار بی‌نتیجه ایجاد می‌کند. همچنین پیش‌فروش و سفارش با تأخیر، مدل‌های متفاوتی هستند: اگر مشتری می‌تواند اکنون سفارش قطعی ثبت کند، شرایط آن باید جداگانه توضیح داده شود.
در صفحه محصول، وضعیت واقعی را نزدیک بخش خرید نمایش دهید. اگر زمان تأمین معلوم نیست، همان را صریح بنویسید؛ عبارت «به‌زودی» نباید جای داده معتبر را بگیرد. یک توضیح کوتاه مانند «فعلاً موجود نیست؛ در صورت موجودشدن همین اندازه اطلاع می‌دهیم» توقع روشن‌تری از یک دکمه بی‌توضیح می‌سازد. ثبت درخواست هم نباید به‌اشتباه رزرو کالا یا تضمین قیمت تلقی شود.
خبرم کن بخشی از مسیر خرید است و باید با انتخاب گونه، قیمت و شرایط محصول هماهنگ باشد. اگر ساختار صفحه هنوز مبهم است، ابتدا راهنمای طراحی صفحه محصول فروشگاهی را مبنای اصلاح قرار دهید. افزودن اعلان به صفحه‌ای که مشتری در آن رنگ انتخاب‌شده را نمی‌فهمد، مشکل اصلی را حل نمی‌کند.
درخواست باید به گونه مشخص کالا متصل باشد
رنگ و اندازه را در لحظه ثبت نشان دهید
فرض کنید یک کفش مشکی در اندازه ۴۲ ناموجود است، اما اندازه ۴۱ موجود است. ثبت درخواست برای شناسه کلی کفش کافی نیست؛ باید شناسه همان ترکیب رنگ و اندازه ذخیره شود. پیش از تأیید، نام محصول و مشخصات انتخابی را دوباره نشان دهید تا مشتری بتواند اشتباه را اصلاح کند.
اگر کاربر بعد از بازشدن فرم، گونه را تغییر داد، فرم نباید انتخاب قبلی را پنهانی ثبت کند. می‌توانید فرم را با انتخاب تازه همگام کنید یا از کاربر بخواهید انتخاب را تأیید کند. مهم این است که آنچه دیده می‌شود و آنچه در سامانه ثبت می‌شود یکسان باشد. همین قاعده برای ظرفیت حافظه، بسته‌بندی، جنس و سایر ویژگی‌های تعیین‌کننده موجودی صدق می‌کند.
تغییرات کاتالوگ را فراموش نکنید
ممکن است مدیر فروشگاه یک گونه را حذف یا با شناسه جدید جایگزین کند. انتقال خودکار همه متقاضیان به محصول مشابه تصمیم بی‌خطری نیست. درخواست قدیمی باید یا با نگاشت تأییدشده ادامه پیدا کند یا بسته شود؛ مشتری نباید برای کالای دیگری پیام «محصول شما موجود شد» بگیرد. پیشنهاد جایگزین را با عنوان خودش ارائه کنید، نه در پوشش موجودشدن انتخاب قبلی.
فرم کوتاه باشد، اما هدف آن مبهم نباشد
برای یک اعلان مشخص، معمولاً یک راه تماس انتخابی کافی است. دریافت اجباری نام کامل، نشانی و اطلاعات اضافی پیش از ارسال خبر موجودی، اصطکاک و حجم داده نگهداری‌شده را افزایش می‌دهد. فرم باید برچسب واضح، راهنمای قالب شماره یا ایمیل و پیام خطای قابل‌فهم داشته باشد؛ تکیه بر رنگ قرمز به‌تنهایی کافی نیست.
هدف استفاده از راه تماس را کنار فرم توضیح دهید. درخواست خبر موجودی را به عضویت پنهان در همه پیام‌های بازاریابی تبدیل نکنید. این یک توصیه طراحی مبتنی بر شفافیت و کاهش داده است؛ الزامات حقوقی و مقررات کانال پیام‌رسان باید جداگانه برای بازار هدف بررسی شوند. همچنین کنترل سوءاستفاده لازم است تا کسی نتواند شماره دیگران را مرتب وارد کند و برایشان پیام ناخواسته بسازد.
پس از ثبت موفق، تأیید مشخص نشان دهید: چه کالایی، چه گونه‌ای و از چه کانالی پیگیری خواهد شد. راه لغو یا مدیریت درخواست را در نظر بگیرید. اگر همان کاربر دوباره برای همان گونه ثبت کرد، بهتر است وضعیت موجود را به او نشان دهید، نه اینکه چند درخواست فعال و چند پیام آینده ایجاد شود.
موجودی انبار با موجودی قابل‌فروش برابر نیست
ورود یک عدد مثبت به انبار الزاماً به معنی امکان خرید نیست. بخشی از کالا ممکن است رزرو سفارش‌های قبلی، قرنطینه کنترل کیفیت یا مخصوص شعبه‌ای باشد که ارسال اینترنتی ندارد. رویداد مناسب برای اعلان، تغییر وضعیت به «قابل‌فروش در کانال مربوط» است؛ این تعریف باید با تیم انبار و سفارش توافق شود.
بهتر است منبع تصمیم موجودی معلوم باشد. اگر پنل فروشگاه، نرم‌افزار انبار و بازارگاه هر کدام عددی متفاوت دارند، سامانه اعلان نباید ساده‌ترین عدد در دسترس را حقیقت نهایی فرض کند. زمان آخرین همگام‌سازی و وضعیت خطای اتصال هم اهمیت دارند. هنگام نامطمئن‌بودن داده، توقف ارسال معمولاً از فرستادن خبر نادرست قابل دفاع‌تر است.
پیش از ارسال هر دسته، موجودی قابل‌فروش دوباره کنترل شود. با این حال بین ارسال و کلیک مشتری ممکن است کالا تمام شود. متن پیام باید روشن کند موجودی در زمان بررسی برقرار بوده و خرید یا رزرو فقط طبق فرایند واقعی فروشگاه انجام می‌شود. عبارت‌هایی مانند «برای شما کنار گذاشتیم» بدون رزرو واقعی، وعده نادرست هستند.
صف اعلان را متناسب با مقدار موجودی طراحی کنید
اگر تعداد کمی کالا رسیده و افراد زیادی منتظرند، ارسال هم‌زمان به همه می‌تواند بسیاری را به صفحه ناموجود برگرداند. یکی از گزینه‌های طراحی، ارسال مرحله‌ای بر مبنای ترتیب ثبت درخواست و بررسی مجدد موجودی میان دسته‌هاست. این یک سیاست پیشنهادی است، نه نسخه مناسب همه فروشگاه‌ها؛ دوره انتظار و اندازه دسته باید با رفتار فروش و سرعت پردازش سفارش تنظیم شود.
سیاست اولویت را مستند کنید. اگر اولویت بر اساس زمان ثبت است، اجرای آن باید قابل پیگیری باشد. اگر فروشگاه واقعاً رزرو موقت ارائه می‌کند، زمان پایان رزرو، شرایط آزادسازی و رفتار سفارش ناموفق نیز باید مشخص شود. قابلیت رزرو را صرفاً با یک جمله در پیام اضافه نکنید؛ این تصمیم به منطق تخصیص موجودی نیاز دارد.
برای محصولاتی که موجودی آن‌ها مرتب بین صفر و یک جابه‌جا می‌شود، از ارسال پشت‌سرهم جلوگیری کنید. یک دوره موجودشدن باید از دوره بعد قابل تشخیص باشد و مشخص شود هر درخواست در هر دوره چند بار مجاز به دریافت خبر است. مشتری نباید به خاطر اصلاح عدد انبار، چند اعلان مشابه دریافت کند.
ارسال ناموفق و ارسال تکراری را جدا مدیریت کنید
سامانه باید وضعیت‌هایی مانند فعال، در صف، ارسال‌شده، لغوشده و منقضی را از هم جدا کند. پاسخ ناموفق سرویس پیامک با بی‌اعتباربودن شماره یکسان نیست؛ قطع ارتباط هم ثابت نمی‌کند پیام ارسال نشده است. اگر نتیجه نامعلوم بود، وضعیت ارائه‌دهنده را تا حد امکانات رسمی آن بررسی کنید و از تکرار بی‌حساب خودداری کنید.
برای هر تلاش ارسال، شناسه قابل پیگیری داشته باشید و نتیجه را بدون افشای اطلاعات تماس در گزارش عمومی ثبت کنید. دریافت دوباره یک رویداد موجودی نباید خودبه‌خود پیام تازه بسازد. ارتباط میان درخواست، گونه و دوره موجودشدن می‌تواند مبنای جلوگیری از تکرار باشد؛ روش فنی دقیق باید با قابلیت‌های زیرساخت انتخاب شود.
لغو درخواست باید پیش از ارسال نهایی هم بررسی شود، نه فقط هنگام ورود به صف. در غیر این صورت کاربری که تازه لغو کرده همچنان پیام می‌گیرد. درخواست‌های قدیمی نیز نباید بدون پایان روشن برای همیشه فعال بمانند؛ مدت نگهداری و انقضا را متناسب با چرخه محصول تعریف و به کاربر توضیح دهید.
پیام باید مستقیم به انتخاب درست برگرداند
پیام خوب، محصول و گونه را مشخص می‌کند و لینک آن به همان انتخاب می‌رسد. فرستادن همه کاربران به صفحه اصلی فروشگاه، مسیر خرید را طولانی می‌کند. اگر قیمت از زمان ثبت درخواست تغییر کرده، صفحه مقصد باید قیمت جاری را شفاف نشان دهد؛ خبر موجودی نباید به‌عنوان تضمین قیمت قبلی نوشته شود.
اگر موجودی پیش از مراجعه تمام شد، صفحه هنوز باید مفید باشد: وضعیت تازه را نشان دهد، امکان درخواست دوباره را مطابق سیاست فروشگاه فراهم کند و در صورت وجود، جایگزین‌های واقعاً مرتبط پیشنهاد دهد. برای یافتن جایگزین، اصول طراحی جست‌وجوی داخلی فروشگاه کمک می‌کند مسیر کاربر به یک بن‌بست ختم نشود.
از فشار ساختگی مثل «فقط همین الان» بدون دلیل واقعی پرهیز کنید. ناموجودی نباید ابزار ایجاد فوریت جعلی شود. اعتماد زمانی حفظ می‌شود که تفاوت اطلاع‌رسانی، رزرو و سفارش قطعی در فرم، پیام و صفحه مقصد یکسان توضیح داده شده باشد.
موجودی قابل‌مشاهده و داده ساختاریافته هماهنگ باشند
در مستندات رسمی داده ساختاریافته محصول گوگل، وضعیت‌هایی مانند InStock و OutOfStock برای بیان موجودی محصول معرفی شده‌اند. وقتی وضعیت قابل‌خریدبودن تغییر می‌کند، اطلاعات صفحه و داده ساختاریافته باید روایت سازگاری داشته باشند. دکمه خبرم کن نشانه موجودبودن کالا نیست و نباید به‌تنهایی باعث درج InStock شود.
اگر از خوراک محصول استفاده می‌کنید، راهنمای فیلد availability در گوگل نیز مرجع فنی مرتبط است. استفاده از این مستندات به معنی تضمین پذیرش فروشگاه در خدمات گوگل یا نمایش نتیجه ویژه نیست. هدف اینجا جلوگیری از تناقض اطلاعاتی است، نه وعده رتبه یا قابلیت تضمین‌نشده.
برای کالای موقتاً ناموجود، حذف شتاب‌زده صفحه می‌تواند مسیر مراجعه مشتری و لینک اعلان را از بین ببرد. تصمیم نگهداری یا تغییر مسیر صفحه را بر اساس چرخه واقعی محصول بگیرید. در هر حالت، لینک ارسالی باید به مقصدی برسد که وضعیت روشن و اقدام بعدی مفید دارد، نه خطای نامفهوم.
یک سناریوی پذیرش پیش از راه‌اندازی
این مثال فرضی است: فروشگاه برای کیف آبی درخواست خبر موجودی می‌گیرد. ابتدا فقط کیف مشکی تأمین می‌شود؛ نباید پیامی برای متقاضی آبی برود. سپس موجودی آبی قابل‌فروش می‌شود، اما یک درخواست پیش از ارسال لغو شده و یک شماره هم دوبار ثبت شده است. خروجی درست، ارسال مطابق سیاست به درخواست‌های فعال و یکتا است، نه به همه ردیف‌های جدول.
آزمون را با قطع موقت سرویس پیام، تکرار رویداد انبار و اتمام موجودی هنگام پردازش صف ادامه دهید. لینک پیام را روی موبایل باز کنید و مطمئن شوید انتخاب آبی حفظ می‌شود. این آزمون‌ها را در محیط و با گیرندگان آزمایشی مجاز انجام دهید تا بررسی فنی به ارسال ناخواسته برای مشتریان تبدیل نشود.
پذیرش نهایی فقط دیدن یک پیام موفق نیست. باید ثبت، لغو، تکرار، خطا، انقضا و مقصد لینک بررسی شوند. مسئول رسیدگی به صف متوقف‌شده هم مشخص باشد؛ قابلیتی که هنگام خرابی صاحب ندارد، حتی با ظاهر خوب قابل اتکا نیست.
چه چیزی را اندازه بگیریم و از کجا شروع کنیم؟
تعداد درخواست‌ها، تعداد گیرندگان یکتا، ارسال موفق، مراجعه از پیام و خرید پس از مراجعه را جدا اندازه بگیرید. فروش بعد از اعلان الزاماً تماماً ناشی از اعلان نیست؛ برای ادعای اثرگذاری به طراحی سنجش مناسب نیاز دارید. نرخ لغو، پیام تکراری و مراجعه به کالای دوباره ناموجود نیز شاخص‌های مهم کیفیت هستند، حتی اگر تعداد کلیک بالا باشد.
شروع کوچک می‌تواند شامل یک گروه محصول، یک کانال تماس، درخواست متصل به گونه و یک صف قابل پیگیری باشد. پیش از افزودن کانال‌های بیشتر، خطاهای همین مسیر را رفع کنید. برای طراحی یا اصلاح این قابلیت، از صفحه خدمات طراحی سایت و فروشگاه ایزی‌ساز نیاز خود را مطرح کنید و همراه آن منبع موجودی، انواع گونه و سیاست ارسال را توضیح دهید. خبرم کن زمانی ارزشمند است که وعده‌ای روشن را با داده درست و اجرای قابل‌آزمایش به مشتری برساند.