Saat berinteraksi dengan pengguna melalui agen Business Messages, perhatikan praktik terbaik berikut.
Jangan memberikan atau meminta informasi sensitif
Menghindari konten sensitif selama chat akan menjaga keamanan informasi Anda dan pelanggan. Informasi sensitif mencakup, tetapi tidak terbatas pada
- Nomor kartu kredit
- Nomor Jaminan Sosial, paspor, atau nomor identitas resmi lainnya
- Kredensial login, seperti sandi
Merespons pengguna dengan cepat
Waktu respons yang lambat atau tidak wajar terhadap pesan pengguna akan memberikan pengalaman buruk bagi pelanggan Anda. Pastikan Anda mendesain infrastruktur respons untuk secara konsisten memberikan balasan yang tepat waktu terhadap pesan pengguna.
Lebih buruk dari respons lambat adalah tidak ada respons sama sekali. Pastikan pengguna selalu menerima respons atas pesan mereka, terlepas dari beban pesan Anda. Misalnya, jika staf live tidak tersedia, kirim pesan otomatis yang mengonfirmasi pengguna, dan sertakan perkiraan kapan pengguna dapat mengharapkan respons lengkap.
Google mengukur waktu respons (TTR) di antara pesan. Jika agen merek lambat merespons konsumen, Google akan menghapus tombol pesan merek.
Jika otomatisasi tidak dapat memenuhi permintaan, serahkan kepada manusia
Pengguna akan merasa frustrasi jika otomatisasi tidak merespons mereka dengan benar. Itulah sebabnya semua agen yang diluncurkan dari titik entri yang dikelola Google (kecuali titik entri Google Ads) harus memiliki perwakilan manusia yang dapat menangani percakapan saat otomatisasi tidak dapat melakukannya. Sebelum peluncuran, Anda harus menetapkan jenis interaksi agen untuk menyertakan perwakilan manusia.
Jika otomatisasi tidak dapat memenuhi permintaan pengguna dua kali berturut-turut, sebaiknya kirim pesan dengan saran permintaan agen langsung.
Saat pengguna mengetuk saran ini, agen Anda akan menerima peristiwa permintaan agen langsung. Agen Anda harus merespons dengan menyerahkan percakapan kepada perwakilan manusia, sehingga pengguna mendapatkan bantuan yang mereka butuhkan.
Manusia tidak perlu tersedia 24/7. Tetapkan ketersediaan agen Anda agar pengguna tahu kapan mereka dapat mengharapkan respons dari manusia.
Mengautentikasi pengguna dengan OAuth
Untuk memverifikasi identitas pengguna dan memberikan informasi yang dipersonalisasi kepada mereka, autentikasi pengguna dengan sistem backend melalui OAuth. Autentikasi dengan OAuth memberi agen akses ke data pengguna dengan cepat dan mencegah pengguna atau agen menyertakan informasi sensitif (seperti nama pengguna atau sandi) dalam percakapan. Lihat Melakukan autentikasi dengan OAuth.
Mengukur CSAT dalam Business Messages
Business Messages mengukur Skor Kepuasan Pelanggan (CSAT) dengan survei langsung dalam pengalaman pesan. Untuk mencegah pengguna menerima beberapa survey, gunakan fungsi survei Business Messages. Jangan menerapkan teknik pengukuran CSAT Anda sendiri.
Tetap fokus pada topik
Jangan kirim pesan yang tidak diinginkan atau tidak relevan dengan percakapan saat ini. Misalnya,
- Pesan tentang produk atau layanan yang tidak terkait dengan permintaan awal
- Pesan berulang tanpa respons pengguna
- Pesan yang terlalu panjang atau penggunaan emoji dan URL yang berlebihan
Manfaatkan ID Tempat jika tersedia
Untuk titik entri berbasis lokasi, pesan dapat berisi placeId dalam
payload konteks. Anda dapat memanfaatkannya untuk memberikan informasi yang mungkin
ditanyakan pengguna, seperti inventaris di lokasi tertentu. placeId secara unik mengidentifikasi tempat di database Google Places dan di Google Maps Platform.
Meskipun Anda hanya meluncurkan dengan titik entri berbasis lokasi, pastikan untuk menerapkan strategi untuk situasi saat placeId tidak ada. Meskipun
tidak umum, ada situasi saat placeId, di antara data kontekstual
lainnya, tidak diteruskan ke webhook Anda.
Menerapkan percobaan ulang dengan backoff eksponensial
Saat memanggil API apa pun, panggilan dapat gagal karena masalah infrastruktur, kelebihan beban layanan, batas QPS, dan error lainnya. Untuk memulihkan dengan baik dari panggilan API yang gagal, terapkan percobaan ulang dengan backoff eksponensial.
Dengan menggunakan percobaan ulang dengan backoff eksponensial, infrastruktur Anda akan otomatis
- Mengidentifikasi panggilan API yang gagal
- Menetapkan durasi tunggu awal dan jumlah maksimum percobaan ulang
- Menjeda selama durasi tunggu
- Mencoba ulang panggilan API
Menilai respons panggilan API:
- Jika berhasil, lanjutkan ke langkah berikutnya dalam alur kerja
- Jika gagal, tingkatkan durasi tunggu dan kembali ke langkah 3
- Jika terjadi kegagalan setelah jumlah percobaan ulang maksimum, status akan menjadi gagal
Durasi tunggu yang ideal dan jumlah maksimum percobaan ulang yang ideal bervariasi menurut kasus penggunaan. Tentukan angka ini berdasarkan persyaratan latensi infrastruktur dan alur kerja Anda.
Memeriksa pesan masuk duplikat
Saat Anda memeriksa dan merespons pesan masuk dari pengguna, periksa
messageId dan pastikan Anda belum menerima dan merespons
pesan sebelumnya.
Dengan sistem terdistribusi, ada dua cara untuk mengirim pesan: maksimal sekali, dan minimal sekali. Dengan sistem "paling banyak sekali", sistem akan mengirim pesan sekali, tetapi jika ada error jaringan atau komunikasi di sepanjang proses, pesan mungkin tidak diterima. Dengan sistem "setidaknya sekali", sistem mungkin mengirim pesan beberapa kali, tetapi pesan dapat diterima meskipun ada error jaringan atau komunikasi.
Business Messages menggunakan sistem "setidaknya sekali". Meskipun hal ini dapat menyebabkan pesan masuk duplikat, Anda dapat dengan mudah menghapus duplikat pesan dengan melacak string messageId. Jika Anda sudah menerima pesan, Anda dapat mengabaikan pesan tambahan apa pun yang Anda terima dengan messageId yang sama.