فروشگاه در Demo عالی است: محصول به سبد میرود و درگاه باز میشود. در اولین هفته واقعی، دو مشتری آخرین کالا را همزمان میخرند، تخفیف روی قیمت اشتباه اعمال میشود، پرداخت موفق با سفارش «در انتظار» میماند و تیم پشتیبانی نمیداند بازپرداخت را از کجا پیگیری کند. Feature «سبد و درگاه» وجود داشت؛ قرارداد داده، State و عملیات وجود نداشت.
پاسخ کوتاه: امکانات ضروری سایت فروشگاهی از مدل کسبوکار و Journey استخراج میشوند، نه از فهرست افزونهها. هر قابلیت باید Trigger، Actor، Data، Rule، Stateهای موفق/خطا، Owner، Acceptance و Metric داشته باشد. نسخه نخست باید یک سفارش واقعی را از کشف محصول تا پرداخت، تحویل، مرجوعی، تطبیق مالی و پشتیبانی بدون ابهام کامل کند.
این راهنما برای مدیر کسبوکار، Product owner و تیم خرید/توسعه نوشته شده است تا پیش از سفارش فروشگاه، Requirementهای مشتری و عملیات را بنویسند، قابلیتها را اولویت دهند و Proposal یا Platform را با Evidence بسنجند.
فروشگاه حرفهای یعنی سیستم سفارش، نه ویترین محصول
فروشگاه حداقل شش جریان بههمپیوسته دارد:
| جریان | شروع | Outcome |
|---|---|---|
| Discover | Search/Category/Campaign | Product/Offer مناسب پیدا میشود |
| Decide | صفحه محصول و مقایسه | SKU، Seller و تعهد روشن انتخاب میشود |
| Commit | Cart/Checkout/Payment | Order یکتا با مبلغ و وضعیت قطعی ساخته میشود |
| Fulfill | Allocation/Pick/Pack/Ship | کالای درست، کامل و بهموقع میرسد |
| Recover | Error/Cancel/Return/Refund | پول، موجودی و ارتباط با مشتری Reconcile میشوند |
| Learn | Event/Order/Support/Finance data | تصمیم بعدی با داده قابل اعتماد گرفته میشود |
قابلیتی که یکی از این جریانها را بهتر نمیکند، ممکن است برای نسخه نخست ضروری نباشد. قابلیتی که فقط Happy path را دارد نیز «کامل» نیست.
مدل فروش، چکلیست را تغییر میدهد
| مدل | قابلیتهای خاص | ریسک محوری |
|---|---|---|
| B2C کالای فیزیکی | Inventory، Shipping، Return و Payment | Oversell، Delivery و Refund |
| کالای دیجیتال | Entitlement، Download، License و Revocation | دسترسی نادرست و سوءاستفاده |
| خدمت/رزرو | Capacity، Calendar، Slot، Cancellation | Double booking و Timezone |
| Subscription | Recurring billing، Renewal، Pause/Cancel | Dunning، Consent و Entitlement |
| Marketplace | Seller onboarding، Split/settlement، Dispute | مسئولیت و Reconciliation چندطرفه |
| B2B/عمده | Account approval، Price list، Quote، Credit limit | مجوز قیمت/سفارش و Workflow |
| Omnichannel | Store stock، Pickup، Return-anywhere | Source of truth بین کانالها |
پس «اپلیکیشن، Wishlist یا مقایسه» ذاتاً ضروری یا غیرضروری نیستند. مدل فروش، تکرار خرید، پیچیدگی تصمیم و عملیات تعیینکنندهاند.
قالب Requirement هر قابلیت
بهجای «فروشگاه باید کد تخفیف داشته باشد»، قابلیت را اینگونه بنویسید:
| فیلد | نمونه برای کد تخفیف |
|---|---|
| Outcome | اجرای Promotion بدون کاهش کنترلنشده Margin |
| Actor/Permission | Marketing میسازد؛ Finance سقف را تأیید میکند |
| Trigger | ورود Code در Cart/Checkout |
| Data | Code، زمان، Audience، Product scope، budget، uses |
| Rule | Stacking، حداقل خرید، Variant، Channel و Refund |
| States | Valid، Expired، Exhausted، Ineligible، Removed |
| Failure/Recovery | پیام دلیل و حفظ Cart؛ Fail closed/open طبق ریسک |
| Acceptance | Timezone، concurrency، refund و reporting pass |
| Metric/Guardrail | Redemption و margin/abuse/error |
| Owner | Promotion product owner + Operations |
همین قالب برای Search، Payment، Return، Notification و Admin استفاده میشود. «Feature دارد» با «برای Rule ما درست کار میکند» متفاوت است.
نقشه Journey و عملیات را کنار هم بکشید
| مرحله مشتری | عملیات پشت صحنه | سؤال Requirement |
|---|---|---|
| محصول را میبیند | Catalog/Price/Stock sync | Freshness و Source هر Field چیست؟ |
| Variant را انتخاب میکند | SKU و Availability resolve | Combination نامعتبر چگونه منع میشود؟ |
| به سبد میافزاید | Price snapshot/Cart state | رزرو موجودی چه زمانی است؟ |
| پرداخت میکند | Payment intent/Order transition | Retry/Callback/duplicate چه میشود؟ |
| پیگیری میکند | Fulfillment/Carrier event | وضعیت داخلی چگونه به زبان مشتری ترجمه میشود؟ |
| مرجوع میکند | Inspection/Restock/Refund | موجودی، حسابداری و Notification چگونه Reconcile میشوند؟ |
۱. Catalog و داده محصول
قبل از UI، مدل داده را مشخص کنید:
- Product group، SKU/Variant، Bundle و Service؛
- Brand، Category، Attribute، Unit و Vocabulary؛
- Title، Description، Media و Documents؛
- Price list، Tax/fee context، Currency و تومان/ریال؛
- Stock/Availability/Backorder؛
- Seller، Condition، Warranty و Authenticity؛
- Shipping class، Weight/Dimension و restriction؛
- Identifier مانند SKU/GTIN/MPN در صورت کاربرد؛
- Lifecycle: Draft، Active، Out-of-stock، Discontinued، Successor؛
- Source، Owner، validation و freshness هر Field.
ورود CSV بدون Schema، Dictionary و Reconciliation داده بد را سریعتر وارد میکند. Import باید Dry run، Error report، Idempotency و Rollback داشته باشد.
۲. دستهبندی، ناوبری، جستوجو و فیلتر
- Taxonomy از زبان مشتری و Mental model، نه فقط انبار؛
- Category→Subcategory→Product link قابل Crawl؛
- Search فارسی با ی/ک، نیمفاصله، رقم و Synonym policy؛
- Typo tolerance کنترلشده و Zero-result recovery؛
- Filter از Attribute تمیز و Count معتبر؛
- Sort با Definition روشن: قیمت، جدید، پرفروش یا مرتبط؛
- Selected filters قابل دیدن/حذف و State در Back/Share حفظ شود؛
- Facet URL، Canonical و Index policy؛
- Empty/loading/error و timeout state؛
- Measurement از Query→Result→Click→Order.
Google توضیح میدهد که Crawler معمولاً Search box را Submit نمیکند؛ Productهای قابل ایندکس باید از Navigation/Link یا Sitemap/Feed قابل کشف باشند.
۳. کارت و صفحه محصول
کاربر باید Product، Variant، Offer و تعهد را بدون حدس انتخاب کند:
- عنوان و تصویر نماینده دقیق؛
- Variant با تصویر/قیمت/موجودی همگام؛
- قیمت، واحد، تخفیف و شرایط؛
- موجودی و Promise ارسال وابسته به مقصد؛
- Benefit، Spec و Compatibility؛
- Seller/Condition/Warranty در Marketplace؛
- Review/Q&A با Moderation؛
- مرجوعی، ارسال و اقلام داخل بسته؛
- CTA با Pending/Success/Error/stock-change state؛
- Product/Offer/Variant Schema همخوان با صفحه و Feed.
قرارداد کامل Card/PDP/Variant در راهنمای نمایش محصول فروشگاهی آمده است.
۴. Cart؛ Quote زنده با State روشن
| قابلیت | Rule لازم | Failure test |
|---|---|---|
| Add/update/remove | Quantity/min/max/step و SKU | Double-click و Network retry |
| Persist | Guest/account، expiry و merge | Login، device و stale cart |
| Price | Snapshot/refresh و اطلاع تغییر | Campaign پایانیافته |
| Inventory | رزرو در Cart/Checkout/Payment | آخرین واحد همزمان |
| Promotion | Eligibility/stacking/budget | کد منقضی یا abuse |
| Shipping estimate | Destination/method/threshold | هزینه پنهان تا آخر |
| Total | Item/discount/shipping/tax/fee | ریال/تومان و rounding |
۵. Checkout مهمان، حساب و آدرس
ساخت حساب را فقط وقتی Require کنید که Outcome نیاز دارد. Requirementها:
- Guest checkout یا دلیل روشن برای حساب؛
- حداقل Field لازم و Autofill/Autocomplete مناسب؛
- موبایل ایران با ۰۹/+۹۸ و رقم فارسی/لاتین طبق Policy؛
- آدرس چندخطی، استان/شهر، کدپستی و پلاک/واحد طبق Fulfillment؛
- Label، Hint، Error summary و حفظ مقدار درست؛
- Shipping/Billing address و Same-as کنترلشده؛
- Review order پیش از Commit؛
- Session expiry، Back/Refresh و Multi-tab؛
- Consentهای مستقل و غیرپیشفرض برای Marketing؛
- Accessible authentication و Recovery.
جزئیات Funnel، Form state، خطا و Experiment در راهنمای بهینهسازی Checkout قرار دارد.
۶. پرداخت و State machine سفارش
بازشدن درگاه موفقیت پرداخت نیست. یک State machine مشخص کنید:
| State | معنا | عملیات مجاز |
|---|---|---|
| Draft/Cart | هنوز Order قطعی نیست | ویرایش و Reprice |
| Payment pending | Intent ساخته، نتیجه قطعی نیست | Poll/verify؛ Fulfill ممنوع |
| Paid | نتیجه Server-side تأیید و مبلغ Match | Allocation/Fulfillment |
| Payment failed | Failure قطعی | Retry امن و روش جایگزین |
| Unknown | Callback/timeout مبهم | Reconcile؛ سفارش تکراری ممنوع |
| Cancelled | تعهد لغو | Release inventory و Refund policy |
| Partially/full refunded | پول بازگشته طبق Evidence | Accounting/notification |
- Idempotency برای ایجاد Order/Payment/Callback؛
- تأیید مبلغ، Currency، Order و Provider response در Server؛
- Webhook/Callback signature و Replay control؛
- Timeout و Unknown-state reconciliation job؛
- Retry بدون Double charge؛
- Payment method eligibility و fallback؛
- Refund کامل/جزئی و Reason؛
- Daily settlement/reconciliation با Finance.
مدل انتخاب روش پرداخت، Wallet/BNPL، ریسک و Reconciliation در راهنمای روشهای پرداخت فروشگاه توضیح داده شده است.
۷. موجودی و رزرو
منبع واقعیت موجودی و زمان Reservation را تعیین کنید:
- Available = on-hand − allocated − safety stock طبق تعریف؛
- رزرو در Add-to-cart، Checkout یا Payment با TTL؛
- Release روی timeout/cancel/fail؛
- Backorder/Preorder و Promise؛
- Multi-warehouse allocation و split shipment؛
- Cycle count، adjustment reason و audit log؛
- Oversell policy و approval؛
- Bundle component availability؛
- Return inspection و restock/dispose؛
- Sync conflict، lag و manual override.
۸. Fulfillment، ارسال، تحویل و مرجوعی
| حوزه | Requirement | Edge case |
|---|---|---|
| Allocation | انبار/فروشنده و SLA | Partial stock |
| Pick/Pack | SKU/quantity/serial/quality check | Substitution یا damaged |
| Shipping rate | مقصد/وزن/ابعاد/روش/threshold | Remote area و محدودیت کالا |
| Promise | Handling cutoff + Carrier ETA | تعطیل/ظرفیت/تاخیر |
| Tracking | Status map و tracking code | Carrier update missing |
| Delivery | Proof/failed delivery | آدرس/گیرنده نامعتبر |
| Return | Eligibility/window/reason/method | Partial/bundle/used item |
| Refund | Inspection→decision→payment | قیمت تخفیف و هزینه ارسال |
طراحی دقیق Inventory/Fulfillment/Return با KPI و تست در راهنمای انبار و ارسال فروشگاه آمده است.
۹. قیمتگذاری، Promotion و مالیات/کارمزد
- Price list براساس Channel/Customer/Quantity در صورت نیاز؛
- تومان/ریال و تبدیل مرکزی بدون Double conversion؛
- Start/End با Timezone و Scheduler؛
- قیمت مرجع تخفیف و Audit history؛
- Coupon/automatic promotion، eligibility و stacking؛
- Budget/usage limit و abuse control؛
- Refund allocation بین Item/discount/shipping/fee؛
- Invoice/receipt و شماره یکتا طبق نیاز قابل اعمال؛
- Rounding و reconciliation؛
- Approval برای تغییر حساس.
اعداد و Rules مالی باید با حسابدار و مشاور حقوقیِ آشنا با مدل شما تأیید شوند؛ Plugin default الزاماً منطبق با قرارداد و عملیات کسبوکار ایران نیست.
۱۰. حساب مشتری و خدمات پس از خرید
حساب باید Task واقعی را حل کند:
- Order history و Detail قابل فهم؛
- Tracking و Invoice/receipt؛
- Cancel/return request طبق State؛
- Address book و preference؛
- Password/MFA/recovery در صورت ریسک؛
- Session/device management در صورت نیاز؛
- Data access/correction/deletion workflow طبق Policy؛
- Support ticket/chat linkage بدون افشای PII؛
- Loyalty/wallet فقط با ledger و Rule روشن؛
- Notification preference.
۱۱. اعلان Email، پیامک و In-app
| Event | Recipient | محتوای لازم | Guardrail |
|---|---|---|---|
| Order received | Customer/ops | Order ID، items، amount، next step | Paid را زود اعلام نکند |
| Payment result | Customer/finance | Status و recovery | اطلاعات حساس در پیامک نباشد |
| Shipped | Customer | Carrier/track/ETA | Link امن و Status واقعی |
| Delay/exception | Customer/support | علت قابل بیان و گزینه | Silence یا وعده ساختگی |
| Return/refund | Customer/ops/finance | Item، amount، stage، زمان | تطبیق با Ledger |
| Stock alert | Opted-in customer | Product/variant و unsubscribe | Consent و rate limit |
Template، Retry، Provider outage، Bounce، Dedupe، Locale، Consent و Delivery log باید Owner داشته باشند.
۱۲. پنل مدیریت؛ Feature فراموششده
یک فروشگاه حرفهای فقط Frontend نیست. Admin باید:
- محصول/Variant/Media/Attribute را با Validation مدیریت کند؛
- Bulk import/export با Dry run و error report داشته باشد؛
- Order timeline، Payment، Fulfillment و Communication را یکجا ببیند؛
- عملیات حساس Approval، reason و audit log داشته باشند؛
- Role/permission حداقل دسترسی داشته باشد؛
- PII را Mask و Export را کنترل کند؛
- Refund/cancel/manual adjustment با Reconciliation اجرا شود؛
- Search و Filter براساس Order/SKU/customer/status ممکن باشد؛
- Dashboard Actionable باشد، نه فقط نمودار؛
- Accessibility و Keyboard برای کارکنان نیز رعایت شود.
۱۳. Integration و System of Record
| داده | System of record نمونه | Conflict policy |
|---|---|---|
| Product content | PIM/CMS | کدام Field از ERP override میشود؟ |
| Price | Pricing/ERP | Campaign local یا مرکزی؟ |
| Inventory | WMS/ERP | Lag، safety stock و manual adjustment |
| Order | Commerce/OMS | Identifier و state ownership |
| Payment | Payment ledger/provider | Callback در برابر reconciliation |
| Customer | Commerce/CRM/Identity | Merge، consent و delete |
| Shipment | OMS/Carrier | Status mapping و missing event |
Integration فقط API call نیست. Contract باید Version، auth، rate limit، idempotency، retry/backoff، timeout، dead-letter، replay، ordering، observability، PII و recovery داشته باشد.
۱۴. امنیت، حریم خصوصی و تقلب
امنیت را Feature انتهای پروژه نگذارید:
- MFA و least privilege برای Admin؛
- جداکردن حساب فردی و Shared credential ممنوع؛
- Server-side validation و Authorization هر Action؛
- Session، CSRF، XSS، injection و file upload controls؛
- Secret management و rotation؛
- Secure logging بدون Card/Password/Token/PII غیرضروری؛
- Rate limit و abuse/bot/fraud signals؛
- Dependency/plugin/app inventory و patch SLA؛
- Backup خارج Failure domain و Restore drill؛
- Incident runbook، notification و evidence retention؛
- Payment scope و Third-party scripts براساس Requirementهای قابل اعمال؛
- Retention/deletion و consent inventory.
OWASP ASVS نسخهدار میتواند Requirement قابل تست و قراردادی بدهد. صرف SSL، درگاه Redirect یا برند Platform امنیت کل فروشگاه را اثبات نمیکند.
۱۵. دسترسپذیری، موبایل و فارسی
- ساختار، Heading، Label، Table و Landmark معنایی؛
- Keyboard و Focus در Menu، Filter، Gallery، Modal و Checkout؛
- Contrast، رنگ تنها، Zoom/Reflow و Text spacing؛
- Error summary، Status announcement و حفظ داده؛
- Touch target، Keyboard باز و Sticky elements؛
lang="fa"،dir="rtl"و Bidi برای کد/URL/عدد؛- فونت، نیمفاصله، ی/ک و Search normalization؛
- تومان/ریال، رقم فارسی/لاتین و تاریخ/Timezone؛
- موبایل ایران، Cache سرد و شبکههای هدف؛
- WCAG ۲.۲ با Automated + human + user test.
UX کل Journey و قابلیتهای Assistive در راهنمای UX فروشگاه اینترنتی عمیقتر بررسی شدهاند.
۱۶. سئو، Feed و Lifecycle URL
- Taxonomy و Link path از Home/Category به Product؛
- URL پایدار برای Product/Variant/Facet؛
- Title/H1/Description براساس Intent و داده واقعی؛
- Canonical/Hreflang/Pagination و Parameter policy؛
- Product/Offer/ProductGroup/Breadcrumb/Organization Schema؛
- Page/Schema/Feed consistency برای Price/Availability/Condition؛
- Sitemap و Lastmod معتبر؛
- Out-of-stock/Discontinued/Successor/۴۰۴/Redirect policy؛
- JavaScript Render و crawlable
<a href>؛ - Search Console/Merchant diagnostics و regression monitoring.
Google برای فروشگاه، Navigation لینکمحور و Structured data مرتبط را توصیه میکند. معماری کامل Catalog، Facet و Lifecycle در راهنمای سئو فروشگاه اینترنتی آمده است.
۱۷. Analytics، Experiment و Reconciliation
Event dictionary را پیش از Tag manager بنویسید:
| مرحله | Event نمونه | پارامتر کلیدی | Validation |
|---|---|---|---|
| List | view_item_list/select_item | list_id، item_id، position | Impression واقعی |
| Product | view_item | item_id/variant/price | Data layer با صفحه |
| Cart | add_to_cart/remove_from_cart | quantity/value | فقط Success |
| Checkout | begin_checkout/add_shipping_info | cart/order context | Dedupe |
| Payment | add_payment_info | method بدون داده حساس | Privacy |
| Purchase | purchase | transaction_id/value/items | Server/order reconciliation |
| Refund | refund | transaction/items/amount | Finance match |
Click روی «پرداخت» Purchase نیست. Event مرورگر را با Order/Payment/Fulfillment/Return منبع عملیاتی Reconcile کنید. PII و Secret را وارد Analytics نکنید.
۱۸. گزارشهایی که تصمیم میسازند
- Revenue، Discount، Return، Refund و Contribution margin؛
- Order funnel با Error reason، نه فقط Conversion؛
- Search zero-result و Query→order؛
- Stockout، aged stock و inventory accuracy؛
- Payment success/unknown/duplicate/refund؛
- On-time/complete fulfillment و carrier exception؛
- Support contacts و return reasons؛
- Page/Schema/Feed mismatch؛
- Performance/Reliability by device/network؛
- Data freshness و integration failure.
Dashboard بدون Owner، threshold و Action فقط نمایش است. هر Metric باید cadence و تصمیم مرتبط داشته باشد.
۱۹. Reliability، Performance و Observability
| حوزه | Requirement | Evidence |
|---|---|---|
| Availability | SLO برای Browse/Cart/Checkout/Admin | Synthetic و outcome |
| Performance | Budget بر Template/Device/Network | Lab + Field |
| Capacity | Campaign/peak order scenario | Load test و scaling |
| Timeout | Third-party fail/fallback | Failure injection |
| Telemetry | Log/metric/trace با correlation ID | Incident drill |
| Alert | Actionable، owner و escalation | Alert test |
| Recovery | Rollback، RPO/RTO و restore | Rehearsal |
تصویر و Script سریع کافی نیست؛ تأخیر Search، Price، Payment و Inventory باید در Journey اندازهگیری شود.
۲۰. قانون، Policy و عملیات ایران
Requirement حقوقی را براساس مدل، کالا، داده و زمان با متخصص ذیصلاح بررسی کنید. حداقل Inventory تصمیم داشته باشید:
- هویت فروشنده و اطلاعات تماس؛
- قیمت/هزینه/شرایط پیش از Commit؛
- شرایط فروش، لغو، مرجوعی، ضمانت و شکایت؛
- Privacy/consent/retention/deletion؛
- Invoice/مالیات و نگهداری Record قابل اعمال؛
- مجوز یا محدودیت Category؛
- درگاه/تسویه و قرارداد Provider؛
- پیامک/Email بازاریابی و Opt-out؛
- Accessibility و حمایت از مصرفکننده در Scope مربوط؛
- Policy version و Evidence پذیرش.
خلاصه کاربردی و مرزبندی «قانون/Policy/توصیه» در راهنمای قوانین فروشگاه اینترنتی ایران آمده است.
Non-functional requirement هم Feature است
این موارد را به «بعداً» نفرستید:
| Quality | سؤال پذیرش |
|---|---|
| Security | کدام Risk/ASVS requirements و چه Evidence؟ |
| Accessibility | کدام Scope/WCAG level و human test؟ |
| Performance | Budget روی کدام Template/Device/Network؟ |
| Reliability | SLO/Error budget و dependency failure؟ |
| Privacy | Data inventory، purpose، retention و access؟ |
| SEO | Source/render/crawl/index/URL/schema acceptance؟ |
| Operations | Monitoring، backup، restore، support و rollback؟ |
| Localization | RTL/Bidi/number/date/currency/search؟ |
اولویتبندی: Critical path پیش از Feature جذاب
هر قابلیت را روی پنج معیار امتیاز دهید:
- Journey criticality: نبود آن سفارش/تحویل/Recovery را متوقف میکند؟
- Risk reduction: خطای مالی، قانونی، امنیتی یا موجودی را کم میکند؟
- Reach/frequency: چند کاربر/سفارش و چند بار؟
- Evidence: Support/Search/Return/Data چه میگوید؟
- Effort/dependency: Data/Integration/Team/Operations آماده است؟
| فاز | تعریف | نمونه |
|---|---|---|
| MVP/Release gate | یک Journey و Recovery کامل | Catalog→Order→Pay→Ship→Refund |
| Next | Friction پرتکرار با Evidence | Search synonym، saved address |
| Scale | حجم/اتوماسیون/کانال جدید | WMS، multi-warehouse، B2B price |
| Experiment | ارزش نامطمئن و Guardrailدار | Recommendation/AR/personalization |
| Not now | بدون Owner/Data/Outcome | App یا Loyalty صرفاً بهخاطر رقبا |
چه قابلیتهایی معمولاً به فاز بعد میروند؟
اگر Critical path بدون آنها کامل است و Evidence ندارند:
- اپلیکیشن Native؛
- AR/3D برای همه محصولات؛
- Recommendation شخصی پیشرفته؛
- Loyalty چندسطحی و Gamification؛
- Wallet داخلی؛
- Marketplace چندفروشنده؛
- Chatbot خودکار؛
- Multi-language/multi-currency بدون بازار واقعی؛
- گزارشساز سفارشی وقتی Export معتبر کافی است.
اینها بد نیستند؛ Dependency و عملیات دارند. «بعداً» باید Trigger ورود به Roadmap داشته باشد، مثل رسیدن حجم، نرخ تکرار، زمان پشتیبانی یا Evidence آزمایش.
پلتفرم را با Pilot سخت انتخاب کنید
Plugin list یا Demo کافی نیست. Pilot Representative:
- ۲۰ تا ۵۰ محصول با Simple/Variant/Bundle و داده فارسی واقعی؛
- Search/Filter و صفر نتیجه؛
- Cart و Promotion با Rule واقعی؛
- Checkout موبایل، آدرس ایران و Payment Sandbox؛
- Payment success/fail/unknown/duplicate؛
- Inventory last-unit و Release reservation؛
- Pick/ship/track و Return/refund؛
- Page/Schema/Feed/Event reconciliation؛
- Admin bulk task، permission و audit؛
- RTL/A11y/Performance/Security/Export.
مقایسه Platform، TCO، Ownership و Exit در راهنمای انتخاب فروشگاهساز آمده است.
Acceptance matrix پیش از قرارداد
| Lane | Acceptance نمونه | Evidence |
|---|---|---|
| Catalog | Import/validation/variant/lifecycle پاس | Reconciliation report |
| Browse | Search/filter/card/PDP با داده واقعی | Task test و zero-result logs |
| Commerce | Cart/price/promotion/checkout | E2E cases |
| Payment | Success/fail/unknown/retry/refund | Provider + ledger match |
| Operations | Inventory→ship→return | Order rehearsal |
| Admin | Role/bulk/audit/support | Staff usability test |
| Quality | A11y/RTL/security/performance/SEO | Test reports |
| Reliability | timeout/retry/alert/backup/rollback | Failure/restore drill |
| Ownership | Account/data/code/config/export | Handover + import test |
سه نمونه Scope برای ایران
| سناریو | MVP حیاتی | فاز بعد |
|---|---|---|
| فروش پوشاک D2C | Variant/size، عکس، stock، mobile checkout، shipping/return | Loyalty، recommendation، app |
| قطعات B2B | Part/compatibility، account approval، quote/price list، inventory | Credit workflow، ERP automation، procurement portal |
| فایل آموزشی | Product/access، payment، entitlement، download، refund/support | Subscription، certificate، community |
Scope با Business rule واقعی تغییر میکند. نمونهها نسخه آماده خرید نیستند.
ماتریس QA فروشگاه
| محور | نمونه |
|---|---|
| Product | Simple/Variant/Bundle/Digital/Marketplace |
| Stock | In/low/out/backorder/last unit/concurrent |
| Price | Regular/sale/coupon/tier/rounding/currency |
| Payment | Success/fail/cancel/timeout/duplicate/refund |
| Fulfillment | Full/partial/split/delay/lost/return |
| User | Guest/account/admin/support/warehouse |
| Device/Locale | Mobile/Zoom/RTL/عدد/شبکه/Screen reader |
| Dependency | Provider timeout/lag/bad response/rate limit |
| SEO/Data | HTML/URL/schema/feed/event/order/finance |
برنامه ۳۰روزه تعریف فروشگاه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱ تا ۵ | Business model، Customer/ops journey و Failureهای فعلی | Journey/operations map |
| روز ۶ تا ۱۰ | Domain model، Source of truth، Rule و State | Catalog/order/payment dictionary |
| روز ۱۱ تا ۱۵ | Requirement template و NFR/Legal/Security scope | Backlog با Acceptance |
| روز ۱۶ تا ۲۰ | Critical path، dependency و phase priority | MVP/Next/Scale roadmap |
| روز ۲۱ تا ۲۵ | Platform/team pilot با edge cases | Evidence و defect/gap register |
| روز ۲۶ تا ۳۰ | Contract، ownership، release/operation plan | Scope، RACI، test plan و TCO |
چکلیست امکانات ضروری سایت فروشگاهی
- مدل B2C/Digital/Service/Subscription/Marketplace/B2B و Outcome روشن است.
- Journey مشتری با عملیات، Finance، Support و Recovery Map شده است.
- هر Feature Trigger/Actor/Data/Rule/State/Acceptance/Metric/Owner دارد.
- Catalog، SKU/Variant، Attribute، Price، Stock و Lifecycle قرارداد دارند.
- Search/Filter با فارسی و Zero-result و SEO Facet تست شده است.
- Product/Offer/Variant در Page/Schema/Feed یکساناند.
- Cart قیمت/موجودی/Promotion/Shipping/Total را قابل توضیح نگه میدارد.
- Checkout مهمان/حساب، آدرس ایران، Error و Consent درست دارد.
- Payment state machine برای Unknown/Retry/Duplicate/Refund و Reconcile کامل است.
- Inventory reservation، Fulfillment، Tracking، Return و Refund Owner دارند.
- پنل Admin، Role، Audit، Bulk، Support و Reconciliation قابل استفاده است.
- Integrationها Source of truth، Idempotency، timeout/retry و observability دارند.
- Security/Privacy/Accessibility/RTL/SEO/Performance/Recovery Release gate هستند.
- Event dictionary با transaction_id و Order/Finance reconciliation دارد.
- قانون و Policy قابل اعمال ایران با متخصص و Version بررسی شدهاند.
- MVP یک Order واقعی تا تحویل/مرجوعی را کامل و قابل پایش میکند.
- Platform با Pilot سخت، TCO، Ownership و Exit انتخاب شده است.
پرسشهای متداول امکانات فروشگاه
ضروریترین امکانات سایت فروشگاهی چیست؟
Catalog و Product data، Search/Category، PDP/Variant، Cart، Checkout، Payment، Order state، Inventory، Shipping/Return، Admin، Security، Analytics و SEO پایهاند؛ اما Rule و عمق هرکدام از مدل فروش میآید. MVP باید یک Order و Recovery کامل داشته باشد.
آیا برای شروع فروشگاه اپلیکیشن موبایل لازم است؟
معمولاً نه، مگر Evidence نشان دهد قابلیت Device-native یا تکرار استفاده ارزشش را توجیه میکند. ابتدا Web موبایل سریع، دسترسپذیر و قابل اعتماد را بسازید؛ سپس با Retention، Task و TCO درباره App تصمیم بگیرید.
درگاه پرداخت بهتنهایی برای پرداخت کافی است؟
خیر. Order/Payment state machine، Server-side verify، Idempotency، Callback/Webhook، Unknown-state reconciliation، Retry، Refund و تطبیق روزانه لازماند. Redirect موفق یا کلیک «پرداخت» Evidence قطعی نیست.
چه قابلیتهایی را به فاز بعد منتقل کنیم؟
قابلیتهایی که Critical path و Risk gate را متوقف نمیکنند و Evidence/Owner/Data ندارند؛ مثل Personalization، Loyalty پیچیده، App، AR یا Marketplace. برای هرکدام Trigger ورود به Roadmap تعریف کنید، نه «بعداً» مبهم.
چطور امکانات پیشنهادی شرکت طراحی سایت را ارزیابی کنیم؟
Feature را با Requirement template و edge caseهای خود بسنجید، سپس Pilot واقعی اجرا کنید. «دارد/ندارد» کافی نیست؛ Actor، Data، Rule، State، Integration، Admin، Acceptance، Operations، TCO، Ownership و Exit را Evidence بخواهید.
منابع رسمی برای Requirement و QA
- Google Search Central: ساختار Navigation و کشف Product
- Google Search Central: Structured data مرتبط با فروشگاه
- Google Search Central: Product/Merchant listing و Policy data
- Google Analytics: Eventهای توصیهشده Ecommerce
- Google Analytics: Scopeهای Event و Item در Ecommerce
- OWASP ASVS ۵: Security requirements قابل تست/قرارداد
- W3C: استاندارد WCAG ۲.۲ برای وب و Checkout دسترسپذیر
- PCI SSC: ریسک Script و تغییر غیرمجاز صفحه پرداخت Ecommerce
فروشگاه حرفهای با تعداد Featureها سنجیده نمیشود؛ با تعداد تعهدهایی سنجیده میشود که در State عادی و خطا درست انجام میدهد. اگر یک سفارش را بتوانید از Product تا پول، کالا، داده و Recovery دنبال و Reconcile کنید، پایهای دارید که واقعاً قابل رشد است.
