دراپ‌شیپینگ چیست؟ مدل عملیاتی، سود و ریسک در ایران

در دراپ‌شیپینگ ممکن است هیچ کارتن کالایی در انبار شما نباشد، اما یک سفارش ناموجود، کالای اشتباه، تأخیر پیک، خسارت حمل یا Refund معطل همچنان با نام فروشگاه شما در ذهن مشتری ثبت می‌شود. حذف انبار، مسئولیت تجربه خرید را حذف نمی‌کند؛ فقط بخشی از کنترل را به تأمین‌کننده منتقل می‌کند.

دراپ‌شیپینگ یک مدل Fulfillment است: فروشگاه سفارش را می‌گیرد و تأمین‌کننده کالا را مستقیم برای خریدار می‌فرستد. این مدل می‌تواند سرمایه موجودی را کم کند، اما هزینه جذب، اختلاف موجودی، کیفیت، ارسال، مرجوعی، جبران خطا، مالیات، فناوری و نقدینگی را صفر نمی‌کند. تصمیم درست با «محصول برنده» یا رقم درآمد شروع نمی‌شود؛ با قرارداد فروشنده، Unit Economics هر سفارش و توان کنترل زنجیره سفارش تا بازگشت آغاز می‌شود.

دراپ‌شیپینگ چیست؟

در مدل Dropshipping، خریدار در فروشگاه یا Channel شما سفارش می‌دهد؛ سفارش برای یک Supplier یا Fulfillment partner ارسال می‌شود؛ آن طرف کالا را Pick، Pack و Ship می‌کند. بسته ممکن است با نام برند شما، نام تأمین‌کننده یا بسته‌بندی خنثی برسد—اما این موضوع باید در قرارداد و تجربه مشتری روشن باشد.

دراپ‌شیپینگ شکل حقوقی واحدی در همه کشورها نیست. باید بدانید چه کسی فروشنده قراردادی، دریافت‌کننده وجه، صادرکننده Invoice، Importer، مسئول Warranty، پاسخ‌گوی Return و کنترل‌کننده داده شخصی است. واژه عملیاتی «تأمین‌کننده ارسال می‌کند» این نقش‌ها را تعیین نمی‌کند.

چهار مدل را از هم جدا کنید

اگر هنوز مدل کسب‌وکار، Order-to-cash، Catalog، Checkout و ۱۰۰ سفارش نخست را طراحی نکرده‌اید، ابتدا راهنمای راه‌اندازی فروشگاه اینترنتی در ایران را ببینید. Dropshipping جای این معماری را نمی‌گیرد.

Seller of record یعنی چه؟

Seller of record در قرارداد یا Policy پلتفرم، طرفی است که فروش به نام او انجام می‌شود و مسئولیت‌های مشخصی در قبال خریدار دارد. تعریف دقیق به حوزه قضایی و Channel بستگی دارد، اما برای عملیات این سؤال‌ها را بدون پاسخ نگذارید:

• نام چه کسب‌وکاری در صفحه، Invoice، پیام پرداخت و روی بسته دیده می‌شود؟
• چه کسی قیمت، موجودی و زمان تحویل را وعده می‌دهد؟
• چه کسی شکایت، Cancel، Return، Warranty و Refund را می‌پذیرد؟
• چه کسی مالیات/صورتحساب، مجوز و Product compliance را مدیریت می‌کند؟
• تأمین‌کننده داده نام، شماره و آدرس مشتری را با چه Purpose و Retentionی می‌گیرد؟

برای نمونه، Policy رسمی Dropshipping در eBay تأمین مستقیم از Wholesale supplier را مشروط می‌پذیرد و فروشنده را مسئول تحویل امن در زمان وعده‌داده‌شده و رضایت خریدار می‌داند؛ خرید پس از فروش از Retailer/Marketplace دیگر را مجاز نمی‌داند. این فقط Policy همان پلتفرم است، نه مجوز عمومی برای هر بازار؛ Terms جاری Channel خود را جدا بررسی کنید.

دراپ‌شیپینگ چه ریسکی را کم و چه ریسکی را زیاد می‌کند؟

