AI Commerce untuk Marketplace: Tantangan Multi-Seller dan Data Availability

Seorang buyer mengetik:

“Cari laptop model X yang ready, garansi resmi, bisa dikirim ke Depok besok, dan seller-nya terpercaya.”

Bagi marketplace, query itu terlihat sederhana.

Di belakang layar, ia bisa berubah menjadi puzzle.

Model laptopnya satu.

Sellernya 47.

Ada official store.

Ada distributor.

Ada reseller.

Ada refurbished seller.

Harga berbeda.

Stok berbeda.

Lokasi fulfillment berbeda.

Garansi berbeda.

Estimasi pengiriman berbeda.

Sebagian seller belum update stock.

Sebagian punya promo yang hanya berlaku di aplikasi.

Sebagian listing duplicate.

Sekarang bayangkan AI mencoba menjawabnya dalam satu rekomendasi yang ringkas.

Itulah mengapa AI commerce untuk marketplace jauh lebih kompleks daripada untuk brand direct-to-consumer dengan satu catalog dan satu merchant.

Product bukan seller.

Seller bukan offer.

Offer bukan inventory.

Marketplace harus menjaga hubungan di antara semuanya.

Google Merchant Center bahkan secara eksplisit membedakan konfigurasi marketplace, termasuk multi-seller, marketplace-owned seller, dan single-seller. Di ekosistem OpenAI Agentic Commerce, product feed juga membawa seller context, price, availability, serta data product lainnya agar sistem dapat memahami apa yang benar-benar dapat ditawarkan.

Untuk marketplace Indonesia, seller context bukan detail tambahan.

Ia inti dari trust dan availability.

Satu produk bisa punya banyak kebenaran komersial sekaligus

Katakanlah ada satu produk: kamera mirrorless tertentu.

Secara product identity, spesifikasinya sama.

Tetapi Offer A:

seller official,

harga Rp14 juta,

stock 5,

garansi resmi,

same-day Jakarta.

Offer B:

seller reseller,

harga Rp13,5 juta,

stock 1,

garansi toko,

pengiriman dua hari.

Offer C:

seller lain,

harga Rp12,8 juta,

condition used,

tidak ada garansi resmi.

Kalau AI hanya melihat nama produk dan harga terendah, jawaban bisa misleading.

Buyer mungkin berkata “yang termurah”, tetapi tetap mengasumsikan barang baru dan garansi resmi.

Marketplace perlu membuat semantic boundary yang jelas antara product attributes dan offer attributes.

Product:

brand,

model,

specification,

variant,

identifier.

Offer:

seller,

price,

condition,

availability,

warranty,

shipping,

promotion,

return terms.

Dalam multi-seller environment, AI recommendation yang akurat membutuhkan keduanya.

Availability juga harus seller-specific

Ini bagian yang sering gagal.

Marketplace menyimpan status “product available” pada product level.

Padahal sebenarnya seller A sold out, seller B available, seller C listing inactive.

Kalau AI memilih seller A berdasarkan reputation lalu menggabungkan stock seller B, tercipta synthetic offer yang tidak pernah benar-benar ada.

Harga dari satu seller.

Stok dari seller lain.

Garansi dari seller ketiga.

Ini jenis hallucination yang sebenarnya bukan murni “model mengarang”. Sumber datanya sendiri tidak menjaga boundary yang cukup jelas.

Karena itu availability harus melekat pada offer yang spesifik.

Seller X.

Variant Y.

Location atau fulfillment node Z bila relevan.

Timestamp.

State.

Available.

Out of stock.

Preorder.

Backorder.

Discontinued.

Marketplace dengan inventory cepat berubah juga perlu memahami latency.

“Available” dari lima jam lalu tidak punya confidence yang sama dengan “available” dari dua menit lalu untuk produk flash-sale.

Freshness perlu menjadi bagian dari decision.

AI seharusnya tidak diberi false certainty hanya karena field availability tidak kosong.

Seller identity perlu canonical

Marketplace Indonesia punya problem yang familiar.

Nama toko berubah.

Satu seller punya beberapa storefront.

Official store pindah account.

Distributor memakai nama mirip brand.

Unauthorized seller menambahkan kata “official”.

Seller merger.

Seller suspended.

Seller aktif lagi.

Kalau identity layer tidak rapi, AI sulit menilai siapa yang sebenarnya menjual.

Marketplace perlu canonical seller ID yang stabil di belakang display name.

