Inventory Grounding: Apa yang Terjadi Kalau AI Merekomendasikan Produk yang Habis

Ada satu momen yang kelihatannya receh, tapi efeknya lumayan brutal ke trust. Seorang user tanya ke AI, “Laptop 14 inci yang ringan, RAM 16 GB, budget di bawah Rp15 juta, ada apa?” AI menjawab cukup meyakinkan, menyebut satu produk, menjelaskan spesifikasi, lalu user klik. Begitu masuk ke toko: stok habis.

Kalau kejadian ini cuma sekali, mungkin orang menganggapnya bad luck. Kalau kejadian berkali-kali, masalahnya berubah. User mulai belajar bahwa rekomendasi AI tidak selalu transaksional. Merchant kehilangan peluang. Platform AI terlihat kurang grounded. Dan tim commerce baru sadar bahwa data inventory yang selama ini dianggap urusan backend ternyata sudah menjadi bagian dari pengalaman discovery.

Di sinilah konsep inventory grounding jadi penting.

Grounding, dalam konteks AI commerce, bukan berarti AI “tahu semuanya”. Artinya jawaban atau rekomendasi sedapat mungkin ditambatkan ke data yang nyata, tersedia, dan cukup baru untuk mendukung keputusan pengguna. Kalau AI merekomendasikan produk yang statusnya sudah out of stock, ada celah antara dunia percakapan dan dunia transaksi.

OpenAI, misalnya, pada spesifikasi product feed untuk commerce meminta merchant menyertakan availability dan price pada setiap baris produk atau variant. Dokumentasinya juga secara eksplisit menjelaskan bahwa structured product feed digunakan agar ChatGPT dapat menampilkan produk dengan harga dan ketersediaan yang up to date. Itu bukan detail kosmetik. Itu sinyal bahwa inventory merupakan data inti, bukan pelengkap.

Masalahnya, “stok” di dunia nyata jauh lebih messy daripada satu kolom in_stock atau out_of_stock.

Stok Bukan Boolean Sederhana

Bayangkan sebuah retailer punya 80 toko, tiga gudang, aplikasi sendiri, marketplace, social commerce, dan website. Di dashboard pusat, sebuah SKU tercatat tersedia 42 unit. Kedengarannya aman.

Ternyata 30 unit ada di Surabaya, 8 sedang dialokasikan untuk pesanan yang belum dibayar, 3 rusak tapi belum terhapus dari sistem, dan satu unit terakhir ada di toko yang tidak melayani pengiriman ke alamat user.

Secara agregat: in stock.

Secara transaksional untuk user tertentu: mungkin tidak tersedia.

Ini alasan inventory grounding perlu dibahas lebih dalam daripada sekadar “update feed”. Merchant harus menentukan apa definisi available untuk surface tertentu. Apakah produk dianggap tersedia jika ada minimal satu unit secara nasional? Harus tersedia untuk online fulfillment? Harus bisa dikirim ke lokasi target? Apakah preorder masuk kategori tersedia? Bagaimana dengan backorder?

Spesifikasi OpenAI sendiri membedakan status seperti in_stock, out_of_stock, backorder, dan pre_order, serta meminta availability date untuk skenario preorder atau backorder tertentu. Itu memberi gambaran bahwa availability adalah state yang punya konsekuensi, bukan label dekoratif.

AI Bisa Benar Secara Produk tapi Salah Secara Momen

Ini bagian yang sering bikin tim marketing bingung.

AI bisa benar saat menjelaskan produk: mereknya benar, spesifikasi benar, URL benar, bahkan harga mungkin masih benar. Tetapi jika stok sudah berubah lima menit lalu dan feed belum sinkron, rekomendasinya tetap gagal secara pengalaman.

Dalam commerce, correctness bukan cuma soal deskripsi.

Correctness juga punya dimensi waktu.

Kalau sebuah rekomendasi dibuat berdasarkan inventory kemarin untuk kategori yang stoknya berubah sangat cepat, data itu mungkin sudah tidak layak dipakai untuk keputusan hari ini. Sebaliknya, untuk produk industrial yang lead time-nya mingguan dan stok jarang berubah, update beberapa kali sehari mungkin cukup.

