Business plan & roadmap 2026 / HTML v7

Satu mesin untuk memahami produk dan menu Indonesia.

Navv Commerce Intelligence mengubah foto, barcode, teks, suara, dan kode lokal menjadi identitas produk atau menu yang dapat dipakai POS, restoran, kendaraan, dan sistem enterprise.

Custom POS retail Voice food intelligence Enterprise API as a Service

Lihat alur produk Mulai dari 90 hari

Keputusan utama

Tiga produk, satu fondasi data.

Tim tidak membangun tiga mesin terpisah. Custom POS dan voice ordering menjadi kanal pengumpulan serta pembuktian data. API enterprise menggunakan mesin resolusi yang sama untuk pekerjaan berskala besar.

01 / Retail

Kenali produk di Custom POS

Foto, barcode, nama, atau SKU menghasilkan kandidat produk. Kasir mengonfirmasi sebelum produk masuk ke transaksi dan persediaan.

02 / Restaurant

Pahami pesanan melalui suara

Suara diubah menjadi pesanan terstruktur berdasarkan menu aktif restoran yang sudah dipilih pengguna.

03 / Enterprise

Jual kemampuan sebagai API

Perusahaan memakai Navv untuk mencocokkan katalog, menyebarkan data produk, lalu mengukur distribusi pada channel yang berpartisipasi.

Batas penting: “Global product database” adalah target cakupan yang tumbuh dari sumber berizin. Ia bukan klaim bahwa Navv sudah memiliki semua produk dunia.

Core products

Dua pengalaman pengguna dibangun bersama.

Keduanya realistis bila memakai akun, katalog tenant, penyimpanan bukti, dan proses koreksi yang sama. Yang berbeda hanya input dan hasil operasionalnya.

Custom POS retail

Foto barang, konfirmasi, lalu jual

Ambil inputFoto atau barcode

CariKandidat produk

PeriksaVarian dan ukuran

KonfirmasiKasir memilih

SimpanProduk tenant

Pekerjaan yang diselesaikan: mendaftarkan produk yang belum tersedia tanpa mengetik ulang semua atribut.

Barcode tetap menjadi pilihan utama ketika tersedia. Foto membantu produk tanpa barcode terbaca atau data yang belum ada.

Food intelligence

Pilih restoran, lalu bicara

PilihRestoran/tenant

BicaraPesanan pengguna

PahamiItem dan modifier

CocokkanMenu aktif

KonfirmasiSebelum order

Pekerjaan yang diselesaikan: mengubah bahasa percakapan menjadi menu ID, jumlah, dan pilihan seperti “tanpa pedas” atau “es sedikit”.

Navv tidak menebak harga atau ketersediaan. Data tersebut tetap berasal dari restoran atau POS.

Jalur in-car: setelah voice ordering stabil di restoran, aplikasi kendaraan memakai API yang sama. Pengguna memilih restoran dahulu, menyebut pesanan, mendengar ringkasan, lalu memberi konfirmasi eksplisit. Apple menyediakan kategori quick food ordering dan template CarPlay; implementasi tetap membutuhkan entitlement dan desain interaksi yang singkat.

Market & users

Pasarnya besar, cara masuknya harus sempit.

Angka pasar memberi konteks, bukan bukti penjualan. Navv memakai toko dan restoran yang sudah dapat dijangkau sebagai tempat belajar, kemudian menjual API melalui perusahaan yang dapat membawa banyak channel.

Sinyal dari riset v6	Angka indikatif	Makna untuk Navv
SAM layanan data	Rp42-307 miliar ARR; skenario dasar Rp140 miliar.	Ruang kontrak software/data, bukan nilai transaksi retail dan bukan ramalan pendapatan Navv.
Target tiga tahun	Rp1,1-4,5 miliar ARR; dasar Rp2,4 miliar.	Target kapasitas dari asumsi jumlah pelanggan dan harga yang belum divalidasi.
Produsen pangan	8.593 produsen menengah/besar dan 2,07 juta IKM pangan.	Produsen lebih besar lebih mungkin memiliki banyak SKU, channel, dan anggaran.
Outlet retail	Hampir 4 juta toko tradisional dan sekitar 49.987 gerai modern.	Distribusi luas, tetapi penjualan satu per satu ke warung akan mahal.
Adopsi digital	9,24% memakai POS digital dalam survei BI yang dirujuk v6.	Penyedia POS adalah jalur distribusi potensial; angka ini bukan kondisi pasti semua toko saat ini.