چه زمانی این مدل مناسب نیست؟

با Drop shipping شروع نکنید اگر یکی از موارد زیر را نمی‌توانید کنترل یا پوشش دهید:

• کالای سلامت، مکمل، آرایشی، کودک، الکتریکی یا ایمنی‌محور بدون مجوز و Evidence لازم؛
• کالای دارای احتمال تقلب، نقض Trademark/Copyright یا منشأ نامعلوم؛
• شکستنی، حجیم، گران‌قیمت یا سریالی با خسارت حمل و Fraud بالا؛
• پوشاک/کفش با جدول اندازه نامعتبر و Return بالا؛
• کالای Warranty-intensive بدون شبکه تعمیر/تعویض؛
• محصولی که تأمین‌کننده اجازه نمونه، QA، API/Feed یا قرارداد روشن نمی‌دهد؛
• بازاری که Payment، Platform، واردات یا Service eligibility آن برای شخصیت شما تأیید نشده است؛
• Unit Economics فقط با فرض Return صفر، تبلیغ ارزان یا فروش تکراری خیالی مثبت می‌شود.

محصول را با ریسک سفارش انتخاب کنید، نه Trend

«Niche» به‌خودی‌خود مزیت نیست. یک بازار کوچک با کالاهای شکننده، Regulation سنگین و تقاضای کم می‌تواند بدتر از بازار بزرگ باشد. Product scorecard بسازید:

Unit Economics واقعی هر سفارش

Revenue یا تفاوت قیمت فروش و خرید، سود نیست. Contribution را در سطح سفارش نگه‌داشته‌شده و با Currency/Tax treatment درست محاسبه کنید:

Net collected revenue
− supplier product cost
− fulfillment / packaging
− outbound shipping and delivery surcharges
− customs / duty / tax borne by seller
− payment fee and failed-payment cost
− expected return / refund / reship / damage / fraud reserve
− variable support and operations
− discount / affiliate / channel commission
= contribution before acquisition

contribution after acquisition
= contribution before acquisition − incremental CAC

Fixed platform، App، تیم، حسابداری، مجوز، عکاسی، Development، Insurance و Management هنوز از Contribution پرداخت می‌شوند. اگر مالیات یا VAT از مشتری وصول می‌شود، آن را Revenue اقتصادی فرض نکنید. برای Channel budget، CAC، Incrementality و Profit، راهنمای بازاریابی فروشگاه از اقتصاد سفارش تا رشد مکمل است.

Break-even CAC

سقف جذب نباید کل Contribution قبل از Acquisition باشد، مگر این‌که هیچ سهمی برای Fixed cost، Risk و Profit نخواهید:

Break-even CAC (operating target)
= contribution before acquisition
− allocated fixed cost per kept order
− risk buffer
− target profit

CAC را برای New customer واجد شرایط و با هزینه Creative، Agency، ابزار و تخفیف Acquisition حساب کنید. ROAS درآمدمحور ممکن است سفارش زیان‌ده را موفق نشان دهد.

مثال عددی فرضی با تومان

اعداد زیر قیمت بازار یا توصیه مالی نیستند؛ فقط نشان می‌دهند هزینه‌های ظاهراً کوچک چه می‌کنند. فرض کنید یک سفارش پس از تخفیف ۱٬۲۵۰٬۰۰۰ تومان وصول شده است:

این ۴۵هزار تومان هنوز Fixed cost، مالیات بر درآمد، Incident بزرگ و Profit هدف را نپوشانده است. اگر Return reserve واقعاً ۱۶۰هزار یا CAC سیصدهزار باشد، سفارش منفی می‌شود. Base/Best/Worst و Sensitivity برای CAC، نرخ نگه‌داشت، تأخیر و FX بسازید.

Working capital؛ «بدون موجودی» یعنی «بدون پول» نیست

ممکن است Supplier پیش از Dispatch پول بخواهد، درگاه با تأخیر تسویه کند، بخشی از وجه Hold شود و Refund پیش از دریافت Credit از Supplier پرداخت شود. Peak cash need را روزانه مدل کنید:

