When you interact with users through Business messages agents, keep the following best practices in mind.
Don't provide or request sensitive information
Avoiding sensitive content during chats keeps your and your customers' information safe. Sensitive information include, but isn't limited to
- Credit card numbers
- Social Security, passport, or other government identification numbers
- Login credentials, like passwords
Respond to users quickly
Slow or unreasonable response times to user messages create a bad user experience for your customers. Make sure that you design your response infrastructure to consistently provide timely replies to user messages.
Even worse than a slow response is no response at all. Make sure that users always receive responses to their messages, regardless of your message load. For example, if live staff aren't available, send an automated message acknowledging the user, and include an estimate of when the user can expect a full response.
Google measures time to respond (TTR) between messages. If a brand's agent is slow to respond to consumers, Google will remove the brand's messaging buttons.
When automation can't fulfill requests, hand off to humans
Users get frustrated when automation fails to fulfill their requests. To prevent bad user experiences, when automation fails to properly respond or fulfill a request twice in a row, send a message with a live agent request suggestion.
Live agent request suggestions enable agents to programmatically transition conversations to human representatives and empower users to take action, bettering their experiences.
When a user taps a live agent request suggestion, the agent receives a live agent requested event.
Authenticate users with OAuth
To verify users' identities and provide personalized information to them, authenticate users with backend systems through OAuth. Authentication with OAuth gets agents access to user data quickly and prevents users or agents from including sensitive information (such as usernames or passwords) in the conversation. See Authenticate with OAuth.
Measure CSAT within Business Messages
Business Messages measures Customer Satisfaction Scores (CSAT) with surveys directly within messaging experiences. To prevent users from receiving multiple surveys, use Business Messages' survey functionality. Don't implement your own CSAT measurement techniques.
Stay on topic
Don't send messages that are unwanted or irrelevant to the current conversation. For example,
- Messages about a product or service unrelated to the original request
- Repeated messages with no user response
- Excessively long messages or excessive use of emoticons and URLs
Leverage placeId when it's available
For location-based entry points, messages may contain a placeId in the
context payload. You can leverage it to provide contextual information that the
user may be asking about, like inventory at a particular location. A placeId
uniquely identifies a place in the Google Places database and in the
Google Maps Platform.
Even if you only launch with location-based entry points, make sure to
implement a strategy for situations where a placeId isn't present. Although
not common, there are circumstances where a placeId, among other contextual
data, isn't passed to your webhook.
Implement retries with exponential backoff
When calling any API, it's possible for a call to fail because of infrastructure issues, service overload, QPS limits, and myriad other errors. To recover from failed API calls gracefully, implement retries with exponential backoff.
Using retries with exponential backoff, your infrastructure automatically
- Identifies a failed API call
- Sets the initial wait duration and the maximum number of retries
- Pauses for the wait duration
- Retries the API call
Assesses the API call response:
- If a success, proceeds with next step in the workflow
- If a failure, increases the wait duration and returns to step 3
- If a failure after the maximum number of retries, enters a fail state
Ideal wait durations and the ideal maximum number of retries vary by use case. Determine these numbers based on the latency requirements of your infrastructure and workflows.
Check for duplicate incoming messages
When you check for and respond to incoming messages from users, check the
messageId and verify that you haven't already received and responded to the
message previously.
With distributed systems, there are two ways of sending messages: at most once, and at least once. With "at most once" systems, the system sends a message once, but if there are network or communication errors along the way, the message may not be received. With "at least once" systems, the system might send a message multiple times, but the message can be received even when there are network or communication errors.
Business Messages uses an "at least once" system. While this can lead to
duplicate incoming messages, it's straightforward to de-duplicate messages by
tracking messageId strings. If you've already received a message, it's safe to
disregard any additional messages you receive with the same messageId.