Pengguna awal

Tempat belajar

Toko retail dengan produk kemasan dan pemilik yang terlibat.
Restoran dengan menu aktif yang terstruktur dan pesanan berulang.
Data boleh dipakai untuk pilot sesuai perjanjian.
Lokasi mudah mendapat pendampingan tim kecil.

Pembeli B2B

Jalur tumbuh

Penyedia POS yang ingin menambah intelligence tanpa membangun engine sendiri.
FMCG yang perlu membandingkan product master dengan katalog retail.
Jaringan toko/restoran yang memiliki banyak cabang dan nama berbeda.
Distributor regional dengan konflik supplier SKU dan unit kemasan.

Keputusan distribusi: toko dan restoran langsung dipakai untuk pilot. Pertumbuhan bisnis diarahkan melalui POS provider, FMCG, distributor, dan jaringan multi-outlet.

Product boundary

Buat yang menguji intelligence layer.

Custom POS bukan tujuan akhir. Ia adalah produk yang dipakai pelanggan sekaligus laboratorium nyata untuk membuktikan image recognition, voice resolution, dan kualitas katalog.

Buat sekarang

Alur minimum yang utuh

Akun dan pemisahan data tenant.
Katalog produk dan menu.
Foto/barcode ke kandidat produk.
Suara/teks ke menu, jumlah, dan modifier.
Konfirmasi, input manual, riwayat, koreksi, dan rollback.
Transaksi serta persediaan dasar yang diperlukan untuk menguji alur.
Backup yang benar-benar dapat dipulihkan.

Tunda dahulu

Fitur yang tidak membuktikan inti

Akuntansi dan payroll lengkap.
Promosi, loyalty, dan pembayaran yang rumit.
Multi-gudang serta fitur POS umum.
Katalog nasional sebagai proyek tersendiri.
Auto-order, EDI, dan perubahan master tanpa persetujuan.
Integrasi khusus yang belum dibiayai pelanggan.

Fallback wajib: bila hasil tidak yakin, tampilkan kandidat, minta barcode, atau izinkan input manual. Penjualan dan pemesanan tidak boleh berhenti hanya karena Navv belum tahu.

Shared engine

Yang menjadi produk utama adalah mesin resolusinya.

Speech-to-text, OCR, dan image model dapat dibeli dari penyedia lain. Nilai Navv berada pada pemetaan hasilnya ke produk atau menu yang benar, lengkap dengan bukti dan tingkat keyakinan.

Masukan

Foto produk
Barcode dan SKU
Nama lokal
Suara dan teks
Katalog supplier

Navv Intelligence Core

Normalisasi dan pencarian kandidat
Identitas produk dan menu
Varian, ukuran, unit, modifier
Confidence, sumber, versi
Review dan koreksi

Pemakai

Custom POS
Restaurant POS
In-car ordering
FMCG dan retailer
POS/ERP partner

Entitas 1

Produk kemasan

GTIN, merek, varian, ukuran, unit dagang, foto, dan alias merchant.

Entitas 2

Menu restoran

Menu tenant, varian, modifier, nama percakapan, periode aktif, dan ketersediaan.

Aturan

Jangan dicampur

Mesinnya sama, tetapi produk kemasan dan menu restoran tetap memiliki model data terpisah.

Data strategy

Golden record menyatukan identitas; sumber tetap jelas.

Untuk CPG, GTIN mengaitkan product record lintas channel. Navv menambahkan nama lokal, unit, bukti, confidence, dan riwayat koreksi. GTIN atau data GS1 tetap harus digunakan sesuai izin sumbernya.

Lapisan	Isi	Pemilik kebenaran
GS1	GTIN, pemilik identifier, atribut dasar dan standar pertukaran data.	Brand owner dan GS1.
Manufacturer	Spesifikasi, kemasan, sertifikasi, status produk dan materi resmi.	Manufacturer/PIM.
POS/retailer	Merchant SKU, nama lokal, harga, listing, transaksi dan persediaan.	Retailer atau tenant.
Navv	Pemetaan antar-ID, alias, konflik unit, confidence, sumber dan riwayat koreksi.	Navv untuk hasil resolusi; sumber asli tetap dicatat.
Taxonomy	Kategori BPOM untuk konteks Indonesia, dengan mapping terpisah ke GS1 GPC dan taxonomy feed yang dibutuhkan.	Pemilik taxonomy; Navv menyimpan mapping serta versinya.

