요구사항 및 가이드라인

Business Messages 에이전트를 통해 사용자와 상호작용할 때 다음 권장사항에 유의하세요.

민감한 정보 제공 또는 요청 안함

채팅 중 민감한 콘텐츠를 피하면 고객과 고객의 정보를 안전하게 보호할 수 있습니다. 민감한 정보(이에 국한되지 않음)

  • 신용카드 번호
  • 주민등록번호, 여권번호 또는 기타 국가 발급 신분증 번호
  • 로그인 사용자 인증 정보(예: 비밀번호)

사용자의 신속한 응답

사용자 메시지에 대한 느리거나 비합리적인 응답 시간은 고객에게 좋지 않은 경험을 제공합니다. 사용자 메시지에 적시에 응답을 제공하도록 응답 인프라를 설계해야 합니다.

느린 응답보다 더 나쁜 것은 전혀 응답이 없다는 것입니다. 메시지 로드에 관계없이 사용자가 항상 메시지에 대한 응답을 받을 수 있어야 합니다. 예를 들어 실시간 담당 직원을 사용할 수 없는 경우 사용자를 확인하는 자동 메시지를 전송하고 사용자가 완전한 응답을 받을 수 있을 것으로 예상되는 시기를 포함합니다.

Google은 메시지 간의 응답 시간 (TTR)을 측정합니다. 브랜드의 상담사가 소비자 반응 속도가 느리면 Google에서 브랜드의 메시지 버튼을 삭제합니다.

자동화가 요청을 처리할 수 없는 경우 의사에게 전달

자동화가 제대로 응답하지 않으면 사용자는 불만을 느낍니다. 이러한 이유로 Google에서 관리하는 진입점(Google Ads 진입점 제외)에서 실행되는 모든 에이전트에는 자동화를 사용할 수 없을 때 대화를 처리할 수 있는 사람이 있어야 합니다. 출시하기 전에 상담사 상호작용 유형을 담당자를 포함하도록 설정해야 합니다.

자동화가 사용자 요청을 연속으로 두 번 처리할 수 없는 경우 실시간 에이전트 요청 제안이 포함된 메시지를 보내는 것이 가장 좋습니다.

실시간 상담사 요청 제안

사용자가 이 추천을 탭하면 에이전트가 실시간 에이전트 요청 이벤트를 수신합니다. 에이전트가 사용자에게 필요한 도움을 받을 수 있도록 대화를 인간 담당자에게 전달하여 응답해야 합니다.

인간이 24시간 연중무휴로 근무할 필요는 없습니다. 사용자가 언제 인간의 응답을 받을 수 있는지 알 수 있도록 에이전트의 가용성을 설정합니다.

OAuth로 사용자 인증

사용자 ID를 확인하고 사용자에게 맞춤설정된 정보를 제공하려면 OAuth를 통해 백엔드 시스템으로 사용자를 인증합니다. OAuth로 인증하면 에이전트가 사용자 데이터에 빠르게 액세스할 수 있고 사용자 또는 에이전트가 대화에 민감한 정보 (예: 사용자 이름 또는 비밀번호)를 포함하지 못하게 됩니다. OAuth로 인증을 참고하세요.

Business Messages에서 CSAT 측정

Business Messages는 메시지 환경 내에서 직접 설문조사를 통해 고객 만족도 점수 (CSAT)를 측정합니다. 사용자가 여러 설문조사를 받지 못하게 하려면 Business Messages의 설문조사 기능을 사용하세요. 자체 CSAT 측정 기법을 구현하지 마세요.

주제에서 벗어나지 않아야 합니다.

현재 대화와 관련이 없거나 원치 않는 메시지는 보내지 않습니다. 예를 들면 다음과 같습니다.

  • 원래 요청과 관련 없는 제품 또는 서비스에 대한 메시지
  • 사용자 응답이 없는 반복 메시지
  • 메시지가 너무 길거나 이모티콘 및 URL을 과도하게 사용

가능한 경우 장소 ID 활용

위치 기반 진입점의 경우 메시지에 컨텍스트 페이로드의 placeId가 포함될 수 있습니다. 이를 활용하여 특정 위치의 인벤토리와 같이 사용자가 요청할 수 있는 정보를 제공할 수 있습니다. placeId는 Google Places 데이터베이스 및 Google Maps Platform에서 장소를 고유하게 식별합니다.

위치 기반 진입점으로만 출시하더라도 placeId가 없는 상황에 맞는 전략을 구현해야 합니다. 드물지만 다른 컨텍스트 데이터 중 placeId가 웹훅에 전달되지 않는 상황이 있습니다.

지수 백오프로 재시도 구현

API를 호출할 때 인프라 문제, 서비스 과부하, QPS 한도 및 기타 오류로 인해 호출이 실패할 수 있습니다. 실패한 API 호출에서 정상적으로 복구하려면 지수 백오프를 사용하여 재시도를 구현합니다.

지수 백오프로 재시도를 사용하여 인프라 자동 구성

  1. 실패한 API 호출 식별
  2. 초기 대기 시간 및 최대 재시도 횟수를 설정합니다.
  3. 대기 시간 동안 일시중지
  4. API 호출 재시도
  5. API 호출 응답을 평가합니다.

    • 성공하면 워크플로의 다음 단계로 진행
    • 실패하면 대기 시간을 늘리고 3단계로 돌아갑니다.
    • 최대 재시도 횟수 후에 실패한 경우 실패 상태로 전환됩니다.

이상적인 대기 시간 및 이상적인 최대 재시도 횟수는 사용 사례에 따라 다릅니다. 인프라 및 워크플로의 지연 시간 요구사항에 따라 이 수를 결정합니다.

중복 수신 메일 확인

사용자로부터 받은 메시지를 확인하고 응답할 때는 messageId를 확인하고 아직 메시지를 받은 적이 없고 이전에 메시지를 보낸 적이 없는지 확인하세요.

분산 시스템에서는 메시지를 전송하는 방법에는 최대 한 번, 최소 한 번, 두 가지가 있습니다. '최대 1회' 시스템의 경우 메시지가 한 번 전송되지만 네트워크 또는 통신 오류가 발생하는 경우 메시지가 수신되지 않을 수 있습니다. '최소 1회' 시스템의 경우 시스템이 메시지를 여러 번 전송할 수 있지만 네트워크 또는 통신 오류가 있어도 메시지를 수신할 수 있습니다.

Business Messages는 '최소 1회' 시스템을 사용합니다. 이로 인해 수신 메시지가 중복될 수 있지만 messageId 문자열을 추적하여 중복 메시지를 간단하게 삭제할 수 있습니다. 이미 메시지를 받은 경우 동일한 messageId로 수신된 추가 메시지를 무시해도 됩니다.