Tentukan masalah layanan yang ingin diselesaikan
Rapikan kepemilikan akun dan akses nomor
Susun alur dari pesan masuk sampai keputusan selesai
Pisahkan pesan layanan, izin kontak, dan informasi pelanggan
Uji integrasi sebagai pekerjaan yang jelas
Jalankan uji terbatas dengan hasil yang ditentukan sebelumnya
Bawa bahan evaluasi yang dapat diperiksa bersama
API WhatsApp sebaiknya dinilai dari pekerjaan tim, bukan hanya daftar fitur. Mulailah dengan satu pertanyaan: percakapan seperti apa yang sulit ditangani dalam proses sekarang? Pelanggan mungkin harus mengulang nomor pesanan ketika berganti petugas. Pertanyaan yang memerlukan keputusan bisa berhenti di antrean tanpa penanggung jawab. Atau petugas harus membuka beberapa sistem untuk menemukan informasi yang sama.
Bayangkan sebuah toko daring di Indonesia yang menerima pertanyaan produk, status pengiriman, dan permintaan penukaran melalui satu nomor. Contoh ini bersifat ilustratif, bukan kisah pelanggan imBee. Tim penjualan menjelaskan produk, tim layanan memeriksa pesanan, dan petugas yang berwenang memutuskan pengecualian. Koneksi pesan baru harus membantu pembagian pekerjaan tersebut, termasuk ketika percakapan berpindah tangan.
WhatsApp Business Platform menyediakan koneksi pesan melalui API. Tampilan yang dipakai petugas, aturan penugasan, dan hubungan dengan sistem bisnis bergantung pada solusi yang dipilih. WhatsApp Business App adalah produk yang berbeda. Jangan menganggap kata API berarti semua kebutuhan layanan sudah tersedia dalam satu paket.
Checklist ini membantu Anda menyiapkan evaluasi dan uji yang terkendali. Isinya tidak menjanjikan waktu aktivasi, tarif, persyaratan dokumen nasional tertentu, atau hasil persetujuan. Tujuannya sederhana: sebelum mengubah nomor yang dipakai pelanggan, ketahui apa yang harus bekerja, siapa yang memeriksa, dan keputusan apa yang masih menunggu konfirmasi.
| Bagian yang disiapkan | Pertanyaan utama | Bukti yang perlu dilihat |
|---|---|---|
| Akun dan nomor | Siapa yang berwenang mengelola koneksi? | Identitas aset dan penanggung jawab |
| Alur layanan | Siapa yang menerima setiap jenis pertanyaan? | Contoh penugasan dan pemindahan |
| Sistem bisnis | Informasi apa yang dibutuhkan petugas? | Uji pada sistem dan kolom yang ditentukan |
| Penanganan gangguan | Siapa yang bertindak ketika alur gagal? | Langkah pemulihan dan kontak yang jelas |
Tentukan siapa yang mengelola aset bisnis di Meta dan siapa yang dapat menyetujui perubahan nomor. Referensi teknis Cloud API dari Meta membedakan portofolio bisnis, akun WhatsApp Business, dan nomor telepon. Nama bisnis yang terlihat oleh pelanggan tidak cukup untuk menjelaskan semua akses administratif tersebut.
Buat catatan yang membantu perusahaan tetap menguasai akses ketika anggota tim berganti. Catatan itu tidak perlu berisi kata sandi atau kode verifikasi. Isinya dapat berupa nama pengelola, pihak pengganti, jalur persetujuan, dan lokasi instruksi pemulihan yang disimpan secara terbatas. Bedakan orang yang boleh mengambil keputusan dengan orang yang melaksanakan langkah teknis.
Pengelola Pihak pengganti Pemulihan akses
Jika nomor sudah digunakan untuk melayani pelanggan, minta penjelasan tentang jalur koneksi yang benar untuk kondisi akun Anda. Tanyakan dampaknya terhadap aplikasi yang digunakan sekarang, riwayat percakapan, kemungkinan jeda layanan, dan langkah jika proses tidak berhasil. Jawaban perlu sesuai dengan nomor, akun, serta penyedia yang dipakai. Panduan umum belum cukup menjadi dasar untuk mengubah layanan yang sedang berjalan.
Jangan menjadikan kode verifikasi sebagai bagian dari bahan presentasi yang dibagikan. Saat evaluasi, cukup tunjukkan informasi yang diperlukan untuk memahami struktur akses. Data pelanggan dan kredensial harus tetap berada dalam proses yang disetujui. Pengujian layanan seharusnya membuktikan bahwa tim dapat bekerja bersama tanpa saling meminjam akun pribadi.
Untuk pelaksana teknis, pusat sumber daya pengembang WhatsApp membantu menemukan rujukan resmi. Dokumentasi menjelaskan konsep dan alat implementasi. Prosedur yang tersedia pada akun perusahaan tetap harus dikonfirmasi sebelum dijalankan.
Pilih satu alur yang mudah diamati. Dalam contoh toko daring, pelanggan bertanya tentang pengiriman. Petugas perlu menemukan pesanan yang tepat, melihat status yang diizinkan, lalu menjelaskan langkah berikutnya. Jika ada pengecualian, percakapan diserahkan kepada orang yang berwenang. Setiap perpindahan harus punya tujuan dan penanggung jawab.
Halaman kotak masuk imBee menjelaskan penugasan percakapan dan kerja sama tim. Saat demonstrasi, minta alur Anda ditunjukkan melalui fitur yang tersedia dalam konfigurasi yang ditawarkan. Deskripsi publik tidak membuktikan bahwa suatu fungsi sudah aktif pada lingkungan yang akan Anda gunakan.
Aturan penugasan perlu menjawab situasi normal dan situasi tanpa petugas. Misalnya, pertanyaan pengiriman masuk ke tim layanan. Permintaan keputusan khusus masuk ke penanggung jawab yang ditentukan. Jika orang tersebut tidak tersedia, percakapan harus tetap terlihat di antrean yang ditinjau, bukan dianggap selesai hanya karena sudah dipindahkan.
Gunakan informasi yang diperlukan
Tulis informasi minimum untuk serah terima. Petugas berikutnya perlu mengetahui masalah pelanggan, pemeriksaan yang sudah dilakukan, jawaban terakhir, dan tindakan yang masih menunggu keputusan. Gunakan identitas internal pesanan jika diperlukan, dengan akses sesuai tugas. Hindari menyalin seluruh data pelanggan ketika ringkasan singkat sudah cukup.
Anda dapat menguji alur ini tanpa langsung menambah percakapan otomatis yang rumit. Jika memakai otomatisasi, pelanggan harus memiliki jalur yang jelas menuju manusia. Hal tersebut tercantum dalam kebijakan WhatsApp Business. Periksa apakah jalur itu dapat digunakan dan apakah petugas menerima konteks yang dibutuhkan untuk melanjutkan layanan.
Bedakan balasan terhadap percakapan pelanggan dengan pesan yang ingin dimulai oleh perusahaan. Kebijakan yang berlaku menjelaskan jendela layanan 24 jam dan penggunaan template yang disetujui di luar jendela tersebut. Penjelasan fitur resmi platform membedakan pesan yang dimulai pelanggan dan bisnis. Gunakan aturan itu untuk memeriksa alur, tanpa menarik kesimpulan tentang tarif.
Mulai dari satu tujuan kontak yang spesifik. Pembaruan pengiriman seharusnya berhubungan dengan kebutuhan yang dipahami pelanggan. Catat izin yang berlaku dan cara tim menghormati permintaan berhenti menerima pesan. Nomor telepon di daftar pelanggan tidak otomatis menjadi izin untuk semua jenis kampanye.
Tentukan pula informasi yang boleh dilihat petugas. Untuk menjawab status pengiriman, tim mungkin hanya membutuhkan identitas pesanan dan status yang relevan. Akses ke seluruh catatan pelanggan belum tentu diperlukan. Sebelum menyambungkan sistem, tulis siapa yang boleh melihat informasi tersebut dan siapa yang boleh mengubahnya.
| Situasi yang diuji | Persiapan | Hasil yang diperiksa |
|---|---|---|
| Pelanggan menanyakan pesanan | Cara mencari pesanan secara benar | Petugas memakai catatan yang tepat |
| Bisnis mengirim pembaruan | Izin dan bentuk pesan yang sesuai | Alur mengikuti ketentuan kanal saat ini |
| Pelanggan meminta berhenti | Prosedur untuk mencatat permintaan | Tim menghormati penghentian kontak |
| Kasus memerlukan keputusan manusia | Tujuan dan penanggung jawab | Konteks diterima sebelum mengambil tindakan |
| Informasi tidak ditemukan | Jalur klarifikasi atau eskalasi | Tidak muncul jawaban yang dibuat-buat |
Keputusan tersebut berhubungan dengan cara perusahaan mengelola data dan layanan. Menggunakan API tidak dengan sendirinya membuktikan kepatuhan terhadap hukum atau ketentuan sektor tertentu. Simpan peta data, tanggung jawab, dan pertanyaan yang belum terjawab sebagai bagian dari evaluasi. Pernyataan umum tentang keamanan tidak menggantikan pemeriksaan yang dibutuhkan oleh bisnis Anda.
Pernyataan “terhubung dengan CRM” terlalu luas untuk menjadi kriteria penerimaan. Sebutkan nama sistem yang digunakan dan tindakan yang diperlukan petugas. Membaca status pesanan berbeda dari memperbarui alamat, membuat tiket, atau menjalankan tindakan yang mempunyai akibat di luar percakapan. Setiap tindakan membutuhkan akses dan pengujian yang sesuai.
Halaman integrasi imBee menjelaskan hubungan dengan sistem bisnis. Ketersediaan konektor, kolom yang dapat digunakan, arah perubahan, dan penanganan gangguan harus dikonfirmasi untuk kebutuhan Anda. Kehadiran nama suatu aplikasi di materi pemasaran belum membuktikan bahwa alur khusus perusahaan sudah selesai diintegrasikan.
Gunakan catatan fiktif atau data uji yang telah diizinkan. Tunjukkan informasi yang harus terlihat, pengguna yang boleh membacanya, dan perilaku ketika sistem tidak merespons. Jika pengujian mencakup penulisan data, periksa konfirmasi perubahan serta cara mencegah tindakan berulang yang tidak disengaja. Keberhasilan membaca data bukan bukti bahwa perubahan data juga aman dijalankan.
Halaman otomatisasi imBee menjelaskan penggunaan aturan untuk mengarahkan layanan. Sebelum menerapkan aturan pada pelanggan, lihat bagaimana sistem menangani topik yang tidak dikenal dan tim yang tidak tersedia. Aturan awal yang sederhana, dengan jalur manusia yang jelas, lebih mudah diperiksa daripada alur panjang yang belum pernah diuji.
Pesan yang berhasil terkirim hanya membuktikan satu bagian dari alur. Pengujian layanan perlu menunjukkan penerimaan, penugasan, pemeriksaan informasi, penyerahan kasus, dan hasil akhir. Gunakan peserta serta nomor uji yang telah diizinkan. Jangan memakai percakapan pelanggan nyata sebagai percobaan yang belum disepakati.
Siapkan satu kasus biasa dan satu pengecualian. Pada contoh toko, kasus biasa bisa berupa pertanyaan status pengiriman. Pengecualian bisa berupa permintaan penukaran yang membutuhkan keputusan. Tulis hasil yang diharapkan sebelum demonstrasi dimulai. Dengan begitu, tim menilai tindakan yang terlihat, bukan hanya kesan bahwa tampilan aplikasi rapi.
Periksa juga keadaan ketika petugas tidak tersedia atau sistem pesanan tidak memberikan jawaban. Cari tahu di mana percakapan berada, siapa yang melihatnya, dan bagaimana pelanggan mendapat penjelasan. Jika kegagalan hanya ditemukan setelah seseorang kebetulan membuka antrean, proses perlu diperbaiki sebelum diperluas.
Hasil yang diharapkan Hasil yang terlihat Perbaikan yang diperlukan
Sepakati arti respons pertama, penyerahan, dan penyelesaian. Pesan otomatis yang menyatakan pertanyaan sudah diterima belum menyelesaikan permintaan pelanggan. Pemindahan percakapan juga belum membuktikan bahwa tim tujuan telah menerima tanggung jawab. Definisi yang jelas membantu membandingkan hasil uji tanpa menjanjikan peningkatan waktu atau kepuasan yang belum diukur.
Catat hasil setiap kasus, orang yang memeriksa, dan keputusan yang masih terbuka. Ketika suatu langkah gagal, perbaiki bagian tersebut lalu ulangi kasus yang terkait. Pengujian tidak perlu menjadi proyek besar. Yang diperlukan adalah bukti bahwa pekerjaan utama dapat diselesaikan dan tim memahami apa yang harus dilakukan ketika ada gangguan.
Sebelum meminta demonstrasi, rangkum masalah saat ini, penggunaan nomor, pengelola akun, tugas petugas, dan sistem yang dibutuhkan. Tambahkan kasus uji beserta hasil yang diharapkan. Bahan singkat ini membantu penyedia menunjukkan alur yang relevan, bukan sekadar memperlihatkan semua fitur yang tersedia.
Konfirmasikan ruang lingkup penawaran dan ketersediaan layanan untuk operasi Anda di Indonesia. Halaman berbahasa Indonesia tidak membuktikan adanya kantor lokal, dukungan pada jam tertentu, atau jalur kontrak tertentu. Tanyakan hal tersebut kepada tim yang bertanggung jawab. Hal yang sama berlaku untuk kebutuhan penyimpanan dan penggunaan data perusahaan.
Halaman API WhatsApp imBee memberi gambaran tentang produk. Gunakan sebagai awal pembahasan, lalu minta alur penugasan, serah terima, dan akses informasi yang benar-benar Anda perlukan. Saat menghubungi tim imBee, bawalah contoh pekerjaan dan pertanyaan yang belum terjawab. Sasaran evaluasi adalah rencana yang bisa diuji sebelum mengambil keputusan tentang kanal pelanggan.
API merupakan koneksi pesan. Tampilan kerja dan fitur kolaborasi bergantung pada solusi yang digunakan. Dalam demonstrasi, lihat bagaimana percakapan diterima, ditugaskan, dan diserahkan pada konfigurasi yang ditawarkan. Gunakan satu contoh pekerjaan tim agar Anda dapat menilai seluruh alur, termasuk keputusan ketika ada pengecualian.
Hal tersebut perlu dikonfirmasi untuk kondisi akun dan jalur koneksi yang tersedia. Sebelum melakukan perubahan, tanyakan penggunaan aplikasi saat ini, riwayat, kemungkinan gangguan, dan pemulihan. Jangan mengubah nomor pelanggan berdasarkan petunjuk umum saja. Pastikan penanggung jawab memahami dampaknya dan menyetujui langkah yang akan dijalankan.
Tidak harus. Tim dapat memulai dengan antrean dan pembagian tanggung jawab yang jelas. Jika menambahkan otomatisasi, uji jalur menuju manusia serta informasi yang diterima petugas. Bot bukan pengganti keputusan tentang siapa yang bertanggung jawab. Tambahkan aturan setelah ada tugas berulang yang memang perlu dibantu.
Tentukan sistem, informasi, dan tindakan yang dibutuhkan. Uji memakai catatan yang diizinkan. Periksa akses, hasil baca atau perubahan, serta keadaan ketika sistem gagal. Demonstrasi umum belum membuktikan alur perusahaan Anda. Tuliskan hasil yang diharapkan untuk setiap tindakan dan simpan apa yang terlihat saat pengujian.
Siapkan satu kasus biasa, satu pengecualian, penanggung jawab, dan hasil yang diharapkan. Jelaskan penggunaan nomor serta sistem saat ini. Jangan memasukkan kata sandi, kode verifikasi, atau informasi pelanggan nyata ke bahan presentasi. Gunakan catatan fiktif yang tetap menunjukkan tugas penting dalam proses layanan Anda.
Tidak. Persetujuan mengikuti proses dan kondisi akun yang berlaku. Penanganan data serta kewajiban bisnis membutuhkan pemeriksaan tersendiri. Alat pesan tidak menggantikan tanggung jawab perusahaan dalam menentukan akses, tujuan, dan proses layanan. Tentukan pihak yang memeriksa keputusan tersebut sebelum mengubah kanal yang digunakan pelanggan.
Tidak. Sepakati peserta, nomor, dan catatan uji yang diizinkan terlebih dahulu. Periksa alur utama dengan hasil yang sudah ditentukan. Perubahan pada kanal yang sedang digunakan perlu prosedur dan persetujuan tersendiri setelah evaluasi. Simpan hasil pengujian serta daftar perbaikan yang harus diselesaikan sebelum melanjutkan.
Diskusikan kanal, tim, dan kebutuhan pengalihan percakapan Anda dalam demo produk.