Contoh: “Teh Botol 350 ml”, “tehbotol 350”, dan “TBS-350 PCS” dapat menunjuk produk yang sama. “TBS 24 × 350 ml” adalah unit karton yang terkait, tetapi bukan unit transaksi yang sama.

Data playbook

Dua jalur data, tiga lapisan yang saling terhubung.

Data CPG membangun identitas produk lintas toko. Data food menggabungkan katalog aktual milik tiap restoran dengan ontology hidangan dan bahasa Indonesia. Keduanya memakai sumber, versi, confidence, dan feedback yang bisa ditelusuri.

Halaman terkait: dua dokumen riset CPG/menu · rancangan context graph untuk Navv →

Retail / CPG

Golden record produk

Mulai dari makanan kemasan dengan identifier stabil. Kombinasi utama adalah brand + GTIN; SKU toko tetap menjadi alias lokal, bukan identitas universal.

Nama resmi dan sebutan konsumen, manufacturer, barcode/checksum, serta varian.
Kategori BPOM dan mapping terpisah ke GS1 GPC; Google/OFF hanya saat dibutuhkan untuk distribusi atau seed.
Nomor BPOM dan sertifikat halal dengan sumber serta tanggal pemeriksaan.
Netto, jenis dan ukuran kemasan, isi karton, packshot, label belakang, dan OCR.
Provenance per atribut, confidence, payload sumber, versi, dan riwayat merge.

Food / Voice

Katalog merchant + ontology

Katalog merchant menjawab menu yang benar-benar dijual di outlet dan saat ini. Ontology membantu mengenali nama hidangan, alias, dialek, dan modifier lintas merchant.

Menu item terkait merchant/outlet, harga, status aktif, jam/channel, dan waktu pembaruan.
Varian dan modifier terstruktur dengan pilihan wajib/opsional, batas pilih, tambahan harga, dan alias.
Ontology menyimpan canonical dish, keluarga/daerah, parent/variant, bahan umum, alias, dan variasi pelafalan/ASR.
Audio pesanan aktual dikumpulkan dengan izin; koreksi kasir menjadi labeled feedback.
Harga, stok, availability, dan order tetap berasal dari sistem merchant.

Fokus CPG	Kategori pangan	Urutan kerja
P1	15.0 snack; 06.0 serealia/mi; 14.0 minuman non-susu.	Mulai di kategori yang dekat dengan transaksi retail dan pesanan restoran.
P2	07.0 bakeri; 05.0 cokelat/permen; 01.0 susu.	Tambah setelah coverage atribut, sumber, dan proses review P1 terbukti.

1 / Resolve

Jangan auto-merge dari kemiripan saja

Urutan kandidat: GTIN valid → brand + nama ternormalisasi → kemiripan gambar/label → antrean review manusia untuk konflik atau confidence rendah.

2 / Seed

Pakai sumber sesuai kewenangannya

Prioritaskan principal untuk spesifikasi, BPOM/BPJPH untuk status resmi, GS1 untuk identifier melalui jalur yang diizinkan, lalu open dataset sebagai kandidat yang perlu diverifikasi.

3 / Connect

Hubungkan produk dan menu secara terkontrol

Menu “Teh Botol” dapat menunjuk CPG product record yang tepat. Menu merchant tetap memiliki harga, modifier, ketersediaan, dan nama tampilnya sendiri.

Aturan sumber: menu resmi chain dapat dipakai untuk mempelajari kategori dan pola modifier dengan mematuhi syarat situs; jangan menyalin deskripsi brand untuk dijual ulang. Menu aktual untuk API komersial harus berasal dari merchant/partner yang memberi izin. Katalog promo retail hanya referensi tambahan, bukan sumber utama harga atau stok.

Target dokumen riset	Angka rencana	Cara membaca
CPG makanan kemasan, 12 minggu	700–900 golden records; >90% atribut wajib; minimal 2 sumber cross-validation per SKU.	Target kerja yang bergantung akses sumber dan kapasitas review, bukan data Navv yang sudah terkumpul.
Menu publik chain, fase seed	1.500–2.500 item; 150–250 canonical dishes; sekitar 40 modifier groups.	Target parsing/ontology. Bukan pengganti onboarding katalog merchant.
Food voice, validasi merchant	Mulai 1 design partner, lanjut 3–5 merchant sejenis; visi perluasan hingga 20 outlet.	Utamakan menu aktif, modifier, harga yang mutakhir, dan audio terkoreksi sebelum mengejar jumlah outlet.

