Dashboard Tidak Cukup: Owner Bisnis Perlu Monitoring yang Menemukan Akar Masalah

Masalah bisnis sering terlihat di angka setelah uangnya sudah bocor.

Retur naik, tetapi baru ketahuan saat margin bulan ini turun. Conversion rate turun, tetapi baru terlihat setelah biaya iklan habis. Average order value mengecil, stok produk cepat habis tanpa rencana, pengiriman terlambat, penjualan cabang melemah, atau SLA layanan pelanggan tidak tercapai.

Dashboard tetap penting. Namun untuk owner bisnis dan UMKM, dashboard saja sering belum cukup. Alasannya sederhana: dashboard biasanya menunggu kita membuka, membaca, membandingkan, lalu menyimpulkan sendiri.

Pertanyaannya bukan hanya apakah angka hari ini naik atau turun. Pertanyaan yang lebih penting adalah: kapan sistem bisa memberi tahu saya bahwa ada yang tidak normal, lalu membantu menunjukkan kemungkinan penyebabnya?

Dashboard Menjawab Apa yang Terjadi, Bukan Selalu Mengapa

Dashboard yang baik bisa memperlihatkan metrik seperti:

• Total penjualan harian
• Jumlah order
• Conversion rate toko online
• Average order value
• Retur dan refund
• Stok tersedia
• Keterlambatan pengiriman
• Performa cabang
• SLA customer service

Masalahnya, owner sering tidak punya waktu membuka semua dashboard setiap hari. Bahkan kalau dibuka, penurunan kecil bisa terlihat normal sampai dampaknya membesar.

Contoh sederhana:

• Conversion rate turun dari 2,8 persen ke 2,1 persen selama 5 hari
• Produk best seller stoknya tinggal sedikit, tetapi belum masuk daftar restock
• Keterlambatan pengiriman naik di satu area tertentu
• Retur meningkat hanya untuk satu varian produk
• Cabang A turun penjualan, tetapi cabang B stabil

Jika semua ini hanya tampil sebagai angka, owner tetap harus mencari sendiri: ini masalah iklan, stok, harga, halaman produk, kurir, kualitas barang, atau tim operasional?

Di sinilah monitoring yang lebih aktif menjadi penting.

Pengumuman Google Cloud: Looker Agentic Workflows dalam Preview

Pada 30 Juli 2026, Google Cloud mengumumkan Looker Agentic Workflows dalam status preview. Berdasarkan pengumuman tersebut, pendekatannya adalah mengubah pertanyaan ad hoc menjadi monitoring berkelanjutan.

Artinya, pertanyaan seperti:

• Kenapa penjualan produk ini turun?
• Apakah keterlambatan pengiriman mulai berdampak ke retur?
• Cabang mana yang performanya menyimpang dari pola normal?
• Apakah average order value turun karena diskon, stok, atau perubahan perilaku pembeli?

Dapat diarahkan menjadi workflow yang terus memeriksa metrik, membantu analisis akar masalah, dan dibuat dari instruksi bahasa natural.

Namun ini perlu dibaca dengan hati-hati. Ini adalah pengumuman dan fitur preview dari Google Cloud, bukan jaminan bahwa fitur tersebut sudah tersedia untuk semua akun, cocok untuk semua model bisnis, atau langsung bisa menggantikan proses analisis manusia.

Bagi saya, poin paling menarik bukan sekadar produknya. Poin pentingnya adalah arah berpikirnya: bisnis tidak cukup hanya menyimpan data dan menampilkannya di dashboard. Bisnis perlu sistem yang aktif memantau, memberi konteks, dan membantu menemukan penyebab masalah lebih cepat.

Versi Sederhana untuk UMKM: Tidak Harus Mulai dari Tools Mahal

Owner UMKM tidak harus langsung membeli platform enterprise untuk menerapkan prinsip ini. Versi sederhananya bisa dibangun dari komponen yang sudah umum:

• Spreadsheet atau database sederhana untuk menyimpan data
• API toko online, marketplace, POS, atau sistem order
• Data iklan dari platform ads
• Data pengiriman dari ekspedisi atau aggregator
• Notifikasi WhatsApp, email, atau Slack
• Jadwal pengecekan otomatis, misalnya setiap jam atau setiap pagi

Contoh monitoring praktis:

1. Jika conversion rate turun lebih dari 20 persen dibanding rata-rata 7 hari terakhir, kirim notifikasi.
2. Jika stok produk best seller kurang dari batas aman, beri peringatan ke tim pembelian.
3. Jika retur naik pada SKU tertentu, tampilkan daftar order, varian, kurir, dan tanggal pengiriman.
4. Jika average order value turun, cek apakah terjadi perubahan diskon, bundle, atau mix produk.
5. Jika SLA chat pelanggan melewati batas, kirim ringkasan jam sibuk dan tim yang bertugas.
6. Jika penjualan cabang turun tidak normal, bandingkan dengan stok, promo, hari operasional, dan trafik.

Dengan cara ini, owner tidak hanya menerima laporan bulanan. Owner mendapat sinyal lebih cepat saat ada kebocoran kecil sebelum menjadi kerugian besar.

Bedanya Alert Biasa dan Monitoring yang Membantu Akar Masalah

Alert biasa hanya berbunyi saat angka melewati batas. Misalnya: penjualan hari ini turun 30 persen.

Monitoring yang lebih berguna seharusnya membantu menjawab lanjutan:

• Turunnya terjadi di semua produk atau produk tertentu?
• Terjadi di semua channel atau hanya marketplace tertentu?
• Apakah stok kosong ikut memengaruhi?
• Apakah ada perubahan harga atau promo?
• Apakah trafik turun atau conversion rate yang turun?
• Apakah pengiriman terlambat di area tertentu?
• Apakah retur naik setelah batch produk tertentu dikirim?

Untuk owner bisnis, jawaban seperti ini lebih bernilai daripada sekadar grafik merah. Grafik merah memberi tahu bahwa ada masalah. Analisis akar masalah membantu menentukan tindakan.

Contoh Skenario: Retur Naik tetapi Penyebabnya Tidak Jelas

Misalnya retur naik 15 persen dalam seminggu. Dashboard menunjukkan angka retur naik, tetapi belum menjelaskan kenapa.

Monitoring yang lebih baik bisa memecahnya:

• Retur paling banyak berasal dari produk X
• Produk X varian ukuran M mengalami kenaikan retur paling besar
• Kenaikan terjadi setelah tanggal tertentu
• Mayoritas alasan retur adalah ukuran tidak sesuai
• Produk tersebut memiliki perubahan deskripsi atau foto ukuran pada halaman toko
• Kenaikan retur terkonsentrasi di channel tertentu

Dari sini, tindakan bisnis menjadi lebih jelas. Bukan sekadar menyuruh tim menurunkan retur, tetapi memperbaiki panduan ukuran, mengecek deskripsi produk, meninjau batch barang, atau mengubah komunikasi di halaman produk.

Yang Harus Dikontrol: Data, Definisi, dan Akses

Monitoring otomatis bisa membantu, tetapi juga bisa menyesatkan kalau fondasinya salah. Ada beberapa hal yang perlu dijaga.

1. Definisi metrik harus benar

Pastikan semua orang sepakat tentang arti metrik. Misalnya, revenue itu sebelum refund atau setelah refund? Order batal dihitung atau tidak? Retur dihitung saat diajukan atau saat barang diterima kembali?

Kalau definisinya tidak jelas, alert bisa berbunyi untuk hal yang salah.

2. Threshold harus jelas

Jangan semua perubahan dianggap masalah. Bisnis punya pola musiman, akhir pekan, payday, tanggal kembar, promo, dan hari libur.

Threshold bisa dibuat sederhana, misalnya:

• Turun lebih dari 20 persen dibanding rata-rata 7 hari
• Stok di bawah 3 hari proyeksi penjualan
• SLA lewat 2 jam untuk lebih dari 10 tiket
• Retur SKU tertentu naik 2 kali lipat dari rata-rata normal

3. Semantic layer dan akses data perlu diatur

Dalam konteks tools BI modern seperti Looker, semantic layer membantu menjaga definisi data agar konsisten. Untuk UMKM, prinsipnya sama: buat satu sumber kebenaran untuk definisi metrik.

Selain itu, akses data harus dibatasi. Tidak semua orang perlu melihat margin, data pelanggan, atau informasi sensitif. Monitoring yang baik harus tahu data mana yang boleh dibaca dan oleh siapa.

4. Audit trail wajib ada

Setiap alert dan tindakan perlu punya jejak:

• Kapan alert muncul
• Metrik apa yang memicu alert
• Data apa yang dicek
• Siapa yang menerima notifikasi
• Rekomendasi apa yang diberikan
• Tindakan apa yang diambil

Tanpa audit trail, sulit mengevaluasi apakah sistem membantu atau malah membuat noise.

5. Human review sebelum tindakan eksternal

Saya tidak menyarankan agent atau workflow otomatis langsung mengubah data, mengirim pesan ke pelanggan, mengganti harga, atau mematikan campaign tanpa review manusia.

Untuk tahap awal, gunakan otomatisasi sebagai asisten pemantau dan pemberi rekomendasi. Keputusan yang berdampak ke pelanggan, uang, harga, stok, atau komunikasi eksternal tetap sebaiknya melewati persetujuan manusia.

Mulai dari Monitoring Kecil yang Paling Dekat dengan Uang

Kalau baru mulai, jangan mencoba memonitor semua hal. Pilih 3 sampai 5 metrik yang paling dekat dengan kebocoran uang.

Untuk toko online, saya biasanya akan mulai dari:

• Conversion rate
• Average order value
• Stok produk best seller
• Retur per SKU
• Keterlambatan pengiriman

Untuk bisnis jasa:

• Jumlah lead masuk
• Conversion dari lead ke deal
• SLA respons
• Pembatalan jadwal
• Nilai transaksi rata-rata

Untuk bisnis multi-cabang:

• Penjualan per cabang
• Stok kritis per cabang
• Produk paling lambat bergerak
• Selisih performa antar cabang
• Komplain pelanggan per lokasi

Setelah itu, buat aturan sederhana: jika metrik menyimpang dari pola normal, sistem mengirim ringkasan dan dugaan penyebab yang perlu dicek.

Kesimpulan

Dashboard membantu owner melihat kondisi bisnis. Tetapi kalau owner baru tahu masalah setelah uangnya bocor, dashboard belum cukup.

Arah baru seperti yang diumumkan Google Cloud melalui Looker Agentic Workflows menunjukkan bahwa data analytics bergerak dari sekadar melihat laporan menuju monitoring berkelanjutan dan bantuan analisis akar masalah. Namun, karena fitur tersebut masih diumumkan dalam status preview, bisnis tetap perlu menilai ketersediaan, kecocokan, biaya, kontrol, dan kesiapan datanya sendiri.

Untuk UMKM, pelajaran praktisnya jelas: mulai bangun sistem yang tidak hanya menampilkan angka, tetapi juga memantau perubahan penting, memberi notifikasi cepat, dan membantu menjawab kenapa angka itu berubah.

Tidak harus kompleks. Spreadsheet, database sederhana, API toko online, dan notifikasi WhatsApp atau email sudah cukup untuk langkah awal. Yang penting, metriknya benar, batasnya jelas, akses datanya aman, dan keputusan penting tetap ditinjau manusia.

Referensi

• Looker adds agentic workflows for data monitoring and insights, Google Cloud, https://cloud.google.com/blog/products/business-intelligence/looker-adds-agentic-workflows-for-data-monitoring-and-insights, dipublikasikan 30 Juli 2026.