Grok BotとBrevoで製品への要望に応える

サポートチケットが「完了」でも、顧客が機能を使えないことがあります。仮の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とリリースIDは提案するイベントの属性であり、Brevoの既定値ではありません。有効化前に社内連絡先で試します。承認とキー予約の成功後に限り、イベントを一回だけ発行します。それ以外はサポート担当者が手動で返信します。Brevoは独自イベントとワークフローの設定を文書化しています。アカウントで利用できるアクションを確認してください。Grok Botの下書きは実行許可ではありません。Brevo APIガイドは別のAPI経路を扱います。イベントの受け付けとメッセージの送信記録は別々に残します。イベントを受け付けたことはメールが送られた証拠ではありません。正確な宛先、承認済みの文章、リリースの証拠、目的、チャネル、事業者の送信ID、時刻を記録します。送信の受領を確認するか、手動のサポート返信を文書化してから、チケットを「フォロー済み」にします。BrevoのMCP文書が示すのは利用可能な接続面であり、使っているクライアントで全ての書き込み操作や権限が得られるという意味ではありません。

各リリースの観測終了時点を決めます。たとえば担当者が利用可能と確認してから7日です。その時点で、確認済みのフォローアップが一件ある対象依頼数を、そのリリースの対象依頼数で割って完了率を測ります。保留中と連絡不能の依頼は別々に数えます。配信状態と顧客の返信は失敗の発見に役立ちますが、開封は顧客が機能を見たり使ったりした証拠にはなりません。確認済みの宛先がないリリースは、まだ残作業です。別の成果を測るキャンペーン実験にも、同じ証拠管理が必要です。