Penyesuaian untuk tim kecil: rencana CPG 10 principal/6 kategori dan seed chain nasional adalah arah ekspansi. Mulai dari data retail dan restoran yang sudah dapat diakses, satu kategori CPG P1, satu merchant restoran, lalu tambah sumber hanya ketika proses verifikasi mampu mengikutinya.

Architecture

Satu backend untuk semua channel.

Aplikasi boleh berbeda, tetapi identitas, review, bukti, dan aturan data hidup pada layanan yang sama. Pilihan teknologi dapat berubah; batas data dan kontrak API tidak boleh ikut berubah tanpa alasan.

Aplikasi

Retail Custom POS
Restaurant POS
In-car client
Resolve Console
POS/ERP partner

Service layer

API, login, tenant access
Product/menu resolver
Database dan object storage
Background jobs dan model routing
Audit, rate limit, backup

Sumber berizin

GS1/GDSN
Brand dan supplier
POS dan tenant
Maps untuk lokasi
BPOM/BPJPH untuk status resmi

Keputusan awal

Infrastructure-first

Gunakan model dasar yang dapat diganti untuk gambar, OCR, speech-to-text, dan kemiripan. Gabungkan hasilnya dengan pencarian katalog, aturan atribut, confidence, dan review manusia.

Fine-tuning

Menunggu pola kegagalan

Fine-tune hanya jika kesalahan berulang sudah jelas, tersedia ribuan contoh berizin dan set uji terpisah, serta hasilnya lebih baik atau lebih murah dari perbaikan data/aturan.

Mirrorless camera: gunakan untuk kasus katalog yang sulit atau layanan fotografi tambahan. Ponsel tetap cukup untuk alur harian bila barcode dan tulisan kemasan terbaca.

Location context

Lokasi membantu memilih tenant, bukan membuktikan stok.

Konteks lokasi penting untuk merchant onboarding, cabang yang benar, restaurant-first ordering, wilayah penjualan, dan channel measurement. Data produk dan stok tetap berasal dari pihak yang berwenang.

Merchant

Identitas cabang

Hubungkan ID cabang Navv dengan Place ID agar toko atau restoran bernama mirip tidak tercampur. Owner tetap mengonfirmasi.

In-car

Pilih restoran

Lokasi mempersempit tenant yang dapat dipilih. Menu aktif, harga, pickup, dan ketersediaan berasal dari restoran.

Enterprise

Wilayah pengamatan

Setiap listing dan pengamatan membawa cabang serta tanggal. Nearby Search bukan data penjualan, pengunjung, atau pangsa pasar.

Enterprise API

Tiga tahap yang mudah dipahami perusahaan.

Setiap tahap baru dimulai setelah tahap sebelumnya menghasilkan penggunaan berulang dan hak data yang jelas.

Catalog reconciliation

Mencocokkan katalog perusahaan dengan data POS/retailer dan menunjukkan produk hilang, duplikat, salah unit, atau sudah tidak aktif.

Mulai jikaSatu FMCG memberi product master dan satu channel POS memberi data berizin.

Product content syndication

FMCG memasukkan data produk sekali. Navv menyesuaikan dan mengirim draft data ke berbagai POS atau retailer sesuai format masing-masing.

Lanjut jikaPelanggan meminta pengiriman pembaruan berulang, bukan sekadar pembersihan satu kali.

Retail measurement

Mengolah data channel yang berpartisipasi untuk menunjukkan distribusi listing, harga, dan performa produk secara agregat.

Lanjut jikaCoverage, metodologi, kontrak penggunaan data, dan kualitas sampel cukup untuk membuat klaim yang dapat dipertanggungjawabkan.

API minimum

Empat kemampuan inti

/resolve/product - mencari identitas produk.
/resolve/menu - memetakan suara/teks ke menu tenant.
/catalogs/compare - mencari perbedaan dua katalog.
/feedback - menerima keputusan dan koreksi pengguna.

Enterprise contract

Yang sebenarnya dibeli

