Cara Membuat Portal Pelanggan Tanpa Meminta Kata Sandi

Portal pelanggan adalah halaman pribadi tempat setiap orang hanya melihat miliknya sendiri — pesanannya, janji temunya, dan berkasnya. Tidak perlu kata sandi; cukup tautan pribadi atau email yang sudah diverifikasi.

Adriana adalah ahli gizi di Pachuca dan melayani sekitar empat puluh pasien per bulan. Pekerjaan sesungguhnya bukan konsultasinya, melainkan apa yang terjadi di antara satu konsultasi dengan berikutnya. Ia menjual program empat minggu yang dilengkapi materi — panduan porsi, daftar belanja, kumpulan resep — dan mengirimkannya lewat WhatsApp. Ia mengingat tanggal janji temu berikutnya. Ia mencatat di buku catatan siapa yang sudah bayar lunas dan siapa yang baru separuh. Dan setiap minggu ia menjawab tiga atau empat kali pesan yang sama: “eh, boleh kirim ulang panduannya? chat-nya kehapus”.

Semua itu bisa diselesaikan oleh portal pelanggan. Dan bagian yang sulit bukan yang biasanya dibayangkan orang.

Apa itu portal pelanggan?

Portal pelanggan adalah halaman pribadi di dalam situsmu tempat setiap pelanggan hanya melihat miliknya sendiri: status pesanannya, janji temu berikutnya, dan berkas yang menjadi haknya. Ini bukan sekadar bagian tambahan dari halamanmu. Halamanmu bersifat publik dan berbicara kepada siapa pun yang datang; portal berbicara kepada satu orang dan menunjukkan hal-hal miliknya.

Dalam kasus Adriana ada tiga hal: kapan konsultasi berikutnya, materi programnya untuk diunduh kapan pun ia mau, dan berapa banyak yang sudah ia bayar.

Apakah pelanggamu benar-benar perlu punya kata sandi?

Hampir tidak pernah, dan di sinilah kebanyakan proyek seperti ini gagal.

Kita sudah pernah bahas bahwa bisnis kecil jarang butuh aplikasi dengan pendaftaran dan kata sandi. Itu masih benar. Yang terjadi adalah kata “portal” terdengar seperti login, dan begitu kamu meminta orang membuat akun, kamu sudah kehilangan separuhnya: mereka lupa kata sandi, mereka menghubungimu lewat WhatsApp supaya kamu mengingatkannya, dan akhirnya kamu mengerjakan sendiri secara manual pekerjaan yang seharusnya dihilangkan oleh portal. Pasien Adriana tidak akan ingat kata sandi yang hanya ia pakai sekali sebulan.

Portal yang benar-benar berguna dimulai dari pertanyaan yang lebih sederhana: bagaimana aku membuktikan bahwa orang ini memang yang ia klaim, tanpa memaksanya membuat kata sandi.

Bagaimana portalmu tahu bahwa itu memang pelangganmu?

Ada dua cara, dan tidak satu pun dari keduanya adalah kata sandi.

Cara pertama adalah tautan pribadi. Ketika seseorang membeli atau memesan janji temu darimu, tersimpan di ponselnya sebuah tautan panjang yang mustahil ditebak. Tautan itu adalah buktinya. Siapa pun yang memilikinya bisa melihat pesanannya; siapa pun yang tidak memilikinya tidak akan bisa masuk ke sana meski mencoba menebak-nebak alamat secara acak. Ini prinsip yang sama dengan tiket pesawat yang dikirim ke emailmu: kamu tidak diminta username atau kata sandi, kamu dikirimi sesuatu yang hanya kamu miliki.

Cara kedua adalah emailnya, yang sudah diverifikasi. Jika pelangganmu memang pernah mendaftar, ia masuk dengan emailnya dan melihat semua yang terkait dengan alamat itu.

Perbedaannya penting: tautan hidup di sebuah ponsel, email hidup pada orangnya. Karena itu tautan cocok untuk pelanggan satu kali beli — yang membeli darimu di meja kasir dan tidak akan pernah mendaftar — sementara email cocok untuk yang kembali setiap bulan.

Apa yang harus dijawab portalmu ketika seseorang bukan pemilik pesanan?

Persis sama seperti yang akan dijawabnya jika pesanan itu tidak ada. Bukan “pesanan ini bukan milikmu”, bukan “akun itu ada tapi kamu tidak bisa melihatnya”: tidak ada apa pun, kami tidak menemukan apa pun. Ini aturan yang membedakan portal yang serius dari yang akan membuatmu bermasalah, dan yang paling jarang dipikirkan orang.

