Saat Anda berinteraksi dengan pengguna melalui agen Business Messages, ingatlah praktik terbaik berikut.
Jangan berikan atau minta 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
Menanggapi pengguna dengan cepat
Waktu respons yang lambat atau tidak wajar terhadap pesan pengguna menciptakan pengalaman yang buruk bagi pelanggan Anda. Pastikan Anda mendesain infrastruktur respons untuk memberikan balasan pesan pengguna secara tepat waktu.
Lebih buruk daripada respons yang lambat adalah tidak ada respons sama sekali. Pastikan pengguna selalu menerima respons terhadap pesan mereka, terlepas dari pemuatan pesan. Misalnya, jika staf live tidak tersedia, kirim pesan otomatis yang mengonfirmasi pengguna, dan sertakan perkiraan kapan pengguna akan mendapatkan respons lengkap.
Google mengukur waktu untuk merespons (TTR) antar-pesan. Jika agen merek lambat merespons konsumen, Google akan menghapus tombol pesan merek.
Saat otomatisasi tidak dapat memenuhi permintaan, serahkan kepada manusia
Pengguna akan merasa frustrasi jika otomatisasi tidak meresponsnya dengan tepat. Itulah sebabnya semua agen yang diluncurkan dari titik entri yang dikelola Google (kecuali untuk titik entri Google Ads) harus memiliki perwakilan manusia yang dapat menangani percakapan jika otomatisasi tidak dapat dilakukan. Sebelum peluncuran, Anda perlu menetapkan jenis interaksi agen untuk mencakup 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 acara yang diminta agen langsung. Agen Anda harus merespons dengan menyerahkan percakapan kepada perwakilan manusia, agar pengguna mendapatkan bantuan yang mereka butuhkan.
Manusia tidak harus selalu siap 24/7. Tetapkan ketersediaan agen agar pengguna dapat mengetahui kapan mereka akan merespons secara manual.
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 Pesan Bisnis
Business Messages mengukur Skor Kepuasan Pelanggan (CSAT) dengan survei langsung dalam pengalaman pesan. Untuk mencegah pengguna menerima beberapa survei, gunakan fungsi survei Business Messages. Jangan terapkan teknik pengukuran CSAT Anda sendiri.
Tetap fokus pada topik
Jangan mengirim 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 Place ID jika tersedia
Untuk titik entri berbasis lokasi, pesan dapat berisi placeId dalam payload konteks. Anda dapat memanfaatkannya untuk memberikan informasi yang mungkin diminta 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 jika tidak ada placeId. Meskipun
tidak umum, ada kasus saat placeId, di antara data kontekstual
lainnya, tidak diteruskan ke webhook Anda.
Menerapkan percobaan ulang dengan backoff eksponensial
Saat memanggil API apa pun, ada kemungkinan panggilan gagal karena masalah infrastruktur, kelebihan layanan, batas QPS, dan error lainnya. Untuk memulihkan dengan baik dari panggilan API yang gagal, terapkan percobaan ulang dengan backoff eksponensial.
Menggunakan percobaan ulang dengan backoff eksponensial, infrastruktur Anda secara otomatis
- Mengidentifikasi panggilan API yang gagal
- Menetapkan durasi tunggu awal dan jumlah maksimum percobaan ulang
- Menjeda selama durasi tunggu
- Mencoba lagi panggilan API
Menilai respons panggilan API:
- Jika berhasil, lanjutkan dengan langkah berikutnya dalam alur kerja
- Jika gagal, tingkatkan durasi tunggu dan kembali ke langkah 3
- Jika kegagalan setelah jumlah maksimum percobaan ulang terjadi, masukkan status gagal
Durasi tunggu ideal dan jumlah maksimum percobaan ulang yang ideal bervariasi menurut kasus penggunaan. Tentukan angka-angka ini berdasarkan persyaratan latensi infrastruktur dan alur kerja Anda.
Periksa apakah ada pesan masuk duplikat
Saat Anda memeriksa dan membalas pesan masuk dari pengguna, periksa
messageId dan verifikasi bahwa Anda belum menerima dan membalas
pesan tersebut sebelumnya.
Dengan sistem terdistribusi, ada dua cara untuk mengirim pesan: maksimum satu kali, dan setidaknya satu kali. Dengan sistem "maksimal satu kali", sistem mengirim pesan satu kali, tetapi jika terjadi error jaringan atau komunikasi selama proses berlangsung, pesan mungkin tidak akan diterima. Dengan sistem "setidaknya sekali", sistem mungkin mengirim pesan beberapa kali, tetapi pesan bisa diterima meskipun terjadi error jaringan atau komunikasi.
Business Messages menggunakan sistem "setidaknya sekali". Meskipun dapat menyebabkan
pesan masuk duplikat, Anda dapat dengan mudah menghapus pesan duplikat
dengan melacak string messageId. Jika Anda sudah menerima pesan, Anda dapat mengabaikan pesan tambahan apa pun yang diterima dengan messageId yang sama.