• فاصله دریافت وجه مشتری تا تسویه درگاه؛
• فاصله پرداخت Supplier تا تحویل/پایان مهلت Return؛
• Deposit، Minimum balance یا نرخ ارز؛
• Refund/Chargeback/Reship هم‌زمان؛
• رشد سفارش و تأخیر Reconciliation؛
• Reserve برای Incident و توقف Supplier.

فروش سریع می‌تواند نیاز نقدینگی را بیشتر کند. Dashboard سود بدون Cash forecast، تصویر ناقص است.

Due diligence تأمین‌کننده

پروفایل در Directory یا عبارت «Verified supplier» جای Sample، مرجع، قرارداد و Test order را نمی‌گیرد. نخست با آدرس‌های کنترل‌شده در چند شهر سفارش واقعی بدهید و بسته، محتوا، زمان و Tracking را ثبت کنید.

قرارداد تأمین‌کننده باید قابل اندازه‌گیری باشد

«ارسال سریع و کیفیت عالی» SLA نیست. قرارداد تجاری/حقوقی را متخصص مربوط بازبینی کند و حداقل این بخش‌های عملیاتی را به Acceptance وصل کنید:

• Catalog، SKU، Territory، حق فروش و استفاده از Assets؛
• Price file، مالیات، تغییر قیمت، Notice و سفارش‌های باز؛
• Inventory feed، Allocation، Out-of-stock و Substitute ممنوع/مجاز؛
• زمان Acknowledge، Pick/Pack، Dispatch و Carrier handoff؛
• Packaging، Invoice/Insert، Label، Tracking و Proof of dispatch؛
• Defect/incorrect/damage/lost/late ownership و Remedy؛
• Return authorization، inspection، restock/dispose و Credit time؛
• داده شخصی، محرمانگی، Security، Subprocessor و Incident؛
• گزارش، Audit/sample، Service credit و تکرار نقض؛
• Term، Exit، سفارش باز، داده، Inventory claim و Transition.

RACI سفارش تا Refund

RACI قراردادی با مسئولیت قانونی یکی نیست؛ برای همین هر دو باید بررسی شوند. مشتری نباید بین Supplier، Carrier و فروشگاه پاس داده شود.

Product truth و Catalog

در Dropshipping، صفحه محصول احتمالاً بدون دیدن هر Batch ساخته می‌شود. یک Source of truth برای نام، SKU، Variant، ابعاد، جنس، Country of origin، موجودی، قیمت، Warranty، Warning، Media rights و Change time داشته باشید.

• عنوان و عکس Supplier را بی‌بررسی کپی نکنید.
• Variant و رنگ را با شناسه پایدار نگه دارید؛ «آبی» در Feed و تصویر باید یکی باشد.
• ادعای پزشکی، ایمنی، «اصل»، «ارگانیک» یا «ضدآب» Evidence می‌خواهد.
• زمان ارسال را از مسیر SKU/مبدأ/Carrier بسازید، نه متن ثابت کل سایت.
• قیمت و Availability stale را با TTL، timestamp و Fail-safe کنترل کنید.

برای قرارداد Card/PDP/Variant/Stock/Delivery، راهنمای نمایش محصول بر پایه Product truth را ببینید.

موجودی قابل فروش با موجودی انبار یکی نیست

Supplier ممکن است ده واحد On hand نشان دهد، اما بخشی Reserved، معیوب، در چند Channel فروخته یا خارج از Cutoff باشد. Available-to-promise را با Safety buffer و Latency تعریف کنید:

ATP = on_hand
      − allocated
      − safety_buffer
      − blocked_or_quality_hold
      − expected_concurrent_demand

اگر Feed قطع شد، فروش بی‌نهایت ادامه ندهید. Last successful sync، Maximum staleness و Fail-open/Fail-closed را به تفکیک ریسک SKU تعیین کنید. کالای محدود یا گران بهتر است با Stock صفر امن شود تا Oversell.

State machine سفارش

