Chat থেকে order: stock, payment ও permission-এর পরিষ্কার flow

ভাবুন, Instagram story-র পরে একটি lighting shop-এ চ্যাটের ভিড়। একজন ধূসর lamp-টির কথা জানতে চাইলেন। কর্মী স্মৃতি থেকে বললেন “আছে”; কিছুক্ষণ পর payment-এর screenshot এল। এটি বোঝানোর কাল্পনিক দৃশ্য, কোনো গ্রাহকের case study নয়।

শেষ lamp-টি আগেই counter-এ বিক্রি হয়েছে। বলা দাম ৫৪ currency unit, screenshot-এ ৪৮। ঠিকানা আছে voice note-এ। যাচাই করার বিষয় কয়েকটি, কিন্তু সম্মত order reference বা বিশ্বাসযোগ্য payment state নেই।

কাজের পরিবর্তন হলো কথোপকথনের সঙ্গে নিয়ন্ত্রিত order process জুড়ে দেওয়া। এই guide-এ enquiry থেকে stock, quote, order, payment ও support-এর পথ দেখব। Messaging policy পর্যালোচনা: ৪ নভেম্বর ২০২৬। Launch-এর আগে account permission ও effective pricing যাচাই করতে হবে।

চ্যাট কেন একটা সত্যিকারের সেলস চ্যানেল

চেনা app-এ পণ্যের প্রশ্ন করা chat সহজ করতে পারে। তবে সব form, identity check বা checkout step বাদ যায় না। যাঁরা সহায়তা চান তাঁদের জন্য chat রাখুন; self-service পছন্দ করা ক্রেতার পথও পরিষ্কার রাখুন।

কথায় variant, delivery option বা published policy বোঝানো যায়। উত্তর নির্ভরযোগ্য তথ্য থেকে আসুক। Availability বা শুক্রবারে delivery নিয়ে দ্রুত আন্দাজ এমন promise বানাতে পারে যা রাখা সম্ভব নয়। ভালো product page ও মানুষের সহায়তা একে অন্যকে সাহায্য করে।

সঠিক integration থাকলে modern inbox-এ order ও stock দেখা যায়। কিন্তু একটি chat thread নিজে stock reserved, payment captured বা courier booked হওয়ার প্রমাণ নয়। প্রতিটি fact-এর নির্ভরযোগ্য record ও owner রাখুন।

শুধু চ্যাটে থাকা order-এর লুকানো খরচ

Chat ও operations-এর মাঝখানের কাজ মাপুন। যেমন:

• Product, variant, total ও delivery promise বারবার নিশ্চিত করা।
• Short বা reference-হীন payment সঠিক order-এর সঙ্গে মেলানো।
• সম্মত follow-up বা reservation expiry হারিয়ে যাওয়া।
• Address আবার লেখা ও এড়ানো যেত এমন courier ভুল ঠিক করা।
• Cancellation, return ও ভুল ব্যক্তিকে পাঠানো message তদন্ত করা।

Handling time, exception ও completed delivery-র baseline লিখুন। বেশি chat বা accepted order মানেই বেশি profit নয়; messaging cost, কর্মীর সময়, return ও payment failure-ও হিসাবের অংশ।

ইনকোয়ারি থেকে ডেলিভারি: পরিষ্কার একটা ফ্লো

Enquiry, draft, accepted order ও payment state আলাদা রাখুন। দাম জিজ্ঞেস করলেই order হয় না। Confirmation screenshot bank record নয়।

নিজের business rules অনুযায়ী এই ছয়টি checkpoint ব্যবহার করুন:

1. Enquiry ও identity: প্রশ্ন ও permitted purpose বুঝুন। Channel identity সাবধানে ব্যবহার করুন; দরকার হলে delivery details নিন, শুরুতেই full profile নয়।
2. Product ও stock: variant, current selling price ও eligible location নিশ্চিত করুন। Availability দেখা নিজে reservation নয়।
3. Quote ও acceptance: quantity, total, delivery cost, সম্ভাব্য সময় ও relevant terms দেখান। Transcribe করা address acceptance-এর আগে ক্রেতাকে যাচাই করতে দিন।
4. Order ও reservation: সম্মত stage-এ order লিখে concurrency protection-সহ stock reserve করুন। Expiry, cancellation ও duplicate request handling ঠিক করুন।
5. Payment evidence: বাছা method-এর actual state দেখান। COD accepted হয়েও unpaid থাকতে পারে; stock hold শেষের পরে payment এলে review লাগবে।
6. Confirmation ও support: allowed message-এ সঠিক reference ও state দিন। Delivery failure track, human route ও দরকারি update দিন; প্রতিটি internal event-এ message নয়।

StoreConsole demo-তে order entry, stock ও payment record দিয়ে মহড়া দিন। নির্দিষ্ট chat connector, provider contract, account permission ও supported message আলাদা যাচাই করে integration scope ঠিক করুন। Shared platform-এও identity mapping, reservation rules ও access control সঠিক হতে হবে।

