Business Messages temsilcileri aracılığıyla kullanıcılarla etkileşimde bulunurken aşağıdaki en iyi uygulamaları aklınızda bulundurun.
Hassas bilgi vermeyin veya hassas bilgiler istemeyin
Sohbet sırasında hassas içeriklerden kaçınmak sizin ve müşterilerinizin bilgilerini güvende tutar. Hassas bilgiler aşağıdakileri kapsar, ancak bunlarla sınırlı değildir:
- Kredi kartı numaraları
- Sosyal Güvenlik, pasaport veya diğer resmi kimlik numaraları
- Şifreler gibi giriş kimlik bilgileri
Kullanıcılara hızlı yanıt verin
Kullanıcı mesajlarına yavaş veya makul olmayan yanıt süreleri, müşterilerinizin kötü bir deneyim yaşamasına neden olur. Yanıt altyapınızı, kullanıcı mesajlarına düzenli olarak zamanında yanıt verecek şekilde tasarladığınızdan emin olun.
Yavaş yanıt daha da kötüsü, hiç yanıt vermiyor. Mesaj sayınıza bakılmaksızın, kullanıcıların her zaman iletilerine yanıt verdiğinden emin olun. Örneğin, canlı personel müsait değilse kullanıcıyı tanıyan otomatik bir mesaj gönderin ve kullanıcının tam yanıt bekleme süresiyle ilgili bir tahmin ekleyin.
Google, mesajlar arasında yanıt verme süresini (TTR) ölçer. Bir markanın temsilcisi tüketicilere yanıt vermekte yavaşsa Google, markanın mesajlaşma düğmelerini kaldırır.
Otomasyon, istekleri karşılayamadığında insanlara geçin
Otomasyon gereken şekilde tepki vermediğinde kullanıcılar hayal kırıklığına uğrar. Bu nedenle, Google tarafından yönetilen giriş noktalarından (Google Ads giriş noktası hariç) başlatılan tüm aracıların, otomasyonun işlem yapamayacağı durumlarda görüşmeleri işleyebilecek gerçek kişi temsilcilerinin olması gerekir. Lansmandan önce, aracı etkileşimi türünüzü gerçek temsilcileri içerecek şekilde ayarlamanız gerekir.
Otomasyon, kullanıcının isteğini art arda iki kez yerine getiremediğinde en iyi yöntem, canlı temsilci istek önerisi içeren bir mesaj göndermektir.
Bir kullanıcı bu öneriye dokunduğunda temsilciniz canlı temsilci tarafından istenen bir etkinlik alır. Temsilciniz, görüşmeyi bir insan temsilcisine vererek yanıt vermelidir. Böylece kullanıcı ihtiyaç duyduğu yardımı alabilir.
İnsanların 7/24 ulaşılabilir olması gerekmez. Kullanıcıların ne zaman yanıt alabileceğini bilmesi için aracınızın müsaitlik durumunu ayarlayın.
OAuth ile kullanıcıların kimliğini doğrulama
Kullanıcıların kimliklerini doğrulamak ve onlara kişiselleştirilmiş bilgiler sağlamak için OAuth aracılığıyla arka uç sistemleriyle kullanıcıların kimliğini doğrulayın. OAuth ile kimlik doğrulama, aracıların kullanıcı verilerine hızlı bir şekilde erişmesini sağlar ve kullanıcıların veya temsilcilerin, görüşmeye hassas bilgileri (kullanıcı adı veya şifre gibi) dahil etmesini engeller. OAuth ile kimlik doğrulama bölümünü inceleyin.
Business Messages içinde CSAT ölçümü
Business Messages, doğrudan mesajlaşma deneyimlerindeki anketlerle Müşteri Memnuniyeti Puanlarını (CSAT) ölçer. Kullanıcıların birden fazla anket almasını önlemek için Business Messages'ın anket işlevini kullanın. Kendi CSAT ölçüm tekniklerinizi uygulamayın.
Konudan ayrılmayın
Mevcut görüşmeyle istenmeyen veya alakasız mesajlar göndermeyin. Örneğin,
- Orijinal istekle ilgili olmayan bir ürün veya hizmet hakkındaki mesajlar
- Kullanıcı yanıtı olmayan tekrar eden mesajlar
- Aşırı uzun mesajlar veya emoji ve URL'lerin aşırı kullanımı
Kullanılabilir olduğunda Yer Kimliği'nden yararlanın
Konuma dayalı giriş noktaları için iletiler bağlam yükünde placeId içerebilir. Belirli bir konumdaki envanter gibi, kullanıcının sorabileceği
bilgileri sağlamak için bunlardan yararlanabilirsiniz. placeId, Google Yerler veritabanındaki ve Google Haritalar Platformu'ndaki bir yeri benzersiz olarak tanımlar.
Yalnızca konuma dayalı giriş noktalarıyla başlatsanız bile bir placeId bulunmadığında strateji uyguladığınızdan emin olun. Yaygın olmasa da, diğer bağlamsal verilerin yanı sıra placeId değerinin webhook'unuza aktarılmadığı durumlar da vardır.
Eksponansiyel geri yükleme ile yeniden denemeleri uygulama
Bir API çağrılırken altyapı sorunları, hizmet aşırı yüklemesi, QPS sınırları ve diğer hatalar nedeniyle başarısız olabilir. Başarısız API çağrısından hassas bir şekilde kurtarmak için eksponansiyel geri yükleme ile yeniden denemeler uygulayın.
Altyapınız eksponansiyel geri yükleme ile yeniden kullanıldığında, altyapınız otomatik olarak
- Başarısız bir API çağrısı tanımlar
- İlk bekleme süresini ve yeniden deneme sayısını belirler
- Bekleme süresinde duraklatılır
- API çağrısını yeniden dener
API çağrısı yanıtını değerlendirir:
- İstek başarılı olursa iş akışındaki bir sonraki adımla devam eder
- İstek başarısız olursa bekleme süresini uzatır ve 3. adıma döner
- Maksimum yeniden deneme sayısından sonra işlem başarısız olursa hata durumuna geçer
İdeal bekleme süreleri ve ideal maksimum yeniden deneme sayısı kullanım alanına göre değişir. Bu sayıları altyapınızın ve iş akışlarınızın gecikme gereksinimlerine göre belirleyin.
Yinelenen gelen iletileri kontrol etme
Kullanıcılardan gelen mesajları kontrol edip yanıtlarken messageId özelliğini kontrol edin ve mesajı daha önce almadığınızı ve yanıtlamadığınızı doğrulayın.
Dağıtılmış sistemlerde mesaj göndermenin iki yolu vardır: En çok bir, en az bir kez. "En fazla bir kez" sistemde sistem bir mesaj gönderir ancak bu süreçte ağ veya iletişim hataları varsa mesaj alınamayabilir. "En az bir" sistemde sistem bir iletiyi birden çok kez gönderebilir ancak ağ veya iletişim hataları olsa bile mesaj alınabilir.
Business Messages "en az bir kez" sistem kullanır. Bu durum, gelen iletilerin yinelenmesine neden olsa da messageId dizelerini izleyerek iletilerin tekilleştirilmesi kolaydır. Bir ileti aldıysanız aynı messageId ile aldığınız diğer iletileri yoksayabilirsiniz.