지원 티켓에 ‘완료’라고 적혀 있어도 고객이 기능을 사용하지 못할 수 있습니다. 가상의 CSV 내보내기 요청 T-104에서는 코드가 병합됐지만 기능 출시가 꺼져 있습니다. ‘요청하신 기능을 이제 사용할 수 있습니다’라고 말하면 지키지 못한 약속이 됩니다.
한 요청을 확인된 한 릴리스와 연락 가능한 한 사람에게 연결합니다. xAI의 GTM Loop Closer 예시는 약속을 찾고, 증거를 보여 주고, 답장을 준비하는 방법을 설명합니다. 여기서는 더 엄격하게, 제품 담당자가 무엇이 출시됐고 누가 사용할 수 있는지 확인해야 합니다.
출시 증거가 있을 때 시작합니다
트리거는 티켓 상태 변경이 아니라 제품 릴리스 기록입니다. 안정적인 feature_id, release_id, 출시된 동작, 출시일, 공개 상태, 지정 담당자가 필요합니다. 담당자는 요청 고객의 계정이나 요금제에서 기능을 사용할 수 있음을 확인해야 합니다. 코드 병합, 시험 환경 시연, 예정된 릴리스 노트만으로는 부족합니다.
요청 기록과 릴리스는 기능 ID로, 요청과 고객은 지원 시스템에 보관된 연락처 ID로 연결합니다. 매핑과 상태만 저장합니다. Grok Bot에 전체 받은편지함이나 카탈로그는 필요하지 않습니다. 어느 ID든 없으면 비슷한 이름으로 추측하지 말고 검토 항목으로 돌려줍니다.
| 입력 | 최소 필드 | 확인할 사항 |
|---|---|---|
| 요청 | 티켓 ID, 기능 ID, 요청일, 요청자의 연락처 ID | 해당 사람이 실제로 기능을 요청했는지 |
| 릴리스 | 릴리스 ID, 기능 ID, 출시된 동작, 사용 가능 여부, 담당자 승인 | 이 계정에서 지금 사용할 수 있는지 |
| 연락처 | 연락처 ID, 승인된 지원 연락 경로, 발송 제한 상태 | 이 사람에게 이런 종류의 답장을 보낼 수 있는지 |
요청은 마케팅 동의가 아닙니다. 해당 요청에 대한 사실 중심 답장에는 승인된 지원 연락 경로를 사용합니다. 초안이 다른 기능을 홍보하거나 상위 상품 판매를 유도하거나 요청하지 않은 사람을 대상으로 한다면 별도 적격 규칙이 있는 마케팅 캠페인으로 다룹니다. 선택한 채널의 수신 거부와 발송 제한을 지킵니다. 이중 수신 동의 가이드는 티켓이 구독 기록을 대신할 수 없는 이유를 설명합니다.
범위가 정해진 프롬프트로 답장 하나를 만듭니다
가상의 결과가 T-104를 F-7, R-22와 연결하지만 공개 상태가 꺼져 있음을 발견합니다. 기다리고 보내지 마세요.
승인된 기록을 제공한 뒤 다음 프롬프트를 복사하세요.
제가 제공하는 요청, 릴리스, 연락처 기록만 조사하세요. 문구의 유사성이 아니라 안정적인 기능 ID와 연락처 ID로 매칭하세요. 후보마다 티켓 ID, 기능 ID, 릴리스 ID, 담당자 승인, 해당 계정의 사용 가능 여부, 승인된 연락 목적, 발송 제한 상태를 보여 주세요. 빠지거나 충돌하는 증거는 보류로 표시하세요. 확인됐고 사용 가능한 릴리스에 대해서만 짧고 사실적인 답장을 작성하세요. 제공된 사실만으로 바뀐 내용, 고객이 어디서 사용하는지, 어디서 도움받는지 말하세요. 마케팅 동의를 추측하거나 홍보 문구를 추가하거나 연락처를 만들거나 변경하거나 메시지를 보내거나 티켓을 닫지 마세요. 증거 표와 초안을 검토용으로 여기에 반환하세요.
확인: 제품 담당자가 초안을 릴리스 기록과 비교하고 요청 계정에서 사용 가능성을 시험합니다. 지원 담당자가 수신자의 신원과 연락 목적을 확인합니다. 하나라도 실패하면 초안은 채팅에 남깁니다. Grok Bot과 Brevo 시작 가이드는 문서화된 MCP 연결과 실제 사용 가능한 작업을 다시 확인해야 하는 이유를 설명합니다. 이 구체적 워크플로는 Grok Bot 계정에서 실행하지 않았습니다.
한 번 보내고 전송 증거를 기록합니다
승인된 발송을 대기열에 넣기 전에 feature_id + contact_id + release_id로 중복 방지 키를 계산하고 영속 장부에 원자적으로 예약합니다. 예약됨, 처리 중, 상태 불명, 성공 상태의 키는 다시 대기열에 넣지 못하게 합니다. 두 작업자가 별도의 읽기 후 쓰기 검사를 함께 통과해서는 안 됩니다. 시간 초과 뒤에는 재시도를 고려하기 전에 이벤트와 제공업체의 전송 기록을 대조합니다. 응답이 없다고 미전달이 증명되는 것은 아닙니다.
검토 후 Brevo에서 승인된 경로를 설정합니다. Automations > Workflows > Create an automation에서 계정이 사용자 지정 이벤트 트리거와 이메일 작업을 제공한다면 제안한 feature_followup_approved 이벤트를 승인된 지원 목적 템플릿에 매핑합니다. 이벤트에는 확인된 연락처 식별자가 필요합니다. 기능 ID와 릴리스 ID는 제안하는 이벤트 속성이지 Brevo 기본값이 아닙니다. 활성화 전 내부 연락처로 시험합니다. 승인과 키 예약이 성공한 후에만 이벤트를 한 번 내보냅니다. 그렇지 않으면 지원 담당자가 수동으로 답합니다. Brevo는 사용자 지정 이벤트와 워크플로 설정을 문서화했습니다. 계정에서 실제 작업을 확인하세요. Grok Bot 초안은 실행 허가가 아닙니다. Brevo API 가이드는 별도 API 경로를 다룹니다. 이벤트 수락과 메시지 발송 기록을 따로 저장합니다. 이벤트가 수락됐다는 사실이 이메일 발송을 증명하지 않습니다. 정확한 수신자, 승인된 문안, 릴리스 증거, 목적, 채널, 제공업체 발송 ID, 시각을 기록합니다. 확인된 발송 기록이나 문서화된 수동 지원 답장이 있어야 지원 티켓을 후속 조치 완료로 표시합니다. Brevo의 MCP 문서는 연동 가능성을 설명할 뿐, 사용 중인 클라이언트에서 모든 쓰기 작업이나 권한이 가능하다는 뜻이 아닙니다.
릴리스마다 관찰 마감 시점을 정합니다. 예를 들어 담당자가 사용 가능하다고 확인한 뒤 7일입니다. 그때 완료율은 한 번의 확인된 후속 조치가 있는 적격 요청 수를 해당 릴리스의 적격 요청 수로 나눈 값입니다. 보류와 연락 불가 요청은 각각 따로 셉니다. 전달 상태와 고객 답장은 실패를 찾는 데 도움이 되지만 열람은 고객이 기능을 보거나 사용했다는 증거가 아닙니다. 확인된 수신자가 없는 릴리스는 여전히 남은 일입니다. 다른 성과를 재는 캠페인 실험에도 같은 증거 원칙이 적용됩니다.
자주 묻는 질문
요청 기능은 언제 고객에게 안내할 준비가 되나요?
담당자가 릴리스 ID, 그 고객 계정의 사용 가능 여부, 실제 출시된 동작을 확인한 뒤에만 가능합니다. 닫힌 티켓, 병합된 코드 또는 초안 릴리스 노트는 고객이 사용할 수 있다는 증거가 아닙니다.
지원 요청으로 마케팅 메일을 보내도 되나요?
안 됩니다. 해당 고객 요청에 대한 사실 중심 답장은 승인된 지원 연락 절차로 보냅니다. 더 넓은 홍보 캠페인에는 별도의 허용된 대상과 구독 근거가 필요하며 티켓이 이를 만들지는 않습니다.
Grok Bot이 Brevo로 출시 알림을 자동 발송할 수 있나요?
이 가이드는 Grok Bot으로 증거를 매칭하고 답장 초안을 만듭니다. Brevo 쓰기나 발송에는 별도로 검증한 연결, 허가 확인, 승인이 필요합니다. 문서화된 MCP 호환성을 여기서 실계정으로 시험하지는 않았습니다.