Waktu katalog siap pakai yang lebih singkat.
Lebih sedikit duplikasi dan konflik unit.
Keputusan yang bisa ditelusuri dan dibatalkan.
Integrasi berulang dengan dukungan dan SLA.

Manufacturer to retail

Syndication mengalirkan data; transaksi tetap milik channel.

Navv menghubungkan product release dari FMCG ke retailer yang relevan tanpa mengambil alih harga, stok, kredit, atau fulfillment.

1. Publish

Manufacturer mengirim GTIN, nama, merek, varian, kemasan, aset, dan area distribusi.

Manufacturer/PIM memegang data resmi dan syarat komersial.

2. Validate

Navv memeriksa identitas, kelengkapan, hubungan unit, konflik, sumber, dan versi.

Kasus ragu masuk review; tidak dipaksakan menjadi jawaban.

3. Route

Navv menyesuaikan atribut ke format POS atau retailer dan mengirimnya sebagai draft.

Retailer memilih menerima, melewati, atau meminta penawaran.

4. Fulfil

Sales atau distributor menangani harga, MOQ, kredit, ketersediaan, order, dan pengiriman.

Sistem dagang para pihak tetap menjadi sumber transaksi.

5. Learn

Penerimaan, penolakan, konflik, dan koreksi kembali menjadi feedback yang dapat diaudit.

Navv memperbaiki aturan tanpa mencampur data antar-tenant.

Batas awal: belum ada auto-order, EDI penuh, payment, atau perubahan diam-diam ke product master. Mulai dari draft, persetujuan manusia, dan jejak pembatalan.

Enterprise use cases

Sembilan pekerjaan yang dapat dihitung dampaknya.

Wedge pertama tetap catalog reconciliation. Kasus lain menambah nilai setelah identitas produk dan unit kemasan stabil.

Banyak supplier

Samakan nama dan kode berbeda untuk barang yang sama, sambil menyimpan alias lama.

Banyak cabang

Hubungkan kode pembelian, gudang, cabang, dan POS ke satu identitas acuan.

Marketplace

Temukan listing ganda, barcode tidak cocok, dan merek tidak konsisten sebelum terbit.

Produk berubah

Simpan versi, sumber, tanggal, dan persetujuan untuk perubahan atribut penting.

Botol, pak, karton

Hubungkan unit dan konversi tanpa mencampur barang jual yang berbeda.

Migrasi ERP

Kelompokkan produk dengan bukti dan pertahankan kode lama sebagai alias.

Izin dan sertifikat

Hubungkan katalog ke nomor serta status BPOM/BPJPH beserta sumber dan tanggal.

Penarikan produk

Petakan pemberitahuan ke SKU, unit, cabang, dan transaksi; bukan sistem recall lengkap.

Invoice vs pesanan

Cocokkan nama, kode, unit, dan varian; keputusan membayar tetap di perusahaan.

Nilai yang dijual: jam review berkurang, duplikasi turun, katalog lebih cepat siap, kesalahan unit tertangkap, dan setiap perubahan dapat ditelusuri serta dibatalkan.

Enterprise adoption

Masuk tanpa langsung menulis ke sistem utama.

Kualitas, keamanan, dan proses pembatalan dibuktikan bertahap sebelum ruang lingkup diperbesar.

1. Sponsor & scope

Pemberi anggaran, pemilik data, IT, satu kategori, satu sumber, tujuan, dan akses disepakati.

2–4 minggu

2. Paid pilot

Data berizin dan sampel terpisah; presisi, coverage, jam kerja, serta biaya diukur.

4–8 minggu

3. Shadow mode

Navv hanya memberi saran dan dibandingkan dengan petugas; unit serta kemasan diperiksa.

2–4 minggu

4. Limited production

Satu bagian perusahaan; akses, audit, recovery, insiden, dan rollback diuji.

4–8 minggu

5. Staged expansion

Sumber atau unit bisnis baru ditambah hanya ketika kontrak, layanan, tanggung jawab, dan biaya jelas.

Setelah stabil 8 minggu

Yang perlu disiapkan

Perjanjian data, daftar vendor/subprocessor, retensi dan penghapusan, tenant isolation, security review, incident plan, serta kontak darurat.

Yang belum dijanjikan

SLA 24/7, migrasi otomatis penuh, dan rekomendasi pembelian sebelum kualitas, hak data, stok, serta waktu pembaruan terbukti.

Roadmap

