ব্ল্যাক ফ্রাইডে সেল60% পর্যন্ত ছাড়
  • বার্ষিক প্ল্যানে প্রথম বছর 60% ছাড়
  • লাইফটাইম লাইসেন্সে 45% ছাড়
শেষ হবে
অফারটি নিন

Returns Management: Jacket, Refund আর আসল Margin-এর হিসাব

Return-এর পর contribution কত থাকে, refund কীভাবে পরিষ্কারভাবে সামলাবেন ও inspected stock কোথায় যাবে—40টি jacket-এর সম্পূর্ণ উদাহরণে বুঝুন।

লেখক

Anichur Rahaman

1 মাস আগে8 মিনিট পড়া136 দেখা
Returns Management: Jacket, Refund আর আসল Margin-এর হিসাব

সোমবার এক দোকানের মালিক report-এ দেখলেন চল্লিশটি jacket বিক্রি। প্রতিটির দাম 80 currency unit, cost 44; gross margin দেখা যাচ্ছে 1,440। Packing desk-এর পাশে আটটি jacket ফেরত এসেছে। একজন size exchange চান, আরেকজন refund-এর update-এর অপেক্ষায়।

গল্প ও সংখ্যা শেখানোর উদাহরণ। কিন্তু প্রশ্নটি বাস্তব ব্যবসার: refund, shipping ও recovery cost বাদ দিয়ে এই order group কত contribution দিল? শুধু sales counter-এ উত্তর নেই। গ্রাহকের সমাধান আর পণ্যটি এরপর কোথায় যাবে—দুটিই অনুসরণ করতে হবে।

ভালো returns process এই দুই যাত্রা স্পষ্ট করে। গ্রাহক পরের ধাপ জানেন, unchecked পণ্য বিক্রিযোগ্য stock-এ মেশে না, buyer-ও বুঝতে পারেন কোন product-এ নজর দরকার। প্রতিটি return-কে বিরোধে না ঠেলে এমন ব্যবস্থা কীভাবে করবেন, সেটাই এখানে দেখব।

একটি সম্পূর্ণ Order Group দিয়ে শুরু করুন

হিসাব পরিষ্কার রাখতে নির্ধারিত return-observation period শেষে এক-jacket করে চল্লিশটি order-এর cohort স্থির করুন। এখানে আটটি full refund ও আটটি item পাওয়া গেছে ধরা হয়েছে। শুরুর exchange request এই all-refund scenario-তে নেই। দামে tax নেই, customer আলাদা delivery charge দেননি; সব original order-এ নিচের shipping ও payment cost হয়েছে।

প্রতি jacket-এর original cost 44। ফেরত item প্রথমে ওই cost-এ উদ্ধার হয়েছে, তারপর প্রতিটিতে গড়ে 12 write-down ধরে carrying value 32। এটি inventory impairment-এর assumption; retail discount-কে আবার loss ধরা হয়নি। ফেরত inventory-এর value 8 × 32 = 256। পরে resale হলে তার revenue এই cohort-এ ধরা নেই।

Cohort-এর অংশহিসাবUnit
Original Goods Sales40 × 803,200
Full Refund8 × 80-640
Net Goods Sales3,200 − 6402,560
গ্রাহকের রাখা 32টি Jacket-এর Cost32 × 44-1,408
40টি Order-এর Outbound Shipping40 × 8-320
সব Order-এর ফেরত না পাওয়া Original Payment Fee40 × 2.60-104
Return Shipping8 × 9-72
Receiving ও Handling8 × 4-32
Return-সম্পর্কিত Support8 × 3-24
Inventory Write-down8 × 12-96
উল্লিখিত খরচের পর Contribution2,560 − 1,408 − 320 − 104 − 72 − 32 − 24 − 96504

উল্লিখিত contribution 504: 2,560 − 1,408 − 320 − 104 − 72 − 32 − 24 − 96। Rent, marketing, tax ও অন্য খরচ নেই, তাই এটি net profit নয়। একই assumption-এ return না হলে hypothetical contribution 1,016; পার্থক্য 512। এটি ভবিষ্যতের loss মাপা forecast নয়।

অন্যভাবে মেলান: রাখা 32টি order-এর প্রতিটিতে contribution 36 − 8 − 2.60 = 25.40। প্রতিটি refunded order-এ shipping, fee, handling, support ও impairment মিলিয়ে −38.60। তাই 32 × 25.40 − 8 × 38.60 = 504। শুধু return-এ outbound freight ধরলে অন্য order-এর আসল খরচ বাদ পড়ে।

নিজের evidence দিয়ে প্রতিটি allowance বদলান। Fee ফেরত পাওয়া provider contract-এর বিষয়। যেমন Stripe refund documentation-এ original processing fee ফেরত না আসা ও pending/failed state বলা আছে। Inventory valuation-এও consistent policy লাগে; cost ও net realisable value নিয়ে দেখুন IAS 2।