ساخت Label به معنی ارسال نیست. «Shipped» را فقط با Evidence حمل تنظیم کنید. Webhook را Idempotent و Eventهای out-of-order را قابل Reconcile کنید.

Split shipment و چند تأمین‌کننده

یک Cart ممکن است به سه بسته، سه زمان و سه Return address تبدیل شود. پیش از پرداخت، تعداد بسته و هزینه/زمان هرکدام را تا حد ممکن روشن کنید. Order parent و Fulfillment child داشته باشید؛ Cancel، Refund و Notification باید Line-level را بفهمند.

معماری کامل ATP، Fulfillment، Carrier، RTO و Reverse logistics در راهنمای مدیریت موجودی، ارسال و مرجوعی فروشگاه آمده است.

Promise تحویل را از Evidence بسازید

«ارسال ۲ تا ۳ روز» را از بهترین سفارش برندارید. Promise شامل Processing + Carrier transit + Non-working day + منطقه + Buffer است. P50 برای تبلیغ امن کافی نیست؛ P90/P95 و Tail را ببینید. Cutoff، تعطیلی، آب‌وهوا، Peak و Remote area را لحاظ کنید.

اگر به بازار آمریکا می‌فروشید، مثلاً راهنمای FTC برای سفارش اینترنتی درباره داشتن مبنای معقول برای زمان ارسال و در صورت تأخیر، رضایت به تأخیر یا Refund مقررات مشخصی دارد. این قاعده برای بازار آمریکا است؛ برای هر مقصد، قانون و Policy جاری همان بازار را بررسی کنید.

Return، Refund و Warranty را پیش از فروش حل کنید

در Revenue report فقط Return درخواست‌شده را نبینید؛ Refund aging، Credit تأمین‌کننده، کالای برگشتی قابل فروش، Disposal و Support cost را Reconcile کنید.

قوانین فروشگاه اینترنتی در ایران

این بخش راهنمای عمومی است، نه مشاوره حقوقی یا مالیاتی. مدل Dropshipping شما را از تعهدات فروش آنلاین معاف نمی‌کند. نقش‌های قراردادی، نوع کالا، بازار، شخصیت فروشنده و جریان واردات می‌تواند تکلیف را تغییر دهد؛ قبل از عرضه با متخصص و مرجع جاری بررسی کنید.

قانون تجارت الکترونیکی ایران در مواد مربوط به حمایت مصرف‌کننده، ارائه اطلاعات مؤثر پیش از عقد، مشخصات تأمین‌کننده، هزینه‌ها/شرایط و حق انصراف در معاملات از راه دور را با دامنه و استثناهای خود پوشش می‌دهد. عدد «هفت روز کاری» را بدون خواندن شرایط شروع، هزینه بازپس‌فرستادن و استثناها به Policy عمومی تبدیل نکنید.

همچنین پرونده مالیاتی، صورتحساب و سامانه‌های مرتبط باید بر اساس وضعیت جاری کسب‌وکار بررسی شوند؛ متن قانون پایانه‌های فروشگاهی و سامانه مؤدیان یکی از مبانی است، اما فراخوان، دستورالعمل و اجرای جاری را باید از مرجع مالیاتی/مشاور واجد صلاحیت استعلام کرد. راهنمای جامع‌تر قوانین فروشگاه اینترنتی در ایران لایه‌های حقوق مصرف‌کننده، مالیات و Requirement محصول را مرزبندی می‌کند.

چک‌لیست Compliance به تفکیک SKU

• قانونی بودن فروش، تبلیغ، واردات و ارسال کالا؛
• مجوز، استاندارد، برچسب، زبان، Warning و نگهداری؛
• اصالت، مالکیت فکری و حق استفاده از عکس/متن؛
• اطلاعات پیش از خرید، قیمت کل، تحویل، Return و Warranty؛
• Invoice، مالیات و ثبت رویداد مالی؛
• حریم خصوصی، اشتراک آدرس با Supplier و Security؛
• سوابق Batch/Serial/تأمین‌کننده برای Recall یا شکایت.

Cross-border؛ هزینه نهایی و Importer را پنهان نکنید

