Kasus Grubhub Mengingatkan Platform Bahwa Skala Tidak Bisa Menggantikan Kepercayaan

The Core Update

Lebih dari setengah juta driver dan pelanggan Grubhub akan menerima bagian dari settlement senilai sekitar $23,8 juta setelah Federal Trade Commission menuduh perusahaan melakukan praktik yang menyesatkan.

FTC menyebut dana tersebut akan dibagikan kepada 640.038 konsumen. Sebagian besar penerima akan mendapat cek lewat pos, sementara sebagian lain menerima pembayaran melalui PayPal.

Kasus ini berasal dari gugatan FTC dan jaksa agung Illinois pada Desember 2024. Tuduhannya cukup luas: klaim pendapatan driver yang dianggap menyesatkan, pembatasan akses pelanggan ke akun dan dana mereka, serta pencantuman restoran di platform tanpa izin.

Salah satu bagian yang paling menarik adalah soal listing restoran. Menurut keluhan tersebut, Grubhub pernah memiliki hingga 325.000 restoran yang tidak terafiliasi dengan platformnya. FTC menilai listing seperti ini membuat platform terlihat lebih besar dari kondisi sebenarnya.

Ada juga tuduhan bahwa Grubhub tidak selalu menghapus restoran yang meminta keluar dari platform. Sebaliknya, perusahaan disebut mencoba mendorong beberapa restoran tersebut masuk ke kerja sama berbayar.

Settlement ini mewajibkan Grubhub mengubah beberapa cara operasinya. Perusahaan harus lebih akurat saat mengiklankan potensi pendapatan driver, memberi pelanggan cara untuk menggugat pembatasan akun yang membuat mereka tidak bisa mengakses akun atau dana, dan mendapatkan persetujuan restoran sebelum mencantumkannya di platform.

Di permukaan, ini terlihat seperti berita hukum tentang satu perusahaan delivery. Tetapi secara bisnis, kasus ini lebih besar dari Grubhub.

Ini adalah pengingat bahwa platform digital tidak hanya dinilai dari jumlah pengguna, jumlah mitra, atau jumlah transaksi. Platform juga dinilai dari seberapa jujur sistemnya menjelaskan posisi setiap pihak di dalamnya.

The Reality Check

Banyak platform tumbuh dengan tekanan yang mirip: harus terlihat besar, aktif, dan menarik bagi banyak sisi sekaligus.

Driver perlu percaya bahwa peluang penghasilannya masuk akal. Pelanggan perlu percaya bahwa saldo, akun, dan pesan di aplikasi bisa diakses secara adil. Restoran perlu percaya bahwa nama dan menu mereka tidak dipakai tanpa kendali. Investor dan pasar ingin melihat jaringan yang terus membesar.

Masalah muncul ketika pertumbuhan platform mulai bergantung pada gambaran yang tidak cukup akurat.

Klaim pendapatan yang terlalu optimistis mungkin membantu menarik driver baru. Listing restoran yang belum memberi izin mungkin membuat marketplace terlihat lebih lengkap. Alur pembatasan akun yang sulit digugat mungkin terlihat efisien secara operasional. Tetapi semua itu menyimpan utang kepercayaan.

Utang ini sering tidak langsung terlihat di dashboard pertumbuhan.

Angka restoran bisa naik. Jumlah driver bisa bertambah. Pesanan bisa bergerak. Namun di balik angka itu, ada pihak yang merasa dirugikan karena informasi yang mereka terima tidak sama dengan kenyataan operasional.

Untuk bisnis digital, terutama yang menghubungkan banyak pihak, masalah seperti ini jarang hanya soal halaman marketing atau teks promosi. Biasanya ia masuk ke desain produk, proses internal, data, dan insentif tim.

Pertanyaannya bukan hanya: apakah klaim ini menarik?

Pertanyaan yang lebih sehat adalah:

• apakah klaim ini bisa dibuktikan oleh data aktual?
• apakah angka yang ditampilkan punya konteks yang cukup?
• apakah pengguna bisa menggugat keputusan sistem?
• apakah mitra memberi izin yang jelas?
• apakah tim support punya prosedur untuk memperbaiki kesalahan?
• apakah dashboard internal membedakan pertumbuhan yang sehat dan pertumbuhan yang berisiko?

Di banyak bisnis, celah seperti ini muncul bukan karena satu keputusan besar yang jahat. Sering kali ia muncul karena banyak keputusan kecil yang dibiarkan terlalu lama.

Tim marketing ingin pesan yang lebih kuat. Tim growth ingin akuisisi lebih cepat. Tim product ingin onboarding lebih pendek. Tim operations ingin proses lebih ringan. Tim legal baru masuk ketika masalah sudah besar.

Akibatnya, sistem menjadi cepat, tetapi tidak selalu adil. Platform terlihat lengkap, tetapi tidak selalu punya persetujuan yang jelas. Klaim terlihat kuat, tetapi tidak selalu cocok dengan pengalaman pengguna paling umum.