Decision Automate করার আগে Promise লিখুন

কেনার আগেই প্রযোজ্য window, কীভাবে request করবেন, shipping কে দেবেন, অনুমোদিত remedy ও পরের ধাপ জানান। Change-of-mind offer আর defect, damage বা wrong-item claim আলাদা করুন। Order-এর সঙ্গে policy version রাখুন। “Final sale” label দিলেই আইনগত অধিকার মুছে যায় না।

Market, product ও claim অনুযায়ী প্রযোজ্য consumer rule মিলিয়ে নিন। শুধু “যে নিয়মে বেশি দিন, সেটি নিন”—এভাবে সব অধিকার, exception বা deadline ঠিক হয় না। একটি jurisdiction-এর উদাহরণ হিসেবে Your Europe-এর withdrawal/returns ও defective-goods guarantee আলাদা নির্দেশনা দেখুন।

গ্রাহকের পাওনা option সহজে দেখান। Size exchange সমস্যার সমাধান করতে পারে, তবে stock, price difference ও নতুন fulfilment লাগে। Store credit গ্রাহকের প্রতি obligation, নতুন profit নয়। পাওনা refund-এর বদলে credit চাপাবেন না। Policy বদলালে conversion ও return কোন দিকে যাবে, তা test করুন; আগে থেকে নিশ্চিত ধরে নেবেন না।

Customer ও Item-এর যাত্রা পাশাপাশি চলুক

Original order line, quantity, price, discount ও payment-এর সঙ্গে case খুলুন। Identity ও access যাচাই করুন; staff কেবল role-এ অনুমতিপ্রাপ্ত record দেখবেন। Customer claim ও শেষ inspection result আলাদা রাখুন। Request, accepted remedy ও successful refund তিনটি আলাদা তথ্য।

Item-এর যাত্রা: non-saleable returns status-এ গ্রহণ করে quantity ও identity মেলান, condition/safety inspect করুন, তারপর destination অনুমোদন করুন। সত্যিই saleable হলে restock; recovery value অনুযায়ী লাভজনক হলে rework; উপযুক্ত ক্ষেত্রে সঠিক বর্ণনায় open-box listing। Supplier claim, recycling বা write-off-এর owner ও evidence লাগবে। Label বা tracking scan মানেই stock ফিরে আসা নয়।

Customer-এর যাত্রা: প্রযোজ্য remedy ও timing ঠিক করে approval নিন এবং progress জানান। সব ক্ষেত্রে warehouse receipt-এর জন্য আটকে রাখবেন না; সময় নির্ভর করে প্রযোজ্য obligation ও process-এর ওপর। Refund-এ payment reference, amount, currency, পুরোনো refund/dispute দেখুন। যেখানে প্রয়োজন বা supported, original method ব্যবহার করুন; ব্যর্থ হলে verified exception route থাকবে।

Courier বা payment timeout হলে unresolved state থাকবে। আবার চালানোর আগে পুরোনো reference দেখুন; bounded retry, backoff ও দৃশ্যমান case owner রাখুন। দ্বিতীয় click-এ দ্বিতীয় label, reservation বা refund হবে না। Exchange-এর নিজস্ব stock reservation ও traceable order movement দরকার।

এক return case-এর দুটি পথ: item গ্রহণ, inspect ও route করা; customer-এর অনুমোদিত remedy ও payment state যাচাই। দুটির evidence মিলিয়ে case বন্ধ।
দুই পথ একই case-এ linked; একটির জন্য অন্যটিকে সব সময় অপেক্ষা করতেই হবে—এমন স্বয়ংক্রিয় নিয়ম নয়।

Return Reason দিয়ে ভালো প্রশ্ন করুন

উপকারী reason দিয়ে শুরু করুন: too small, too large, not as described, damaged, defective, wrong item, change of mind এবং note-সহ other। Customer-এর বক্তব্য ও পরের inspection finding আলাদা রাখুন। Request করতে ভুল reason বাছতে বাধ্য করা চলবে না।

ধরুন আটটি jacket-এর পাঁচটিতে “too small”। সংশ্লিষ্ট size, supplier measurement, copy ও picking accuracy তদন্ত করার signal এটি। Size chart ভুল বা customer ভুল—কোনোটির প্রমাণ নয়। বিক্রি হওয়া size mix ও mature observation window-এর সঙ্গে তুলনা করুন।

Actual item-এর সঙ্গে product page মেলান: measurement, fit note, colour, scale, material ও parcel-এ কী আছে। Damage pattern হলে packaging ও carrier evidence দেখুন। একটি change test করে কাছাকাছি cohort ও margin তুলনা করুন। Copy ঠিক করলেই return চিরতরে বন্ধ হয় না।