در سفارش مستقیم خارجی باید روشن باشد چه کسی Importer است، چه کالا/مقداری جنبه تجاری یا محدودیت دارد، چه مجوز/استانداردی لازم است و Duty/Tax/Handling را چه کسی و چه زمانی می‌پردازد. عبارت مبهم «ممکن است هزینه گمرک داشته باشد» تجربه قابل اتکا نمی‌سازد.

Landed cost را با Range بنویسید:

landed cost = product + international freight + insurance
              + duty/tax/clearance/handling
              + local delivery + expected delay/return loss

مقررات و فهرست کالاها تغییر می‌کنند. برای هر SKU و مسیر، از مراجع رسمی تجارت/گمرک و متخصص استعلام تاریخ‌دار بگیرید؛ سفارش پستی شخصی را به‌عنوان مسیر تجاری مقیاس‌پذیر فرض نکنید.

پرداخت و پلتفرم برای ایران

ساخت Store روی یک SaaS خارجی پیش از تأیید Eligibility، مسیر پرداخت، تسویه، KYC، Country support، Currency، Refund و Export داده، ریسک توقف دارد. VPN یا آدرس/شخصیت جعلی راهکار عملیاتی یا حقوقی پایدار نیست.

Portfolio روش پرداخت، ریسک Provider و محدودیت ایران در راهنمای روش‌های پرداخت فروشگاه اینترنتی بررسی شده است.

تجربه مشتری؛ شما یک ورودی پاسخ‌گو هستید

Customer نباید برای یافتن Order owner به تأمین‌کننده ناشناس ارجاع داده شود. Self-service و Agent view باید همان State را ببینند. حداقل:

• Stock و Delivery promise به تفکیک SKU؛
• تأیید سفارش بدون ادعای زودهنگام Shipping؛
• Tracking قابل فهم برای Split shipment؛
• اعلان Proactive برای Delay/Exception؛
• یک مسیر Support با Order context؛
• Return/Refund status و زمان‌بندی؛
• Remedy روشن برای خطای Supplier/Carrier؛
• لغو، شکایت و حذف داده قابل یافتن.

اعتماد از Badge و بسته‌بندی به‌تنهایی نمی‌آید؛ Claim→Evidence→Experience→Remedy لازم است. راهنمای جلب اعتماد مشتری فروشگاه این قرارداد را برای کل Journey توضیح می‌دهد.

Brand دراپ‌شیپینگ چیست؟

لوگو و Insert سفارشی Brand نمی‌سازد اگر ETA نادرست، عکس متفاوت، Return مبهم و Support بی‌اطلاع باشد. Brand promise باید از چیزهایی ساخته شود که کنترل می‌کنید: Assortment معتبر، توضیح دقیق، آموزش، Bundle، پاسخ‌گویی، Remedy، Community و تجربه منسجم.

Private label یا Branded packaging می‌تواند تمایز بدهد، اما ممکن است MOQ، IP، مسئولیت Product، Quality control و سرمایه را بیشتر کند. آن را «مرحله طبیعی و حتماً بهتر» فرض نکنید.

بازاریابی را پس از اقتصاد سفارش مقیاس دهید

تبلیغ قبل از Inventory/Delivery/Return readiness فقط سرعت تولید مشکل را زیاد می‌کند. Channel pilot را با Qualified order و Kept contribution بسنجید:

• Pixel/Attribution را با سود قطعی یکی نکنید.
• Refund، cancellation و failed delivery را به Campaign برگردانید.
• New/returning و Cohort را جدا کنید.
• CLV پیش‌بینی‌شده را جای Cash و Margin فعلی ننشانید.
• Creative و UGC باید محصول واقعی و Claim قابل اثبات نشان دهد.
• Affiliate/Influencer disclosure و Code-level contribution را ثبت کنید.

AI و اتوماسیون؛ کنترل را خودکار کنید، واقعیت را نسازید

