Когда вы взаимодействуете с пользователями через агентов Business Messages, помните о следующих рекомендациях.
Не предоставляйте и не запрашивайте конфиденциальную информацию
Избегание конфиденциального контента во время чатов обеспечивает безопасность вашей информации и информации ваших клиентов. Конфиденциальная информация включает, помимо прочего:
- Номера кредитных карт
- Номера социального страхования, паспорта или других государственных идентификационных номеров
- Учетные данные для входа, например пароли
Быстро отвечайте пользователям
Медленное или необоснованное время ответа на сообщения пользователей создает неприятные впечатления для ваших клиентов. Убедитесь, что вы спроектировали свою инфраструктуру реагирования так, чтобы постоянно предоставлять своевременные ответы на сообщения пользователей.
Еще хуже, чем медленный ответ, это отсутствие ответа вообще. Убедитесь, что пользователи всегда получают ответы на свои сообщения, независимо от вашей загрузки сообщений. Например, если живой персонал недоступен, отправьте автоматическое сообщение с подтверждением пользователя и укажите примерное время, когда пользователь может ожидать полного ответа.
Google измеряет время ответа (TTR) между сообщениями. Если агент бренда медленно отвечает потребителям, Google удалит кнопки обмена сообщениями бренда.
Когда автоматизация не может выполнить запросы, передайте их людям.
Пользователи расстраиваются, когда автоматизация не реагирует на них должным образом. Вот почему все агенты, которые запускаются из точек входа , управляемых Google (за исключением точки входа Google Рекламы), должны иметь представителей, которые могут вести разговоры, когда автоматизация не может. Перед запуском вам необходимо настроить тип взаимодействия вашего агента , включив в него представителей людей.
Если автоматизация не может выполнить запрос пользователя дважды подряд, лучше всего отправить сообщение с предложением запроса живого агента .
Когда пользователь нажимает на это предложение, ваш агент получает событие, запрошенное действующим агентом . Ваш агент должен ответить, передав разговор представителю-человеку, чтобы пользователь получил необходимую ему помощь.
Людям не обязательно быть доступными 24/7. Настройте доступность вашего агента , чтобы пользователи знали, когда им следует ожидать ответа человека.
Аутентификация пользователей с помощью OAuth
Чтобы проверить личность пользователей и предоставить им персонализированную информацию, аутентифицируйте пользователей в серверных системах через OAuth. Аутентификация с помощью OAuth позволяет агентам быстро получить доступ к пользовательским данным и не позволяет пользователям или агентам включать конфиденциальную информацию (например, имена пользователей или пароли) в разговор. См. Аутентификация с помощью OAuth .
Измерьте CSAT в бизнес-сообщениях
Business Messages измеряет показатели удовлетворенности клиентов (CSAT) с помощью опросов непосредственно в процессе обмена сообщениями. Чтобы запретить пользователям получать несколько опросов, используйте функцию опросов Business Messages. Не внедряйте свои собственные методы измерения CSAT.
Оставайтесь в теме
Не отправляйте сообщения, которые нежелательны или не имеют отношения к текущему разговору. Например,
- Сообщения о продукте или услуге, не связанные с исходным запросом.
- Повторяющиеся сообщения без ответа пользователя
- Чрезмерно длинные сообщения или чрезмерное использование смайлов и URL-адресов.
Используйте идентификатор места, когда он доступен
Для точек входа на основе местоположения сообщения могут содержать placeId в полезных данных контекста. Вы можете использовать его для предоставления информации, которую может запрашивать пользователь, например, инвентаризации в определенном месте. placeId уникально идентифицирует место в базе данных Google Адресов и на платформе Google Maps .
Даже если вы запускаете только точки входа на основе местоположения, обязательно реализуйте стратегию для ситуаций, когда placeId отсутствует. Хотя это и нечасто, но бывают случаи, когда placeId среди других контекстных данных не передается вашему веб-перехватчику.
Реализуйте повторы с экспоненциальной задержкой
При вызове любого API вызов может завершиться неудачей из-за проблем с инфраструктурой, перегрузки службы, ограничений количества кадров в секунду и других ошибок. Чтобы корректно восстановиться после неудачных вызовов API, реализуйте повторные попытки с экспоненциальной задержкой.
Используя повторы с экспоненциальной задержкой, ваша инфраструктура автоматически
- Определяет неудачный вызов API
- Устанавливает начальную продолжительность ожидания и максимальное количество повторов.
- Паузы на время ожидания
- Повторяет вызов API
Оценивает ответ на вызов API:
- В случае успеха переходим к следующему шагу рабочего процесса.
- В случае сбоя увеличивает продолжительность ожидания и возвращается к шагу 3.
- В случае сбоя после максимального количества повторений переход в состояние сбоя
Идеальная продолжительность ожидания и идеальное максимальное количество повторов зависят от варианта использования. Определите эти цифры на основе требований к задержке вашей инфраструктуры и рабочих процессов.
Проверьте наличие дубликатов входящих сообщений
Когда вы проверяете входящие сообщения от пользователей и отвечаете на них, проверьте messageId и убедитесь, что вы еще не получили сообщение и не ответили на него ранее.
В распределенных системах существует два способа отправки сообщений: не более одного раза и не более одного раза. В системах «не более одного раза» система отправляет сообщение один раз, но если на этом пути возникают ошибки сети или связи, сообщение может быть не получено. В системах «хотя бы один раз» система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии ошибок в сети или связи.
Business Messages использует систему «хотя бы один раз». Хотя это может привести к дублированию входящих сообщений, их можно легко устранить, отслеживая строки messageId . Если вы уже получили сообщение, можно смело игнорировать любые дополнительные сообщения, которые вы получаете с тем же messageId .
Когда вы взаимодействуете с пользователями через агентов Business Messages, помните о следующих рекомендациях.
Не предоставляйте и не запрашивайте конфиденциальную информацию
Избегание конфиденциального контента во время чатов обеспечивает безопасность вашей информации и информации ваших клиентов. Конфиденциальная информация включает, помимо прочего:
- Номера кредитных карт
- Номера социального страхования, паспорта или других государственных идентификационных номеров
- Учетные данные для входа, например пароли
Быстро отвечайте пользователям
Медленное или необоснованное время ответа на сообщения пользователей создает неприятные впечатления для ваших клиентов. Убедитесь, что вы спроектировали свою инфраструктуру реагирования так, чтобы постоянно предоставлять своевременные ответы на сообщения пользователей.
Еще хуже, чем медленный ответ, это отсутствие ответа вообще. Убедитесь, что пользователи всегда получают ответы на свои сообщения, независимо от вашей загрузки сообщений. Например, если живой персонал недоступен, отправьте автоматическое сообщение с подтверждением пользователя и укажите примерное время, когда пользователь может ожидать полного ответа.
Google измеряет время ответа (TTR) между сообщениями. Если агент бренда медленно отвечает потребителям, Google удалит кнопки обмена сообщениями бренда.
Когда автоматизация не может выполнить запросы, передайте их людям.
Пользователи расстраиваются, когда автоматизация не реагирует на них должным образом. Вот почему все агенты, которые запускаются из точек входа , управляемых Google (за исключением точки входа Google Рекламы), должны иметь представителей, которые могут вести разговоры, когда автоматизация не может. Перед запуском вам необходимо настроить тип взаимодействия с агентом , включив в него представителей людей.
Если автоматизация не может выполнить запрос пользователя дважды подряд, лучше всего отправить сообщение с предложением запроса живого агента .
Когда пользователь нажимает на это предложение, ваш агент получает событие, запрошенное действующим агентом . Ваш агент должен ответить, передав разговор представителю-человеку, чтобы пользователь получил необходимую ему помощь.
Людям не обязательно быть доступными 24/7. Настройте доступность вашего агента , чтобы пользователи знали, когда им следует ожидать ответа человека.
Аутентификация пользователей с помощью OAuth
Чтобы проверить личность пользователей и предоставить им персонализированную информацию, аутентифицируйте пользователей в серверных системах через OAuth. Аутентификация с помощью OAuth позволяет агентам быстро получить доступ к пользовательским данным и не позволяет пользователям или агентам включать конфиденциальную информацию (например, имена пользователей или пароли) в разговор. См. Аутентификация с помощью OAuth .
Измерьте CSAT в бизнес-сообщениях
Business Messages измеряет показатели удовлетворенности клиентов (CSAT) с помощью опросов непосредственно в процессе обмена сообщениями. Чтобы запретить пользователям получать несколько опросов, используйте функцию опросов Business Messages. Не внедряйте свои собственные методы измерения CSAT.
Оставайтесь в теме
Не отправляйте сообщения, которые нежелательны или не имеют отношения к текущему разговору. Например,
- Сообщения о продукте или услуге, не связанные с исходным запросом.
- Повторяющиеся сообщения без ответа пользователя
- Чрезмерно длинные сообщения или чрезмерное использование смайлов и URL-адресов.
Используйте идентификатор места, когда он доступен
Для точек входа на основе местоположения сообщения могут содержать placeId в полезных данных контекста. Вы можете использовать его для предоставления информации, которую может запрашивать пользователь, например, инвентаризации в определенном месте. placeId уникально идентифицирует место в базе данных Google Адресов и на платформе Google Maps .
Даже если вы запускаете только точки входа на основе местоположения, обязательно реализуйте стратегию для ситуаций, когда placeId отсутствует. Хотя это и не частое явление, но бывают случаи, когда placeId среди других контекстных данных не передается в ваш вебхук.
Реализуйте повторы с экспоненциальной задержкой
При вызове любого API вызов может завершиться неудачей из-за проблем с инфраструктурой, перегрузки службы, ограничений количества кадров в секунду и других ошибок. Чтобы корректно восстановиться после неудачных вызовов API, реализуйте повторные попытки с экспоненциальной задержкой.
Используя повторы с экспоненциальной задержкой, ваша инфраструктура автоматически
- Определяет неудачный вызов API
- Устанавливает начальную продолжительность ожидания и максимальное количество повторов.
- Паузы на время ожидания
- Повторяет вызов API
Оценивает ответ на вызов API:
- В случае успеха переходим к следующему шагу рабочего процесса.
- В случае сбоя увеличивает продолжительность ожидания и возвращается к шагу 3.
- В случае сбоя после максимального количества повторений переход в состояние сбоя
Идеальная продолжительность ожидания и идеальное максимальное количество повторов зависят от варианта использования. Определите эти цифры на основе требований к задержке вашей инфраструктуры и рабочих процессов.
Проверьте наличие дубликатов входящих сообщений
Когда вы проверяете входящие сообщения от пользователей и отвечаете на них, проверьте messageId и убедитесь, что вы еще не получили сообщение и не ответили на него ранее.
В распределенных системах существует два способа отправки сообщений: не более одного раза и не более одного раза. В системах «не более одного раза» система отправляет сообщение один раз, но если на этом пути возникают ошибки сети или связи, сообщение может быть не получено. В системах «хотя бы один раз» система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии ошибок в сети или связи.
Business Messages использует систему «хотя бы один раз». Хотя это может привести к дублированию входящих сообщений, их можно легко устранить, отслеживая строки messageId . Если вы уже получили сообщение, можно смело игнорировать любые дополнительные сообщения, которые вы получаете с тем же messageId .
Когда вы взаимодействуете с пользователями через агентов Business Messages, помните о следующих рекомендациях.
Не предоставляйте и не запрашивайте конфиденциальную информацию
Избегание конфиденциального контента во время чатов обеспечивает безопасность вашей информации и информации ваших клиентов. Конфиденциальная информация включает, помимо прочего:
- Номера кредитных карт
- Номера социального страхования, паспорта или других государственных идентификационных номеров
- Учетные данные для входа, например пароли
Быстро отвечайте пользователям
Медленное или необоснованное время ответа на сообщения пользователей создает неприятные впечатления для ваших клиентов. Убедитесь, что вы спроектировали свою инфраструктуру реагирования так, чтобы постоянно предоставлять своевременные ответы на сообщения пользователей.
Еще хуже, чем медленный ответ, это отсутствие ответа вообще. Убедитесь, что пользователи всегда получают ответы на свои сообщения, независимо от вашей загрузки сообщений. Например, если живой персонал недоступен, отправьте автоматическое сообщение с подтверждением пользователя и укажите примерное время, когда пользователь может ожидать полного ответа.
Google измеряет время ответа (TTR) между сообщениями. Если агент бренда медленно отвечает потребителям, Google удалит кнопки обмена сообщениями бренда.
Когда автоматизация не может выполнить запросы, передайте их людям.
Пользователи расстраиваются, когда автоматизация не реагирует на них должным образом. Вот почему все агенты, которые запускаются из точек входа , управляемых Google (за исключением точки входа Google Рекламы), должны иметь представителей-людей, которые могут вести разговоры, когда автоматизация не может. Перед запуском вам необходимо настроить тип взаимодействия с агентом , включив в него представителей людей.
Если автоматизация не может выполнить запрос пользователя дважды подряд, лучше всего отправить сообщение с предложением запроса живого агента .
Когда пользователь нажимает на это предложение, ваш агент получает событие, запрошенное действующим агентом . Ваш агент должен ответить, передав разговор представителю-человеку, чтобы пользователь получил необходимую ему помощь.
Людям не обязательно быть доступными 24/7. Настройте доступность вашего агента , чтобы пользователи знали, когда им следует ожидать ответа человека.
Аутентификация пользователей с помощью OAuth
Чтобы проверить личность пользователей и предоставить им персонализированную информацию, аутентифицируйте пользователей в серверных системах через OAuth. Аутентификация с помощью OAuth обеспечивает быстрый доступ агентов к пользовательским данным и не позволяет пользователям или агентам включать конфиденциальную информацию (например, имена пользователей или пароли) в разговор. См. Аутентификация с помощью OAuth .
Измерьте CSAT в бизнес-сообщениях
Business Messages измеряет показатели удовлетворенности клиентов (CSAT) с помощью опросов непосредственно в процессе обмена сообщениями. Чтобы запретить пользователям получать несколько опросов, используйте функцию опросов Business Messages. Не внедряйте свои собственные методы измерения CSAT.
Оставайтесь в теме
Не отправляйте сообщения, которые нежелательны или не имеют отношения к текущему разговору. Например,
- Сообщения о продукте или услуге, не связанные с исходным запросом.
- Повторяющиеся сообщения без ответа пользователя
- Чрезмерно длинные сообщения или чрезмерное использование смайлов и URL-адресов.
Используйте идентификатор места, когда он доступен
Для точек входа на основе местоположения сообщения могут содержать placeId в полезных данных контекста. Вы можете использовать его для предоставления информации, которую может запрашивать пользователь, например, инвентаризации в определенном месте. placeId уникально идентифицирует место в базе данных Google Адресов и на платформе Google Maps .
Даже если вы запускаете только точки входа на основе местоположения, обязательно реализуйте стратегию для ситуаций, когда placeId отсутствует. Хотя это и нечасто, но бывают случаи, когда placeId среди других контекстных данных не передается вашему веб-перехватчику.
Реализуйте повторы с экспоненциальной задержкой
При вызове любого API вызов может завершиться неудачей из-за проблем с инфраструктурой, перегрузки службы, ограничений количества кадров в секунду и других ошибок. Чтобы корректно восстановиться после неудачных вызовов API, реализуйте повторные попытки с экспоненциальной задержкой.
Используя повторы с экспоненциальной задержкой, ваша инфраструктура автоматически
- Определяет неудачный вызов API
- Устанавливает начальную продолжительность ожидания и максимальное количество повторов.
- Паузы на время ожидания
- Повторяет вызов API
Оценивает ответ на вызов API:
- В случае успеха переходим к следующему шагу рабочего процесса.
- В случае сбоя увеличивает продолжительность ожидания и возвращается к шагу 3.
- В случае сбоя после максимального количества повторений переход в состояние сбоя
Идеальная продолжительность ожидания и идеальное максимальное количество повторов зависят от варианта использования. Определите эти цифры на основе требований к задержке вашей инфраструктуры и рабочих процессов.
Проверьте наличие дубликатов входящих сообщений
Когда вы проверяете входящие сообщения от пользователей и отвечаете на них, проверьте messageId и убедитесь, что вы еще не получили сообщение и не ответили на него ранее.
В распределенных системах существует два способа отправки сообщений: не более одного раза и не более одного раза. В системах «не более одного раза» система отправляет сообщение один раз, но если на этом пути возникают ошибки сети или связи, сообщение может быть не получено. В системах «хотя бы один раз» система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии ошибок в сети или связи.
Business Messages использует систему «хотя бы один раз». Хотя это может привести к дублированию входящих сообщений, их можно легко устранить, отслеживая строки messageId . Если вы уже получили сообщение, можно смело игнорировать любые дополнительные сообщения, которые вы получаете с тем же messageId .
Когда вы взаимодействуете с пользователями через агентов Business Messages, помните о следующих рекомендациях.
Не предоставляйте и не запрашивайте конфиденциальную информацию
Избегание конфиденциального контента во время чатов обеспечивает безопасность вашей информации и информации ваших клиентов. Конфиденциальная информация включает, помимо прочего:
- Номера кредитных карт
- Номера социального страхования, паспорта или других государственных идентификационных номеров
- Учетные данные для входа, например пароли
Быстро отвечайте пользователям
Медленное или необоснованное время ответа на сообщения пользователей создает неприятные впечатления для ваших клиентов. Убедитесь, что вы спроектировали свою инфраструктуру реагирования так, чтобы постоянно предоставлять своевременные ответы на сообщения пользователей.
Еще хуже, чем медленный ответ, это отсутствие ответа вообще. Убедитесь, что пользователи всегда получают ответы на свои сообщения, независимо от вашей загрузки сообщений. Например, если живой персонал недоступен, отправьте автоматическое сообщение с подтверждением пользователя и укажите примерное время, когда пользователь может ожидать полного ответа.
Google измеряет время ответа (TTR) между сообщениями. Если агент бренда медленно отвечает потребителям, Google удалит кнопки обмена сообщениями бренда.
Когда автоматизация не может выполнить запросы, передайте их людям.
Пользователи расстраиваются, когда автоматизация не реагирует на них должным образом. Вот почему все агенты, которые запускаются из точек входа , управляемых Google (за исключением точки входа Google Рекламы), должны иметь представителей, которые могут вести разговоры, когда автоматизация не может. Перед запуском вам необходимо настроить тип взаимодействия с агентом , включив в него представителей людей.
Если автоматизация не может выполнить запрос пользователя дважды подряд, лучше всего отправить сообщение с предложением запроса живого агента .
Когда пользователь нажимает на это предложение, ваш агент получает событие, запрошенное действующим агентом . Ваш агент должен ответить, передав разговор представителю-человеку, чтобы пользователь получил необходимую ему помощь.
Людям не обязательно быть доступными 24/7. Настройте доступность вашего агента , чтобы пользователи знали, когда им следует ожидать ответа человека.
Аутентификация пользователей с помощью OAuth
Чтобы проверить личность пользователей и предоставить им персонализированную информацию, аутентифицируйте пользователей в серверных системах через OAuth. Аутентификация с помощью OAuth позволяет агентам быстро получить доступ к пользовательским данным и не позволяет пользователям или агентам включать конфиденциальную информацию (например, имена пользователей или пароли) в разговор. См. Аутентификация с помощью OAuth .
Измерьте CSAT в бизнес-сообщениях
Business Messages измеряет показатели удовлетворенности клиентов (CSAT) с помощью опросов непосредственно в процессе обмена сообщениями. Чтобы запретить пользователям получать несколько опросов, используйте функцию опросов Business Messages. Не внедряйте свои собственные методы измерения CSAT.
Оставайтесь в теме
Не отправляйте сообщения, которые нежелательны или не имеют отношения к текущему разговору. Например,
- Сообщения о продукте или услуге, не связанные с исходным запросом.
- Повторяющиеся сообщения без ответа пользователя
- Чрезмерно длинные сообщения или чрезмерное использование смайлов и URL-адресов.
Используйте идентификатор места, когда он доступен
Для точек входа на основе местоположения сообщения могут содержать placeId в полезных данных контекста. Вы можете использовать его для предоставления информации, которую может запрашивать пользователь, например, инвентаризации в определенном месте. placeId уникально идентифицирует место в базе данных Google Адресов и на платформе Google Maps .
Даже если вы запускаете только точки входа на основе местоположения, обязательно реализуйте стратегию для ситуаций, когда placeId отсутствует. Хотя это и не распространено, но бывают случаи, когда placeId среди других контекстных данных не передается в ваш вебхук.
Реализуйте повторы с экспоненциальной задержкой
При вызове любого API вызов может завершиться неудачей из-за проблем с инфраструктурой, перегрузки службы, ограничений количества кадров в секунду и других ошибок. Чтобы корректно восстановиться после неудачных вызовов API, реализуйте повторные попытки с экспоненциальной задержкой.
Используя повторы с экспоненциальной задержкой, ваша инфраструктура автоматически
- Определяет неудачный вызов API
- Устанавливает начальную продолжительность ожидания и максимальное количество повторов.
- Паузы на время ожидания
- Повторяет вызов API
Оценивает ответ на вызов API:
- В случае успеха переходим к следующему шагу рабочего процесса.
- В случае сбоя увеличивает продолжительность ожидания и возвращается к шагу 3.
- В случае сбоя после максимального количества повторов переход в состояние сбоя
Идеальная продолжительность ожидания и идеальное максимальное количество повторов зависят от варианта использования. Определите эти цифры на основе требований к задержке вашей инфраструктуры и рабочих процессов.
Проверьте наличие дубликатов входящих сообщений
Когда вы проверяете входящие сообщения от пользователей и отвечаете на них, проверьте messageId и убедитесь, что вы еще не получили сообщение и не ответили на него ранее.
В распределенных системах существует два способа отправки сообщений: не более одного раза и не более одного раза. В системах «не более одного раза» система отправляет сообщение один раз, но если на этом пути возникают ошибки сети или связи, сообщение может быть не получено. В системах «хотя бы один раз» система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии ошибок в сети или связи.
Business Messages использует систему «хотя бы один раз». Хотя это может привести к дублированию входящих сообщений, их можно легко устранить, отслеживая строки messageId . Если вы уже получили сообщение, можно смело игнорировать любые дополнительные сообщения, которые вы получаете с тем же messageId .