Display name boleh berubah.

Seller ID tidak seharusnya ikut berubah tanpa alasan kuat.

Lalu tambahkan seller attributes yang memang dapat diverifikasi:

official status bila benar,

business identity sesuai policy,

rating atau reputation signal jika boleh digunakan,

fulfillment capability,

service area,

return participation,

warranty role,

account status.

Jangan mengubah semua itu menjadi satu “trust score” misterius tanpa explainability.

Lebih sehat menyimpan signals terpisah.

Karena pertanyaan user berbeda.

“Seller resmi” membutuhkan bukti berbeda dari “seller cepat kirim”.

“Seller murah” berbeda dari “seller dengan return paling mudah”.

AI commerce yang bagus harus bisa memilih signal yang sesuai intent.

Multi-seller juga menciptakan ranking dilemma

Bayangkan lima seller menawarkan produk yang sama.

Siapa yang ditampilkan?

Harga termurah?

Official?

Paling dekat?

Stock terbanyak?

Delivery tercepat?

Rating tertinggi?

Checkout paling mudah?

Tidak ada jawaban universal.

OpenAI pernah menjelaskan bahwa ketika beberapa merchant menjual produk yang sama, experience dapat mempertimbangkan faktor seperti availability, price, quality, primary seller status, serta support untuk checkout tertentu untuk mengoptimalkan pengalaman pengguna. Itu bukan formula yang boleh diterjemahkan menjadi “ranking factor pasti dengan bobot sekian”.

Bagi marketplace, implication-nya lebih sederhana.

Feed harus menyediakan data yang memungkinkan sistem membuat trade-off secara benar.

Kalau seller type tidak jelas, sistem tidak bisa membedakan official dan reseller.

Kalau shipping estimate tidak ada, delivery constraint tidak dapat dinilai.

Kalau condition tidak jelas, harga termurah bisa menang padahal produk bekas.

Kalau stock stale, seller yang sudah habis bisa terlihat available.

Quality data membuat ranking decision lebih grounded, walaupun formula ranking tidak kita ketahui.

Jangan menyatukan marketplace inventory dengan brand inventory

Brand sering punya feed sendiri.

Marketplace punya feed sendiri.

Reseller mungkin juga punya feed.

Satu produk muncul dari banyak jalur.

Ini normal.

Yang berbahaya adalah ketika organisasi mencoba membuat satu record universal yang menghapus provenance.

Sistem perlu tahu:

data ini berasal dari siapa,

seller siapa,

kapan diperbarui,

offer mana,

market mana,

currency apa,

policy mana yang berlaku.

Provenance membantu correction.

Kalau harga salah di seller tertentu, brand tidak perlu mengubah canonical product price yang sebenarnya hanya MSRP atau reference price.

Kalau warranty berbeda antar seller, jangan mengubah product attribute menjadi “garansi 2 tahun” untuk semua offer.

Semakin marketplace besar, semakin penting menjaga product truth dan seller truth sebagai layer berbeda.

Data availability bukan cuma stock

Dalam conversation, buyer jarang bertanya “stock ada?”

Mereka bertanya:

“Bisa sampai besok?”

“Warna hitam ready?”

“Bisa COD?”

“Ada cicilan?”

“Garansi resmi?”

“Bisa retur?”

“Dikirim dari mana?”

Availability dalam arti praktis adalah kemampuan menyelesaikan kebutuhan user.

Produk mungkin in stock tetapi tidak deliverable ke alamat tertentu.

Produk available tetapi seller sedang libur.

Produk ready tetapi shipping cutoff sudah lewat.

Produk bisa dibeli tetapi metode pembayaran user tidak didukung.

Variant tersedia, ukuran yang diminta tidak.

Jadi marketplace perlu memikirkan contextual availability.

Inventory state adalah satu input.

Fulfillment.

Geography.

Payment.

Seller operation.

Policy.

Time.

Semuanya dapat memengaruhi apakah offer benar-benar actionable.

Agentic commerce membuat masalah ini makin konkret karena AI tidak berhenti pada recommendation. Ketika user ingin melanjutkan transaksi, state harus dapat divalidasi kembali.

Snapshot untuk discovery tidak cukup untuk checkout.

Revalidate sebelum commitment

Marketplace sebaiknya punya dua level.

Discovery state.

Authoritative transaction state.

Pada discovery, cache mungkin acceptable untuk performance dengan batas freshness tertentu.

