ब्लैक फ्राइडे सेल60% तक की छूट
  • सालाना प्लान के पहले साल पर 60% छूट
  • लाइफ़टाइम लाइसेंस पर 45% छूट
खत्म होगा
ऑफ़र पाएँ

Agentic Commerce: AI Shopper को वही Offer दें जिसे निभा सकें

एक jacket, दो checkout routes और छोटा merchant pilot: discovery, खरीद की अनुमति और fulfilment को अलग रखकर product data सुधारें।

लेखक

Anichur Rahaman

2 महीने पहले6 मिनट पढ़ें219 दृश्य
Agentic Commerce: AI Shopper को वही Offer दें जिसे निभा सकें

“150 के अंदर waterproof jacket चाहिए, weekend से पहले पहुँच जाए।” कल्पना करें कि खरीदार assistant से यह पूछता है। एक outdoor shop में सही jacket है, लेकिन product card पर दूसरे size की कीमत है। Delivery estimate ऐसे postcode पर आधारित है जो खरीदार ने बताया ही नहीं। यह समझाने के लिए बनाया दृश्य है, किसी ग्राहक का वास्तविक नतीजा नहीं।

दुकान को AI जैसी भाषा बोलने की जरूरत नहीं। उसे भरोसेमंद offer देना है: यही variant, यही कुल रकम, इस पते के लिए उपलब्ध, इन शर्तों पर। Assistant खोजने, तुलना करने या खरीदने में मदद कर सकता है। ये अलग काम हैं।

Agentic commerce में software shopping के काम करता है और जहाँ सुविधा व अधिकार हों, व्यक्ति की ओर से खरीद की कार्रवाई भी करता है। इसका अर्थ यह नहीं कि हर assistant भुगतान कर सकता है, हर merchant पात्र है या ग्राहक से रिश्ता खत्म हो गया है।

Protocol के logo से पहले रास्ता समझें

एक रास्ते में assistant product सुझाता है और खरीदार आपकी website पर खरीद पूरी करता है। दूसरे में supported integration assistant के भीतर checkout दिखाता है। Cart transfer बीच का रास्ता है: cart भर सकता है, भुगतान नहीं। Tracking, cancellation और returns को अलग supported capabilities चाहिए; खरीद का integration होने से तीनों नहीं मिल जाते।

इस फर्क से तय होता है कि कौन-सा काम खरीदना है। Feed discovery सुधार सकता है, किसी को order की अनुमति दिए बिना। API specification प्रकाशित करना platform programme में enrolment नहीं। अपने merchant, देश, category और users के लिए वास्तव में उपलब्ध experience जाँचें।

5 नवंबर 2026 को official sources क्या कहते हैं

ये चुने हुए checkpoints हैं, विश्वव्यापी availability list नहीं। OpenAI merchant page और कुछ checkout/help documentation अलग experiences बताते हैं। इसलिए अपना approved route सत्यापित करें; न सभी को access मानें, न सभी के लिए वापसी।

Programme / official referenceक्या सत्यापित करें
ChatGPT merchant programmeवर्तमान merchant page discovery और merchant-owned checkout को प्राथमिकता देता है; shopping U.S. में बताता है। अपना approved experience जाँचें।
Google UCP Cart APIOctober documentation cart transfer को native checkout से अलग रखता है। केवल transfer के लिए native checkout integration जरूरी नहीं।
Perplexity Instant BuyHelp centre compatible merchants से U.S. purchases बताता है। हर store का हर product पात्र नहीं।
Amazon Shop Direct / Buy for MeShop Direct external store खोलता है; पात्र Buy for Me products खरीदार की ओर से खरीदे जा सकते हैं। Participation controls देखें।

Jacket को एक पहचाने जाने योग्य Offer बनाएं

स्थायी product identity और अलग variant identifiers रखें। उदाहरण में JKT-M-TEAL एक medium teal jacket है, model के सभी sizes नहीं। Material, fit, care, weight और प्रमाणित performance claims उचित attributes में रखें। खाली field भरने के लिए GTIN या waterproof test rating न गढ़ें। “Water-resistant” और प्रमाणित waterproof specification एक नहीं।

अच्छी कहानी और तस्वीरें भी रखें। लोग और multimodal assistants imagery, reviews, preferences और brand context इस्तेमाल कर सकते हैं; structured fields उनका विकल्प नहीं। Product page, feed और checkout के दावे नियंत्रित source records से आएं; हर channel mapping में गलती जाँचें।

