فرض کنید برای فروشگاه اینترنتی‌تان دو پیش‌فاکتور گرفته‌اید و رقم یکی تقریباً دو برابر دیگری است. اغلب مسئله گرانی یا ارزانی نیست. در واقع این دو پیشنهاد دو کار متفاوت را قیمت داده‌اند. هزینه طراحی سایت فروشگاهی را روش ساخت، امکانات خرید، پیچیدگی محصولات، اتصالها و پشتیبانی تعیین می‌کنند، نه فقط تعداد صفحه یا کالا.
- پیشنهادها را با امکانات و مسئولیت‌های یکسان مقایسه کنید، نه فقط مبلغ نهایی.
- هزینه اولیه، تمدید سرویس‌ها و تغییر درخواست را جدا ثبت کنید.
- پیچیدگی محصول و کیفیت داده‌ها از تعداد کالا به‌تنهایی مهم‌ترند.
- اتصال انبار و حسابداری بدون بررسی دسترسی‌ها و قواعد تبادل، برآورد قابل اتکایی ندارد.
- مبلغ نامشخص را در برگه مقایسه، صفر در نظر نگیرید.
هزینه طراحی سایت فروشگاهی به چه عواملی بستگی دارد؟
به‌طور خلاصه، هزینه طراحی سایت فروشگاهی به روش ساخت، امکانات خرید، پیچیدگی محصولات، آماده‌بودن محتوا، اتصال به انبار و حسابداری و سطح پشتیبانی بستگی دارد. پس برای اینکه برآوردها قابل مقایسه باشند، هزینه راه‌اندازی را از ورود اطلاعات، اشتراک سرویس‌ها، تمدید سالانه و تغییرات بعدی جدا کنید. تعداد صفحات یا محصولات به‌تنهایی معیار کافی نیست.
برای مثال، پیشنهاد اول ورود ۳۰۰ کالا، اتصال درگاه پرداخت و سه ماه پشتیبانی را در مبلغ آورده است. پیشنهاد دوم فقط از «طراحی فروشگاه کامل» حرف می‌زند. این دو عدد را نمی‌شود کنار هم گذاشت، چون دامنه کارشان یکی نیست. دامنه کار یعنی فهرست دقیق کارهایی که مجری انجام می‌دهد. وقتی این فهرست فرق دارد، هزینه طراحی سایت فروشگاهی در دو پیشنهاد درباره دو چیز متفاوت حرف می‌زند.
از همین‌جا معنای برآورد هم باید روشن شود. برآورد مبلغی است که به فرض‌ها و اقلام مشخص تکیه دارد. اگر فرضی عوض شود، مثلاً تعداد انبارها بیشتر شود، مجری حق دارد مبلغ را دوباره بررسی کند. اما برآورد تعهدی نامحدود برای هر نیازی نیست که سال بعد پیدا می‌کنید.
معمولاً اولین سؤالی که در جلسه برآورد می‌پرسم این است: «این عدد با چه فرض‌هایی درست است؟» اگر مجری نتواند فرض‌ها را بنویسد، عددش هم چندان قابل اتکا نیست.
هزینه طراحی فروشگاه از چه اجزایی تشکیل می‌شود؟
دو بخش اصلی در هزینه طراحی سایت فروشگاهی هست: کاری که تیم اجرا انجام می‌دهد و سرویس‌هایی که از بیرون می‌خرید. شناخت نیاز، طراحی، پیاده‌سازی، انتقال اطلاعات، آزمون و تحویل جزو بخش اول‌اند. میزبانی، دامنه، مجوز ابزارها و پیامک هم به بخش دوم تعلق دارند.
اما فهرست اقلام به‌تنهایی کافی نیست. پیشنهاد من این است که برای هر قلم چهار ستون بخواهید: خروجی، مسئول اجرا، نوع هزینه و معیار پذیرش. معیار پذیرش یعنی شرطی که با آن می‌فهمید کار واقعاً تمام شده است؛ مثلاً «یک خرید آزمایشی از اول تا آخر بدون خطا انجام شد».
قلم | خروجی | مسئول اجرا | یک‌باره یا تکراری | معیار پذیرش |
|---|---|---|---|---|
شناخت نیاز | سند دامنه کار و فرض‌ها | مجری با همکاری شما | یک‌باره | تأیید مکتوب فهرست امکانات |
طراحی | طرح صفحه‌های کلیدی در موبایل و دسکتاپ | مجری | یک‌باره | تأیید طرح پس از دورهای بازبینی توافقی |
پیاده‌سازی | فروشگاه قابل استفاده روی نسخه آزمایشی | مجری | یک‌باره | اجرای کامل یک خرید آزمایشی |
انتقال اطلاعات | محصولات و دسته‌ها در فروشگاه جدید | مشترک | یک‌باره | تطبیق نمونه‌ای کالاها با فایل مرجع |
آزمون | گزارش آزمون و رفع اشکال | مجری | یک‌باره | نبود خطای باز در مسیرهای اصلی |
تحویل | دسترسی‌ها، راهنما و آموزش | مجری | یک‌باره | انتقال مالکیت حساب‌ها به شما |
سرویس‌های بیرونی | میزبانی، دامنه، مجوزها، پیامک | معمولاً کارفرما | تکراری یا مصرفی | فعال‌بودن به نام کسب‌وکار شما |
بنابراین برای بودجه شروع یک فرمول ساده و بدون عدد دارید: اجرای توافق‌شده، به‌علاوه آماده‌سازی داده، راه‌اندازی اتصالها و سرویس‌های لازم. اگر یکی از این چهار جزء در پیشنهادی غایب است، هنوز هزینه ساخت فروشگاه اینترنتی را کامل ندیده‌اید. یعنی بخشی از هزینه طراحی سایت فروشگاهی جایی بیرون از پیش‌فاکتور منتظر شماست.
همین‌جا یک اشتباه رایج هم رخ می‌دهد: تولید عکس و متن محصول با بارگذاری محتوای آماده یکی نیست. عکاسی از ۲۰۰ کالا و نوشتن توضیح برای هرکدام، خودش پروژه‌ای جداست. پس اگر پیش‌فاکتور فقط «ورود محصولات» نوشته، بپرسید محتوا را شما می‌دهید یا مجری تولیدش می‌کند. جواب این سؤال میتواند هزینه طراحی سایت فروشگاهی را به‌شکل محسوسی جابه‌جا کند.
چگونه جدول قیمت نیاسا را بخوانیم؟
جدول قیمت را نقطه شروع یک گفت‌وگو بدانید، نه فاکتور نهایی. نسخه جاری را در صفحه خدمات طراحی سایت و جدول قیمت نیاسا ببینید؛ به‌روزترین اطلاعات همان‌جاست. در این مقاله نام بسته یا رقمی نمی‌آورم، چون قیمت‌ها با زمان و فرض‌ها تغییر می‌کنند.
در واقع تعرفه سایت فروشگاهی در هر جدولی خلاصه یک دامنه کار استاندارد است. هزینه طراحی سایت فروشگاهی شما ممکن است با همان استاندارد فرق داشته باشد. پس وقتی جدول را می‌خوانید، این موارد را یکی‌یکی کنار نیاز خودتان بگذارید:
سقف امکانات: کدام قابلیت‌ها داخل بسته است و کدام بیرون از آن.
تعداد الگوهای صفحه: الگو یعنی قالب طراحی یک نوع صفحه، مثل صفحه محصول یا سبد خرید. صد صفحه محصول ممکن است فقط یک الگو باشد.
ورود محصول: چند کالا و با چه سطح جزئیاتی داخل مبلغ است.
پشتیبانی: مدت آن و کارهایی که شامل آن هستند.
مالیات: مبلغ با مالیات بر ارزش افزوده است یا بدون آن.
خدمات خارج از بسته: اتصالها، تولید محتوا یا قابلیتهای سفارشی که قیمت جداگانه دارند.
قاعده ما ساده است: هر رقمی فقط وقتی معتبر است که تیم فروش تأییدش کرده باشد. چنین رقمی باید واحد پول، تاریخ اعتبار و فرض‌های برآورد را همراه داشته باشد. بنابراین اگر یکی از این سه را ندیدید، رقم را قطعی فرض نکنید و از ما بپرسید.
با این حال، هیچ جدولی به همه سؤال‌ها جواب نمی‌دهد. موارد مبهم، مثل نوع اتصال انبار یا روش ارسال، جایشان در پیش‌فاکتور اختصاصی شماست. معمولاً همین موارد هزینه طراحی سایت فروشگاهی را از عدد جدول دور می‌کنند. جدول می‌گوید از کجا شروع کنید؛ پیش‌فاکتور می‌گوید دقیقاً چه چیزی می‌خرید.
کنار هر مبلغ، واحد پول، دوره پوشش و تاریخ اعتبار را ثبت کنید. هزینه سرویس بیرونی ممکن است مستقل از هزینه اجرای سایت تغییر کند.
مقایسه سه سناریوی فروشگاه با فرض‌های روشن
سه سناریوی زیر کاملاً فرضی‌اند و بسته‌های نیاسا نیستند. هدفشان این است که ببینید هزینه طراحی سایت فروشگاهی چطور با داده و اتصالها تغییر می‌کند، نه با اسم بسته. به همین دلیل جدول عمداً قیمت ندارد.
سناریو | داده محصول | موجودی | اتصال |
|---|---|---|---|
شروع ساده | اطلاعات و عکس‌ها آماده، هر کالا یک قیمت | دستی، به‌دست مدیر فروشگاه | فقط درگاه پرداخت |
فروشگاه متنوع | کالاها با ترکیب رنگ و اندازه، قیمت متفاوت برای برخی ترکیب‌ها | دستی، اما جدا برای هر ترکیب | درگاه پرداخت و سرویس ارسال |
فروشگاه متصل | داده اصلی در نرم‌افزار حسابداری | چند انبار با به‌روزرسانی خودکار | درگاه، ارسال، حسابداری و انبار |
نکته‌ای که خیلی‌ها انتظارش را ندارند این است که فروشگاه کوچک همیشه ارزانتر نیست. فرض کنید فروشگاهی ۴۰ کالا دارد، اما قیمت هر کالا به تعداد سفارش، نوع مشتری و تخفیف ترکیبی بستگی دارد. اجرای چنین فروشگاهی ممکن است از کاتالوگی با ۲۰۰۰ کالای ساده دشوارتر باشد. در نتیجه هزینه طراحی سایت فروشگاهی آن هم میتواند بالاتر برود.
برای اینکه بفهمید به کدام سناریو نزدیک‌ترید، به این سه سؤال جواب دهید:
قیمت و موجودی هر کالا امروز کجا ثبت می‌شود؛ در یک فایل، در نرم‌افزار حسابداری یا در ذهن یک نفر؟
سفارش بعد از ثبت چه مسیری را طی می‌کند و چه کسی آن را تأیید می‌کند؟
آیا همان کالا هم‌زمان جای دیگری، مثل فروشگاه حضوری، هم فروش می‌رود؟
جواب همین سه سؤال بیشتر از تعداد کالا درباره هزینه طراحی سایت فروشگاهی حرف می‌زند.
هزینه فروشگاه وردپرسی چگونه برآورد می‌شود؟
برآورد هزینه فروشگاه وردپرسی جمع پنج قلم است: تنظیم، طراحی ظاهر، آزمون سازگاری، نگهداری و مجوز ابزارها. وردپرس یک سامانه مدیریت محتوای آماده است؛ یعنی نرم‌افزاری که بخش‌های پایه سایت و پنل مدیریت را از قبل دارد. افزونه (Plugin) هم قابلیتی نصب‌شدنی است که امکانی مثل فروشگاه یا روش ارسال را اضافه می‌کند.
اما رایگان‌بودن هسته وردپرس به معنای اجرای رایگان نیست. بعضی افزونه‌ها هزینه خرید دارند و برخی برای دریافت به‌روزرسانی تمدید سالانه می‌خواهند. هر افزونه هم باید با بقیه سازگار بماند و کسی باید بعد از هر به‌روزرسانی این سازگاری را بررسی کند. همین اقلام کوچک، هزینه طراحی سایت فروشگاهی وردپرسی را از تصور «رایگان» دور می‌کنند.
پیش از اینکه سفارشیسازی سفارش بدهید، بررسی کنید قابلیتهای آماده با روش فروش شما جور هستند یا نه. برای مثال، اگر تخفیف پلکانی می‌خواهید، یعنی قیمت واحد کمتر برای خرید بیشتر، شاید افزونه‌ای آماده دقیقاً همین را انجام دهد. گاهی هم افزونه آماده بیشتر نیاز را پوشش می‌دهد و همان بخش کوچک باقی‌مانده بیشترین کار را می‌برد.
از مجری بخواهید این بخش از هزینه طراحی سایت فروشگاهی را در چهار دسته جدا بنویسد:
تنظیم و پیکربندی فروشگاه و افزونه‌ها
طراحی ظاهر و تطبیق قالب با هویت برند
آزمون سازگاری افزونه‌ها با هم و با نسخه‌های جدید
مجوز ابزارها، همراه با دوره تمدید هرکدام
قاعده تصمیم من این است: اگر امکانات آماده و قابل نگهداری نیازتان را پوشش می‌دهند، توسعه اضافی را بدون دلیل وارد دامنه کار نکنید. دلیلش روشن است؛ هر خط کد سفارشی بعداً هزینه نگهداری هم دارد.
قیمت سایت فروشگاهی اختصاصی از کجا افزایش پیدا می‌کند؟
از جایی که قواعد کسب‌وکار شما در هیچ ابزار آماده‌ای جا نمی‌شود، قیمت سایت فروشگاهی اختصاصی بالا می‌رود. ساخت اختصاصی یعنی توسعه نرم‌افزار متناسب با همین قواعد خاص. اما ظاهر متفاوت به‌تنهایی دلیل ساخت اختصاصی نیست؛ طراحی منحصربه‌فرد روی بستر آماده هم شدنی است.
فرض کنید شرکتی پخش‌کننده لوازم بهداشتی هم به مغازه‌ها عمده می‌فروشد و هم به مصرف‌کننده. هر گروه مشتری قیمت خودش را دارد. سفارش بالای یک مبلغ مشخص به تأیید مدیر فروش نیاز دارد. هر مشتری عمده هم سقف اعتبار دارد و اگر بدهی‌اش از این سقف بگذرد، نباید بتواند سفارش جدید ثبت کند.
یعنی پشت یک دکمه «ثبت سفارش» چند تصمیم پنهان است. برآورد چنین فروشگاهی باید این اقلام را صریح نشان دهد:
تحلیل قواعد: نوشتن دقیق اینکه چه کسی، در چه شرایطی، چه قیمتی می‌بیند.
پنل مدیریت: جایی که کارکنان گروه مشتری، سقف اعتبار و تأییدها را مدیریت کنند.
آزمون وضعیت‌های استثنایی: مثلاً مشتری‌ای که وسط سفارش از سقف اعتبارش عبور می‌کند.
مستندات نگهداری: توضیحی که تیم بعدی با آن کد را بفهمد و تغییر دهد.
پیش از انتخاب روش ساخت، از مجری بخواهید بنویسد کدام نیاز شما را راهکار آماده پوشش نمی‌دهد. اگر جواب فقط «انعطاف بیشتر» است، دلیل کافی نشنیده‌اید. اما اگر جواب به قاعده‌ای مشخص مثل سقف اعتبار اشاره می‌کند، بحث جدی است. بخش بزرگی از هزینه طراحی سایت فروشگاهی اختصاصی همان‌جا شکل می‌گیرد.
تعداد محصول، تنوع و ورود اطلاعات چه اثری دارند؟
اثر تعداد محصول واقعی است، اما تنوع و کیفیت داده معمولاً اثر بزرگ‌تری بر هزینه طراحی سایت فروشگاهی می‌گذارند. اول سه مفهوم را از هم جدا کنیم. محصول همان چیزی است که مشتری در صفحه می‌بیند، مثل «پیراهن کتان آستین‌بلند».
گونه محصول (Variation) هر ترکیب قابل انتخاب از آن است. اگر این پیراهن سه رنگ و چهار اندازه داشته باشد، دوازده گونه دارد. شناسه قابل فروش (SKU) کدی است که هر گونه را در انبار از بقیه جدا می‌کند. پس یک «محصول» در عمل دوازده ردیف موجودی و شاید دوازده قیمت دارد.
حالا دو فایل را مقایسه کنید. فایل اول ستون‌های منظم دارد: نام، دسته، رنگ، اندازه، قیمت، موجودی و نام عکس. فایل دوم ترکیبی از چند اکسل قدیمی است؛ عکس‌ها نام بی‌ربط دارند و نیمی از کالاها وزن ندارند. ورود فایل اول کاری تکراری و قابل پیش‌بینی است. اما فایل دوم پیش از ورود به پاک‌سازی و تصمیم‌گیری نیاز دارد.
به همین دلیل سهم هر طرف را از قبل بنویسید و برای هر کار زیر مشخص کنید شما انجامش می‌دهید یا مجری:
پاک‌سازی داده: یکسان‌کردن نام‌ها، حذف تکراری‌ها و تکمیل مشخصات
دسته‌بندی: تصمیم نهایی درباره درخت دسته‌ها، که معمولاً با شماست و مجری پیشنهادش را می‌دهد
آماده‌سازی تصویر: برش، هم‌اندازه‌کردن و نام‌گذاری عکس‌ها
ورود اطلاعات: بارگذاری در فروشگاه و تطبیق نمونه‌ای با فایل مرجع
پیشنهاد عملی من این است که پیش از برآورد، نمونه‌ای نماینده از محصولات را به مجری بدهید. چند کالای ساده، چند کالای پرتنوع و چند کالای ناموجود کافی است. با این نمونه، مجری داده واقعی شما را می‌بیند. در نتیجه هزینه طراحی سایت فروشگاهی فقط بر پایه تعداد کالا حساب نمی‌شود.
اگر فروشگاه قبلی دارید، انتقال آن را قلم جداگانه ببینید. آدرس صفحات قدیمی باید به صفحات جدید هدایت شوند تا جایگاه جست‌وجو و لینک‌های قدیمی از دست نروند. سوابق مشتریان و سفارش‌ها را هم فقط به اندازه‌ای منتقل کنید که واقعاً به کارتان می‌آید، چون هر ردیف اضافه یعنی کار تطبیق بیشتر.
فقط ساده‌ترین محصول را برای برآورد نفرستید؛ یک کالای چندحالته و یک نمونه با اطلاعات ناقص هم اضافه کنید تا حجم واقعی آماده‌سازی روشن شود.
پرداخت و ارسال کدام هزینه‌های پنهان را دارند؟
هزینه پنهان پرداخت و ارسال در وضعیت‌های غیرعادی است، نه در اضافه‌کردن خود گزینه. افزودن یک درگاه پرداخت شاید کار کوتاهی باشد، اما کار اصلی جای دیگری است:
بازگشت ناموفق: مشتری پرداخت کرده، اما به سایت برنگشته است.
پرداخت تکراری: مشتری دو بار دکمه پرداخت را زده است.
سفارش معلق: سفارشی که نه پرداخت‌شده است و نه لغوشده.
تطبیق وضعیت: مقایسه تراکنش‌های درگاه با سفارش‌های فروشگاه در پایان روز.
ارسال هم همین وضع را دارد. ارسال با هزینه ثابت ساده است. اما وقتی نرخ به وزن، شهر مقصد، بازه تحویل یا تعداد مرسوله وابسته شود، هرکدام قواعد و آزمون خودش را می‌خواهد. مثلاً سفارشی که بخشی‌اش از تهران و بخشی از اصفهان می‌رود، دو مرسوله و احتمالاً دو هزینه دارد.
همچنین هزینه اجرای اتصال را از کارمزد سرویس جدا کنید. مجری برای راه‌اندازی اتصال درگاه یا سرویس ارسال دستمزد می‌گیرد؛ کارمزد تراکنش یا هزینه هر مرسوله را خود سرویس‌دهنده از شما می‌گیرد. اولی جزو هزینه طراحی سایت فروشگاهی است و دومی جزو هزینه جاری فروش. آماده‌بودن حساب درگاه، قرارداد با شرکت ارسال و دسترسی‌ها هم وابستگی پروژه است و تأخیرشان کار مجری را متوقف می‌کند.
برای معیار پذیرش، یک سناریوی مشخص بنویسید. فرض کنید مشتری پرداخت کرده، اما پاسخ درگاه چند دقیقه دیر به فروشگاه می‌رسد. وضعیت سفارش، رزرو موجودی، پیامی که مشتری می‌بیند و اطلاع‌رسانی به کارکنان را برای همین فاصله از قبل تعیین کنید.
پیش‌فاکتوری که سؤال سخت نپرسیده، هنوز قیمت واقعی را هم نمی‌داند.
اتصال انبار و حسابداری چگونه برآورد می‌شود؟
ما این اتصال را با چهار پاسخ برآورد می‌کنیم: منبع اصلی داده، جهت تبادل، فاصله به‌روزرسانی و مسئول اصلاح خطا. ابزار این اتصال معمولاً API است؛ یعنی رابطی که دو نرم‌افزار از طریق آن با هم داده رد و بدل می‌کنند.
با این حال، داشتن API به معنای اتصال بدون کار فنی نیست. API فقط درِ ارتباط را نشان می‌دهد. تیم فنی هنوز باید تعیین کند چه داده‌ای، کِی و با چه قاعده‌ای از این در عبور کند. پس این چهار تصمیم را پیش از برآورد بگیرید:
منبع اصلی: قیمت و موجودی در کدام سیستم حرف آخر را می‌زند؟
جهت تبادل: داده فقط از حسابداری به فروشگاه می‌رود یا سفارش‌ها هم برمی‌گردند؟
فاصله به‌روزرسانی: لحظه‌ای، هر چند دقیقه یا روزی یک بار؟
مسئول خطا: اگر کالایی با کد اشتباه رسید، چه کسی اصلاحش می‌کند؟
برآورد دقیق سه پیش‌شرط هم دارد: مستندات API، یک دسترسی آزمایشی برای کار بدون خطر و همکاری تأمین‌کننده نرم‌افزار حسابداری. بدون این‌ها هر رقمی برای اتصال حدس است، نه برآورد.
یک مثال فرضی را در نظر بگیرید. آخرین عدد یک کالا هم‌زمان در فروشگاه اینترنتی و در شعبه حضوری فروش می‌رود. حالا باید تصمیم بگیرید موجودی هنگام افزودن به سبد رزرو شود یا هنگام پرداخت. اگر سفارش اینترنتی بی‌موجودی ماند، لغو خودکار شود یا کارمندی با مشتری تماس بگیرد؟ هر سیاست دامنه کار را عوض می‌کند؛ بنابراین تصمیمش را به بعد از برآورد نسپارید.
در پیش‌فاکتور، این اتصال را در سه قلم مجزا ببینید: اجرای اولیه، هزینه سرویس واسط در صورت نیاز و نگهداری اتصال. نسخه نرم‌افزار حسابداری عوض می‌شود و اتصال هم باید همراهش به‌روز بماند. بدون این تفکیک، سهم این بخش از هزینه طراحی سایت فروشگاهی را نمی‌توانید بسنجید.
طراحی تجربه خرید و امکانات سفارشی چقدر کار می‌برند؟
حجم کار طراحی تجربه خرید به تعداد حالت‌ها و تصمیم‌ها بستگی دارد، نه به تعداد صفحه. تجربه خرید یعنی کل مسیری که مشتری از پیدا کردن کالا تا پرداخت طی می‌کند. صفحه محصول زیبا، وقتی سبد خرید روی موبایل گیج‌کننده است، فروش را نجات نمی‌دهد. به همین دلیل این بخش از هزینه طراحی سایت فروشگاهی را با فهرست حالت‌ها بسنجید.
در دامنه طراحی، حالت‌های کم‌دیده‌شده را صریح بنویسید: کالای ناموجود، خطای فرم، سبد خالی، کد تخفیف نامعتبر و نمایش همه این‌ها روی موبایل. اگر طراح فقط حالت ایدئال را بکشد، برنامه‌نویس جای خالی را با حدس پر می‌کند. برای خوانایی و استفاده‌پذیری فرم‌ها هم راهنمای دسترس‌پذیری وب مرجع خوبی برای تعریف حداقل‌هاست.
جست‌وجو و فیلتر را هم بر اساس داده محصول بسنجید. مثلاً فیلتر اندازه وقتی معنا دارد که اندازه در داده شما ستونی منظم باشد. مقایسه کالا برای لوازم فنی مفید است و برای پوشاک کمتر. خرید مهمان، یعنی خرید بدون ثبت‌نام، معمولاً مسیر را کوتاه می‌کند؛ اما اگر باشگاه مشتریان دارید، آن را با هدفتان بسنجید.
قابلیتهای سفارشی را طوری شرح دهید که قابل آزمون باشند. فرض کنید فروشگاهی پرده می‌فروشد و می‌خواهد قیمت را بر اساس ابعاد حساب کند:
ورودی‌ها: عرض و ارتفاع به سانتی‌متر و نوع پارچه
محدودیت‌ها: حداقل و حداکثر ابعاد قابل سفارش و قاعده گردکردن اعداد
خروجی: قیمت نهایی برای چند ابعاد نمونه که از قبل حساب کرده‌اید و با نتیجه سایت مقایسه می‌کنید
یک نکته دیگر هم پیش از قرارداد لازم است: تعداد دور بازبینی طرح را مشخص کنید. اصلاح رنگ یک دکمه بازبینی است؛ اما اضافه‌کردن مقایسه کالا به صفحه محصول قابلیت جدید است. این مرز را از اول بنویسید تا بعداً سرش بحث نکنید.
آزمون، امنیت و تحویل چه سهمی از بودجه دارند؟
سهم آزمون، امنیت و تحویل از بودجه واقعی و قابل‌توجه است و این‌ها نباید اولین جای صرفهجویی باشند. من مسئول کنترل کیفیتم و از این نگاه، بخشی که خروجی قابل بررسی ندارد در عمل انجام نشده است. پس آزمون را هم با خروجی تعریف کنید تا سهمش در هزینه طراحی سایت فروشگاهی معلوم باشد:
آزمون مسیر خرید: چند سفارش آزمایشی کامل، از سبد تا تأیید پرداخت و ثبت در پنل
دسترسی کارکنان: انباردار سفارش‌ها را ببیند، اما به تنظیمات پرداخت دسترسی نداشته باشد
بازیابی نسخه پشتیبان: یک بار واقعاً نسخه پشتیبان را برگردانید، نه اینکه فقط وجودش را تأیید کنید
نمایش موبایل: بررسی مسیر خرید روی چند گوشی رایج با اندازه‌های مختلف
امنیت را کار مداوم و مجموعه‌ای از کنترل‌ها بدانید. هیچ مجری‌ای نمی‌تواند مصونیت کامل را وعده دهد؛ بنابراین اگر کسی چنین وعده‌ای داد، احتیاط کنید. برای اینکه بدانید چه کنترل‌هایی را بپرسید، چارچوب بررسی امنیت برنامه‌های وب فهرست مرجع خوبی است.
در پیش‌فاکتور دنبال این موارد بگردید: نام صاحب دامنه و حساب سرویس‌ها، روش تحویل دسترسی‌ها، راهنمای مدیریت و شکل آموزش کارکنان. چرا این‌قدر مهم است؟ چون فروشگاهی که حساب‌هایش به نام مجری است، در عمل کاملاً مال شما نیست.
همچنین محدوده رفع اشکال پس از تحویل را روشن کنید. رفع اشکال یعنی کاری که طبق توافق باید درست کار می‌کرد و نمی‌کند. زمان پاسخگویی توافقی را هم بنویسید. اما درخواست قابلیت تازه در این دوره توسعه جدید است، نه رفع اشکال.
اگر جزئیات قراردادی برایتان مهم است، راهنمای سفارش طراحی سایت؛ از انتخاب تا تحویل را بخوانید. ترتیب اجرای کار را هم در مراحل طراحی سایت فروشگاهی؛ از قرارداد تا تحویل توضیح داده‌ایم.
هزینه‌های سال اول و تمدیدهای بعدی چگونه جدا می‌شوند؟
برای سال اول، اجرای اولیه و هزینه‌های دورهای همان سال را با هم جمع کنید و تمدیدهای بعدی را بدون هزینه ساخت حساب کنید. سهم ساخت در هزینه طراحی سایت فروشگاهی یک بار پرداخت می‌شود، نه هر سال. هزینه سالانه فروشگاه اینترنتی به انتخاب‌های پروژه بستگی دارد و دامنه، میزبانی، مجوز ابزارها، پیامک و پشتیبانی نمونه‌های رایج آن هستند. با این حال، همه این اقلام الزاماً پرداخت سالانه ندارند.
قلم | دوره پوشش | پرداخت‌کننده | حساس به |
|---|---|---|---|
دامنه | سالانه یا چندساله | کارفرما | تعرفه ثبت‌کننده دامنه |
میزبانی | ماهانه یا سالانه | معمولاً کارفرما | رشد ترافیک و ظرفیت |
مجوز افزونه‌ها و ابزارها | معمولاً سالانه | کارفرما یا از طریق مجری | نرخ ارز |
پیامک | مصرفی | کارفرما | تعداد پیامک ارسالی |
پشتیبانی و نگهداری | طبق قرارداد | کارفرما | دامنه خدمات توافق‌شده |
فرمول سال اول ساده است: اجرای اولیه به‌علاوه هزینه‌های دورهای و مصرفی همان دوره. اما برای سال دوم، هزینه ساخت را تکرار نکنید؛ فقط تمدیدها، مصرف و نگهداری می‌مانند. خیلی از جدول‌های بودجه همین‌جا اشتباه می‌کنند و فروشگاه را هر سال گران‌تر از واقعیت نشان می‌دهند.
رشد ظرفیت و تغییر امکانات هم جزو نگهداری معمول نیستند. اگر فروش زیاد شد و به میزبانی قوی‌تر نیاز پیدا کردید، این هزینه رشد است. اگر روش ارسال تازه‌ای خواستید، این توسعه است. پس هر دو را در ستونی جدا نگه دارید.
برای اینکه هزینه‌ای را دو بار نشمارید، هر قلم را با دوره پوشش و پرداخت‌کننده‌اش ثبت کنید. گاهی مجری مجوزی را می‌خرد و در فاکتور می‌آورد، در حالی که شما همان را جداگانه در بودجه دارید. مبالغ وابسته به ارز، مصرف یا تعرفه سرویس بیرونی را هم پیش از هر تمدید دوباره بررسی کنید.
کدام امکانات را می‌توان به مرحله بعد منتقل کرد؟
امکاناتی را می‌توان عقب انداخت که بدون آن‌ها سفارش همچنان درست ثبت، پرداخت و اجرا می‌شود. پس اول قابلیتهای لازم برای فروش را از قابلیتهای بهبود فروش جدا کنید. باشگاه مشتریان، پیشنهاد محصول مرتبط یا کیف پول معمولاً در گروه دوم‌اند.
اما بعضی چیزها را نباید فقط برای کم‌کردن هزینه طراحی سایت فروشگاهی حذف کرد: صحت موجودی، درستی پرداخت و دسترسی مدیریت. فروشگاهی که کالای ناموجود می‌فروشد، پول صرفه‌جویی‌شده را با مرجوعی و مشتری ناراضی پس می‌دهد.
برای اولویت‌بندی، این ترتیب را پیشنهاد می‌کنم:
تشخیص گلوگاه: کدام بخش اگر نباشد، سفارش متوقف می‌شود؟
انتخاب جایگزین موقت: مثلاً پیامک دستی به‌جای اطلاع‌رسانی خودکار.
ثبت وابستگی: بنویسید قابلیت عقب‌افتاده به کدام بخش‌ها وصل است تا بعداً غافلگیر نشوید.
تعریف شرط بازگشت: مثلاً «وقتی سفارش روزانه از حد مشخصی گذشت، اتصال انبار را اضافه می‌کنیم.»
تعویق اتصال انبار فقط وقتی منطقی است که ورود دستی قابل کنترل باشد. مثلاً با روزی ده سفارش، به‌روزکردن دستی موجودی شاید کار کوتاهی باشد. اما با روزی صد سفارش، هزینه عملیاتی و خطای انسانی‌اش از هزینه اتصال جلو می‌زند. برای دیدن مشکلات رایج این مرحله، چالش‌های ساخت فروشگاه آنلاین و راه‌حل‌های آن را هم ببینید.
از سوی دیگر، معماری آینده را بهانه ساختن همه امکانات در روز اول نکنید. ساختار خوب اجازه می‌دهد قابلیت را بعداً اضافه کنید؛ مجبورتان نمی‌کند همه را حالا بسازید.
پیش‌فاکتورهای ظاهراً مشابه را چگونه مقایسه کنیم؟
به‌جای جمع نهایی، پیش‌فاکتورها را قلم‌به‌قلم و با یک برگه مقایسه کنار هم بگذارید. برگه زیر دو پیشنهاد فرضی برای یک نیاز یکسان را نشان می‌دهد. هیچ‌کدام نماینده شرکت واقعی نیستند و جای مبالغ را عمداً خالی گذاشته‌ایم تا خودتان پرش کنید.
قلم | پیشنهاد الف | پیشنهاد ب |
|---|---|---|
ورود محصول | وضعیت: ...... / مبلغ: ...... | وضعیت: ...... / مبلغ: ...... |
اتصال حسابداری | وضعیت: ...... / مبلغ: ...... | وضعیت: ...... / مبلغ: ...... |
هزینه اولیه | وضعیت: ...... / مبلغ: ...... | وضعیت: ...... / مبلغ: ...... |
تمدید | وضعیت: ...... / مبلغ: ...... | وضعیت: ...... / مبلغ: ...... |
تغییر درخواست | روش قیمت‌گذاری: ...... | روش قیمت‌گذاری: ...... |
معیار تحویل | شرح: ...... | شرح: ...... |
جمع اقلام قابل مقایسه | ...... | ...... |
برای هر قلم یکی از سه وضعیت را بنویسید: داخل مبلغ، جداگانه یا نامشخص. «داخل مبلغ» یعنی پیش‌فاکتور صریحاً آن را پوشش داده است. «جداگانه» یعنی مبلغ مستقل خودش را دارد. «نامشخص» یعنی پیش‌فاکتور درباره‌اش ساکت است.
قلم نامشخص را صفر حساب نکنید. اگر پیشنهادی درباره اتصال حسابداری چیزی نگفته، یعنی هنوز قیمتش را نمی‌دانید، نه اینکه رایگان است. پس از مجری بپرسید و پاسخ را مکتوب بگیرید.
دو عدد را هر کسی میتواند مقایسه کند؛ کار اصلی، مقایسه دو دامنه کار است.
سپس اقلام حذف‌شده را هم‌سطح کنید. اگر پیشنهاد الف ورود محصول را داخل مبلغ دارد و ب ندارد، هزینه ورود محصول را از ب استعلام کنید و به جمعش بیفزایید. فقط بعد از این کار، قیمت طراحی سایت فروشگاهی در دو پیشنهاد واقعاً قابل مقایسه است.
بعد به‌جای پایین‌ترین جمع، به تعهدات قابل آزمون نگاه کنید. «فروشگاه سریع و امن» تعهد قابل آزمون نیست، اما «پنج سفارش آزمایشی کامل روی موبایل بدون خطا» هست. چنین تعهدهایی به شما نشان می‌دهند هزینه طراحی سایت فروشگاهی دقیقاً بابت چه چیزی پرداخت می‌شود.
خانه خالی پیش‌فاکتور را خدمت رایگان فرض نکنید. پیش از مقایسه جمع‌ها، وضعیت هر قلم مبهم را کتبی بپرسید.
تغییر درخواست و تأخیر چگونه هزینه ایجاد می‌کنند؟
هر تغییر درخواست هزینه دارد، چون کاری بیرون از توافق است؛ ولی رفع نقص هزینه ندارد، چون بخشی از همان توافق است. فرض کنید محاسبه هزینه ارسال برای یک شهر اشتباه است؛ این رفع نقص است. اما اگر بخواهید سفارش از دو انبار جداگانه ارسال شود، با تغییر نیاز روبه‌رو هستید و برآورد تازه لازم دارید.
برای هر تغییر یک ثبت کوتاه داشته باشید. الگوی پیشنهادی من این است:
شرح: چه چیزی باید عوض شود
دلیل: چرا این تغییر لازم شده است
بخش‌های درگیر: طراحی، پنل، اتصالها یا داده
اثر بر هزینه و زمان: برآورد مجری برای همین تغییر
تأیید: امضای کسی که حق تصمیم دارد
تأخیر هم شکل دیگری از هزینه است. دیر رسیدن محتوا، دسترسی حسابداری یا تأیید طرح، وابستگی برنامه به شمار می‌آید. با این حال هر تأخیری الزاماً هزینه اضافه ندارد؛ قرارداد تعیین می‌کند کِی تأخیر کارفرما به هزینه تبدیل می‌شود. این بند را پیش از امضا با دقت بخوانید.
در واقع بیشترین هزینه تغییر از بازکاری می‌آید. وقتی ساختار داده محصول بعد از پیاده‌سازی عوض شود، تیم باید بخش‌های زیادی را دوباره بسازد. پس داده محصول و قواعد سفارش را پیش از شروع توسعه تثبیت کنید.
به همین دلیل هم برای همه فروشگاه‌ها زمان ثابت اعلام نمی‌کنیم. زمان پروژه به همان عواملی وابسته است که هزینه طراحی سایت فروشگاهی را تعیین می‌کنند، به‌علاوه سرعت آماده‌شدن وابستگی‌ها از سمت شما.
سه مسیر برای رسیدن بهPackages
این اعداد نقطه‌ی شروع‌اند. قیمت نهایی پس از یک جلسه‌ی مشاوره و بر اساس تعداد صفحات، امکانات و حجم محتوا در پروپوزال کتبی اعلام می‌شود.
برای دریافت برآورد اختصاصی چه اطلاعاتی لازم است؟
اطلاعاتی که برای برآورد اختصاصی لازم است باید دامنه کار را مشخص کند، نه فقط اسم کسب‌وکار و تعداد کالا. این فرم ساده را پر کنید و برای هر مجری بفرستید:
نوع فروش: خرده، عمده یا هر دو
نمونه داده محصول: چند ردیف از فایل واقعی، شامل کالای ساده، پرتنوع و ناموجود
قواعد قیمت: تخفیف، قیمت گروهی، قیمت وابسته به ابعاد یا تعداد
روش ارسال: ثابت، وابسته به وزن و شهر، یا از چند انبار
اتصالها: درگاه پرداخت، حسابداری، انبار، پیامک
نیاز طراحی: طرح اختصاصی یا تطبیق یک قالب با برند
مسئول محتوا: چه کسی عکس و متن را آماده می‌کند
موعد مطلوب: همراه با دلیلش، مثلاً یک فصل فروش
در هر فیلد، پاسخ «هنوز مشخص نیست» مجاز است. این پاسخ از حدس بهتر است، چون مجری می‌فهمد آن موضوع بررسی جداگانه می‌خواهد و آن را با قابلیت قطعی قاطی نمی‌کند.
همچنین سه فهرست کوتاه بنویسید: امکانات ضروری، موارد قابل تعویق و سقف بودجه‌ای که در ذهن دارید. سقف بودجه به مجری کمک می‌کند گزینه‌های واقع‌بینانه پیشنهاد دهد. با این حال، جای برآورد دامنه کار را نمی‌گیرد.
در مقابل، از مجری این خروجی را بخواهید: اقلام اجرا، فرض‌ها، استثناها، هزینه اولیه، تمدیدها و روش قیمت‌گذاری تغییرات. پیش‌فاکتوری که این شش بخش را دارد، با خیال راحت کنار پیشنهادهای دیگر می‌نشیند؛ چون هزینه طراحی سایت فروشگاهی در آن دیگر جای حدس ندارد.
اگر می‌خواهید نیاسا هم پیشنهاد بدهد، همین فرم را برای ما بفرستید. ما نیازها را می‌خوانیم، ابهام‌ها را می‌پرسیم و برآوردی با فرض‌ها و استثناهای مکتوب برمی‌گردانیم. دامنه کار ما را هم در صفحه خدمات طراحی سایت، که در بخش جدول قیمت معرفی شد، ببینید. اما مبلغ یا زمان پاسخ قطعی را پیش از دیدن نیازتان اعلام نمی‌کنیم.
قدم‌های بعدی شما، به همین ترتیب:
نمونه‌ای نماینده از داده محصولات آماده کنید.
فرم بالا را پر کنید و جاهای نامعلوم را صادقانه علامت بزنید.
از هر مجری پیش‌فاکتوری با شش بخش گفته‌شده بخواهید.
برگه مقایسه را پر کنید و فقط بعد از هم‌سطح‌کردن اقلام، تصمیم بگیرید.
نوع فروش، نمونه محصولات و اتصال‌های لازم را برای نیاسا بفرستید تا گفت‌وگو درباره دامنه اجرا و هزینه‌ها بر اساس نیاز مشخص شما پیش برود.
پرسش‌های پرتکرار
۵قیمت طراحی سایت فروشگاهی چقدر است؟
بدون مشخصبودن روش فروش، وضعیت محصولات و اتصالها، یک مبلغ واحد قابل اتکا نیست. جدول جاری خدمات نیاسا را مبنا قرار دهید و برای اقلام خارج از بسته، برآورد جداگانه با تاریخ اعتبار بخواهید.
آیا تعداد محصولات قیمت فروشگاه را تعیین می‌کند؟
تعداد محصولات فقط یکی از عوامل است؛ کیفیت فایل اطلاعات و تنوع هر کالا هم کار اجرایی ایجاد می‌کند. یک کاتالوگ بزرگ و منظم ممکن است ورود ساده‌تری از مجموعه کوچک اما پراکنده و چندحالته داشته باشد.
آیا فروشگاه وردپرسی همیشه ارزانتر است؟
اگر نیازها با قابلیتهای آماده پوشش داده شوند، ممکن است کار توسعه اولیه کمتر باشد. اما سفارشیسازی گسترده، مجوز ابزارها و نگهداری میتوانند نتیجه مقایسه را تغییر دهند.
پشتیبانی در هزینه طراحی فروشگاه حساب می‌شود؟
این موضوع به دامنه پیشنهاد و قرارداد بستگی دارد. مدت پوشش، نوع خدمات و تفاوت رفع اشکال با افزودن امکانات باید صریح نوشته شوند.
چطور هزینه ساخت فروشگاه اینترنتی را کاهش دهیم؟
داده محصول را پیش از اجرا مرتب کنید و قابلیتهای غیرضروری را به زمان مشخص دیگری بسپارید. حذف آزمون پرداخت یا کنترل موجودی، صرفهجویی قابل اتکایی نیست و میتواند هزینه عملیاتی ایجاد کند.