AI می‌تواند Ticket را دسته‌بندی، Feed anomaly را علامت‌گذاری، Draft توضیح را آماده و تقاضا را Scenario کند. اما نباید مشخصات، Material، Safety claim، Review یا ETA را حدس بزند. Human review و Source citation برای Product facts لازم است.

پایداری و ادعای سبز

ارسال تک‌مرسوله‌ای طولانی، بسته‌بندی چندلایه و Return بین‌مرزی می‌تواند Hotspot ایجاد کند. «دوست‌دار محیط زیست» را از ظاهر Supplier copy نکنید. Functional unit، مرز زنجیره، Material، Transport، Return و End-of-life را با Evidence بسنجید.

اگر Supplier ادعای Recycled، biodegradable، carbon-neutral یا ethical دارد، Standard/Scope/percentage/certifier/date را ثبت کنید. برای روش Hotspot، Scope ۳ و Claim registry، راهنمای تجارت الکترونیک پایدار بدون Greenwashing را ببینید.

معماری حداقلی داده و سیستم

Spreadsheet برای Pilot کوچک ممکن است کافی باشد، اگر Owner، timestamp، validation و reconciliation دارد. ابزار گران بدون قرارداد داده، موجودی کاذب را سریع‌تر منتشر می‌کند.

داشبورد عملیاتی و سود

Revenue، AOV یا ROAS تنها با Contribution سفارش نگه‌داشته‌شده و Cash قابل تصمیم می‌شود.

Pilot قبل از مقیاس

نمونه Scale/Stop gate

عددها باید از دسته و وعده شما بیایند، نه Template عمومی. Gate می‌تواند شامل Fill rate حداقل، Stock mismatch حداکثر، Dispatch P90، On-time delivery، Defect/return، Refund age، WISMO، Kept contribution و Peak cash باشد. نقض Product safety، اصالت یا مجوز می‌تواند Knockout باشد حتی اگر سود خوب است.

Runbookهای ضروری

Stock mismatch و Oversell

SKU/Feed/last sync را مهار، فروش را بر اساس ریسک Stop، سفارش‌های متاثر را شناسایی، Substitute را فقط با رضایت و برابری واقعی پیشنهاد، Refund/Delay consent را اجرا و علت Allocation/latency را اصلاح کنید.

Supplier outage یا افزایش ناگهانی قیمت

Orderهای پذیرفته/نپذیرفته را جدا، Price publish را Freeze، Alternate supplier را فقط پس از QA فعال، Customer promise را اصلاح و Contract notice/credit را پیگیری کنید. Checkout با Margin منفی ادامه ندهد.

Shipment بدون Scan یا گمشده

Label-created را Shipped ندانید. Handoff evidence، Carrier inquiry، Customer update cadence، deadline جبران و Refund/Reship را اجرا کنید؛ سپس Supplier و Carrier liability را پشت صحنه حل کنید.

موج عیب یا کالای اشتباه

SKU/Batch را Quarantine، فروش را متوقف، Order cohort را استخراج، Supplier/Regulatory escalation لازم را انجام، پیام و Remedy یکسان بدهید و Recall/return/disposal را ثبت کنید.

Refund backlog

Payment reference و Status را Reconcile، Age bucket و cash reserve را ببینید، Customer را با زمان واقعی آگاه، دستی/جایگزین را طبق قانون/پرداخت اجرا و Credit تأمین‌کننده را از Refund مشتری جدا کنید.

جایگزین‌های Dropshipping

برنامه ۳۰، ۶۰ و ۹۰ روزه

چک‌لیست تصمیم

• آیا مدل داخلی/خارجی/Marketplace/Hybrid و Seller-of-record روشن است؟
• آیا هر SKU از Safety/Regulation/IP/quality/shipping/return Knockout گذشته است؟
• آیا Sample از چند Batch و Test order واقعی دارید؟
• آیا قرارداد Supplier موجودی، قیمت، Dispatch، Tracking، Return، data و Exit دارد؟
• آیا Product truth و ATP منبع، timestamp و Fail mode دارند؟
• آیا Return/Refund/Warranty قبل از فروش قابل اجراست؟
• آیا قوانین، مالیات، واردات، Payment و Platform eligibility تاریخ‌دار تأیید شده‌اند؟
• آیا Contribution پس از CAC و Worst case و Peak cash مثبت/قابل تحمل است؟
• آیا Dashboard سفارش نگه‌داشته‌شده، Supplier، Delivery، Return و Cash را به هم وصل می‌کند؟
• آیا Pilot Stop rule دارد یا قرار است تبلیغ، Evidence را جایگزین کند؟