Bangun dua channel sekarang, perluas enterprise dengan bukti.

Roadmap ini mengikuti kapasitas tim kecil. Custom POS retail dan restaurant voice dibuat bersama karena keduanya memakai foundation yang sama; fitur enterprise bertambah satu tahap pada satu waktu.

0-3 bulan

Foundation tenant, katalog, product/menu entity, bukti sumber, review, Custom POS retail, dan voice ordering restoran.

Dua channel dapat menyelesaikan alur nyata tanpa kehilangan data dan koreksi dapat dilacak.

3-6 bulan

Pilot pada channel yang sudah dimiliki; ukur foto-ke-produk dan suara-ke-menu sampai hasil benar.

Pemakaian berulang, hasil lebih cepat dari cara lama, serta biaya review dapat diterima.

6-12 bulan

Catalog reconciliation API untuk satu FMCG dan satu kategori produk.

Ada product master, data POS berizin, sponsor enterprise, dan pilot berbayar.

12-18 bulan

Product content syndication ke POS/retailer yang sudah menjadi partner.

Minimal dua pelanggan meminta pembaruan data berulang dan format integrasi mulai berulang.

18-36 bulan

Retail measurement pada jaringan yang berpartisipasi; uji pengalaman in-car melalui partner aplikasi.

Coverage layak, metodologi transparan, hak data jelas, dan insight benar-benar dibayar.

Urutan kerja enterprise: sponsor dan izin → pilot berbayar → berjalan berdampingan tanpa menulis master → produksi terbatas → perluasan bertahap.

Team & operations

Tim kecil, satu pemilik hasil untuk setiap pekerjaan.

Asumsi kapasitas v6: satu owner, dua pengembang, satu analis data, dan satu pendamping lapangan. Jika pengembang hanya satu, jadwal dua produk harus diperlambat.

Peran	Tanggung jawab utama	Ukuran kerja
Owner	Pilot, harga, perjanjian, prioritas, kas, dan penjualan.	Toko aktif, calon mitra, kontrak, dan runway.
Developer retail/backend	Transaksi, inventory, tenant isolation, security, backup, dan API dasar.	Gangguan, kehilangan data, kecepatan, dan stabilitas.
Developer voice/intelligence	Foto produk, voice-to-menu, confidence, confirmation, dan integration API.	Waktu input ke hasil benar serta jumlah koreksi.
Data analyst	Correct set, sumber, error review, measurement, dan antrean kasus ragu.	Presisi, coverage, dan waktu review.
Field/customer support	Pelatihan, observasi penggunaan, respons masalah, dan feedback.	Waktu respons, masalah selesai, dan penggunaan harian.

Ritme mingguan

Senin menetapkan satu prioritas bisnis dan satu prioritas kualitas. Harian memeriksa hambatan dan antrean. Jumat meninjau error, penggunaan, biaya, serta penjualan.

Batas kapasitas review

1.200 kasus × 3 menit = 60 jam per bulan. Jika antrean melewati 2 hari kerja selama 2 minggu, perbaiki data/aturan, batasi scope, atau jual kapasitas tambahan.

Commercial model

Pilot → bukti → kontrak berulang.

Harga dan angka keuangan berikut dipindahkan dari v6 sebagai asumsi kerja, bukan harga pasar atau proyeksi yang sudah tervalidasi. Model dua produk harus dihitung ulang setelah usage nyata tersedia.

1 / Uji

Gunakan channel sendiri

Dua lokasi, alur retail dan restoran, transaksi nyata, izin data, serta masukan operator.

2 / Buktikan

Hitung sebelum–sesudah

Waktu lebih cepat, error dan koreksi tercatat, biaya review terlihat, serta video demo nyata.

3 / Jual

Masuk melalui hasil

Tawarkan pilot sempit ke FMCG, distributor, penyedia POS, atau jaringan restoran.

Paket	Harga uji v6	Lingkup awal
Custom POS pilot	Gratis atau diskon terbatas	Dua lokasi, 90 hari, transaksi sederhana, pendampingan, dan aturan data tertulis.
API pilot / 4 minggu	Rp8–15 juta sekali	Satu mitra, satu kategori, batas record, dua perbaikan, dan laporan hasil.
API basic	Rp3 juta/bulan	Kuota kecil untuk nama, barcode, foto atau menu; laporan dan dukungan jam kerja.
API growth	Rp8 juta/bulan	Kuota lebih besar, unggah katalog, release event, dan laporan; integrasi khusus terpisah.
Enterprise	Mulai Rp25 juta/bulan	Berdasarkan usage, keamanan, sistem terhubung, support, dan hasil paid pilot.
Restaurant voice	Belum ditetapkan	Validasi biaya per order, correction rate, dan nilai ke restoran sebelum memilih subscription atau usage.