Pada checkout, price, stock, seller, shipping, tax/fee, dan policy yang material perlu divalidasi lagi.

Kalau berubah, user perlu melihat perubahan.

Skenario:

AI menemukan seller A dengan harga Rp3,2 juta.

User bilang lanjut.

Saat checkout, stock seller A habis.

Sistem mengganti otomatis ke seller B Rp3,45 juta.

Apakah boleh langsung charge?

Tidak seharusnya.

Seller dan total berubah.

User perlu confirmation baru.

Multi-seller membuat revalidation jauh lebih penting karena substitution dapat mengubah banyak hal sekaligus.

Bukan hanya price.

Warranty.

Delivery.

Return.

Merchant identity.

Data yang baik harus memungkinkan sistem mendeteksi bahwa perubahan itu material.

Marketplace juga perlu correction path

Katakan AI berkali-kali menunjukkan seller yang sudah suspended.

Siapa yang memperbaiki?

Team feed?

Trust and safety?

Catalog?

Search?

Seller ops?

AI integration?

Tanpa correction ownership, incident berputar.

Buat classification.

Product identity error.

Offer price error.

Availability error.

Seller identity error.

Policy error.

Fulfillment error.

Duplicate listing error.

Trust signal error.

Lalu tetapkan owner dan SLA internal.

Untuk high-volume marketplace, manual correction satu per satu tidak scalable. Pola error harus dikembalikan ke source system.

Kalau 2.000 listing salah karena satu seller mapping, perbaiki mapping.

Jangan edit 2.000 rows.

Jangan lupakan seller-generated content

Marketplace mempunyai sumber noise yang tidak dimiliki retailer tunggal: seller dapat membuat atau mengubah listing.

Satu seller menulis nama resmi.

Seller lain menambah “BEST SELLER TERMURAH ORIGINAL!!!”.

Seller ketiga menaruh model number yang salah.

Seller keempat memakai foto variant lama.

Kalau product matching terlalu bergantung pada seller title, entity confusion akan terus masuk ke canonical catalog.

Marketplace perlu layer normalization.

Map seller listing ke canonical product bila confidence cukup.

Tahan listing untuk review jika identifier bertentangan.

Pisahkan seller marketing copy dari product specification canonical.

Jangan biarkan satu seller mengubah fakta produk untuk semua seller.

Namun normalization juga tidak boleh terlalu agresif. Dua produk yang namanya mirip belum tentu sama. Variant, region, bundle, storage, size, condition, dan warranty package dapat membuat offer materially berbeda.

Jadi matching system perlu confidence dan exception handling.

Untuk produk high-value atau high-risk, human review mungkin tetap diperlukan pada edge case.

Di sisi lain, seller perlu feedback yang actionable.

Bukan cuma “listing rejected”.

Jelaskan apakah problem ada pada identifier, image, price mismatch, prohibited claim, variant mapping, atau availability.

Data quality marketplace tidak akan sehat kalau seller hanya diberi error message generik lalu menebak-nebak cara memperbaikinya.

Marketplace punya keunggulan besar jika datanya disiplin

Multi-seller memang rumit, tetapi marketplace juga punya asset yang brand tunggal tidak punya.

Breadth.

Comparative price.

Seller diversity.

Inventory distribution.

Delivery options.

Buyer reviews.

Transaction history.

Fulfillment network.

Semua itu dapat membuat AI recommendation lebih useful.

Syaratnya: mesin dapat memahami boundary di antara data tersebut.

Satu produk.

Banyak seller.

Banyak offer.

Banyak state.

Banyak policy.

AI tidak boleh dipaksa menyimpulkan semuanya dari judul listing yang dibuat seller.

Marketplace yang serius di AI commerce perlu bergerak dari listing-centric data ke entity-and-offer architecture.

Product identity stabil.

Seller identity stabil.

Offer relationship jelas.

Availability hidup.

Freshness terlihat.

Policy attached ke pihak yang benar.

Transaction state divalidasi sebelum commitment.

Itu pekerjaan berat.

Tetapi buyer tidak akan melihat kompleksitas tersebut.

Mereka hanya melihat satu jawaban sederhana:

“Yang ini ready, dijual official store, bisa sampai besok, totalnya sekian.”

Kalau marketplace ingin AI memberikan jawaban sesederhana itu dengan benar, backend datanya justru harus jauh lebih sophisticated daripada kalimat yang akhirnya terlihat di layar.