Jadi pertanyaan “berapa sering harus update inventory?” tidak punya satu angka sakti untuk semua merchant.

Yang lebih waras adalah bertanya: seberapa cepat state produk bisa berubah, dan berapa lama kita rela membiarkan AI atau channel commerce lain melihat state yang sudah stale?

Itu namanya freshness tolerance.

Beda Produk, Beda Toleransi

Flash sale punya tolerance nyaris real time. Tiket event punya tolerance sangat rendah. Fashion dengan ukuran populer bisa berubah cepat. Spare part B2B mungkin lebih lambat. Furniture made-to-order bahkan bisa memiliki model availability yang bukan stok fisik, melainkan production capacity.

Kalau semua kategori dipaksa mengikuti satu SLA, hasilnya bisa absurd.

Tim commerce sebaiknya memetakan setidaknya empat hal: velocity stok, dampak salah rekomendasi, kompleksitas fulfillment, dan kemampuan sistem sumber memperbarui data.

SKU yang bergerak cepat dan punya dampak tinggi seharusnya diprioritaskan untuk sinkronisasi lebih agresif. SKU long-tail yang jarang berubah mungkin tidak butuh frekuensi sama.

Masalah klasiknya, banyak perusahaan justru punya pipeline terbalik. Produk best seller diperbarui melalui export batch besar yang lambat, sementara sistem sebenarnya sudah punya event stock change yang bisa dikirim lebih cepat.

Di era AI commerce, arsitektur seperti ini layak ditinjau ulang.

Jangan Biarkan Feed Menjadi Kuburan Data

Banyak perusahaan bangga karena “sudah punya feed”. Setelah dicek, feed itu dibuat dari export harian pukul dua pagi, lalu nyaris tidak pernah dimonitor apakah datanya konsisten dengan storefront.

Secara teknis ada.

Secara operasional, belum tentu bisa dipercaya.

Feed yang sehat perlu punya observability. Merchant seharusnya tahu kapan file terakhir berhasil diproses, berapa produk gagal validasi, berapa SKU berubah status, dan apakah ada perbedaan mencolok antara inventory source dan output feed.

Kalau 12.000 item tiba-tiba semuanya menjadi out_of_stock karena job ERP gagal, sistem harus menyalakan alarm. Kalau harga berubah tapi availability tidak ikut berubah karena field mapping rusak, itu juga harus kelihatan.

Ini bukan pekerjaan SEO tradisional. Ini sudah masuk area data engineering, commerce operations, dan trust engineering.

“Mas, Kan Kalau Habis Tinggal Klik Produk Lain?”

Kalimat seperti ini terdengar masuk akal sampai kita lihat perilaku user.

Ketika orang bertanya ke AI, konteksnya sering lebih spesifik daripada keyword search. User bisa bilang, “Cari stroller cabin size yang bisa masuk pesawat, berat di bawah 7 kg, stok sekarang, kirim ke Jakarta sebelum Jumat.”

Kalau AI menyaring banyak opsi lalu memilih dua produk, setiap hasil punya bobot rekomendasi yang lebih tinggi. Ketika satu ternyata tidak tersedia, friksi terasa lebih besar daripada sekadar melihat satu listing habis di halaman kategori.

AI mempersempit pilihan. Itu bagus. Tetapi makin sempit shortlist, makin mahal biaya sebuah data error.

Ada efek lain: user bisa membuat keputusan lanjutan berdasarkan produk tersebut. Membandingkan garansi, mencari review, menghitung cicilan, atau menyesuaikan budget. Kalau pada ujungnya stok ternyata nol, seluruh reasoning chain tadi menjadi wasted effort.

Karena itu inventory grounding bukan cuma isu conversion. Ia menyentuh kualitas keputusan.

Variant Adalah Titik Rawan

Produk induk sering masih dianggap tersedia walaupun variant yang dicari user sebenarnya habis.

Contoh paling gampang: sepatu.

Model A masih punya 100 unit secara total. Tetapi ukuran 42 warna hitam yang dicari user habis. Kalau feed hanya memodelkan parent product tanpa variant yang cukup jelas, AI bisa memahami bahwa “sepatu ini tersedia” padahal konfigurasi yang relevan tidak tersedia.

