NAVV · RISET PASAR
Sumber
Bagian 1 · Riset Pasar · Versi Interaktif

Masalah nyata SMB & enterprise yang bisa diselesaikan Navv

Navv memposisikan diri sebagai lapisan identitas produk (canonical commerce entity) untuk perdagangan Indonesia — dimulai dari Custom POS berbasis foto untuk toko pilot, lalu diperluas menjadi Navv Resolve / Commerce Intelligence API untuk penyedia POS, distributor, rantai ritel, dan marketplace.

Semua angka & klaim tertaut ke sumber aslinya — klik untuk verifikasi.

Kartu stok toko “Gula 1 kg” Stok: catatan #1
Kasir / POS “Gula Pasir 1kg” Stok: catatan #2
Toko online “Gula 1000gr” Stok: catatan #3
Entitas kanonik · Navv Resolve
Gula Pasir 1 kg
3 sumber terhubung · stok tergabung · match confidence tinggi
3 catatan terpisah — stok terpecah di tiga sistem
64–66 jt UMKM Indonesia basis pasar Navv
0 pengguna aktif 3 POS besar ≈0,7% dari populasi UMKM
39,3–40 jt merchant QRIS pembayaran sudah selesai didigitalisasi
>0 data produk tak konsisten antara supplier & retailer (GS1 UK)
00Ringkasan eksekutif

“Satu produk fisik punya banyak nama dan kode di banyak sistem” — masalah besar, terukur, dan sudah tervalidasi

Riset ini mengumpulkan bukti nyata, dari Indonesia dan pasar pembanding, bahwa masalah identitas produk adalah masalah besar dan terukur secara finansial — divalidasi baik oleh kegagalan (toko yang berhenti input manual) maupun keberhasilan pemain besar yang membangun solusi serupa secara internal.

Temuan 1 · SMB

Pembayaran selesai, katalog belum

QRIS sudah menjangkau 39–40 juta merchant (±93% UMKM), tapi hanya ±450 ribu pengguna tiga POS besar. Katalog dan stok — bukan pembayaran — adalah celah terbesar digitalisasi warung.

Temuan 2 · Enterprise

Masalah terkuantifikasi global

GS1 UK: >80% data produk supplier–retailer tak konsisten, >60% record duplikat, kerugian £700+ juta dalam 5 tahun. India: e-commerce kehilangan ±US$550–600 juta/tahun akibat data produk buruk.

Temuan 3 · Whitespace

API netral belum ada

Shopee, Grab, dan Tokopedia membangun kapabilitas setara secara internal — tapi belum ada yang menjualnya sebagai API netral untuk POS lokal, distributor FMCG, rantai resto, dan ERP yang tak mampu membangun tim data science sendiri.

Sumber bagian ini (10 tautan)
01Segmen SMB / UMKM Indonesia

Pasar besar, tapi katalog dan stok masih manual

1.1 Skala masalah

Warung kelontong tradisional tersisa sekitar 3,9 juta unit (akhir 2025), turun dari 6,1 juta pada 2007, tergerus ritel modern. Dari populasi tersisa, riset Nielsen atas 2.736 warung dan kios pulsa di 14 kota menemukan baru sekitar 25% yang terdigitalisasi.

Adopsi POS digital jauh di bawah asumsi
Jumlah entitas, skala proporsional
Total UMKM Indonesia64–66 juta
Merchant QRIS (pertengahan 2025)39,3–40 juta
Pengguna Moka POS + Pawoon + majoo±450 ribu
≈0,7% dari populasi UMKM — batangnya nyaris tak terlihat, memang itu intinya.
Sumber: Repositori ETD UGM (2024); Bank Indonesia (2025).
Warung kelontong menyusut, yang tersisa belum digital
Kiri: jumlah warung. Kanan: tingkat digitalisasi (Nielsen, 2.736 responden, 14 kota).
20076,1 juta warung
Akhir 20253,9 juta warung
−36% dalam 18 tahun, tergerus ritel modern.
25% TERDIGITALISASI
Baru sekitar 25% warung & kios pulsa yang terdigitalisasi — sisanya masih mengandalkan pencatatan manual.
Sumber: Blog Bukalapak × Nielsen (2022); ANTARA & CNBC Indonesia (Feb 2026).

Studi sistem informasi managemen UMKM lain menemukan POS digital baru dipakai 34,5% responden, sementara mayoritas masih pakai spreadsheet atau pencatatan manual (JUPTI). Sebagai pembanding, QRIS menjangkau 39,3–40 juta merchant atau 93% dari total UMKM per pertengahan 2025 (BI; CNBC Indonesia) — bukti bahwa gap digitalisasi warung bukan lagi soal pembayaran, melainkan soal katalog produk dan pengelolaan stok.

Celah yang disasar Navv

Studi literatur sistematis atas 25 riset adopsi POS UMKM menemukan manfaat POS yang paling dirasakan adalah efisiensi transaksi (80%) dan akurasi pelaporan keuangan (72%), sedangkan kontrol inventaris justru manfaat yang paling lemah dirasakan — hanya 64%. POS yang ada menyelesaikan transaksi, tapi belum menyelesaikan katalog dan stok. (EKOMA Vol 5 No 5, 2026)