جمع‌بندی

دراپ‌شیپینگ کسب‌وکار «بدون انبار» است، نه «بدون عملیات». زمانی ارزش دارد که کاهش سرمایه موجودی از هزینه کنترل کمتر، Return، Dependency و تجربه شکسته بیشتر باشد. فروشنده‌ای که Product truth، Supplier contract، Order state، Customer remedy و Contribution را مالک نیست، فقط شکایت مشتری را با حاشیه سود کم اجاره کرده است.

پیش از ساخت فروشگاه، یک SKU را انتخاب کنید و زنجیره‌اش را روی کاغذ ببندید: چه کسی می‌فروشد، کالا کجاست، چه زمانی رزرو و ارسال می‌شود، اگر اشتباه بود کجا برمی‌گردد، Refund را چه کسی و از چه نقدینگی می‌دهد و پس از همه هزینه‌ها چه می‌ماند. اگر پاسخ‌ها قابل اثبات نیستند، هنوز محصول آماده فروش نیست.

پرسش‌های متداول

آیا دراپ‌شیپینگ در ایران قانونی است؟

یک پاسخ کلی برای همه کالاها و مسیرها کافی نیست. مدل فروش آنلاین شما باید با قانون تجارت الکترونیکی، حقوق مصرف‌کننده، مالیات/صورتحساب، مجوز و استاندارد کالا، مالکیت فکری، حریم خصوصی و—در مسیر خارجی—مقررات واردات/گمرک سازگار باشد. نقش قراردادی تأمین‌کننده مسئولیت فروشگاه را خودکار حذف نمی‌کند؛ برای وضعیت مشخص از مرجع جاری و متخصص استعلام کنید.

دراپ‌شیپینگ چقدر سرمایه می‌خواهد؟

رقم ثابت ندارد. علاوه بر ساخت فروشگاه و جذب، هزینه Sample/QA، قرارداد، اتصال/ابزار، Payment، Support، Refund/Reship reserve، مالیات/مجوز و Peak working capital را مدل کنید. نداشتن خرید عمده، نیاز نقدینگی بین پرداخت Supplier و تسویه/Refund مشتری را صفر نمی‌کند.

سود دراپ‌شیپینگ را چگونه حساب کنیم؟

از درآمد خالص وصول‌شده، کالا، Fulfillment، حمل، عوارض/مالیات متحمل‌شده، Payment، Return/Refund/خرابی/Fraud reserve، Support، Commission و CAC افزایشی را کم کنید. سپس Fixed cost، Risk buffer و Profit هدف را ببینید. Revenue، ROAS یا تفاوت قیمت خرید و فروش به‌تنهایی سود نیست.

چگونه تأمین‌کننده مناسب پیدا کنیم؟

Directory فقط Lead می‌دهد. هویت و اختیار فروش، Product compliance/IP، Sample چند Batch، Inventory/Capacity، Test order، Tracking، Return/Refund، Data security، Reference و Exit را بررسی و در قرارداد قابل اندازه‌گیری کنید. Supplier بدون Sample، Feed یا مسئولیت روشن، Knockout است.

دراپ‌شیپینگ داخلی بهتر است یا خارجی؟

«بهتر» به Job، کالا و اقتصاد بستگی دارد. داخلی معمولاً پرداخت، زمان ارسال، QA و Return قابل‌کنترل‌تری دارد؛ خارجی ممکن است Assortment بیشتری بدهد اما گمرک، ارز، Eligibility، تأخیر و Reverse logistics را اضافه می‌کند. هر دو را با Landed cost، Delivery P90، Return، Compliance، Contribution و Cash مقایسه کنید.