OpenAI pada format produk menyatakan satu produk atau variant per row untuk feed yang kompatibel. Ini penting karena identity dan availability memang sering hidup di level variant.

Hal yang sama berlaku untuk kapasitas storage ponsel, warna kendaraan, ukuran pakaian, bundle, subscription tier, sampai konfigurasi perangkat B2B.

Kalau variant modeling berantakan, inventory grounding ikut berantakan.

Apa yang Sebaiknya Dilakukan Merchant

Mulai dari source of truth. Tentukan sistem mana yang benar-benar authoritative untuk stock state. Jangan sampai website membaca dari ERP, marketplace membaca dari middleware, dan AI feed membaca dari spreadsheet yang dibuat tim lain.

Lalu definisikan availability secara operasional. Jangan cuma “ada stok”. Tentukan apakah status memperhitungkan reservation, fulfillment, lokasi, safety stock, lead time, dan variant.

Setelah itu tentukan freshness SLA per kelompok produk. Produk high velocity mungkin perlu pipeline jauh lebih cepat daripada katalog stabil.

Berikutnya, monitor mismatch. Ambil sampel SKU secara rutin dan bandingkan source inventory, feed, storefront, dan surface eksternal yang menerima data tersebut.

Terakhir, buat kill switch. Kalau pipeline rusak atau data diragukan, merchant perlu kemampuan untuk menghentikan distribusi state yang salah daripada terus mempublikasikannya dengan percaya diri.

AI Commerce Membuat Data Operasional Jadi Customer-Facing

Dulu inventory database terasa seperti sistem belakang layar. Customer melihat hasil akhirnya di halaman produk.

Sekarang lapisannya berubah. AI bisa menjadi interface pertama. Product feed bisa menjadi bahan yang membantu sistem memahami katalog. Agent bisa melakukan comparison. Checkout bisa makin dekat ke conversational surface.

Artinya data yang dulu hanya dibaca sistem internal kini punya pengaruh langsung terhadap percakapan customer.

Ini perubahan besar.

Tim marketing tidak bisa lagi bilang inventory urusan IT. Tim engineering juga tidak bisa bilang bagaimana produk dijelaskan ke AI sepenuhnya urusan marketing. Kedua sisi bertemu di data layer.

Dan justru di sana banyak kegagalan akan muncul.

Jangan Menjanjikan Grounding yang Sempurna

Perlu realistis juga. Feed yang bagus tidak menjamin setiap jawaban AI akan selalu sempurna. Ada banyak layer di luar kontrol merchant: indexing, retrieval, ranking, model behavior, availability processing, user context, dan cara platform menggabungkan berbagai sumber.

Yang bisa dilakukan merchant adalah memperkecil sumber error dari sisi mereka.

Kalau produk habis tetapi feed masih bilang tersedia, itu problem yang bisa diperbaiki.

Kalau variant berbeda punya ID kacau, itu bisa diperbaiki.

Kalau inventory refresh gagal tanpa alert, itu bisa diperbaiki.

Kalau tim tidak punya definisi stale data, itu juga bisa diperbaiki.

GEO untuk commerce pada akhirnya bukan permainan trik supaya AI menyebut brand. Fondasinya justru boring: identity yang konsisten, data yang benar, availability yang fresh, policy yang jelas, dan sistem yang bisa diverifikasi.

Boring, yes. Tapi justru hal-hal boring seperti inilah yang menjaga pengalaman tetap waras ketika skala membesar.

Karena rekomendasi AI yang keren tidak ada gunanya kalau ujungnya cuma membawa user ke tulisan merah kecil: “Stok habis.”

Satu hal lagi: merchant sebaiknya menguji skenario kehabisan stok, bukan hanya kondisi normal. Ambil beberapa SKU, ubah availability secara terkontrol di staging atau pipeline uji, lalu lihat berapa lama perubahan itu mengalir ke output yang relevan. Uji juga backorder, preorder, variant terakhir, dan pembatalan reservation. Tujuannya bukan “mengakali AI”, melainkan memastikan sistem internal punya perilaku yang bisa diprediksi saat state berubah. Reliability justru kelihatan ketika kondisi tidak ideal. Kalau semua proses hanya dites saat stok aman dan harga stabil, perusahaan belum benar-benar menguji commerce readiness.