1.2 Bukti kuantitatif: berapa mahal “input manual nama produk” bagi toko

Beberapa data memberi angka biaya langsung dari masalah yang ingin dipecahkan Navv.

5–10 menitinput manual per item produk baru
vs
3–5 detikdengan pemindaian / foto
Pencatatan manual masih dominan
Persentase, berbagai sumber Indonesia
Pelaku usaha yang mencatat keuangan & stok manual80%
UMKM yang masih andalkan pencatatan manual inventaris~60%
Selisih stok akibat input barang telat / salah (18%+13%+10%)±41%
Kerugian nilai inventaris per tahun (2–5%)2–5%
Sumber: Sentrasoft (2026); AccountingPlus × OCBC Business Fitness Index (2023); analisis stock opname, Jurnal UM Surabaya.
Beban waktu per toko
Yang dihabiskan UMKM untuk urusan stok manual
Per minggu 10–15 jam

Waktu yang dihabiskan UMKM untuk urusan stok manual setiap minggunya — waktu yang bisa dipangkas drastis jika produk baru cukup difoto sekali untuk masuk katalog. (Sentrasoft, 2026)

Contoh literal dari lapangan

Satu barang yang sama dicatat sebagai “Gula 1 kg”, “Gula Pasir 1kg”, dan “Gula 1000gr” di sistem berbeda — stoknya terpecah menjadi tiga catatan yang tidak saling terhubung (Kartu Stok, 2026). Studi kasus Toko Ar-Rahman: transaksi ditulis manual di kertas dulu sebelum dipindah ke aplikasi kasir, membuka celah salah catat di setiap perpindahan (Repositori UIN SATU).

Ini bukti langsung bahwa masalah canonical entity bukan hipotesis — sudah terjadi setiap hari di toko riil Indonesia. Navv menyasar penyebabnya di titik paling awal: saat produk baru pertama kali masuk ke sistem.

1.3 Kenapa barcode bukan solusi bagi produk lokal

Banyak produk UMKM tidak memiliki barcode resmi — foto + resolusi identitas menjadi kebutuhan, bukan sekadar pilihan.

Hambatan birokrasi

GS1 dijual per keanggotaan badan usaha

Kapasitas hingga 1.000 nomor per keanggotaan, tapi mensyaratkan dokumen berat: akta notaris, NPWP, izin edar BPOM, surat domisili. (UKM Indonesia)

Kata pelaku lapangan

Barcode disebut eksplisit “kendala”

Koordinator konsultan PLUT UMKM Aceh menyebut biaya & prosesnya sebagai kendala; contoh nyata: UMKM akhirnya memakai barcode terbitan Indomaret alih-alih GS1 resmi. (BisnisUKM)

Status hukum

Bukan kewajiban — hanya standar industri

Barcode ritel bukan kewajiban hukum, sehingga banyak produk beredar tanpa GTIN valid. (Barcodes Indonesia)

Pasar abu-abu

Barcode non-resmi dijual bebas

Reseller menjual nomor barcode non-GS1 seharga Rp440.000–520.000 per nomor — fragmentasi identitas yang justru menambah duplikasi/konflik data. (Barcodes Indonesia) Beberapa pemda bahkan harus mensubsidi barcode gratis. (ANTARA Banten, 2025)

Implikasi untuk Navv

Selama gap ini bertahan, pengenalan produk berbasis foto adalah satu-satunya jalur praktis menuju identitas produk yang konsisten di kasir.

1.4 Studi kasus AI / computer vision nyata di kasir dan inventory

Bukti implementasi nyata (bukan hipotesis) yang relevan sebagai validasi teknis dan pasar bagi Navv.

Akurasi pengenalan produk dari foto
Riset akademik Indonesia (MobileNetV2, EfficientDet)
Satu produk per foto88,8–100%
Lebih dari satu produk per foto30–72%
Akurasi turun drastis untuk keranjang multi-produk.
Sumber: Jurnal ELKOMIKA Itenas (2023); Jurnal JIKSI Untar (2026).
→ Validasi strategi Navv: fokus dulu ke product onboarding satu-per-satu (foto barang baru), bukan langsung pengenalan keranjang penuh.
FirstMartt (India): onboarding katalog
CV + OCR atas foto faktur + repositori 100.000+ produk FMCG terverifikasi
Sebelum14 hari (±20.160 menit)
Sesudah<120 menit
Pangkas ±99% waktu onboarding katalog toko kelontong.
Sumber: FirstMartt (2026). Validasi paling dekat untuk tesis Navv Resolve API: repositori entitas kanonik adalah aset utama, metrik keberhasilannya kecepatan onboarding katalog.

Preseden yang gagal menyebar: JD.ID membuka toko tanpa kasir pertama di Indonesia (JD.ID X Mart, PIK Avenue, 2018) memakai RFID dan pengenalan wajah — pendekatan mahal ini tidak pernah menyebar ke warung, memperkuat argumen bahwa kamera ponsel + AI adalah jalur jauh lebih realistis untuk skala UMKM (Jakarta Post, 2018; JETRO, 2018).

Pesaing lokal sudah hadir — bukti demand sekaligus sinyal urgensi membangun moat lewat kualitas dan cakupan katalog kanonik F&B Indonesia, bukan sekadar fitur kamera:

AsistenToko 3.200+

pemilik toko aktif; “AI kenali produk & catat transaksi otomatis”. (asistentoko.com)

Skoci POS

Auto-Isi Produk dari Foto AI

Fitur onboarding katalog berbasis foto sebagai fitur jualan utama.

NotaKu 80%

klaim penghematan waktu input lewat scan nota otomatis.

Keevana 2 menit

klaim membuat inventaris dari 10 foto sekaligus. (Google Play)

Pelajaran kegagalan

GrowSari (Filipina)

Mobile POS di ±1.000 toko sari-sari — pemakaian sporadis karena tidak terikat kebutuhan mendesak (restock). Setelah pivot ke B2B ordering, baru 10% toko mendaftar. (The Realistic Optimist, 2025)

Pelajaran GrowSari untuk Navv

Pencatatan produk otomatis via foto harus terikat manfaat langsung (stok akurat, kemudahan restock, berpotensi data untuk akses kredit/supplier), bukan berdiri sebagai fitur mandiri.

1.5 Program pemerintah sebagai jalur adopsi dan sumber data

Go digital 25,5 jt

UMKM sudah “go digital” per Juli 2024, dari target 30 juta. (ANTARA, 2024)

E-commerce 25 jt

dari 64,2 juta UMKM sudah onboarding e-commerce per Nov 2025. (Metro TV News, 2025)

Basis data BPOM 249.366

produk pangan olahan terdaftar di Cek BPOM — kandidat sumber acuan awal katalog kanonik F&B kemasan Navv. (BPOM, 2025)

Izin edar baru 2024 55,9%

dimiliki UMKM — dan biaya izin edar bagi usaha mikro sudah dibebaskan (2026). (umkm.go.id)

Preseden kolaborasi

Menteri Koperasi dan UKM pernah menyatakan minat berkolaborasi dengan penyedia POS (Qasir) untuk pendataan UMKM dalam kerangka Sistem Informasi Data Tunggal KUMKM (ANTARA Makassar) — data katalog/transaksi dari POS dianggap infrastruktur data publik bernilai, membuka jalur kemitraan pemerintah bagi Navv Resolve API.

02Segmen enterprise

Master data produk yang berantakan, duplikasi katalog, dan biaya normalisasi berulang

2.1 Master data produk antara distributor, retailer, dan ERP

