سه پیشنهاد برای ساخت فروشگاه گرفته‌اید. عنوان‌ها شبیه هم‌اند، اما قیمت و زمان تحویل فاصله زیادی با هم دارند. دلیلش ساده است: هر مجری نیاز شما را جور دیگری فرض کرده است. این راهنمای طراحی سایت فروشگاهی کمک میکند پیش از سفارش، روش ساخت، امکانات ضروری، هزینه‌های مستمر و تعهدات مجری را روشن کنید. حاصل کار یک سند نیازسنجی است که همه پیشنهادها را روی یک زمین مقایسه‌پذیر می‌گذارد.
- پیش از انتخاب فناوری، مسیر سفارش و استثناهای فروشگاه را مکتوب کنید.
- پیشنهادها فقط با دامنه کار، فرض‌ها و معیار تحویل یکسان قابل‌مقایسه‌اند.
- بودجه فروشگاه شامل ساخت، عملیات و نگهداری است؛ فقط مبلغ قرارداد را نبینید.
- مرجع موجودی و مسئول پیگیری پرداخت نامشخص باید پیش از توسعه معلوم باشند.
- خروجی نیازسنجی باید روشن کند چه چیزی اکنون ساخته میشود و چه چیزی عقب می‌افتد.
چه زمانی فروشگاه شما به سایت مستقل نیاز دارد؟
وقتی فروش دستی دیگر از پس حجم سفارش‌ها برنیاید و خطاها هزینه بسازند، فروشگاه شما به سایت مستقل نیاز دارد. اول تعریف را یکی کنیم: فروشگاه اینترنتی فقط ویترین آنلاین نیست. سامانه‌ای است که کالا را نشان می‌دهد، سفارش ثبت میکند و پول می‌گیرد. همچنین عملیات بعد از خرید را قابل‌پیگیری نگه می‌دارد.
این نشانه‌ها معمولاً یعنی وقتش رسیده است:
سفارش‌ها در پیام‌رسان ثبت می‌شوند و گاهی یکی جا می‌افتد یا دو بار ارسال میشود.
مشتری برای فهمیدن وضعیت سفارش باید پیام بدهد و منتظر جواب بماند.
اطلاعات مشتریان در گوشی چند نفر پخش است و به آن دسترسی مطمئنی ندارید.
موجودی را در دفتر یا فایلی جدا نگه می‌دارید و گاهی کالای تمام‌شده را می‌فروشید.
اما تصمیم معکوس هم وجود دارد. اگر تأمین کالا هنوز پایدار نیست یا کسی را برای پاسخ‌گویی روزانه ندارید، سایت مشکل فروش را حل نمی‌کند. فقط همان بی‌نظمی را با هزینه بیشتر جلوی چشم مشتری می‌گذارد.
همچنین لازم نیست سایت را جایگزین صفحه‌های اجتماعی ببینید؛ در بیشتر فروشگاه‌ها این دو کنار هم کار می‌کنند. اولین خروجی این راهنمای طراحی سایت فروشگاهی سه سطر در سند نیازسنجی است: دلیل راه‌اندازی، کانال‌های فروش فعلی و نام کسی که عملیات روزانه سایت با اوست.
پیش از سفارش طراحی سایت فروشگاهی چه چیزهایی را باید مشخص کنیم؟
قدم اول این راهنمای طراحی سایت فروشگاهی ساده است. قبل از سفارش طراحی سایت فروشگاهی، نوع کالا و مشتری، تعداد و تنوع محصولات، روش پرداخت و ارسال و قواعد موجودی را مشخص کنید. اتصالهای لازم، بودجه ساخت و نگهداری و مسئول مدیریت روزانه هم باید روشن باشند. بعد امکانات شروع را از توسعه‌های بعدی جدا کنید و برای هر نیاز، معیار پذیرش و صاحب تصمیم بنویسید.
اگر می‌پرسید برای سفارش سایت فروشگاهی چه باید بدانیم، جواب کوتاهش این است: باید بدانید چه مسئله‌ای را حل می‌کنید. سند نیازسنجی توافق اولیه درباره مسئله، محدودیت‌ها و خروجی مورد انتظار است. فهرست نام فناوری‌ها نیست. به همین دلیل جمله‌ای مثل «با فلان زبان برنامه‌نویسی ساخته شود» تقریباً هیچ‌وقت به برآورد کمک نمی‌کند.
بنابراین پیشنهاد من این است که هر نیاز را در یک ردیف با پنج ستون بنویسید. این قالب ساده ستون اصلی هر راهنمای سفارش سایت فروشگاهی است که به کارفرما می‌دهم:
نیاز | دلیل تجاری | اولویت | مسئول پاسخ‌گویی | روش تأیید |
|---|---|---|---|---|
پیامک تغییر وضعیت سفارش | کم کردن تماس‌های پیگیری | ضروری نسخه اول | مدیر عملیات | با تغییر وضعیت در پنل، پیامک درست به شماره خریدار برسد |
قیمت جدا برای فروش عمده | مشتریان همکار | بعد از نسخه اول | مدیر فروش | فقط کاربر تأییدشده قیمت عمده را ببیند |
در واقع ستون آخر از همه مهم‌تر است. وقتی روش تأیید را ننویسید، روز تحویل هر دو طرف سر «انجام شد یا نشد» بحث می‌کنند. سند را یک بار کامل کنید و همان نسخه را برای همه مجریان بفرستید. در این راهنمای طراحی سایت فروشگاهی، هر بخش ردیف تازه‌ای به همین سند اضافه میکند.
نیازهای فروشگاه را چگونه با سناریوی خرید روشن کنیم؟
سناریوی خرید، نیاز مبهم را به رفتاری قابلآزمون تبدیل میکند. برای مثال، فرض کنید یک فروشگاه پوشاک ۲۰۰ مدل لباس دارد. این عدد کاملاً فرضی است و فقط برای تمرین آمده است.
نکته اول همین‌جاست: ۲۰۰ مدل یعنی ۲۰۰ کالا نیست. اگر هر مدل چهار رنگ و پنج اندازه داشته باشد، با حدود چهار هزار تنوع سروکار دارید. موجودی در سطح تنوع معنا دارد، نه مدل. ممکن است پیراهن آبی سایز M تمام شود، در حالی که همان مدل در رنگ‌های دیگر موجود است.
حالا سه مسیر را کامل بنویسید:
خرید معمولی: خریدار مدل، رنگ و اندازه را انتخاب میکند، پرداخت میکند و پیام تأیید می‌گیرد.
ناموجود شدن هنگام خرید: آخرین عدد سایز L در سبد دو نفر است و یکی زودتر پرداخت میکند. سیستم با نفر دوم چه میکند؟
مرجوعی بخشی از سفارش: خریدار از سه کالا یکی را برمی‌گرداند. مبلغ برگشتی، هزینه ارسال و موجودی چطور اصلاح می‌شوند؟
مسیر دوم همان جایی است که عبارت «مدیریت موجودی» معنا پیدا میکند. پس به‌جای این عبارت کلی بنویسید: «سفارش‌های هم‌زمان نباید بیش از موجودی قابل‌فروش تأیید شوند.» این جمله را تیم آزمون واقعاً می‌تواند امتحان کند.
نیازی که نشود آزمونش کرد، هنوز نیاز نیست؛ آرزویی است که به قرارداد راه پیدا کرده.
برای هر مسیر هم مسئولی تعیین کنید که درباره رفتار درست تصمیم می‌گیرد. مثلاً سیاست مرجوعی با مدیر فروش است، نه با برنامه‌نویس. اگر بپرسید در این راهنمای طراحی سایت فروشگاهی کجا بیشترین وقت را بگذارید، جواب من همین‌جاست.
فروشگاه‌ساز، ووکامرس یا توسعه اختصاصی را انتخاب کنیم؟
انتخاب به این بستگی دارد که فرایند فروش شما چقدر با راهحل آماده جور است، نه به سلیقه یا شهرت ابزار. اول تعریف‌ها:
فروشگاه‌ساز: خدمتی آماده که ساخت و اداره فروشگاه را با اشتراک در اختیارتان می‌گذارد. زیرساخت و به‌روزرسانی با ارائه‌دهنده است.
ووکامرس: ابزار فروشگاهی روی بستر وردپرس که میزبانی و نگهداری‌اش با شما یا مجری است.
توسعه اختصاصی: ساخت سامانه‌ای متناسب با فرایند خاص شما، با کدی که برای همین کار نوشته میشود.
سؤال رایج «سایت فروشگاهی با وردپرس یا اختصاصی» را با تعداد کالا جواب ندهید، چون تعداد کالا معیار خوبی نیست. فروشگاهی با کالای کم ممکن است قیمتگذاری پیچیده‌ای داشته باشد. از سوی دیگر، فروشگاهی با هزاران کالا هم ممکن است با راهحل آماده کاملاً راحت باشد. سناریوهای بخش قبل را روی هر گزینه امتحان کنید و ببینید کدام بدون وصله‌کاری از پسشان برمی‌آید.
معیار | سؤالی که باید بپرسید |
|---|---|
انطباق با فرایند فروش | سناریوهای اصلی بدون تغییر عمده در روش کار ما اجرا می‌شوند؟ |
خروجی گرفتن از داده | محصولات، سفارش‌ها و مشتریان را در قالب استاندارد می‌توانیم بیرون بکشیم؟ |
دسترسی مالک | حساب اصلی و سطح مدیر کامل به نام کسب‌وکار است؟ |
اتصال‌ها | برای حسابداری، انبار و ارسال راه اتصال مستندی وجود دارد؟ |
توان نگهداری | چه کسی به‌روزرسانی و رفع خطا را انجام می‌دهد و با چه هزینه‌ای؟ |
برای غربال اولیه این ترتیب را دنبال کنید:
وقتی سناریوهای شما با امکانات استاندارد یک فروشگاه‌ساز اجرا می‌شوند و اتصال خاصی ندارید، از آن شروع کنید.
اگر به انعطاف بیشتر، افزونه‌های خاص یا میزبانی مستقل نیاز دارید، ووکامرس را بسنجید.
در صورتی که پس از بررسی جدی هیچ راهحل آماده‌ای سناریوی اصلی شما را پوشش نداد، سراغ توسعه اختصاصی بروید.
با این حال این فهرست درخت تصمیم نهایی نیست و فقط گزینه‌های بی‌ربط را کنار می‌گذارد. از نگاه این راهنمای طراحی سایت فروشگاهی، هیچ‌کدام ذاتاً بهتر نیست. «نیاز خاص داریم» هم بهتنهایی دلیل ساخت اختصاصی نیست. در سند بنویسید کدام گزینه را انتخاب کردید، چرا بقیه را کنار گذاشتید و کدام موارد هنوز بررسی فنی لازم دارند.
از مجری بخواهید یک سفارش با تنوع کالا، محدودیت ارسال و تغییر موجودی را نشان دهد. نمایش صفحه اصلی درباره تناسب راهحل با عملیات شما اطلاعات کمی می‌دهد.
سایت فروشگاهی چه امکاناتی دارد و کدام برای شروع ضروری‌اند؟
اگر بپرسید سایت فروشگاهی چه امکاناتی دارد، فهرستش تقریباً بی‌پایان است. اما برای شروع فقط آن‌هایی ضروری‌اند که بدونشان سفارش کامل نمی‌شود یا عملیات می‌لنگد. من امکانات را همیشه در سه دسته می‌گذارم: ضروری برای سفارش، ضروری برای عملیات و قابل‌تعویق.
حداقل مسیر سالم این حلقه‌ها را دارد: اطلاعات کامل محصول، تنوع و موجودی، سبد خرید، پرداخت، محاسبه ارسال، اعلان وضعیت به خریدار و پنل مدیریت سفارش. هر حلقه‌ای که نباشد، یعنی کسی پشت صحنه باید جایش را دستی پر کند.
دسته | نمونه‌ها | قاعده تصمیم |
|---|---|---|
ضروری برای سفارش | صفحه محصول، تنوع، سبد، پرداخت، هزینه ارسال | بدون آن خرید کامل نمی‌شود |
ضروری برای عملیات | مدیریت سفارش، اعلان وضعیت، ثبت مرجوعی، نقش کارکنان | بدون آن کار روزانه دستی و پرخطا می‌ماند |
قابل‌تعویق | باشگاه مشتریان، مقایسه کالا، پیشنهاد خودکار | ارزش دارد، اما نبودش فروش را متوقف نمی‌کند |
بعضی امکانات جای ثابتی ندارند. جست‌وجو و فیلتر برای فروشگاهی با چند ده کالا شاید لازم نباشد، ولی برای فروشگاه پوشاک بخش قبل ضروری است. خرید مهمان، یعنی خرید بدون ساختن حساب کاربری، به خریدهای یک‌باره کمک میکند. کد تخفیف هم اگر کمپین منظم دارید، از روز اول لازم است. هر راهنمای طراحی سایت فروشگاهی که نسخه ثابتی از امکانات بدهد، نیمی از فروشگاه‌ها را به اشتباه می‌اندازد.
برای مثال، فرض کنید بودجه فقط به یکی از این دو می‌رسد: باشگاه مشتریان یا محاسبه درست هزینه ارسال بر اساس شهر و وزن. باشگاه مشتریان می‌تواند چند ماه صبر کند. اما هزینه ارسال اشتباه یعنی یا ضرر روی هر سفارش، یا تماس عصبانی خریدار. در این مرحله از راهنمای طراحی سایت فروشگاهی، دو فهرست تحویل می‌گیرید: داخل و خارج محدوده نسخه اول، با دلیل هر اولویت.
طراحی فروشگاه اینترنتی چقدر هزینه دارد و بودجه چگونه بسته میشود؟
هزینه طراحی فروشگاه اینترنتی به دامنه کار بستگی دارد. به همین دلیل بدون سند نیازسنجی هیچ عدد منصفانه‌ای وجود ندارد. این عوامل بیشترین اثر را روی برآورد می‌گذارند:
دامنه کار: تعداد سناریوها و نقش‌های کاربری، نه تعداد صفحه‌ها.
کیفیت داده: فایل محصول مرتب با شناسه یکتا، یا فهرستی پراکنده که باید پاک‌سازی شود.
طراحی: قالب آماده با تنظیمات، یا طراحی رابط کاربری از پایه.
اتصال‌ها: هر سامانه بیرونی، از حسابداری تا شرکت ارسال، کار و آزمون جداگانه دارد.
آزمون: هر چه سناریوی پرداخت و موجودی بیشتر، آزمون سنگین‌تر.
مهاجرت داده: انتقال سفارش‌ها و مشتریان از سایت قبلی کار کوچکی نیست.
همچنین هزینه ساخت را از بقیه هزینه‌ها جدا ببینید. ورود محتوا، عکاسی محصول، مجوز ابزارها و افزونه‌ها، میزبانی و تبلیغات برای جذب مشتری معمولاً بیرون از قرارداد ساخت‌اند. بسیاری از اختلاف‌ها از همین فرضهای نانوشته شروع می‌شوند.
دو پیشنهاد را فقط وقتی مقایسه کنید که فرض‌هایشان برابر باشد. مثلاً از هر مجری بپرسید ورود چند نوع داده و چند سناریوی اتصال را در قیمت دیده است. پیشنهاد ارزان‌تری که ورود محصولات را به خود شما سپرده، در عمل ارزان‌تر نیست؛ آن کار را بالاخره کسی باید انجام دهد. برای دیدن نسخه مرجع دامنه خدمات ما، صفحه خدمات طراحی سایت فروشگاهی و تعرفه‌های مرجع را ببینید.
بنابراین در سند سه چیز بنویسید: سقف بودجه، هزینه‌هایی که می‌دانید خارج از قرارداد است و مواردی که هنوز مبهم‌اند. گفتن سقف بودجه ضعف مذاکره نیست؛ به مجری کمک میکند دامنه‌ای واقع‌بینانه پیشنهاد کند. هر راهنمای طراحی سایت فروشگاهی که بدون این سقف عدد بدهد، حدس زده است.
هزینه نگهداری و امکان جابه‌جایی را چگونه بسنجیم؟
برای سنجیدن هزینه نگهداری، فهرست کارهای مشخص بخواهید، نه یک مبلغ ماهانه کلی. نگهداری یعنی به‌روزرسانی هسته و افزونه‌ها، پایش خطا، تهیه نسخه پشتیبان، آزمون بازیابی آن و رسیدگی به اختلال. اما ساخت قابلیت جدید جزو نگهداری نیست و توافق جدا می‌خواهد. در این راهنمای طراحی سایت فروشگاهی نگهداری را جدی‌تر از ساخت می‌گیرم، چون فروشگاه چند ماه ساخته میشود و سال‌ها کار میکند.
معمولاً اولین سؤالی که از مجری می‌پرسم این است: اگر ساعت یازده شب پرداخت‌ها خطا بدهند، چه کسی می‌فهمد؟ بعد دو سؤال دیگر:
چه کسی پیگیری میکند و در چه مدتی پاسخ می‌دهد؟
دسترسی لازم برای رفع مشکل، مثل پنل میزبانی یا حساب درگاه، نزد چه کسی است؟
اگر جواب هر سه «خودتان» باشد، اشکالی ندارد. اما باید از قبل بدانید و کسی را برایش داشته باشید.
فروشگاهی که نتوانید از آن بیرون بیایید، دارایی شما نیست؛ اجاره‌ای است که شرطش را دیگری می‌نویسد.
امکان جابه‌جایی هم همین‌قدر مهم است. خروجی گرفتن از محصولات بهتنهایی برای مهاجرت کافی نیست، زیرا سفارش‌های قبلی، اطلاعات مشتریان، تصاویر با کیفیت اصلی و نشانی صفحات هم باید منتقل شوند. رمز عبور کاربران را معمولاً نمی‌شود مستقیم منتقل کرد. در نتیجه ممکن است مشتریان مجبور شوند رمز تازه بسازند.
در سندی که با این راهنمای طراحی سایت فروشگاهی می‌سازید، بنویسید مسئولیت نگهداری با کیست، هزینه‌های دوره‌ای کدام‌اند، چه اقلامی قابل‌انتقال است و در پایان همکاری چه چیزی تحویل می‌گیرید.
صفحه محصول چگونه برای تصمیم خرید ارزیابی شود؟
خریدار باید بتواند بدون تماس با شما تصمیم بگیرد؛ صفحه محصول خوب یعنی همین. آزمون ساده‌اش این است: آیا او می‌فهمد کالا به کارش می‌آید، قیمت نهایی چقدر است، موجود است یا نه و کی به دستش می‌رسد؟ اگر از این راهنمای طراحی سایت فروشگاهی فقط یک آزمون را نگه دارید، همین باشد.
برای فروشگاه پوشاک فرضی ما، راهنمای اندازه و تصویر درست هر رنگ از اسلایدر بزرگ و جلوه‌های تزئینی مهم‌ترند. زیرا خریداری که مطمئن نیست سایز L به او می‌خورد، یا پیام می‌دهد یا صفحه را می‌بندد. اگر هم بخرد، احتمال مرجوعی بالاست.
چند مورد را پیش از دکمه افزودن به سبد روشن کنید:
وضعیت ناموجود هر تنوع و اینکه خریدار می‌تواند برای موجود شدنش خبر بگیرد یا نه.
تفاوت قیمت تنوع‌ها، اگر مثلاً سایزهای بزرگ‌تر گران‌ترند.
شرایط مرجوعی به زبان ساده.
محدودیت ارسال، مثلاً کالایی که به همه شهرها نمی‌رسد.
در عین حال، صفحه را روی گوشی واقعی امتحان کنید، نه فقط در پیش‌نمایش طراح. دکمه‌ها باید با انگشت راحت لمس شوند و متن بدون بزرگ‌نمایی خوانا باشد. همچنین کاربری که فقط با صفحه‌کلید حرکت میکند باید بتواند اندازه را انتخاب کند. برای معیارهای دقیق‌تر، راهنماهای دسترس‌پذیری وب مرجع خوبی است.
خروجی این بخش یک قالب محتوای محصول است: چه فیلدهایی، با چه طولی و چه تصاویری. پس نمونه صفحه را با همین معیارها تأیید کنید، نه با اینکه طرح به چشمتان قشنگ است.
سبد خرید و پرداخت چه معیارهای پذیرشی دارند؟
معیار اصلی این است: خریدار پیش از پرداخت کل مبلغ را بداند و در هیچ خطایی پول و سفارش گم نشوند. قیمت کالا، تخفیف، هزینه ارسال و هر هزینه دیگر باید قبل از رفتن به درگاه جلوی چشم باشد. همچنین خطای فرم باید کنار همان فیلد بیاید، نه بالای صفحه با پیامی کلی.
بیشتر تیم‌ها مسیر موفق را خوب می‌سازند. اما مشکل در مسیرهای دیگر است و هر کدام باید جدا نوشته شوند:
خریدار ناموفق از درگاه برمی‌گردد؛ سبدش باید سر جایش باشد.
پول کسر شده، اما ارتباط پیش از بازگشت به سایت قطع شده است.
خریدار دو بار دکمه پرداخت را زده یا صفحه را تازه کرده است.
در فاصله ورود به درگاه تا بازگشت، آخرین عدد کالا فروخته شده است.
یک قاعده فنی را حتماً در سند بنویسید: تأیید پرداخت باید از مسیر معتبر سمت سرور انجام شود. یعنی سایت خودش از ارائه‌دهنده پرداخت استعلام بگیرد. رسیدی که مرورگر نشان می‌دهد، یا صرف بازگشت کاربر به سایت، اثبات پرداخت نیست. در این راهنمای طراحی سایت فروشگاهی، این بخش را با بیشترین دقت بخوانید؛ چون خطای پرداخت مستقیم به اعتماد خریدار ضربه می‌زند.
وضعیت | معنا | اقدام بعدی |
|---|---|---|
در انتظار پرداخت | سفارش ساخته شده، اما پولی تأیید نشده | لغو پس از مدت مشخص و آزادسازی موجودی |
پرداخت نامشخص | کسر وجه محتمل است، اما تأیید سرور نرسیده | استعلام دوباره و پیگیری با درگاه |
پرداخت‌شده | تأیید از سمت سرور رسیده | آماده‌سازی و ارسال |
بازپرداخت | تمام یا بخشی از مبلغ برگشته | اصلاح موجودی و گزارش مالی |
خروجی سند همین فهرست وضعیت‌هاست، به‌علاوه قاعده پیگیری تراکنش نامشخص و نام کسی که به خریدار نگران جواب می‌دهد.
سئو از کجا وارد طراحی فروشگاه میشود؟
از همان روزی که ساختار دسته‌ها و نشانی صفحات را تعیین می‌کنید، سئو وارد طراحی شده است. سئو یعنی آماده کردن صفحات تا موتور جست‌وجو آن‌ها را پیدا کند و بفهمد. پس آن را به نوشتن چند مقاله بعد از تحویل محدود نکنید؛ تا آن موقع بیشتر تصمیم‌های اثرگذار گرفته شده‌اند. به همین دلیل در راهنمای طراحی سایت فروشگاهی، سئو کنار ساختار می‌آید، نه کنار تبلیغات.
سه تصمیم را پیش از ورود گسترده محتوا بگیرید. اول، نقشه دسته‌ها و زیردسته‌ها. دوم، نشانی پایدار محصول؛ نشانی‌ای که با تغییر قیمت یا دسته عوض نشود. سوم، رفتار صفحات فیلتر. در واقع ترکیب رنگ و اندازه و قیمت می‌تواند هزاران نشانی تکراری بسازد، در حالی که فقط چندتایشان ارزش دیده شدن دارند.
تفاوت کالای موقتاً ناموجود با کالای حذف‌شده را هم روشن کنید. صفحه کالایی که دوباره می‌آید باید بماند و فقط وضعیتش عوض شود. اما کالایی که برای همیشه حذف شده، بهتر است با تغییر مسیر دائمی به نزدیک‌ترین کالا یا دسته برود.
در بازطراحی، پیش از انتشار فهرست کامل نشانی‌های قبلی و مقصد جایگزین هر کدام را آماده کنید. هیچ‌کس نمی‌تواند رتبه را تضمین کند؛ با این حال، با رعایت مستندات رسمی الزامات جست‌وجوی گوگل جلوی آسیب‌های قابل‌پیشگیری را می‌گیرید. خروجی سند: نقشه دسته‌ها، قواعد صفحات فیلتر و مسئول تهیه محتوای محصول.
اندازه‌گیری فروش چگونه از ابتدا قابل‌اعتماد شود؟
پیش از راه‌اندازی تعریف کنید دقیقاً چه چیزی را می‌شمارید؛ اندازه‌گیری فقط در این صورت قابل‌اعتماد است. رویداد یعنی ثبت یک اقدام مشخص کاربر، مثل افزودن کالا به سبد. بازدید صفحه، شروع پرداخت و خرید تأییدشده سه رویداد جدا هستند و نباید با هم قاطی شوند.
دو خطای رایج را از اول در نظر بگیرید. اگر رویداد خرید با بار شدن صفحه تشکر ثبت شود، هر تازه‌سازی آن صفحه یک خرید جدید در گزارش می‌سازد. خطای دوم انتظار نادرست است: آمار ابزار تحلیل تقریباً هیچ‌وقت با سفارش‌های واقعی یکی نیست، چون برخی کاربران ردیابی را مسدود می‌کنند.
بنابراین مرجع فروش، پنل سفارش‌هاست. مبلغ ثبت‌شده را به‌طور منظم با پرداخت‌ها، لغوها و بازپرداخت‌ها تطبیق دهید. تعداد بازدید بهتنهایی نشان نمی‌دهد فروشگاه موفق است یا نه. برای پیدا کردن جایی که خریدار رها میکند، تحلیل سفر مشتری برای یافتن موانع خرید را بخوانید.
یک نکته امنیتی هم هست. نام، شماره تماس و نشانی مشتری را بی‌دلیل به ابزار تحلیل نفرستید و دسترسی گزارش‌ها را فقط به کسانی بدهید که لازمش دارند. سهم این قسمت از راهنمای طراحی سایت فروشگاهی در سند شما سه قلم است: فهرست رویدادها، تعریف دقیق خرید موفق و مسئول بررسی اختلاف گزارش‌ها.
اتصال به حسابداری و انبار چه پیش‌نیازهایی دارد؟
پیش‌نیاز اصلی اتصال، توافق روی داده است، نه وجود فنی راه اتصال. رابط برنامه‌نویسی یا API مسیری است که دو سامانه از طریق آن داده رد و بدل می‌کنند. اینکه نرم‌افزار حسابداری شما API دارد، فقط یعنی در باز است؛ اما نمی‌گوید پشت در چه خبر است. این بخش از راهنمای طراحی سایت فروشگاهی معمولاً بیشترین اثر را روی برآورد دارد.
قبل از برآورد این‌ها را روشن کنید:
مرجع نهایی: قیمت و موجودی را کدام سامانه تعیین میکند؟
شناسه مشترک: هر تنوع کالا در هر دو سامانه کد یکسانی دارد؟
فاصله به‌روزرسانی: لحظه‌ای، هر چند دقیقه یا روزی یک بار؟
رزرو موجودی: کالا با افزودن به سبد رزرو میشود یا با پرداخت؟
برای مثال، فرض کنید حسابداری هر شب موجودی را برای سایت می‌فرستد. در نتیجه فروش حضوری ظهر تا شب در سایت دیده نمی‌شود و همان کالا آنلاین هم فروخته میشود. پس یا این ریسک را آگاهانه بپذیرید، یا فاصله به‌روزرسانی را کوتاه کنید.
همچنین ارسال دوباره یک پیام نباید سفارش یا سند حسابداری تکراری بسازد، چون ارتباط گاهی قطع میشود و سامانه‌ها دوباره تلاش می‌کنند. باید معلوم باشد خطا کجا ثبت میشود، چند بار تلاش مجدد انجام میشود و چه کسی خبردار میشود.
اگر حضوری و آنلاین هم‌زمان می‌فروشید، این سناریو را پیش از برآورد با مسئول حسابداری مرور کنید. لغو سفارش و برگشت کالا هم باید در هر دو سمت درست ثبت شود. خروجی سند: فهرست داده‌های مبادله‌شونده، مستندات اتصال و مسئول تأیید هر سمت.
ثبت سفارش در حسابداری پایان کار نیست. مشخص کنید لغو یا برگشت کالا چگونه به موجودی و وضعیت سفارش برمی‌گردد.
چه مدارک و دسترسی‌هایی باید پیش از شروع آماده شوند؟
پیش از شروع باید داده محصول، هویت برند، قواعد عملیاتی، مدارک حقوقی و دسترسی حساب‌ها آماده یا دست‌کم مشخص باشند. فهرست پایه‌ای که در این راهنمای طراحی سایت فروشگاهی پیشنهاد می‌کنم این است:
فایل داده محصولات با نام، توضیح، قیمت، تنوع و شناسه هر کالا
تصویرهای محصول با کیفیت و نسبت یکسان
هویت برند: لوگو، رنگ‌ها، فونت و لحن متن
قواعد ارسال، مرجوعی و بازپرداخت به‌صورت مکتوب
مشخصات حقوقی کسب‌وکار برای درگاه و صفحات قانونی
نام کسی که محتوای نهایی را تأیید میکند
اما الزامات ارائه‌دهنده پرداخت و مجوزهای مرتبط با نوع فعالیت ممکن است تغییر کنند. پس آن‌ها را به‌روز و از مرجع رسمی همان خدمت بررسی کنید. حکم ثابتی برای همه فروشگاه‌ها وجود ندارد و فروش برخی کالاها شرایط جداگانه دارد.
درباره دسترسی‌ها سخت‌گیر باشید. دامنه و حساب‌های اصلی، مثل میزبانی و درگاه، باید به نام و زیر کنترل کسب‌وکار باشند. بنابراین به مجری حساب جداگانه با حداقل سطح لازم بدهید، نه رمز حساب اصلی. جزئیات بیشتر را در پیش‌نیازهای ساخت سایت و آماده‌سازی دسترسی‌ها آورده‌ایم.
یک هشدار هم دارم: در درخواست اولیه برآورد، رمز، کلید اتصال یا اطلاعات مشتری نفرستید؛ در این مرحله هیچ مجری‌ای به آن‌ها نیاز ندارد. در سند بنویسید چه چیزی آماده است، چه چیزی ناقص است، مالک هر حساب کیست و هر قلم تا چه تاریخی لازم است.
مالکیت و مسئولیت‌های پروژه چگونه در قرارداد روشن شوند؟
قلم به قلم مالکیت را در قرارداد بنویسید، چون «سایت مال شماست» جمله‌ای است که هر طرف جور دیگری می‌فهمد. در این راهنمای طراحی سایت فروشگاهی، این اقلام را جدا از هم می‌بینیم: دامنه، داده‌ها، فایل‌های طراحی، کد قابل‌تحویل و مجوز استفاده از ابزارهای ثالث.
با این حال همه اجزا لزوماً قابل‌انتقال نیستند. قالب یا افزونه‌ای که با مجوز سالانه خریده‌اید، معمولاً مال شما نمی‌شود و فقط حق استفاده‌اش را دارید. در فروشگاه‌ساز هم کد زیربنایی متعلق به ارائه‌دهنده است. شرایط مجوزها و اشتراک‌ها را پیش از سفارش بخوانید.
مرز دیگر، فرق رفع نقص با قابلیت تازه است. برای مثال، فرض کنید در سند نوشته‌اید کد تخفیف روی کالاهای حراجی اعمال نشود، اما اعمال میشود. این نقص است و رفعش با مجری است. ولی اگر حالا بخواهید کد فقط برای خرید اول کار کند و این در سند نبوده، درخواست تازه است و برآورد جدا می‌خواهد.
موضوع | کارفرما | مجری |
|---|---|---|
داده و تصاویر محصول | تهیه و تأیید | ورود داده در حد توافق |
دامنه و حساب‌های اصلی | مالکیت و نگهداری | دسترسی محدود برای اجرا |
رفع نقص نسبت به سند | گزارش همراه با شواهد | اصلاح در مدت توافق‌شده |
تغییر دامنه کار | ثبت مکتوب درخواست | اعلام اثر بر هزینه و زمان |
این متن جای مشاوره حقوقی را نمی‌گیرد. برای نکته‌های بیشتر، راهنمای تنظیم قرارداد طراحی سایت را ببینید و قرارداد نهایی را به مشاور حقوقی‌تان نشان دهید.
داشتن رمز ورود الزاماً به معنای مالکیت حساب یا امکان انتقال آن نیست. نام دارنده حساب، روش بازیابی و محدودیت انتقال را جداگانه ثبت کنید.
زمان‌بندی پروژه به چه تصمیم‌ها و وابستگی‌هایی گره خورده است؟
بیشتر از سرعت تیم اجرا، تصمیم‌ها و ورودی‌های شما زمان‌بندی را تعیین می‌کنند. وقتی مجری زمان می‌دهد، چند وابستگی را فرض گرفته است. محتوا به‌موقع آماده میشود و طراحی در مدت معقول تأیید میشود. دسترسی اتصال‌ها می‌رسد و طرف‌های بیرونی، مثل درگاه یا شرکت ارسال، جواب می‌دهند.
زمان تقویمی را از زمان کار تیم جدا کنید. ممکن است کار واقعی چند هفته باشد، اما انتظار برای فایل محصولات یا تأیید طرح کل مسیر را متوقف کند. به همین دلیل در گزارش‌های پروژه، انتظارها را همیشه جدا ثبت می‌کنم تا معلوم باشد تأخیر از کجا آمده است.
اگر تاریخ تجاری ثابتی دارید، مثلاً شروع فصل فروش، دو راه پیش رویتان است: کوچک کردن دامنه نسخه اول یا فشرده کردن آزمون‌ها. پیشنهاد من تقریباً همیشه اولی است، چون حذف آزمون پرداخت برای رسیدن به تاریخ، ریسکی است که روز اول فروش خودش را نشان می‌دهد.
در سند تاریخ هدف، وابستگی‌های باز، مسئول هر تصمیم و قاعده اثر تغییر دامنه بر زمان را بنویسید. این راهنمای طراحی سایت فروشگاهی روی تصمیم‌ها تمرکز دارد؛ شرح گام‌به‌گام اجرا را در مراحل طراحی سایت فروشگاهی؛ از قرارداد تا تحویل آورده‌ایم.
فروشگاه آماده تحویل چه آزمون‌هایی دارد؟
وقتی فروشگاه سناریوهای سند نیازسنجی را با موفقیت بگذراند، آماده تحویل است؛ باز شدن صفحه اصلی چیزی را ثابت نمی‌کند. پس معیار پذیرش را از همان جدولی بیرون بکشید که ستون روش تأیید داشت.
متناسب با دامنه توافق، این راهنمای طراحی سایت فروشگاهی دست‌کم این آزمون‌ها را پیشنهاد میکند:
خرید کالا با تنوع مشخص و بررسی کسر موجودی همان تنوع
تلاش هم‌زمان برای خرید آخرین عدد کالا از دو دستگاه
ارسال به منطقه‌ای با هزینه متفاوت
اعمال کد تخفیف، و حالتی که نباید اعمال شود
پرداخت ناموفق و بازگشت به سبد
بازپرداخت کامل و جزئی
همچنین نسخه پشتیبان را واقعاً بازیابی کنید، آن هم در محیطی جدا از سایت اصلی. پشتیبانی که هیچ‌وقت بازیابی نشده، فقط یک فرض است. حساب مدیر، سطح دسترسی کارکنان و حذف دسترسی‌های موقت مجری را هم بررسی کنید.
برای سرعت و ظرفیت، عدد بی‌زمینه معیار پذیرش نیست. شرایط آزمون را بنویسید: چه دستگاهی، چه شبکه‌ای و چه تعداد کاربر هم‌زمان. به همین دلیل جمله «صفحه در سه ثانیه باز میشود» بدون این شرایط چیزی را ثابت نمی‌کند.
پیشنهاد من این است که آزمون پذیرش را خود کارفرما با حضور مجری اجرا کند. نتیجه هر آزمون را با شواهد، مثل تصویر یا شماره سفارش آزمایشی، ثبت کنید و برای هر خطا مسئول اصلاح بگذارید. خطاها را هم دو دسته کنید: آن‌هایی که مانع انتشارند و آن‌هایی که بعد از انتشار قابل‌پیگیری‌اند.
راهنمای طراحی سایت فروشگاهی چگونه به سند تصمیم تبدیل میشود؟
این راهنمای طراحی سایت فروشگاهی وقتی به سند تصمیم تبدیل میشود که خروجی هر بخش را در چهار خوشه جمع کنید. هر خوشه یک پرسش باز دارد و تا جوابش مکتوب نشود، بسته نیست.
خوشه | پرسش باز | خروجی مکتوب |
|---|---|---|
مدل فروش | چه می‌فروشیم، به چه کسی و از چه کانال‌هایی؟ | دلیل راه‌اندازی، کالا و تنوع، سناریوهای خرید |
روش ساخت | کدام راهحل سناریوهای ما را بدون وصله‌کاری اجرا میکند؟ | گزینه منتخب، دلیل رد بقیه، بودجه و نگهداری |
تجربه خرید | خریدار در کدام نقطه مردد می‌ماند یا رها میکند؟ | قالب صفحه محصول، معیارهای پرداخت، سئو و اندازه‌گیری |
آمادگی تحویل | چه چیزی باید پیش از انتشار درست کار کند؟ | اتصال‌ها، مدارک، قرارداد، زمان‌بندی و آزمون‌ها |
جدول را نقشه راه مطالعه هم ببینید. اگر در یک خوشه به موضوعی رسیدید که تخصص جدا می‌خواهد، مثل مالیات فروش آنلاین یا طراحی برنامه وفاداری، آن را موضوع مطالعه تکمیلی علامت بزنید. یعنی لازم نیست همه را پیش از درخواست برآورد حل کنید.
برای نمونه، فرض کنید در سند نوشته‌اید «اتصال انبار لازم است». تا وقتی تعیین نکرده‌اید مرجع موجودی کدام سامانه است، وضعیت این ردیف «بررسی‌نشده» است، نه «تصمیم‌گرفته». همین برچسب ساده به مجری می‌گوید کجا باید بپرسد و کجا می‌تواند برآورد بدهد.
نسخه یکپارچه سند سه بخش دارد: فرض‌ها، تصمیم‌های قطعی و ابهام‌های باقی‌مانده. پنهان کردن ابهام‌ها برآورد را دقیق‌تر نمی‌کند؛ فقط غافلگیری را عقب می‌اندازد.
برای دریافت برآورد از نیاسا چه اطلاعاتی بفرستیم؟
سند نیازسنجی را همراه چند نمونه واقعی بفرستید؛ این خلاصه عملی کل این راهنمای طراحی سایت فروشگاهی است. این قالب را کپی و کامل کنید:
نوع فروش: خرده‌فروشی، عمده یا هر دو
کالا و تنوع: تعداد تقریبی مدل‌ها و ویژگی‌های تنوع مثل رنگ و اندازه
کانال فعلی: فروش حضوری، شبکه‌های اجتماعی یا سایت قبلی
مشکلات عملیاتی: جاهایی که امروز خطا یا اتلاف وقت دارید
امکانات ضروری: فهرست داخل محدوده نسخه اول
اتصال‌ها: حسابداری، انبار، ارسال، پیامک
بودجه: سقف ساخت و نگهداری
تاریخ هدف: همراه با دلیل تجاری آن
کنار سند، دو نمونه محصول کامل و یک سناریوی سفارش پیچیده بفرستید؛ مثلاً سفارشی با تخفیف و مرجوعی جزئی. اگر از داده واقعی استفاده می‌کنید، نام و شماره و نشانی مشتری را پیش از ارسال پاک کنید.
در نیاسا ترجیح می‌دهیم پیشنهاد طراحی سایت فروشگاهی را با دامنه کار، فرض‌ها، استثناها، وابستگی‌ها و معیار تحویل بنویسیم. پس از ما همین را بخواهید. البته این موارد در گفت‌وگوی نیازسنجی دقیق می‌شوند و از پیش قطعی نیستند.
اگر هنوز روش ساخت را انتخاب نکرده‌اید، قیمت قطعی نخواهید؛ با کمک همین راهنمای طراحی سایت فروشگاهی درخواست بررسی گزینه‌ها بدهید. چون قیمت قطعی برای پروژه‌ای با دامنه نامعلوم یا پر از حاشیه امن است، یا پر از استثنا.
سند را هر قدر هم ناقص است بفرستید. در گفت‌وگوی نیازسنجی با هم می‌بینیم کدام ردیف‌ها قطعی‌اند و کدام هنوز سؤال دارند.
شرح فروشگاه، امکانات ضروری و ابهام‌های فنی را برای نیاسا بفرستید تا مبنای گفتوگو درباره روش ساخت و دامنه پروژه باشند.
پرسش‌های پرتکرار
۵برای سفارش سایت فروشگاهی چه باید بدانیم؟
باید بتوانید مسیر یک سفارش را از انتخاب کالا تا تحویل و مرجوعی توضیح دهید. لازم نیست فناوری را از قبل انتخاب کنید؛ قواعد فروش و محدودیت‌های عملیاتی شما ورودی مهم‌تری برای تصمیم فنی هستند.
سایت فروشگاهی با وردپرس بهتر است یا اختصاصی؟
پاسخ به میزان انطباق راهحل آماده با فرایند شما و توان نگهداری بستگی دارد. پیش از انتخاب، سناریوهای دشوار فروشگاه را آزمایش کنید؛ تعداد زیاد کالا بهتنهایی دلیل کافی برای توسعه اختصاصی نیست.
بدون تعیین امکانات میتوان هزینه طراحی فروشگاه را فهمید؟
میتوان درباره حدود دامنه و عوامل هزینه گفتوگو کرد، اما پیشنهادهای بدون فرضهای روشن قابلمقایسه نیستند. برای برآورد کاربردی، امکانات شروع، وضعیت محتوا و اتصالهای ضروری را مشخص کنید.
آیا اتصال حسابداری باید در نسخه اول انجام شود؟
اگر ثبت دستی باعث اختلاف موجودی یا اختلال روزانه میشود، اتصال ممکن است از نیازهای شروع باشد. اگر حجم عملیات فعلاً قابلکنترل است، میتوان آن را عقب انداخت؛ به شرط آنکه شناسه کالا و مسیر انتقال داده از ابتدا روشن باشند.
آیا داشتن سایت فروشگاهی فروش را تضمین میکند؟
خیر؛ سایت مسیر خرید را فراهم میکند، اما تقاضا، قیمتگذاری، تأمین کالا و جذب مشتری همچنان تعیینکنندهاند. هدفهای پروژه را به خروجیهای قابلآزمون گره بزنید، نه وعده افزایش فروش بدون فرض مشخص.
