Gdy komunikujesz się z użytkownikami za pomocą agentów Business Messages, pamiętaj o tych sprawdzonych metodach.
Nie podawaj informacji poufnych ani nie proś o nie
Unikanie poufnych treści podczas czatów zapewnia bezpieczeństwo danych Twoich klientów. Informacje poufne obejmują między innymi:
- numery kart kredytowych;
- numery ubezpieczenia społecznego, paszportu lub inne numery identyfikacyjne nadane przez instytucje państwowe;
- dane logowania, np. hasła;
Szybko odpowiadaj użytkownikom
Zbyt długi lub nieuzasadniony czas odpowiedzi na wiadomości użytkowników źle wpływa na wrażenia klientów. Pamiętaj, aby zaprojektować infrastrukturę odpowiedzi, aby w sposób spójny odpowiadać na wiadomości użytkowników.
Co gorsza niż wolna odpowiedź w ogóle nie odpowiada. Zadbaj o to, aby użytkownicy zawsze otrzymywali odpowiedzi na swoje wiadomości, niezależnie od obciążenia Twoją wiadomością. Jeśli na przykład pracownicy na żywo nie są dostępni, możesz wysłać automatyczną wiadomość z potwierdzeniem użytkownika i ewentualną datą pełnej odpowiedzi.
Google mierzy czas odpowiedzi (TTR) między wiadomościami. Jeśli jej przedstawiciel nie odpowiada na pytania klientów, Google usuwa przyciski wiadomości marki.
Gdy automatyzacja nie może zrealizować żądań, przekaż je ludziom
Użytkownicy są frustrowani, gdy automatyzacja nie reaguje odpowiednio na zgłoszenia. Dlatego wszyscy pracownicy obsługi klienta uruchamiani z punktów wejścia zarządzanych przez Google (z wyjątkiem punktu wejścia Google Ads) muszą mieć przedstawicieli człowieka, którzy mogą obsługiwać rozmowy, gdy nie jest to możliwe w przypadku automatyzacji. Przed uruchomieniem musisz ustawić typ interakcji z agentem, aby uwzględnić w nim pracowników.
Jeśli automatyzacja nie może zrealizować żądania użytkownika dwukrotnie, najlepiej jest wysłać wiadomość z sugestią agenta na żywo.
Gdy użytkownik kliknie tę sugestię, agent otrzyma wydarzenie, o które prosi agent. Agent powinien odpowiedzieć, przekazując rozmowę do człowieka, aby użytkownik potrzebował pomocy.
Ludzie nie muszą być dostępni przez całą dobę. Ustaw dostępność agenta, aby użytkownicy wiedzieli, kiedy mogą spodziewać się odpowiedzi.
Uwierzytelnianie użytkowników przy użyciu protokołu OAuth
Aby zweryfikować tożsamość użytkowników i udostępnić im spersonalizowane informacje, uwierzytelnij ich za pomocą systemów backendu przez OAuth. Uwierzytelnianie przy użyciu protokołu OAuth zapewnia agentom szybki dostęp do danych użytkowników i uniemożliwia użytkownikom lub agentom uwzględnianie informacji poufnych (takich jak nazwa użytkownika lub hasło) w rozmowie. Zobacz Uwierzytelnianie przy użyciu OAuth.
Pomiar zadowolenia klientów z funkcji Business Messages
Business Messages mierzy wskaźnik zadowolenia klientów (CSAT) za pomocą ankiet bezpośrednio w interfejsie do przesyłania wiadomości. Aby użytkownicy nie mogli otrzymywać wielu ankiet, użyj funkcji ankiety w Business Messages. Nie wdrażaj własnych metod pomiaru CSAT.
Pisz na temat
Nie wysyłaj wiadomości, które są niechciane lub nie mają związku z bieżącą rozmową. Na przykład
- wiadomości o produktach lub usługach niezwiązane z pierwotnym żądaniem;
- Powtarzające się wiadomości bez odpowiedzi użytkownika
- zbyt długie wiadomości lub nadużywanie emotikonów i adresów URL.
Wykorzystanie identyfikatora miejsca, gdy jest dostępny
W przypadku punktów wejściowych opartych na lokalizacji wiadomości mogą zawierać element placeId w ładunku kontekstowym. Możesz wykorzystać go do udostępnienia informacji, o które użytkownik może zapytać, np. o zasoby reklamowe w konkretnej lokalizacji. placeId jednoznacznie identyfikuje miejsce w bazie danych Miejsc Google i w Google Maps Platform.
Nawet jeśli program uruchamiasz tylko z punktami wejścia opartymi na lokalizacji, zaimplementuj strategię w sytuacjach, gdy placeId jest niedostępny. Chociaż zdarza się to rzadko, w pewnych okolicznościach dane placeId nie są przekazywane do webhooka.
Wdrażanie ponownych prób ze wzrastającym czasem ponowienia
Każde wywołanie interfejsu API może się nie udać z powodu problemów z infrastrukturą, przeciążeniem usług, limitem zapytań na sekundę lub innymi błędami. Aby płynnie przywrócić dane po nieudanych wywołaniach interfejsu API, zaimplementuj ponownych próbach z użyciem wzrastającego czasu do ponowienia.
Ponowne próby z użyciem wzrastającego czasu ponowienia w infrastrukturze automatycznie
- Identyfikuje nieudane wywołanie interfejsu API
- Określa początkowy czas oczekiwania i maksymalną liczbę ponownych prób
- Wstrzymywania na czas oczekiwania
- Ponowne wywołanie interfejsu API
Analizuje odpowiedź wywołania interfejsu API:
- Jeśli operacja się powiedzie, przejdź do następnego kroku przepływu pracy.
- W przypadku niepowodzenia wydłuża czas oczekiwania i wraca do kroku 3
- Jeśli nie powiedzie się po osiągnięciu maksymalnej liczby ponownych prób, zostanie podany stan niepowodzenia
Idealny czas oczekiwania i idealna maksymalna liczba ponownych prób zależą od konkretnego przypadku użycia. Określ te liczby na podstawie wymagań dotyczących czasu oczekiwania na infrastrukturę i przepływów pracy.
Sprawdź, czy nie masz zduplikowanych wiadomości.
Kiedy sprawdzasz wiadomości przychodzące od użytkowników i odpowiadasz na nie, sprawdź messageId i sprawdź, czy ta wiadomość nie została jeszcze odebrana.
W systemach rozproszonych istnieją dwa sposoby wysyłania wiadomości: co najmniej raz i co najmniej raz. W przypadku systemów, które „nie częściej niż raz” system wysyła wiadomość jeden raz, ale występują błędy sieci lub komunikacji, wiadomość może nie zostać odebrana. W przypadku systemów, które działają co najmniej raz, system może wysłać wiadomość wiele razy, ale może zostać odebrana, nawet jeśli wystąpią błędy sieci lub komunikacji.
Business Messages używa systemu „przynajmniej raz”. Może to spowodować duplikowanie wiadomości przychodzących, ale łatwo jest usunąć duplikaty, śledząc ciągi tekstowe messageId. Możesz już bezpiecznie zignorować wszelkie dodatkowe wiadomości, które otrzymujesz już w ramach tego samego adresu messageId.