Kasus Grubhub menunjukkan bahwa regulator mulai melihat detail operasional seperti ini sebagai bagian dari perlindungan konsumen dan pekerja. Bukan hanya iklan di luar aplikasi, tetapi juga cara akun dibatasi, cara dana diakses, cara mitra dicantumkan, dan cara potensi pendapatan dijelaskan.

Ini penting untuk bisnis lain, bahkan yang skalanya jauh lebih kecil.

Karena versi kecil dari masalah yang sama sering muncul di banyak sistem: data pelanggan dipakai tanpa konteks, katalog menampilkan stok yang belum pasti, harga promosi tidak menjelaskan syarat, status order tidak transparan, atau dashboard menunjukkan angka yang membuat bisnis terlihat sehat padahal ada komplain yang menumpuk.

Skala Grubhub memang besar. Tetapi pola risikonya tidak eksklusif untuk perusahaan besar.

The Havedev Way

Dari sudut pandang Havedev, pelajaran utama dari kasus ini bukan bahwa bisnis harus takut membangun platform.

Pelajarannya adalah: platform harus punya bahasa operasional yang jujur sejak awal.

Kalau sebuah sistem menampilkan estimasi pendapatan, bisnis perlu tahu dari mana angka itu datang, kapan angka itu relevan, dan batasannya apa. Kalau sistem mencantumkan mitra, harus jelas apakah mitra itu aktif, terverifikasi, memberi izin, atau hanya data historis. Kalau sistem membatasi akun, pengguna perlu punya jalur yang bisa dibaca untuk mengajukan keberatan.

Ini bukan sekadar urusan compliance. Ini bagian dari desain produk yang sehat.

Platform yang baik tidak hanya membuat transaksi terjadi. Platform yang baik membuat setiap pihak tahu posisinya:

• apa yang dijanjikan
• apa yang belum pasti
• siapa yang bertanggung jawab
• data apa yang dipakai
• kapan keputusan bisa digugat
• bagaimana kesalahan diperbaiki

Untuk bisnis yang sedang membangun marketplace, aplikasi internal, CRM, sistem booking, portal partner, atau automation sales, prinsip ini bisa diterapkan lebih awal tanpa harus menunggu masalah hukum.

Mulai dari area yang paling dekat dengan klaim bisnis.

Jika website mengatakan respons cepat, ukur benar-benar waktu respons. Jika dashboard menampilkan lead qualified, sepakati definisi qualified. Jika aplikasi memberi estimasi pendapatan, jelaskan asumsi datanya. Jika sistem mencantumkan partner, simpan bukti persetujuannya. Jika automation mengirim follow-up, pastikan status dan konteksnya tidak menyesatkan.

Banyak bisnis ingin langsung menambah fitur: dashboard baru, automation baru, AI assistant baru, atau integrasi baru. Itu bisa berguna.

Tetapi sebelum itu, cek dulu apakah data dan status yang ditampilkan sudah cukup jujur untuk dipercaya.

Karena sistem digital punya efek penguat. Jika data benar, sistem membuat bisnis lebih cepat dan lebih rapi. Jika data kabur, sistem membuat kebingungan terlihat resmi. Jika klaim terlalu agresif, sistem membuat ekspektasi yang sulit dipenuhi. Jika izin tidak jelas, sistem membuat risiko menyebar ke banyak tempat.

Pendekatan yang lebih sehat adalah membangun dari trust layer paling dasar:

• definisi status yang jelas
• sumber data yang bisa dilacak
• izin yang tercatat
• klaim yang bisa diaudit
• alur komplain yang manusiawi
• log perubahan untuk keputusan penting

Tidak semua bisnis perlu sistem besar untuk ini. Kadang cukup dengan form yang lebih jelas, spreadsheet yang lebih disiplin, CRM yang dirapikan, atau SOP internal yang disambungkan ke notifikasi.

Yang penting bukan kompleksitas teknologinya. Yang penting adalah apakah sistem membantu bisnis berkata benar kepada pelanggan, tim, dan partner.

Kasus Grubhub menjadi pengingat bahwa pertumbuhan yang terlihat besar bisa menjadi rapuh kalau fondasinya tidak transparan. Platform boleh mengejar skala, tetapi skala tidak boleh dibangun dari klaim yang sulit dibuktikan, izin yang kabur, atau akses pengguna yang tidak adil.

Untuk banyak bisnis, pertanyaan praktisnya sederhana:

Apakah sistem Anda sedang membantu pengguna memahami kenyataan, atau hanya membuat bisnis terlihat lebih besar dan lebih rapi dari kondisi sebenarnya?

Kalau jawabannya belum jelas, mulai dari audit kecil. Lihat klaim utama di website, form, dashboard, automation, dan alur support. Cocokkan dengan kenyataan operasional. Cari bagian yang terlalu optimistis, terlalu kabur, atau terlalu sulit digugat.

Sering kali, perbaikan terbesar bukan dimulai dari fitur baru. Perbaikan dimulai dari membuat sistem lebih jujur.

Dapatkan Audit Teknis Gratis untuk meninjau website, dashboard, dan alur digital bisnis Anda sebelum klaim, data, atau automation berubah menjadi risiko operasional.

---

Sumber referensi berita: TechCrunch