دقیقه
3 آبان 1405فروشگاه ووکامرسی شما سفارش می‌گیرد، اما بعضی کارها هنوز بیرون از سایت انجام می‌شوند: قیمت نهایی را در پیام‌رسان اعلام می‌کنید، موجودی را دستی با انبار تطبیق می‌دهید یا سفارش‌های خاص را در یک فایل جدا ثبت می‌کنید. در این نقطه، پرسش طبیعی این است که آیا وقت سفارشی‌سازی ووکامرس رسیده یا با تنظیمات درست و یک افزونه مناسب می‌توان مسئله را حل کرد؟
پاسخ به تعداد محصولات یا مدت فعالیت فروشگاه محدود نمی‌شود. سفارشی‌سازی زمانی توجیه دارد که یک نیاز مشخص و تکرارشونده، با امکانات موجود به شکل قابل اتکا پوشش داده نشود و ارزش حل آن، هزینه ساخت و نگهداری را توجیه کند. این مقاله کمک می‌کند پیش از سفارش توسعه اختصاصی، مسئله را روشن کنید، گزینه‌های ساده‌تر را بسنجید و بدانید چه خروجی‌ای باید تحویل بگیرید.
سفارشی‌سازی ووکامرس دقیقاً کدام بخش فروشگاه را تغییر می‌دهد؟
عبارت «فروشگاه اختصاصی» ممکن است به چند کار متفاوت اشاره کند. تغییر طراحی صفحه محصول، اضافه کردن یک گزینه به سفارش و ساخت اتصال به نرم‌افزار انبار، از نظر تحلیل، اجرا و نگهداری یکسان نیستند. پیش از دریافت پیشنهاد قیمت، مشخص کنید نیاز شما در نمایش اطلاعات است، در قواعد فروش است یا در تبادل داده با سامانه‌ای دیگر.
طراحی قالب اختصاصی با تغییر قواعد فروش فرق دارد
یک قالب اختصاصی می‌تواند چیدمان صفحات، نمایش ویژگی‌های کالا و هماهنگی با هویت بصری را بهتر کند، در حالی که خرید و مدیریت سفارش همچنان از امکانات موجود ووکامرس استفاده کنند. در مقابل، محاسبه قیمت بر اساس ابعاد سفارشی یا کنترل سقف اعتبار مشتری، به قواعد و داده‌های کسب‌وکار مربوط است. صرف تغییر ظاهر، این قواعد را تعریف یا اجرا نمی‌کند.
برای مثال، اگر مشتری اندازه‌های محصول را پیدا نمی‌کند، شاید اصلاح نمایش اطلاعات کافی باشد. اما اگر باید اندازه دلخواه وارد کند و قیمت بر اساس فرمول تولید محاسبه شود، موضوع فراتر از چیدمان صفحه است. پیشنهاد مجری باید روشن کند چه بخشی طراحی می‌شود و چه بخشی به توسعه عملکرد فروشگاه نیاز دارد.
سفارشی‌سازی می‌تواند محدود و مرحله‌ای باشد
لازم نیست با اولین نیاز متفاوت، کل فروشگاه دوباره ساخته شود. ممکن است یک افزونه آماده، یک اتصال محدود یا توسعه یک قابلیت مشخص کافی باشد. در برخی پروژه‌ها هم ترکیبی از این روش‌ها مناسب است: امکانات عمومی از راهکار موجود تأمین می‌شوند و فقط بخشی که به فرایند خاص کسب‌وکار وابسته است توسعه پیدا می‌کند.
از مجری بخواهید مرز تغییر را توضیح دهد؛ کدام صفحه، داده یا مرحله سفارش تغییر می‌کند و کدام رفتار فعلی باید حفظ شود. این کار برآورد را قابل مقایسه می‌کند و جلوی تبدیل یک درخواست محدود به پروژه‌ای با دامنه نامعلوم را می‌گیرد.
پیش از توسعه اختصاصی، ظرفیت امکانات موجود را بررسی کنید
گاهی مسئله از نبود قابلیت نیست؛ تنظیمات ناقص‌اند یا محصولات با مدل مناسبی ثبت نشده‌اند. پیش از سفارش کد جدید، یک نمونه واقعی را از ابتدا تا انتهای خرید بررسی کنید. باید معلوم شود در کدام مرحله، رفتار فعلی با انتظار کسب‌وکار تفاوت دارد و آیا همان تفاوت با امکانات فعلی قابل اصلاح است.
نیازهای متعارف ممکن است با تنظیمات پوشش داده شوند
طبق مستندات محصولات متغیر ووکامرس، می‌توان برای گزینه‌های مختلف یک محصول، قیمت و موجودی جدا تعریف کرد. بنابراین فروش یک لباس در چند رنگ و اندازه، به‌خودی‌خود دلیل ساخت سیستم اختصاصی انتخاب محصول نیست. ابتدا باید بررسی شود آیا ساختار محصول متغیر با نیاز واقعی شما هماهنگ است.
این بررسی باید شامل مدیریت روزمره هم باشد. ممکن است گزینه‌ای برای مشتری درست نمایش داده شود، اما ورود یا اصلاح آن برای تیم فروش پیچیده باشد. راهکار مناسب باید هم خرید را پوشش دهد و هم به مسئول فروشگاه اجازه دهد اطلاعات را با خطای کمتر نگهداری کند؛ نتیجه را فقط از روی نمای صفحه محصول قضاوت نکنید.
افزونه آماده را با سناریوی خودتان ارزیابی کنید
برخی نیازها خارج از امکانات پایه‌اند، اما راهکار آماده دارند. برای نمونه، در مستندات افزونه Product Add-Ons امکاناتی مانند دریافت متن، انتخاب گزینه تکمیلی و دریافت فایل توضیح داده شده است. وجود چنین قابلیتی نشان می‌دهد هر درخواست شخصی‌سازی محصول الزاماً به برنامه‌نویسی از صفر نیاز ندارد؛ البته این مثال، توصیه خرید یک افزونه برای همه فروشگاه‌ها نیست.
نام قابلیت در صفحه معرفی افزونه کافی نیست. با نمونه سفارش خودتان بررسی کنید اطلاعات کجا ثبت می‌شود، مسئول سفارش آن را چگونه می‌بیند و با تغییر تعداد، اعمال تخفیف یا لغو سفارش چه اتفاقی می‌افتد. اگر راهکار آماده بخش ضروری سناریو را پوشش می‌دهد و نگهداری آن روشن است، توسعه اختصاصی باید مزیت مشخصی نسبت به آن داشته باشد.
چه نشانه‌هایی بررسی سفارشی‌سازی را جدی‌تر می‌کنند؟
نشانه مهم، اصطکاک تکرارشونده‌ای است که اثر قابل توضیحی بر فروش یا عملیات دارد. چند تماس درباره نحوه استفاده، لزوماً نشان‌دهنده نیاز به توسعه نیست؛ شاید راهنما کافی نباشد. اما وقتی تیم برای هر سفارش، داده‌ها را دوباره وارد می‌کند یا مشتری نمی‌تواند شرایط واقعی خریدش را در سایت ثبت کند، بررسی دقیق‌تر ارزش دارد.
قواعد قیمت‌گذاری یا سفارش با راهکار موجود جور نیستند
ممکن است قیمت به ترکیبی از ابعاد، جنس، نوع خدمات و شرایط مشتری وابسته باشد. یا سفارش سازمانی پیش از پرداخت به تأیید مسئول خرید نیاز داشته باشد. این موارد نامزد بررسی راهکار آماده یا سفارشی‌اند، نه حکم قطعی برای کدنویسی. ابتدا قواعد و استثناها را مکتوب کنید و سپس ببینید کدام راهکار آن‌ها را بدون تغییر نامطلوب در فرایند فروش پوشش می‌دهد.
اگر کارکنان هر بار با قضاوت متفاوت قیمت را تعیین می‌کنند، هنوز فرمول قابل پیاده‌سازی ندارید. باید روشن شود کدام ورودی روی قیمت اثر دارد، حداقل و حداکثر مجاز چیست و چه کسی اجازه تغییر قواعد را دارد. خودکار کردن یک تصمیم مبهم، اختلاف را از مکالمه فروشنده به صفحه پرداخت منتقل می‌کند.
ورود دوباره داده یا ناهماهنگی سامانه‌ها هزینه‌ساز شده است
وقتی سفارش بین فروشگاه، انبار و حسابداری جابه‌جا می‌شود، اتصال می‌تواند بخشی از کار دستی را کم کند. اما «اتصال به انبار» شرح کار کاملی نیست. مرجع اصلی موجودی، جهت انتقال داده، فاصله به‌روزرسانی و رفتار هنگام قطع ارتباط باید مشخص شوند. همچنین باید بررسی شود آیا برای نرم‌افزار فعلی، اتصال آماده و قابل پشتیبانی وجود دارد.
برای نمونه، اگر فروش حضوری و اینترنتی از موجودی مشترک استفاده می‌کنند، باید بدانید پس از فروش آخرین کالا در یکی از کانال‌ها، کانال دیگر چه زمانی مطلع می‌شود. اگر ارتباط برقرار نبود، آیا فروش ادامه پیدا می‌کند، محدود می‌شود یا نیاز به تأیید دستی دارد؟ پاسخ این پرسش‌ها تعیین می‌کند اتصال موردنیاز چقدر پیچیده است و چه مسئولیتی بر عهده هر سامانه قرار می‌گیرد.
مشتری برای خرید واقعی مجبور به ترک مسیر آنلاین می‌شود
گاهی مشتری باید ترکیب مشخصی از اقلام را انتخاب کند، فایل سفارش را تحویل دهد یا شرایطی را ببیند که در مسیر فعلی خرید قابل ارائه نیست. اگر این نیاز بین مشتریان هدف تکرار می‌شود، بررسی طراحی مسیر و قابلیت لازم منطقی است. شواهد می‌توانند نمونه درخواست‌های پشتیبانی، سفارش‌های ناتمام مرتبط یا مشاهده نحوه خرید کاربران باشند.
با این حال، افت فروش یا رهاشدن سبد خرید به‌تنهایی ثابت نمی‌کند که توسعه اختصاصی لازم است. ابهام هزینه ارسال، اطلاعات ناقص محصول و اشکال در پرداخت هم باید بررسی شوند. ابتدا علت مشخص را پیدا کنید و بعد قابلیت بسازید؛ در غیر این صورت ممکن است هزینه کنید و مسئله اصلی پابرجا بماند.
تنظیمات، افزونه آماده یا توسعه اختصاصی؛ چگونه انتخاب کنیم؟
برای مقایسه، همه گزینه‌ها را با یک سناریوی یکسان بسنجید. راهکاری که فقط حالت عادی را پوشش می‌دهد، با راهکاری که اصلاح سفارش، خطای ارتباط و دسترسی کارکنان را هم مدیریت می‌کند خروجی برابر ندارد. جدول زیر نقطه شروع تصمیم است و جای بررسی فنی فروشگاه را نمی‌گیرد.
| مسیر | چه زمانی بررسی شود؟ | نکته تعیین‌کننده |
|---|---|---|
| تنظیم امکانات موجود | نیاز با رفتار استاندارد فروشگاه هماهنگ است. | درستی پیکربندی و سادگی مدیریت روزمره |
| افزونه آماده | قابلیت موردنیاز راهکار شناخته‌شده و قابل پشتیبانی دارد. | پوشش سناریو، سازگاری و شرایط دریافت به‌روزرسانی |
| توسعه محدود اختصاصی | بخش مشخصی از نیاز با گزینه‌های موجود پوشش داده نمی‌شود. | مرز دقیق تغییر و مسئول نگهداری کد |
| بررسی معماری متفاوت | نیازهای اصلی با تغییرهای گسترده و وابسته به هم قابل اجرا هستند. | مقایسه هزینه و پیچیدگی کل راهکارها، همراه با انتقال داده |
تعداد محصولات، تعداد افزونه‌ها یا مبلغ فروش، به‌تنهایی مرز ثابتی برای این انتخاب ایجاد نمی‌کنند. فروشگاه کوچکی ممکن است قواعد پیچیده داشته باشد و فروشگاه بزرگ‌تری با فرایند استاندارد کار کند. معیار اصلی، تناسب راهکار با نیاز، کیفیت اجرا و توان نگهداری آن است؛ کد اختصاصی نیز به‌خودی‌خود سرعت یا امنیت بیشتری را تضمین نمی‌کند.
یک مثال فرضی از انتخاب مرحله‌ای
فرض کنید فروشگاهی هدیه شخصی‌سازی‌شده می‌فروشد. در شروع، مشتری فقط متن روی محصول را وارد می‌کند و یک گزینه بسته‌بندی انتخاب می‌کند. این نیاز را می‌توان ابتدا با یک راهکار آماده مناسب ارزیابی کرد. اگر بعداً فرایند به تأیید طرح توسط مشتری، ثبت نسخه‌های اصلاحی و ارسال دستور تولید به کارگاه گسترش یابد، بررسی توسعه یک بخش اختصاصی جدی‌تر می‌شود.
در این سناریوی فرضی، دلیل تغییر تصمیم «بزرگ‌تر شدن سایت» نیست؛ وظایف جدید و وابستگی آن‌هاست. حتی در مرحله دوم نیز ممکن است دریافت متن و پرداخت با امکانات موجود باقی بمانند و فقط گردش تأیید طرح و اتصال کارگاه توسعه پیدا کند. چنین تفکیکی به تیم کمک می‌کند هزینه را برای قسمت دارای نیاز واقعی صرف کند.
هزینه واقعی را تا بعد از تحویل حساب کنید
برآورد سفارشی‌سازی فقط مبلغ نوشتن کد نیست. شناخت فرایند، طراحی تجربه استفاده، آماده‌سازی داده، اجرا، آزمون، آموزش و رسیدگی پس از تحویل سهم دارند. اگر اتصال به سرویس دیگری لازم است، هزینه دسترسی و محدودیت‌های آن سرویس هم باید روشن شود. قیمت پایین‌تر بدون مشخص بودن این موارد، مبنای مطمئنی برای مقایسه نیست.
ارزش تغییر را با یک مسئله قابل اندازه‌گیری بسنجید
برای مثال، ثبت کنید کدام کار دستی حذف می‌شود، اکنون چه مدت وقت می‌گیرد و اشتباه در آن چه پیامدی دارد. در قابلیت‌های مربوط به خرید نیز هدف را مشخص کنید: کاهش نیاز به تماس برای یک نوع سفارش، کامل‌تر شدن اطلاعات تحویلی به تولید یا کمتر شدن خطای انتخاب محصول. برآورد را بر داده‌های واقعی خودتان بنا کنید و افزایش فروش قطعی فرض نکنید.
اگر نیاز هنوز کم‌تکرار یا نامطمئن است، یک فرایند دستی محدود و قابل پیگیری می‌تواند به شناخت آن کمک کند. اما وقتی همان فرایند دستی به مانع ثابت عملیات تبدیل شده، ادامه دادن آن هم هزینه دارد. تصمیم مناسب حاصل مقایسه این هزینه با ساخت و نگهداری راهکار جدید است.
سازگاری و نگهداری بخشی از پیشنهاد فنی‌اند
نوع صفحه تسویه‌حساب و افزونه‌های مرتبط با پرداخت باید در بررسی سازگاری مشخص باشند. مستندات توسعه ووکامرس توضیح می‌دهد که همه روش‌های تغییر تسویه‌حساب قدیمی، در بلوک‌های جدید به همان شکل کار نمی‌کنند. بنابراین نمونه کدی که در فروشگاه دیگری جواب داده، مدرک کافی برای سازگاری با فروشگاه شما نیست.
اگر قابلیت به داده سفارش وابسته است، سازگاری با روش ذخیره‌سازی سفارش نیز باید بررسی شود؛ از جمله ذخیره‌سازی پربازده سفارش‌ها یا HPOS. لازم نیست مدیر کسب‌وکار جزئیات پیاده‌سازی را بداند، اما باید از مجری بخواهد محیط بررسی‌شده، وابستگی‌ها و مسئول رفع ناسازگاری پس از به‌روزرسانی را در تحویل مشخص کند.
پیش از سفارش، شرح نیاز و معیار پذیرش را آماده کنید
به‌جای درخواست «یک فروشگاه حرفه‌ای‌تر»، یک سفارش واقعی را شرح دهید: چه کسی چه اطلاعاتی وارد می‌کند، سیستم چه تصمیمی می‌گیرد و نتیجه کجا دیده می‌شود. نمونه عادی و استثناهای مهم را کنار هم بنویسید؛ مانند انتخاب نامعتبر، تغییر تعداد، لغو سفارش یا قطع ارتباط با انبار. این توضیح، پایه مقایسه پیشنهاد مجری‌ها و کنترل خروجی خواهد بود.
بسته اولیه می‌تواند شامل نمونه محصول، قواعد محاسبه، اطلاعات موردنیاز کارکنان، سامانه‌های مرتبط و حدود دسترسی باشد. اگر این موارد هنوز روشن نیستند، ابتدا مرحله تحلیل با خروجی مشخص تعریف کنید. مقاله آماده‌سازی پیش از طراحی فروشگاه اینترنتی برای سامان دادن اطلاعات پایه به شما کمک می‌کند؛ در سفارشی‌سازی، همان اطلاعات باید به رفتار دقیق قابلیت تبدیل شوند.
تحویل را با رفتار قابل بررسی تعریف کنید
برای یک محاسبه‌گر قیمت، صرف نمایش عدد کافی نیست. باید نمونه ورودی و نتیجه مورد انتظار از قبل توافق شود و همان مبلغ در سبد، سفارش و اطلاعات تحویلی به تیم درست باقی بماند. برای اتصال انبار نیز دریافت موفق یک پیام کافی نیست؛ وضعیت خطا و جلوگیری از پردازش تکراری یک رویداد باید متناسب با دامنه پروژه بررسی شوند.
از ابتدا روشن کنید کد و مستندات چگونه تحویل داده می‌شوند، حساب سرویس‌ها در اختیار چه کسی است، کارکنان چه آموزشی می‌بینند و رفع اشکال تا کجا در قرارداد قرار می‌گیرد. تغییر قابلیت در آینده و نگهداری دوره‌ای را هم از اصلاح خطای اجرای توافق‌شده تفکیک کنید تا انتظار دو طرف روشن باشد.
اجرای تغییر را محدود شروع کنید و نتیجه را بسنجید
برای قابلیت جدید، یک دامنه اولیه مشخص انتخاب کنید؛ مثلاً یک گروه محصول یا یک نوع سفارش. این دامنه باید مسئله واقعی را حل کند و در عین حال امکان بررسی دقیق داشته باشد. پس از تأیید رفتار، می‌توان توسعه را گسترش داد. اگر قابلیت برای همه سفارش‌ها حیاتی است، برنامه انتقال و کنترل آن باید پیش از شروع اجرا مشخص شود.
راهنمای رسمی به‌روزرسانی ووکامرس بر نسخه پشتیبان و آزمون در محیط آزمایشی تأکید می‌کند. برای سفارشی‌سازی نیز مسیرهای مرتبط، از انتخاب محصول تا ثبت سفارش و دریافت اطلاعات توسط کارکنان، باید پیش از انتقال بررسی شوند. پس از اجرا، شاخصی را که برای حل مسئله تعیین کرده‌اید دنبال کنید؛ صرف فعال شدن قابلیت، ارزش تجاری آن را ثابت نمی‌کند.
برای تصمیم اولیه، از یک نیاز مشخص شروع کنید: آیا تنظیمات فعلی پاسخ می‌دهند؟ آیا افزونه مناسب سناریو را پوشش می‌دهد؟ اگر شکاف باقی می‌ماند، توسعه محدود آن چه هزینه و مسئولیت نگهداری دارد؟ در آژانس خلاقیت امین، طراحی قالب و توسعه قابلیت‌های اختصاصی وردپرس بر اساس نیاز پروژه بررسی می‌شوند. برای توضیح فرایند فروش و بررسی دامنه اجرای آن، صفحه خدمات طراحی سایت با قالب اختصاصی وردپرس را ببینید.