Kedengarannya seperti detail teknis, tapi bukan. Portal yang menjawab berbeda antara “tidak ada” dan “ada tapi bukan milikmu” berubah menjadi mesin pencari pelanggan orang lain: siapa pun bisa mencoba-coba email dan mencari tahu siapa saja yang menjadi pasien Adriana. Itu bukan kesalahan pemrograman, itu masalah bagi orang-orang yang sudah mempercayainya. Ini berlaku sama di toko, bengkel, atau klinik kecantikan — daftar siapa yang membeli darimu adalah informasi milik pelangganmu, bukan milikmu.

Aturan lengkapnya, dalam satu kalimat: portal tidak pernah mengonfirmasi bahwa sesuatu itu ada jika bukan kamu sendiri yang memintanya.

Apa yang dilihat pelangganmu di dalam?

Tiga blok, dan sebaiknya memang tiga, bukan sepuluh.

Pesanannya. Sedang di tahap apa, apa yang sudah dibayar, dan apa yang masih terutang. Kalau ada sisa saldo, di situ juga ia bisa langsung melunasinya, bukannya kamu yang harus mengingatkan terus. Kalau ada yang salah, di situ juga ia bisa mengajukan pengembalian dana tanpa perlu menghubungimu.

Janji temunya. Kapan jadwal berikutnya. Detail cara menyusun sistem janji temu di baliknya sudah kita bahas sebelumnya; di portal, yang penting hanyalah ia bisa melihatnya tanpa perlu bertanya kepadamu.

Berkasnya. Materi yang menyertai apa yang ia beli: panduan Adriana, kumpulan resep, manual alat yang kamu jual, materi kelas dari kursus. Terbuka baginya karena ia sudah bayar, dan tetap terbuka seterusnya. Inilah yang paling banyak menghemat kerja manualmu, karena justru inilah yang paling sering hilang dan diminta ulang oleh orang.

Satu catatan penting, karena di sinilah orang sering terlalu berharap: ini berfungsi ketika berkasnya sama untuk semua orang yang membeli hal yang sama. Kalau kamu butuh dokumen yang berbeda untuk setiap pelanggan — rencana khusus untuk masing-masing pasien — itu sudah hal lain dan lebih besar cakupannya. Layak dikerjakan, tapi mintalah sebagai hal terpisah, jangan menganggapnya sudah termasuk begitu saja.

Yang tidak perlu ada: perpesanan. Kamu sudah punya WhatsApp dan pelangganmu juga. Chat di dalam portal hanya jadi kotak masuk tambahan yang tidak akan pernah dicek siapa pun.

Bagaimana kalau ia membeli sebagai tamu lalu kemudian membuat akun?

Pembelian-pembelian sebelumnya harus otomatis muncul begitu ia masuk dengan email yang sama. Tidak perlu ia menghubungimu untuk meminta “dipindahkan” riwayat pembeliannya.

Ini terjadi sepanjang waktu — seseorang membeli cepat tanpa mendaftar dan bulan-bulan kemudian baru membuat akun — dan inilah keraguan yang menenggelamkan proyek-proyek semacam ini. Kalau portal yang kamu buat tidak menyatukan keduanya, pelangganmu akan punya dua “kehidupan” berbeda di bisnismu, dan kamulah yang jadi perekat di antara keduanya.

Dari mana mulainya

Sebelum meminta siapa pun membangunkannya untukmu, lakukan ini: tuliskan nama lima pelangganmu yang terakhir, dan di samping masing-masing, tuliskan pertanyaan yang akan mereka ajukan hari ini kalau mereka menghubungimu. Kalau tiga dari lima pertanyaan itu sudah punya jawaban dari sesuatu yang sudah kamu ketahui — tanggalnya, berkasnya, sisa saldonya — maka tiga itulah portalmu. Sisanya urusan nanti.

Dengan itu kamu sudah bisa mendeskripsikannya di Proyecta apa adanya: “sebuah portal untuk pasien-pasienku, tempat masing-masing bisa melihat konsultasi berikutnya, materi program yang mereka beli, dan berapa banyak yang sudah mereka bayar, tanpa perlu membuat kata sandi”. Deskripsikan dan publikasikan di proyecta.dev.