Biaya tetap v6

Rp75 juta per bulan

Owner 10; dua developer 30; analyst 10; support 6; benefit/cadangan tenaga 8; cloud dasar/tools 4; sales/admin/operasional 7. Biaya model dan usage dihitung terpisah.

Kebutuhan kas v6

±Rp904,8 juta dengan cadangan

Pendapatan asumsi Rp236 juta; fixed cost Rp900 juta; usage Rp54 juta; pilot Rp6 juta; initial cost Rp30 juta. Kebutuhan bersih ±Rp754 juta; plus cadangan 20%. Tanpa pendapatan: ±Rp1,116 miliar.

Contoh break-even v6: rata-rata Rp6 juta/pelanggan dengan contribution margin 75% menghasilkan Rp4,5 juta untuk fixed cost; dibutuhkan sekitar 17 pelanggan. Jika contribution margin 60%, sekitar 21 pelanggan.

Success metrics

Ukur hasil benar, bukan sekadar model menjawab.

Angka berikut adalah target uji. Ia bukan kemampuan Navv yang sudah terbukti.

≥99%Presisi untuk hasil yang diterima otomatis pada katalog enterprise.

≥50%Pengurangan waktu sampai produk/menu benar, termasuk koreksi.

0Kesalahan kritis unit, varian, harga, atau order yang dibiarkan tanpa penanganan.

Ukuran retail POS

Waktu produk baru, persentase saran benar, frekuensi fallback manual, penggunaan mingguan, dan kesalahan persediaan.

Ukuran restaurant voice

Waktu sampai cart benar, koreksi item/modifier, kegagalan karena kebisingan, repeat order, dan order yang dibatalkan.

Ukuran enterprise

Record berhasil dicocokkan, review manual, konflik nyata yang ditemukan, waktu katalog siap, API reuse, dan pembelian ulang.

Ukuran bisnis

Pelanggan berbayar, margin setelah biaya model/reviewer/support, waktu integrasi, renewal, dan ketergantungan pada founder.

Evidence

Masalah pasar terbukti; pembelian Navv belum.

Bukti publik mendukung kebutuhan identitas, sinkronisasi, dan measurement. Ia belum membuktikan perusahaan Indonesia akan memilih atau membayar Navv.

Bukti	Makna untuk Navv	Batas interpretasi
METRO menemukan hanya 91% dari 632 SKU P&G pada data pembanding Verified by GS1.	Rekonsiliasi daftar brand-retailer dan lifecycle lag adalah pekerjaan nyata.	Kasus GS1 di luar Indonesia, bukan hasil Navv.
Carrefour masih menggabungkan GDSN dan input Excel untuk bagian katalognya.	Standar tidak otomatis menghapus data lama dan proses manual.	Studi kasus promosi ekosistem GS1.
Syndigo dan Akeneo menawarkan PIM, mapping, API, dan syndication.	Kategori enterprise sudah memiliki anggaran dan produk matang.	Navv tidak boleh menjadi PIM generik yang lebih kecil.
NIQ menawarkan pengukuran FMCG berbasis ePOS di Indonesia.	Data POS memiliki nilai komersial bagi FMCG.	Navv belum memiliki coverage atau metodologi setara NIQ.
Apple mendukung quick food ordering dan voice-based apps di CarPlay.	Jalur in-car secara platform memungkinkan untuk diuji.	Tetap memerlukan entitlement, partner restoran, dan pengalaman yang aman.

Risks & boundaries

Batas yang menjaga Navv tetap dipercaya.

Kesalahan identitas, hak data yang kabur, atau klaim coverage berlebihan lebih berbahaya daripada model yang memilih untuk tidak menjawab.

Kritis

Salah merge

Ukuran, rasa, pcs, pack, dan case tidak boleh digabung hanya karena nama atau gambar mirip.

Kritis

Hak data

Data tenant tidak otomatis boleh dipakai lintas pelanggan. Tujuan, retensi, agregasi, dan penghapusan harus tertulis.