২০২৬-এর WhatsApp rollout check

WhatsApp Business App ও Business Platform আলাদা product। Account-এর workflow, provider ও API permission দেখে setup বাছুন। Chat button বা feature list দেখেই integration আছে ধরে নেবেন না।

Opt-in

Outreach-এর permission ও উদ্দেশ্য record করুন; opt-out মানুন। Support enquiry মানে সম্পর্কহীন promotion-এর blanket permission নয়। প্রত্যেক button click-কে marketing consent না ধরে ক্রেতার choice-এর প্রমাণ রাখুন।

Customer service window

WhatsApp policy অনুযায়ী user message-এর ২৪ ঘণ্টার মধ্যে template ছাড়াই reply দেওয়া যায়; নতুন user message-এ window আবার শুরু হয়। বাইরে permitted purpose-এর approved template লাগবে। Content rules ও account restrictions প্রযোজ্য থাকে।

Eligible ad বা Page-CTA থেকে আসা conversation-এ ৭২ ঘণ্টার pricing benefit থাকতে পারে। Provider-এর কাছে eligibility ও start/end যাচাই করুন। Pricing benefit আলাদা free-form messaging permission বাড়ায় না।

Permission ও pricing checklist

Utility, authentication ও marketing template-এর উদ্দেশ্য আলাদা; pricing overview-এ service-ও একটি category। নিচের table routing checklist, tariff নয়। Message-এর প্রকৃত উদ্দেশ্য অনুযায়ী category ও approval দেখুন।

পরিস্থিতি	Permission check	Budget check
পণ্যের প্রশ্ন	Service window ও permitted content	Current account rules ও provider charge
Window-এর পরে order update	প্রযোজ্য approved utility template	Market, utility rate ও benefit
Promotion বা restock campaign	Permitted outreach ও প্রয়োজনীয় marketing template	Effective rate ও exception
Verification code	Permitted authentication flow ও approved template	প্রযোজ্য authentication/international rate
Eligible ad/Page entry	Window ও template check আলাদা	Eligibility, benefit duration ও provider fee

Effective rate card ও provider contract দিয়ে budget করুন: কোন event-এ bill হয়, recipient market, category, currency, volume tier, benefit, provider fee ও tax। Delivery record ও invoice-এর সঙ্গে metered event মেলান। “পাঠানো যাবে?” ও “খরচ কত?” আলাদা প্রশ্ন। Marketing-এ সব সময় Meta charge লাগবে বা সবচেয়ে বেশি rate হবে—এমন ধরে নেবেন না।

AI নিয়ে একটা কথা

Provider, account ও business use case-এর বর্তমান terms মেনে AI ব্যবহার করুন। Model-এ কোন data যায়, retention settings কী এবং authorised মানুষ কীভাবে দায়িত্ব নেবেন লিখুন। সব customer-service bot সব restriction থেকে নিজে থেকেই ছাড় পায়—এমন নয়।

Instagram ও Messenger আলাদা করে যাচাই করুন

Instagram ও Messenger-এর permission, window ও supported message আলাদা। প্রতিটি connector-এর current documentation দেখুন; WhatsApp-এর template বা pricing rules অন্য channel-এ প্রয়োগ নয়। Product বা campaign reference রাখুন, যাতে কর্মী প্রশ্নের context পান।

দরকারি order, preference ও consent evidence governed system-এ রাখুন। যতটুকু রাখার অধিকার আছে ততটুকুই export করুন, staff access সীমিত ও retention নির্দিষ্ট রাখুন। পুরো inbox export-ই unrestricted marketing list নয়।

payment: link নাকি ক্যাশ অন ডেলিভারি

Payment evidence order-এর সঙ্গে যুক্ত করুন। Provider payment-এ source, order reference, amount, currency ও status যাচাই করুন। Authorised, captured, failed, refunded ও settled আলাদা রাখুন। Duplicate callback যেন দ্বিতীয় payment বা order না বানায়।

• Payment link: agreed total ও order reference দেখান। Provider evidence যাচাই করে expired link, short payment, duplicate notification ও refund সামলান। শুধু link দিয়ে fraud বা reconciliation দূর হয় না।
• COD: accepted কিন্তু unpaid order, delivery evidence ও courier-এর কাছে পাওনা লিখুন। পরে remittance, fee ও adjustment মেলান। Dispatch confirmation ও cash settlement আলাদা ঘটনা।

Deposit চাইলে acceptance-এর আগে amount, বাকি টাকা ও cancellation/refund terms পরিষ্কার করুন। Published policy সমানভাবে প্রয়োগ করুন। Chat-এর “YES” বা advance একটি choice-এর evidence; failed delivery বা dispute বন্ধের guarantee নয়।

AI কোথায় কাজে লাগে, আর কোথায় মানুষ ধরবেন

Source current ও access scoped থাকলে approved, low-risk fact-এ AI সাহায্য করতে পারে। আন্দাজ করা order number দিয়ে অন্যের private order দেখানো বা lookup fail হলে দাম বানানো চলবে না। স্পষ্ট pending state ও দায়িত্বশীল human route রাখুন।

