Business Messages temsilcileri aracılığıyla kullanıcılarla etkileşime geçerken aşağıdaki en iyi uygulamaları göz önünde bulundurun.
Hassas bilgiler vermeyin veya istemeyin
Sohbetlerde hassas içeriklerden kaçınmak, sizin ve müşterilerinizin bilgilerinin güvende kalmasını sağlar. Hassas bilgiler şunları içerir 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 verilen yavaş veya makul olmayan yanıt süreleri, müşterileriniz için kötü bir deneyim oluşturur. Yanıt altyapınızı, kullanıcı mesajlarına tutarlı bir şekilde zamanında yanıt verecek şekilde tasarladığınızdan emin olun.
Yavaş yanıt vermekten daha kötüsü hiç yanıt vermemektir. Mesaj yükünüzden bağımsız olarak kullanıcıların mesajlarına her zaman yanıt almasını sağlayın. Örneğin, canlı destek ekibi müsait değilse kullanıcıyı bilgilendiren otomatik bir mesaj gönderin ve kullanıcının tam yanıtı ne zaman alabileceğini tahmini olarak belirtin.
Google, mesajlar arasındaki yanıtlama süresini (TTR) ölçer. Bir markanın temsilcisi tüketicilere yavaş yanıt veriyorsa Google, markanın mesajlaşma düğmelerini kaldırır.
Otomasyon istekleri yerine getiremediğinde isteği gerçek kişilere aktarma
Otomasyon onlara uygun şekilde yanıt vermediğinde kullanıcılar rahatsız olur. Bu nedenle, Google tarafından yönetilen giriş noktalarından (Google Ads giriş noktası hariç) başlatılan tüm temsilcilerin, otomasyonun yapamadığı durumlarda sohbetleri yönetebilecek gerçek temsilcilere sahip olması gerekir. Lansmandan önce temsilci etkileşim 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 seçenek canlı müşteri temsilcisi istek önerisi içeren bir mesaj göndermektir.
Kullanıcı bu öneriye dokunduğunda temsilcinize canlı temsilci istenen etkinlik gönderilir. Temsilciniz, kullanıcının ihtiyacı olan yardımı alabilmesi için sohbeti gerçek bir temsilciye aktararak yanıt vermelidir.
İnsanların 7/24 müsait olması gerekmez. Kullanıcıların ne zaman gerçek bir kişiden yanıt alabileceklerini bilmesi için müşteri temsilcinizin müsaitlik durumunu ayarlayın.
OAuth ile kullanıcı kimliklerini 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, temsilcilerin kullanıcı verilerine hızlı bir şekilde erişmesini sağlar ve kullanıcıların veya temsilcilerin sohbete hassas bilgiler (kullanıcı adları veya şifreler gibi) eklemesini engeller. OAuth ile kimlik doğrulama başlıklı makaleyi inceleyin.
Business Messages'da CSAT'yi ölçme
Business Messages, doğrudan mesajlaşma deneyimlerinde anketler aracılığıyla Müşteri Memnuniyeti Puanlarını (MÜP) ö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.
Aynı konu ile devam et
İstenmeyen veya mevcut görüşmeyle alakasız mesajlar göndermeyin. Örneğin,
- Orijinal istekle ilgili olmayan bir ürün veya hizmet hakkında mesajlar
- Kullanıcının yanıt vermediği tekrarlanan mesajlar
- Aşırı uzun mesajlar veya çok fazla emoji ve URL kullanımı
Kullanılabilir olduğunda yer kimliğinden yararlanma
Konum tabanlı giriş noktalarında, iletiler bağlam yükü içinde placeId içerebilir. Kullanıcının sorabileceği bilgileri (ör. belirli bir konumdaki envanter) sağlamak için bu özelliği kullanabilirsiniz. placeId, Google Rehber veritabanında ve Google Haritalar Platformu'nda bir yeri benzersiz şekilde tanımlar.
Yalnızca konuma dayalı giriş noktalarıyla lansman yapsanız bile placeId bulunmayan durumlar için bir strateji uyguladığınızdan emin olun. Sık karşılaşılan bir durum olmasa da diğer bağlamsal verilerin yanı sıra placeId'nin webhook'ınıza iletilmediği durumlar vardır.
Eksponansiyel geri yüklemeyle yeniden denemeleri uygulama
Herhangi bir API'yi çağırırken altyapı sorunları, hizmet yükü, istek/saniye sınırlamaları ve diğer hatalar nedeniyle çağrının başarısız olması mümkündür. Başarısız API çağrılarından sorunsuz bir şekilde kurtarmak için yeniden denemeleri üstel geri yüklemeyle uygulayın.
Eksponansiyel geri yüklemeyle yeniden denemeler kullanarak altyapınız otomatik olarak
- Başarısız bir API çağrısını tanımlar
- İlk bekleme süresini ve maksimum yeniden deneme sayısını ayarlar
- Bekleme süresi boyunca duraklatılır.
- API çağrısını yeniden dener.
API çağrısı yanıtını değerlendirir:
- Başarılı olursa iş akışında sonraki adıma geçer
- Başarısızlık olursa bekleme süresini artırır ve 3. adıma döner
- Maksimum yeniden deneme sayısından sonra hata oluşursa başarısız duruma 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 mesajları kontrol etme
Kullanıcılardan gelen iletileri kontrol edip yanıtlarken messageId simgesini işaretleyin ve iletiyi daha önce alıp yanıtlamadığınızı doğrulayın.
Dağıtılmış sistemlerde iletileri göndermenin iki yolu vardır: en fazla bir kez ve en az bir kez. "En fazla bir kez" sistemlerinde sistem bir kez ileti gönderir ancak bu süreçte ağ veya iletişim hataları olursa ileti alınamayabilir. "En az bir kez" sistemlerinde sistem bir mesajı birden çok kez gönderebilir ancak mesaj, ağ veya iletişim hataları olsa bile alınabilir.
Business Messages, "en az bir kez" sistemini kullanır. Bu durum, gelen iletilerin yinelenmesine neden olabilir ancak messageId dizelerini izleyerek iletilerin yinelenmesini önlemek kolaydır. Daha önce bir mesaj aldıysanız aynı messageId iletkeninden gelen diğer mesajları dikkate almamanız güvenlidir.