Feed वितरण के लिए copy है और पीछे रह सकता है। वास्तविक बदलाव की गति और channel requirements के अनुसार update cadence चुनें। Rejected या stale items देखें; transaction के समय कीमत और sellable quantity फिर जाँचें। “Real-time” लिखने से आखिरी jacket reserve नहीं होती।

Checkout पर पहुँचते समय वादा फिर जाँचें

एक अनिर्दिष्ट मुद्रा में उदाहरण: चुना variant 120, पात्र discount 12 घटाता है, shipping 8 और माना गया tax 23.20 जोड़ते हैं: कुल 139.20। यह 150 के budget में तभी है जब budget final total का हो और अन्य लागू charges न बचें। Tax केवल गणित का अनुमान है, किसी बाजार की rate सलाह नहीं।

Delivery quote के लिए जरूरी जानकारी लें। Destination, order cutoff, stock location और carrier service महत्वपूर्ण हैं। “कल dispatch” का अर्थ “weekend से पहले delivery” नहीं। वास्तविक estimate और अनिश्चितता दिखाएं; चुपचाप size, colour, date या महंगा item न बदलें।

Commit करने से पहले current cart जाँचें, system support करे तो stock reserve करें और route के अनुसार approval या delegated authority लें। Recommendation, cart, payment authorisation, captured payment और accepted order अलग records हैं। Timeout के बाद नतीजा अज्ञात हो तो bounded retry से पहले पुराना operation खोजें; screen रुकने पर नया order न बनाएं।

खरीदार के अनुरोध से discovery, फिर merchant website या supported assistant checkout। दोनों में order से पहले validation और authority, बाद में private after-sales access चाहिए।
समझाने वाला route map; हर platform दोनों रास्ते देता है, ऐसा दावा नहीं। Cart transfer paid order नहीं।

Assistant अनुमति से बचने का रास्ता नहीं

Public product facts और private order details को अलग access चाहिए। Status केवल verified buyer या स्पष्ट authorised representative को उसी order और account तक दें। अनुमान योग्य order number या “AI agent” user-agent string अनुमति नहीं। Address, invoice और staff-only stock data public feeds में न दें।

Server पर tokens, scopes और current account permissions सत्यापित करें। Untrusted descriptions, reviews या tool outputs payment instructions या system permissions न बदल सकें। सामान्य fraud, rate-limit और payment controls रखें; automated client भी गलत या दुर्भावनापूर्ण हो सकता है।

Return eligibility, deadlines, condition, costs और refund timing स्पष्ट लिखें, जरूरी कानूनी exceptions समेत। Return request approved refund नहीं और shipped होना delivery का प्रमाण नहीं। नया route खोलने से पहले support, disputes और exceptions का owner तय करें।

Readiness total के बजाय प्रमाण वाला छोटा Pilot

पात्र programme में संभालने योग्य variants चुनें और catalogue quality, checkout तथा support के owner तय करें। Source record से samples मिलाएं; actual destination, discount eligibility, last unit, price change, expired session, commit के बाद timeout और authorised status lookup test करें। यह भी देखें कि दूसरा customer वही order नहीं पढ़ सकता।

Order data leak, unapproved payment या unresolved duplicate-order behaviour पर रुकें। सुंदर images और पूरे attributes का ऊँचा combined score इन failures को नहीं मिटाता। Critical cases pass हों और operations team pilot के orders व पैसे reconcile कर सके, तभी बढ़ाएं।

Feed acceptance और sampled offer accuracy को checkout attempts, accepted orders, settled payments, cancellations और returns से अलग मापें। जहाँ मिले channel order reference व referral data लें; unknown source भी स्वीकारें। Referral हट सकता है, research दूसरे device पर हो सकती है। कुछ attributed sales incremental revenue का प्रमाण नहीं। विस्तार से पहले matched cohorts, acquisition costs, support time और returns के बाद contribution देखें।

अब दुकानमालिक क्या कर सकता है

एक jacket को source record से supported shopping surface, approved order और authorised status lookup तक लेकर जाएं। हर mismatch लिखें और owner दें। बेहतर data भरोसेमंद offer बनाता है; recommendation, ranking या conversion की गारंटी नहीं। अगली platform घोषणा checkout route बदल दे, तब भी यह काम उपयोगी है।

AI shopping series का पहला भाग। आगे product discovery और recommendations, फिर checkout और delegated payments पढ़ें।

समीक्षा: 5 नवंबर 2026। Anichur Rahaman StoreConsole के निर्माता हैं। दुकान, product और गणना शिक्षण उदाहरण हैं; programme availability बदल सकती है।

लेखक का परिचय

Anichur Rahaman

पढ़ना जारी रखें