Bukti paling kuat dan terkuantifikasi: studi industri “Data Crunch” oleh GS1 UK dan Cranfield School of Management (2009), membandingkan 1 juta+ record dari 4 retailer besar (Tesco, Sainsbury's, Asda, Morrisons) dan 4 supplier besar (Nestlé, Unilever, P&G, Mars).

GS1 UK × Cranfield (2009)
Kualitas data produk supplier → retailer
Data yang seharusnya identik ternyata tak konsisten>80%
Record yang dikirim retailer ternyata duplikat>60%
Data yang dipegang retailer cocok dengan supplier<25%
Sumber: GS1 UK/Cranfield (2009); Logistics Manager (2009).
Dampak finansial (grosir Inggris)
Biaya koreksi manual, penyusutan administratif, penjualan hilang
£140 jt/tahunkerugian per tahun
Σ 5 thn
£700jt+total kerugian 5 tahun
Sumber: GS1 UK/Cranfield (2009); Logistics Manager (2009) — “supply chain data errors add £1bn to grocery bill”.

Pasar berkembang menunjukkan pola yang lebih relevan bagi Indonesia. GS1 India dan IBM (2011) menemukan inkonsistensi master data melebihi 70%, dengan bukti paling langsung terhadap masalah Navv Resolve: tiga dari empat retailer memiliki 28% hingga 53% kode item internal yang justru terhubung ke dua kode GS1 atau lebih untuk produk yang sama — estimasi kerugian saat itu Rs 8–10 miliar per tahun (GS1 India/IBM, 2011). Studi Australia menunjukkan pola serupa: hanya 782 dari 3.271 unit konsumen yang match sempurna di ketiga retailer yang diuji (GS1 Australia/IBM).

GS1 US merangkum dampaknya: 80% retailer tidak percaya pada data produk mereka sendiri, inventaris tak akurat menyebabkan ±8,7% penjualan hilang, dan tiga error terbesar adalah listing produk salah, atribut salah, dan duplicate listing/content (GS1 US).

Kasus nyata di Indonesia · Reckitt

Reckitt Indonesia (Dettol, Harpic, Durex) menarik laporan penjualan harian dari ratusan distributor, masing-masing mengirim format berbeda (Excel, CSV, lainnya) tanpa standar baku — tim internal menghabiskan berjam-jam setiap hari membersihkan dan menggabungkan file manual (Toba Consulting, 2025). Yang hilang bukan penyeragaman format file, melainkan pencocokan identitas produk antar distributor — persis pain point Navv Resolve.

Skala Unilever eB2B (5 pasar, termasuk Indonesia)

±500.000 retailer · 600 distributor · 6.000+ sales representative · 75.000 order/hari (Unilever, 2025). Skala ini berarti setiap kesalahan identitas produk direplikasi ke ratusan ribu titik order sekaligus — nilai canonical entity sangat tinggi bagi pemain sebesar ini.

Catatan gap riset: data internal spesifik Indomaret, Alfamart, atau Alfamidi tentang mismatch produk antar sistem tidak tersedia publik — perlu digali lewat wawancara langsung.

2.2 Duplikasi katalog di marketplace e-commerce

Masalah ini diakui terbuka oleh marketplace besar yang beroperasi di Indonesia — dan mereka membangun solusinya sendiri.

Shopee

Standard Product (SSP)

Melarang duplicate listing; menghapusnya berdasar kemiripan nama, gambar, deskripsi. Entitas produk standar dicocokkan lewat kata kunci dan unggahan gambar — Shopee otomatis menyarankan entri standar. (Panduan pelanggaran listing; BigSeller, 2025)

Tokopedia

Ganesha · 350 juta+ listing

Larang listing ganda, wajibkan varian produk sama digabung satu halaman (Seller Center, 2025). Sistem AI internal “Ganesha: Gateway to Product Understanding” memahami katalog >350 juta listing. (Tokopedia Data, 2019; 2020)

Lazada

AI deteksi atribut

Kebijakan anti-duplikasi serupa; kini memakai AI untuk mendeteksi atribut tidak akurat dan merekomendasikan perbaikan pada halaman manajemen atribut penjual. (BigSeller, 2026)

Shopee membuka masalah pencocokan produk ke publik lewat kompetisi Kaggle “Price Match Guarantee” (apakah dua listing dari gambar berbeda adalah produk yang sama), dan klaim knowledge graph multibahasanya memangkas biaya waktu-manusia hingga 60% (wawancara AIQ, 2023). Di Brasil, Shopee bahkan mengadopsi GTIN GS1 pihak ketiga untuk memverifikasi data sebelum listing disetujui setelah menghadapi masalah duplikasi, informasi tak akurat, dan barang tiruan (GS1 case study, 2024) — preseden bahwa marketplace besar bersedia mengintegrasikan layanan identitas produk pihak ketiga.

Biaya masalah, terkuantifikasi (GS1 India × Kanvic, 2026)
Kehilangan tahunan e-commerce & quick-commerce India akibat kualitas data produk buruk
₹5.000 croreper tahun
US$550–600 jtper tahun
FMCG dan makanan disebut kategori dengan dampak margin absolut terbesar (medianews4u, 2026) — sejajar persis dengan fokus vertikal Navv pada makanan & minuman kemasan.
Bukti bahwa verifikasi pihak ketiga bekerja
Bigbasket (India) setelah mengadopsi layanan verifikasi data produk GS1
Pengurangan kesalahan kataloghingga 80%
Sumber: GS1 case study bigbasket (2021). Preseden bahwa pemain besar membayar layanan identitas produk pihak ketiga — dan mendapat hasil terukur.

2.3 Katalog menu di platform food delivery — bukti paling dekat dengan Navv

Konfirmasi bahwa Grab sudah memiliki fungsi internal bernama persis seperti dalam rencana Navv: “Catalog Intelligence”.

Grab · Catalog Intelligence

Tim resmi + CV, OCR, LLM

Inisiatif Menu Quality, Menu Coverage, Menu Management Efficiency — memakai ML, computer vision, OCR, dan LLM untuk foto hidangan, deskripsi item, metadata; mengotomasi onboarding. (Lowongan resmi Grab)

Grab · GenAI GrabFood 2,8 jt

deskripsi menu dibuat otomatis di 5 negara — dari temuan bahwa >50% item menu tak punya deskripsi. (Grab, 2024)

Grab · Merchant Menu Assistant ±70 rb

item menu ditambahkan merchant lewat foto menu fisik dalam ±3 minggu sejak rilis (≈3.300 item/hari) — “foto menu menjadi entitas terstruktur” terbukti pada skala puluhan ribu item/minggu. (Grab, 2024; 500 Global, 2025)

Gojek · GoFood
34% ORDER

order GoFood pernah alami “price edit” akibat harga salah tercantum / item tak tersedia — disebut tim engineering Gojek sendiri sebagai risiko finansial nyata. (Gojek Engineering, 2020)

Infrastruktur katalog GoFood masih mengandalkan template CSV untuk unggah menu massal dan API terpisah untuk update status ketersediaan per outlet (GoBiz Developer Portal; GoFood Merchant Help) — proses manual per outlet inilah sumber utama inkonsistensi nama menu antar cabang. ShopeeFood menegakkan standardisasi nama menu tanpa singkatan lewat aturan manual, bukan layanan resolusi otomatis (Shopee Help Center Indonesia).

Whitespace konkret

Ketiga platform menegakkan standar penamaan secara terpisah dan manual — resto berjaringan yang hadir di GoFood, GrabFood, dan ShopeeFood sekaligus menanggung biaya normalisasi menu tiga kali lipat. Grab membangun kapabilitas ini internal hanya untuk platformnya sendiri; Navv bisa menawarkannya sebagai API netral — termasuk resolusi lintas-sumber (POS, ERP, dan platform delivery sekaligus) — untuk restaurant tech dan resto chain.

2.4 Benchmark akurasi dan model bisnis kompetitor global

Pemain global sudah membuktikan kategori “identitas produk berbasis AI” bernilai komersial signifikan — sekaligus menetapkan bar akurasi yang harus dilampaui Navv. Klik judul kolom untuk mengurutkan.

Pemain Fokus Klaim akurasi / hasil Skala bisnis
DataWeave Product matching lintas retailer — pesaing teknologi terdekat Navv 99%+ akurasi dengan human-in-the-loop Pendanaan relatif kecil (±US$1–7 juta); pelanggan disebut termasuk Adidas, Costco, Home Depot
DataWeave · CB Insights
Trax Retail Shelf vision / retail execution dari foto Identifikasi >1 miliar produk retail; turnaround verifikasi ±10 menit Valuasi ±US$2 miliar (2021); total dana US$975 juta; >500 pelanggan; estimasi pendapatan US$100–150 juta/tahun
Globes, 2021 · Tech Monitor, 2018
ParallelDots (ShelfWatch) Pengenalan SKU dari foto rak 95–98% akurasi; deteksi SKU baru dalam 48 jam 30+ negara; 2,5 juta+ outlet; 15 juta+ foto/bulan; mulai masuk Indonesia (sponsor BIGBOX 2026)
ParallelDots · LinkedIn, 2026
Syndigo + 1WorldSync PIM / sinkronisasi data produk (GTIN-first) Dorel: ROI 380% dalam <2 bulan; kualitas data Stanley Black & Decker naik 60% Enterprise value >US$3,5 miliar pasca merger (2025); >18.000 pelanggan di 60 negara
Syndigo, 2025 · Case study Dorel
Salsify Product experience management ROI 339% dalam 3 tahun (Forrester TEI); Mars hemat ±60.000 jam kerja Valuasi US$2 miliar (2022); total dana >US$450 juta
PR Newswire, 2018 · Case study Mars
Pola positioning Navv

Model bisnis PIM global (Syndigo/1WorldSync, Salsify) berasumsi brand sudah punya GTIN resmi dan tim data sendiri yang mengirim data bersih ke retailer (pendekatan supply-side). Realitas Indonesia berbeda — mayoritas produk F&B lokal tidak punya GTIN terdaftar maupun tim data internal. Di titik inilah Navv melengkapi, bukan bersaing head-to-head: menyelesaikan resolusi dari data kotor, foto, dan produk tanpa barcode resmi.

2.5 Tantangan struktural barcode/GS1 yang memperbesar pasar Navv di sisi enterprise

Barcode GS1 secara de facto wajib untuk masuk ritel modern — Indomaret, Alfamart, dan Transmart mewajibkannya untuk setiap SKU yang masuk rak, dan barcode non-resmi berisiko duplikasi sehingga gagal scan atau ditolak saat QC (BoxHero). Namun kelangkaannya terdokumentasi konkret:

Pamekasan, 2024 10 dari 12

produk UMKM yang lolos kurasi ke toko modern baru berhasil mendapat barcode produk. (Kabar Madura, 2024)

Sosialisasi pemda 40–50 UMKM/acara

jangkauan intervensi pemerintah daerah per acara — jauh di bawah jumlah UMKM F&B yang butuh masuk ritel modern. (Dinas KUKM Babel; Klikduakali, 2026)

Momentum kebijakan terbaru

Bebas listing fee, barcode opsional

Kementerian UMKM × Aprindo sepakat membebaskan listing fee bagi UMKM yang memasok ritel modern — syarat makanan-minuman hanya mencantumkan “barcode, jika tersedia” (opsional, bukan wajib mutlak). (Kabar Bursa)

Implikasi struktural

Gelombang SKU UMKM baru akan masuk ke rak ritel modern dengan data produk mentah dan sering tanpa GTIN resmi — memperbesar, bukan memperkecil, kebutuhan struktural atas layanan resolusi identitas produk di sisi retailer, distributor, dan penyedia POS.

03Matriks peluang

Masalah, target pelanggan, dan bukti pendukung

Filter berdasarkan segmen — setiap kartu merangkum masalah nyata, siapa yang berpotensi bayar, dan bukti kuncinya.

Toko kelontong / warung pilot

Input manual nama produk baru lambat (5–10 menit/item), stok terpecah karena nama tak konsisten

Siapa bayar: pemilik toko (langsung, via Custom POS)

Penyedia POS lokal (Moka, Qasir, Olsera, majoo, dll)

Kontrol inventaris adalah fitur POS dengan manfaat paling lemah dirasakan pengguna (64%)

Siapa bayar: penyedia POS (lisensi API untuk fitur katalog otomatis)

Distributor FMCG

Format laporan berbeda-beda dari ratusan distributor/gudang, tanpa identitas produk terstandar

Siapa bayar: distributor & brand FMCG (kasus serupa: Reckitt)

Rantai ritel modern

Barcode resmi langka untuk SKU UMKM baru pasca penghapusan listing fee

Siapa bayar: retailer & tim procurement/merchandising

Marketplace e-commerce

Duplikasi listing & atribut tak akurat merugikan pengalaman pembeli dan margin

Siapa bayar: tim katalog / trust & safety marketplace

Platform food delivery & resto chain

Normalisasi menu manual per outlet & per platform; 34% order GoFood alami price edit

Siapa bayar: restaurant tech / resto chain multi-outlet

AI commerce agent

Substitusi produk lintas-merchant butuh identitas kanonik dengan confidence score

Siapa bayar: platform agentic commerce (mis. Grab Shopping Agent)

04Kesimpulan & implikasi

Bukti mendukung urutan langkah yang sudah direncanakan

  1. Buktikan manfaat di dua toko pilot sebelum menjual visi enterprise.

    Data menunjukkan penyebab langsung masalah stok di UMKM (±41% terkait input barang telat/salah; 5–10 menit per item input manual) persis yang bisa dipangkas lewat foto-ke-katalog otomatis.

  2. Demand sudah terbukti di pasar warung — kecepatan itu penting.

    Pesaing lokal (AsistenToko, Skoci POS, NotaKu) sudah membuktikan ada permintaan nyata untuk fitur ini di pasar warung Indonesia.

  3. Peringatan GrowSari: ikat fitur ke manfaat bisnis harian.

    Pencatatan produk otomatis harus terikat manfaat langsung yang dirasakan pemilik toko setiap hari (stok akurat, restock, data untuk akses kredit/supplier) — bukan berdiri sendiri sebagai kecanggihan teknologi.

  4. Enterprise tervalidasi oleh pemain terbesar Asia Tenggara — dan itulah whitespace-nya.

    Shopee, Grab, dan Tokopedia semuanya punya tim/sistem setara “Catalog Intelligence” atau canonical product entity, namun belum ada yang menjualnya sebagai API netral ke distributor FMCG menengah, penyedia POS lokal, resto chain multi-platform, atau retailer regional.

  5. Bangun katalog kanonik F&B kemasan Indonesia sebagai moat — sebelum pesaing global masuk.

    Kombinasi benchmark biaya global (GS1 UK, GS1 India) dan realitas struktural Indonesia (barcode langka, gelombang SKU UMKM pasca penghapusan listing fee) memberi Navv jendela waktu, sebelum pemain seperti ParallelDots (yang sudah mulai menjajaki Indonesia) lebih dulu.

Gap riset — tutup lewat wawancara / data primer sebelum pitch ke enterprise besar
Bagian 2 · Arsitektur & Teknologi

Rekomendasi arsitektur teknologi: Navv Commerce Intelligence di Cloudflare

Dari POS pilot berbasis foto hingga Navv Resolve API untuk enterprise — hampir seluruhnya dapat dibangun di atas platform Cloudflare, karena semua kebutuhan inti (API edge bervolume tinggi, penyimpanan gambar murah, pencarian vektor untuk resolusi entitas, dan orkestrasi AI multi-provider) sudah punya produk native yang matang.

16produk Cloudflare dipetakan ke kebutuhan Navv
5langkah pipeline resolusi entitas
3fase rollout: pilot → API v1 → enterprise
US$0biaya pretraining — moat ada di data, bukan model
05Arsitektur · Peta kebutuhan → produk Cloudflare

Setiap kebutuhan Navv sudah punya produk native

Berdasarkan dua fase rencana bisnis Navv — (1) POS kustom untuk toko pilot dan (2) Navv Resolve API untuk POS provider, distributor, dan ritel enterprise — berikut pemetaan komponen ke layanan Cloudflare. Filter per kategori:

Kebutuhan NavvProduk CloudflareLayerAlasan
Aplikasi kasir pilot (ambil foto, transaksi) Pages (PWA) atau app native Capture Distribusi cepat tanpa app store untuk pilot awal — cocok untuk 2 toko / 100–300 produk
Endpoint publik untuk POS, Navv Resolve API Workers Edge compute Compute serverless di 200+ kota, latensi rendah untuk klien enterprise yang tersebar
Simpan foto produk & foto faktur R2 Object storage Tanpa biaya egress — penting karena tiap resolusi butuh baca ulang gambar referensi; kompatibel S3
Optimasi / resize gambar sebelum inferensi AI Images Media pipeline Kompres otomatis sebelum dikirim ke model vision — hemat biaya inferensi
Data relasional: merchant, toko, katalog kanonik, transaksi, log konfidensi D1 Database SQLite di edge, hingga 1 TB per akun paid plan — cukup untuk skala ribuan toko pilot–menengah (D1 release notes)
Cache lookup cepat (produk populer, token sesi) KV Cache Baca sangat cepat di edge untuk hot path resolusi berulang
Status real-time per toko (antrean review, sinkronisasi stok, WebSocket ke kasir) Durable Objects State terkelola Konsistensi transaksional per-entitas (per toko / per sesi) tanpa database lock terpisah
Antrean pemrosesan foto → ekstraksi → pencocokan Queues Async pipeline Decouple upload foto dari pipeline AI yang lebih lambat; retry otomatis tanpa biaya egress
Pencarian kemiripan visual / teks untuk resolusi entitas Vectorize Vector search Inti “kenali produk cukup dari foto” — index vektor untuk mencocokkan foto baru ke entitas kanonik
Ekstraksi atribut dari foto (OCR, deteksi objek, vision-language) Workers AI Inferensi AI Model vision terkelola di edge tanpa perlu kelola GPU sendiri
Orkestrasi ke model eksternal (fallback, caching, kontrol biaya) AI Gateway AI gateway Cache respons identik (hemat latensi hingga 90%), batas anggaran per model/provider, routing dinamis (AI Gateway Features)
Metering pemakaian API untuk tagihan enterprise (per-resolve pricing) Analytics Engine Analytics Hitung volume panggilan per klien enterprise untuk model harga berbasis penggunaan
Autentikasi tim internal (dashboard Data Ops / review) Access (Zero Trust) Akses Kontrol siapa yang bisa membuka antrean review foto sensitif
Proteksi form publik (signup pilot, kontak sales) Turnstile Bot protection Alternatif CAPTCHA tanpa mengganggu UX
Kuota & rate limit per klien enterprise pada Navv Resolve API Rate Limiting / API Shield API management Diferensiasi tier (pilot gratis vs enterprise berbayar)
Audit log & analitik penggunaan Logpush + Analytics Observability Investigasi kualitas resolusi, debugging kasus salah kenali
Sumber bagian ini (2)
06Arsitektur · Tingkat tinggi

Dari foto ke entitas kanonik — satu pipeline dengan manusia sebagai jaring pengaman

Diagram alur sistem end-to-end. Klik setiap node untuk melihat produk Cloudflare yang dipakai dan alasannya.

foto produk · barcode · teks
job async
berdasarkan skor confidence
Detail node — klik node di atas untuk mengganti

Selaras dengan “Navv Data Ops”

Pola ini menjaga “otak” resolusi — kombinasi pencocokan barcode, visual, teks, dan histori merchant, dengan manusia sebagai jaring pengaman untuk kasus tidak pasti — selaras dengan konsep Navv Data Ops yang sudah disebut dalam rencana bisnis. Setiap kasus yang direview manusia otomatis menjadi data latih baru — inilah yang mempercepat pertumbuhan katalog kanonik dari waktu ke waktu.

07Arsitektur · Pipeline AI resolusi foto

Dua tahap: ekstraksi atribut, lalu pencocokan vektor

Fakta penting tentang katalog model

Katalog Workers AI saat ini tidak menyediakan model image-embedding murni ala CLIP untuk pencarian kemiripan visual langsung. Yang tersedia justru model vision-language yang lebih cocok untuk ekstraksi atribut terstruktur dari foto.

Ekstraksi cepat

Moondream 3.1

9B mixture-of-experts, 2B active params — cepat, cocok untuk OCR, deteksi objek, dan output terstruktur dari foto produk.

Penalaran visual kompleks

Llama 3.2 11B Vision & generasi baru

Llama 3.2 11B Vision Instruct, plus model vision generasi baru seperti Kimi K2.6 dan GLM-5.2 untuk kasus yang lebih sulit.

Embedding teks

BGE-M3 multibahasa

Mendukung teks Indonesia (multi-linguality, multi-granularity) — mengubah hasil ekstraksi (merek, varian, ukuran) menjadi vektor yang bisa dicari di Vectorize.

Tahap 1 · Ekstraksi

Foto → atribut terstruktur

Foto produk diproses model vision — Workers AI (Moondream, Llama Vision) untuk kasus umum, atau model frontier eksternal (GPT/Gemini vision) lewat AI Gateway untuk akurasi lebih tinggi di kasus sulit. Keluaran: merek, nama produk, varian, ukuran, teks kemasan.

Tahap 2 · Pencocokan

Teks → vektor → entitas kanonik

Teks terstruktur di-embed dengan BGE-M3 (atau model embedding lain), lalu query Vectorize k-nearest-neighbor terhadap katalog kanonik untuk menemukan entitas yang cocok.

Vectorize · dimensi 1.536

dimensi maksimum per vektor yang didukung

Vectorize · skala 20 jt

vektor per index, hingga 50.000 index per akun paid — kapasitas jauh lebih dari cukup untuk katalog F&B nasional sekalipun

AI Gateway · efisiensi hingga 90%

reduksi latensi lewat caching request identik — plus spend limit per model/provider dan routing fallback otomatis

Sinyal ketiga untuk kasus sulit

Untuk teks kemasan yang tidak terbaca jelas (foto blur, silau, kemasan rusak), tambahkan sinyal image embedding murni dari API vision eksternal khusus product-recognition (semacam yang dipakai NeuralCart atau Google Vertex AI Vision Product Recognizer), dipanggil lewat AI Gateway — caching, spend limit, dan fallback routing sudah ditangani gateway.

Sumber bagian ini (4)
08Arsitektur · Keputusan model

Haruskah Navv membangun LLM sendiri?

Tidak.

Bukan untuk tahap Navv sekarang — dan kemungkinan besar tidak akan pernah perlu pretraining dari nol.

Navv masih di fase pilot 2 toko dengan target minimum 500 transaksi — jauh dari skala yang membenarkan investasi model foundation. Keputusan membangun model dari nol digambarkan sebagai “keputusan modal USD 50 juta+ dengan payback period 3 tahun, yang tepat untuk kurang dari 100 organisasi di dunia” (SFAI Labs).

Biaya melatih model dari nol
Estimasi biaya komputasi pelatihan, skala logaritmik (USD)
Model 7B dari nol (2026) — komputasi saja, belum termasuk data & talentaUS$0,5–2 juta
GPT-3 175B (2020) — ribuan GPU V100 berjalan puluhan hari±US$4,6 juta
Model foundation frontier (2026)US$10 juta – 1 miliar+
Biaya komputasi kelas ini berulang setiap kali model dilatih ulang dari nol — bukan biaya satu kali.
Sumber: Sivaro (2026); GPUnex (2026); Alice Labs, Foundation Models (2026); SFAI Labs.
Moat Navv bukan di model, tapi di data

Model bahasa/vision yang dipakai membaca foto bisa diganti — dari Workers AI ke provider lain, dari model A ke model B — tanpa mengurangi nilai Navv, selama grafik entitas kanonik dan data pelatihan berlabel tetap milik Navv. Kompetitor manapun bisa memanggil GPT/Gemini/Llama vision yang sama; yang tidak bisa mereka tiru dengan cepat adalah dataset berlabel dari ribuan interaksi nyata di toko-toko Indonesia yang sudah dikumpulkan Navv.

8.1 Jalur yang direkomendasikan: pretrained + fine-tuning ringan

  1. Tahap pilot (sekarang): pakai model vision pretrained langsung.

    Workers AI (Moondream 3.1, Llama Vision) untuk kasus umum, atau model frontier eksternal via AI Gateway untuk kasus sulit. Tidak perlu training sama sekali — fokus mengumpulkan data berlabel dari toko pilot (foto + entitas kanonik yang benar, dikonfirmasi lewat review Data Ops).

  2. Tahap penguatan: fine-tuning ringan dengan LoRA, bukan pretraining.

    Setelah ratusan–ribuan foto berlabel terkumpul: LoRA (Low-Rank Adaptation) di atas model open-weight — didukung native oleh Workers AI (bawa adapter LoRA hasil training sendiri, termasuk via integrasi HuggingFace AutoTrain). Biaya: skala ribuan–puluhan ribu dolar, bukan ratusan ribu–juta dolar — bisa dijalankan tim kecil.

  3. Tahap skala: model visual khusus yang sempit — bukan LLM serba-bisa.

    Jika volume sudah sangat besar (jutaan foto/representasi produk F&B Indonesia), pertimbangkan melatih model klasifikasi/embedding visual khusus yang dioptimalkan mengenali kemasan produk F&B Indonesia — scope jauh lebih kecil dan realistis, tetap diserving lewat Workers AI atau infrastruktur inferensi custom di belakang AI Gateway.

Ringkasan keputusan

Jangan investasikan modal untuk membangun LLM sendiri di tahap manapun yang relevan untuk Navv saat ini. Investasikan modal itu untuk mempercepat pengumpulan dan kurasi data entitas kanonik — itulah aset yang benar-benar menjadi penghalang bagi pesaing.

Sumber bagian ini (6)
09Arsitektur · Rekomendasi bertahap

Satu stack yang tumbuh dari 2 toko pilot sampai enterprise

Pilih fase untuk melihat fokus dan stack yang dipakai:

Fase 1 · Pilot (2 toko, 100–300 produk/toko)

Validasi akurasi resolusi & UX kasir

Pages (PWA) Workers D1 R2 Workers AI · vision pretrained Vectorize AI Gateway — opsional, fallback kasus sulit
Fase 2 · Navv Resolve API v1 (POS provider awal)

API stabil, multi-tenant, mulai fine-tuning LoRA dari data pilot

+ Durable Objects — state per-klien + Queues — skala volume + Analytics Engine — metering + Access — dashboard Data Ops + LoRA fine-tune pertama di Workers AI
Fase 3 · Skala enterprise (distributor, ritel, marketplace)

Throughput tinggi, SLA, kontrol biaya AI multi-provider

AI Gateway penuh — spend limit, dynamic routing, guardrails API Shield / rate limiting per tier klien Model visual khusus terlatih sendiri — bila volume data sudah sangat besar (bukan LLM umum)
Kesimpulan bagian arsitektur

Arsitektur Cloudflare-native — Workers sebagai lapisan API, D1/R2/KV untuk penyimpanan, Durable Objects untuk state real-time, Queues untuk pipeline async, Vectorize untuk pencarian entitas, dan Workers AI + AI Gateway untuk inferensi AI fleksibel antar-provider — cukup untuk membawa Navv dari pilot 2 toko hingga Navv Resolve API skala enterprise tanpa perlu mengelola infrastruktur GPU sendiri di awal. Jalur yang tepat: pakai model pretrained yang tersedia (via Workers AI atau AI Gateway), lalu fine-tune ringan dengan LoRA begitu data berlabel dari pilot terkumpul cukup.

AApendiks · Sumber

Semua referensi, dikelompokkan per bagian

Klik untuk membuka. Semua tautan terbuka di tab baru.

1.1 Skala masalah (5)
1.2 Biaya input manual (5)
1.3 Barcode bukan solusi (5)
1.4 Bukti AI / computer vision (8)
1.5 Program pemerintah (5)
2.1 Master data enterprise (7)
2.2 Duplikasi marketplace (10)
2.3 Food delivery (8)
2.4 Benchmark kompetitor global (10)
2.5 Barcode & ritel modern (5) + Matriks peluang (1)
Arsitektur & teknologi (14)