সন্দেহজনক Case ন্যায্যভাবে যাচাই করুন

Serial mismatch, empty parcel বা repeated duplicate request review-এর কারণ হতে পারে। শুধু high return rate fraud-এর প্রমাণ নয়; একাধিক size কেনা বৈধ shopping choice হতে পারে। Proportionate check, consistent decision ও সহজ appeal route রাখুন। Model risk score দিলেই account শাস্তি পাবে না।

প্রয়োজনের ভিত্তিতে condition, parcel weight বা serial/batch evidence reviewer-এর নামে রাখুন। যতটুকু দরকার ততটুকু data নিন, evidence share-এ অপ্রাসঙ্গিক address label ঢাকুন, access/retention সীমিত করুন, staff/customer-এর তথ্য রক্ষা করুন। Photo ও weight তদন্তে সাহায্য করে; একাই intent প্রমাণ করে না।

প্রসঙ্গ হিসেবে NRF/Happy Returns 2025 study-তে US online sales-এর 19.3% return অনুমান করা হয়েছিল। ঐতিহাসিক survey estimate আপনার order-এর rate বা global 2026 benchmark নয়।

Order, Stock ও Money মেলান

Case, stock movement, credit/refund ও payment reference linked রাখুন। Original discount, tax ও delivery adjustment প্রযোজ্য rule অনুযায়ী allocate করুন। Partial return ও bundle-এর হিসাব স্পষ্ট চাই; charge-এর সব অংশ একইভাবে reverse হয় ধরে নেবেন না।

Recoverable inventory ও impairment লিখুন, একই loss দুবার নয়। Exchange-এ return ও নতুন fulfilment দুটিই আছে। Gift credit যথাযথ recognition পর্যন্ত liability। Finance owner-এর সঙ্গে accounting mapping ঠিক করুন; automation event হলেই books সঠিক হয় না।

Case amount, provider state ও ledger entry মেলান। Timing difference, retained fee, pending/failed refund ও dispute দেখুন। কাজ চলমান থাকলে daily total একই নাও হতে পারে। Owner ও age-সহ exception list রাখুন; দরকারি evidence পাওয়া হলে তবেই case বন্ধ করুন।

আড়ালে থাকা ফলগুলো মাপুন

  • Mature Return Rate: একই eligible cohort ও observation window-তে returned unit ÷ delivered unit। Value rate আলাদা, denominator লিখে দিন। এই সপ্তাহের return-এর সঙ্গে এই সপ্তাহের সম্পর্কহীন sales মেশাবেন না।
  • Contribution ও Cost: net sales, retained COGS, সাধারণ fulfilment ও অতিরিক্ত return cost দেখান। Cash spend, allocated labour ও inventory impairment আলাদা রাখুন।
  • Customer Timing: request, authorisation, refund submission ও verified payment outcome আলাদা মাপুন; open overdue case-ও ধরুন। দ্রুত API response মানেই customer টাকা পেলেন না।
  • Recovery Timing/Value: receipt-to-inspection ও receipt-to-saleable stock দেখুন। Actual resale আরেকটি event। Recovery বলতে carrying value, resale proceeds নাকি recovery cost বাদে proceeds, স্পষ্ট করুন।
  • Reason ও ন্যায্যতা: product/variant/channel ধরে reason, grade, appeal ও error pattern দেখুন। Aggregate trend কাজে লাগে; returned value-এর সঙ্গে cost ও ক্ষতির গুরুত্ব ধরেও priority দিন।

Packing Desk-এ কী বদলাবে

Packing desk-এ মালিক এখন customer request, warehouse decision ও provider payment state আলাদা বুঝতে পারেন। পাঁচটি “too small” report থেকে তদন্ত হয়, অভিযোগ নয়। Buyer assumption অনুযায়ী cohort-এর 504 contribution ও পড়ে থাকা inventory value দেখেন; শুরুর 1,440 gross margin-কে খরচ করার profit ভাবেন না।

একটি category দিয়ে শুরু করুন: customer choice লিখুন, inspection route ঠিক করুন, complete cohort মেলান ও evidence থাকা একটি কারণ সংশোধন করুন। কর্মীরা প্রতিটি ধাপ ব্যাখ্যা করতে পারলে বাড়ান। কম unresolved case ও পরিষ্কার decision-এ process-এর মূল্য; শুধু কম return গ্রহণে নয়।

পর্যালোচনা: 4 নভেম্বর 2026। Anichur Rahaman StoreConsole-এর নির্মাতা। Jacket-এর গল্প ও হিসাব উদাহরণ; প্রকৃত policy ও cost ব্যবসাভেদে বদলাবে।

লেখকের পরিচয়

Anichur Rahaman

পড়া চালিয়ে যান