Tinggi

Coverage kecil

Gunakan istilah “channel yang berpartisipasi”; jangan mengklaim gambaran pasar Indonesia sebelum metodologinya layak.

Tinggi

POS melebar

Tunda akuntansi, payroll, promosi kompleks, payment gateway, dan fitur POS umum yang tidak menguatkan intelligence layer.

Tinggi

Reviewer mahal

Jika semua kasus dipindahkan menjadi kerja manual Navv, API tidak akan memiliki margin yang sehat.

Tinggi

In-car distraction

Batasi langkah, bacakan ringkasan, dan minta konfirmasi eksplisit sebelum mengirim order atau pembayaran.

Next 90 days

Bukti yang harus dibeli oleh pekerjaan berikutnya.

Tujuan 90 hari bukan menyelesaikan seluruh visi. Tujuannya memastikan dua produk awal digunakan, foundation-nya sama, dan satu percakapan enterprise berubah menjadi pilot dengan data nyata.

Hari 1-30

Satukan fondasi

Tenant, catalog import, product/menu entity, bukti sumber, confidence, review, koreksi, audit, dan pemisahan data.

Hari 31-60

Jalankan dua alur

Custom POS mengenali produk retail; restaurant POS mengubah suara menjadi cart yang dikonfirmasi.

Hari 61-90

Siapkan pilot FMCG

Pilih minuman kemasan, minta product master, bandingkan dengan data POS berizin, dan tawarkan hasil reconciliation berbayar.

1–2

Pilih lokasi retail dan restoran, tetapkan izin data, baseline waktu/error, kategori, serta fitur yang tidak dibuat.

Owner pilot, dataset, anggaran, tanggal mulai, dan stop rule tertulis.

3–4

Bangun login, tenant, katalog produk/menu, transaksi dan stok dasar, audit, serta correct set.

Data kedua channel terpisah; transaksi manual berjalan aman.

5–6

Tambahkan foto-ke-produk untuk retail dan suara-ke-cart untuk restoran dengan confidence, pilihan, serta fallback.

Kasus ambigu tidak memaksa jawaban; koreksi tersimpan.

7–8

Jalankan pilot pertama dan amati operator di situasi nyata.

Waktu, error, koreksi, biaya inference, dan antrean review tercatat.

9–10

Jalankan channel kedua; perbaiki hanya hambatan yang berulang.

Pemakaian kembali terjadi tanpa pendampingan founder penuh.

11–12

Bekukan demo, laporan sebelum–sesudah, dan contoh catalog reconciliation FMCG.

Keputusan lanjut, persempit, atau hentikan dibuat dari data pilot.

Gerbang investasi: lanjutkan syndication hanya setelah reconciliation digunakan berulang. Lanjutkan retail measurement hanya setelah coverage dan hak data cukup. Lanjutkan in-car hanya setelah voice ordering pada restoran stabil.

Sources

Sumber dan batas bukti.

Diperiksa 11 September 2026. Halaman vendor membuktikan ketersediaan fitur, bukan efektivitas independen atau kemauan pelanggan membayar Navv.

GS1 - Verified by GS1: identitas produk dan akses enterprise melalui kantor GS1 lokal.
GS1 Global Data Model: atribut produk untuk listing, ordering, storage, movement, dan selling.
GS1 GDSN: sinkronisasi product content melalui data pool.
GS1 EPCIS: standar visibility event untuk menjawab apa, kapan, di mana, dan konteks bisnis.
METRO & P&G case study: perbandingan SKU dan lifecycle lag.
Carrefour GDSN case study: GDSN, supplier adoption, dan proses Excel yang tersisa.
Syndigo PIM: mapping, API/EDI, dan product content syndication.
Akeneo API: product, variant, category, PIM, dan integration APIs.
NIQ FMCG measurement Southeast Asia: ePOS measurement untuk Indonesia.
Apple CarPlay quick ordering: dukungan dan entitlement untuk aplikasi pemesanan makanan.
Android for Cars voice actions: input suara melalui mikrofon kendaraan.
Google Places API: identitas tempat, status bisnis, dan jam operasional.
BPOM Cek Produk: pemeriksaan nomor dan status produk yang terdaftar.
BPJPH: sumber resmi layanan dan informasi sertifikasi halal.
UU No. 27 Tahun 2022: kerangka Pelindungan Data Pribadi Indonesia.