কাজ	দায়িত্বশীল handling	Control
Public FAQ	Approved source থেকে AI assistance	Current policy ও human route
Price ও availability	Scoped catalogue lookup	Reservation-এ আবার check; আন্দাজ নয়
Private order status	Verified customer ও authorised lookup	শুধু তাঁর permitted information
Address বা discount change	Authorised staff বা সীমাবদ্ধ approved policy	State, limit ও audit evidence যাচাই
Complaint বা refund	Authorised person ও পরিষ্কার queue	Empathy, authority ও প্রয়োজনীয় context
Outage বা অনিশ্চয়তা	Visible pending state ও operator	Bounded retry; duplicate transaction নয়

Customer message-কে untrusted input ধরুন; business rule পাশ কাটানোর permission নয়। Identity, order ownership, discount ও refund server-এ enforce করুন। Handoff-এ authorised staff-কে শুধু দরকারি permitted context দিন; secret বা অন্য customer-এর thread নয়।

যে সংখ্যাগুলো নজরে রাখবেন

Cohort ও সময়সীমা পরিষ্কার করুন। Conversation, customer ও order আলাদা গুনুন। নিচের measure-গুলো সিদ্ধান্তের সঙ্গে যুক্ত করুন:

• Conversation conversion: অন্তত একটি accepted order হওয়া eligible conversation ÷ eligible conversation × ১০০। Duplicate, spam exclusion ও conversion window লিখুন।
• অর্থবহ response time: median ও p90-এর মতো tail measure দিন। কাজের reply ও auto acknowledgement আলাদা করে staffed hours জানান।
• Order value: qualifying chat order-এর net value ÷ ওই order-এর সংখ্যা। Channel তুলনায় একই exclusion রাখুন।
• Status enquiry: delivery-status প্রশ্ন এসেছে এমন eligible order মাপুন। Late parcel, অস্পষ্ট promise ও message delivery তদন্ত করুন; বেশি rate মানেই একটিমাত্র কারণ নয়।
• Outcome ও cost: accepted, delivered, cancelled ও returned order-এর সঙ্গে payment, messaging, AI ও handling cost দেখুন। Conversion মানে profit নয়।

হিসাব বোঝার উদাহরণ: ৪০০ eligible conversation-এর ৭২টিতে অন্তত একটি accepted order হয়েছে; conversion ১৮%। কাল্পনিক ২১% হলে converted conversation হবে ৮৪। এতে faster reply-ই পরিবর্তনের কারণ বা order-গুলো profit-সহ delivered—কোনোটিই প্রমাণ হয় না। একই ধরনের cohort ও handling cost তুলনা করুন।

যে ভুলগুলো এড়িয়ে চলুন

• Promise নেওয়ার আগে current stock ও complete quote যাচাই করুন।
• সঠিক message purpose, permission ও effective pricing ব্যবহার করুন; opt-out মানুন।
• Failed message-এ bounded backoff, দৃশ্যমান owner ও retry-এর আগে policy check রাখুন। Notification fail হলে আরেকটি order নয়।
• Payment বা courier timeout-এর পরে operation আবার দেওয়ার আগে existing reference খুঁজুন।
• Order lookup রক্ষা করুন; authorised colleague-এর দরকারি handoff context-ই রাখুন।
• Automation বাড়ানোর আগে sold-out item, late payment, duplicate callback ও human escalation test করুন।

ধূসর lamp-টিতে ফিরি। Stock check-এ zero, তাই কর্মী ওই পিসের promise বা payment request পাঠাবেন না। Verified alternative দিতে বা restock notification-এর permission চাইতে পারেন। টাকা আগেই এলে authorised resolution-সহ visible exception হবে। Chat গোছানোর জন্য কাল্পনিক order number তৈরি হবে না।

মূল কথা

• Chat entry point হতে পারে; order, stock ও payment-এর controlled record প্রয়োজন।
• Variant, total ও delivery terms-এ explicit acceptance নিন।
• Sending permission ও pricing আলাদা check; current account rules যাচাই করুন।
• Payment evidence verify করুন; COD, fee ও refund মেলান।
• AI-তে scoped facts এবং দায়িত্বশীল human route দিন।
• শুধু chat বা accepted order নয়; completed outcome ও cost মাপুন।

তথ্যসূত্র ও পর্যালোচনা

পর্যালোচনা: ৪ নভেম্বর ২০২৬। WhatsApp-এর public policy page-এর তারিখ ২৩ সেপ্টেম্বর ২০২৬। Linked official page-এ permission, category ও pricing আছে; actual setup-এ effective account/provider terms দেখুন। হিসাব ও lamp-এর গল্প আমাদের বোঝানোর উদাহরণ, promised result নয়।

• WhatsApp Business Messaging Policy
• WhatsApp Business Platform pricing
• WhatsApp utility messages
• WhatsApp marketing messages

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।