Grok Bot und Brevo: Produktfeedback bis zur bestätigten Rückmeldung verfolgen

Ein Supportticket kann „erledigt“ heißen, obwohl die Kundin oder der Kunde die Funktion nicht nutzen kann. Bei einem hypothetischen CSV-Exportwunsch ist der Code für Ticket T-104 zusammengeführt, die Freischaltung aber noch aus. „Deine Funktion ist live“ wäre eine falsche Zusage.

Verbinde eine Anfrage mit einer bestätigten Version und einer erreichbaren Person. Das GTM-Loop-Closer-Beispiel von xAI beschreibt, wie Zusagen gefunden, Belege gezeigt und Antworten vorbereitet werden. Hier gilt ein strengerer Test: Eine zuständige Produktperson muss bestätigen, was ausgeliefert wurde und wer es nutzen kann.

Beginne erst mit einem Beleg für die Freigabe

Nutze den Produktversionsdatensatz als Auslöser, nicht eine Änderung des Ticketstatus. Er braucht eine stabile feature_id, release_id, die ausgelieferte Funktion, das Versionsdatum, den Freischaltstatus und eine namentlich zuständige Person. Diese muss prüfen, ob die Funktion für das Konto oder den Tarif der anfragenden Person verfügbar ist. Zusammengeführter Code, eine Demo in der Testumgebung oder geplante Versionshinweise genügen nicht.

Ordne die Anfrage anhand der Funktions-ID der Version zu und über die im Supportsystem gespeicherte Kontakt-ID der anfragenden Person. Speichere nur Zuordnung und Status. Grok Bot braucht nicht das gesamte Postfach oder den Katalog. Fehlt eine ID, gib einen Prüfpunkt aus, statt anhand eines ähnlichen Namens zu raten.

Eingabe	Mindestfelder	Was zu prüfen ist
Anfrage	Ticket-ID, Funktions-ID, Anfragedatum, Kontakt-ID der anfragenden Person	Die Person hat tatsächlich diese Funktion angefragt
Version	Versions-ID, Funktions-ID, ausgelieferte Funktion, Verfügbarkeit, Freigabe durch die zuständige Person	Dieses Konto kann sie jetzt nutzen
Kontakt	Kontakt-ID, freigegebener Supportweg, Sperrstatus	Diese Person darf diese Art Antwort erhalten

Eine Anfrage ist keine Marketingeinwilligung. Nutze den freigegebenen Supportweg für eine sachliche Antwort auf genau diese Anfrage. Bewirbt der Entwurf andere Funktionen, enthält ein Zusatzangebot oder richtet sich an Personen ohne Anfrage, behandle ihn als eigene Marketingkampagne mit eigenen Eignungsregeln. Beachte Abmeldungen und Sperren für den gewählten Kanal. Unser Double-Opt-in-Leitfaden erklärt, warum ein Ticket keinen Abonnementdatensatz ersetzt.

Entwirf eine Antwort mit einem begrenzten Prompt

Ein hypothetisches Ergebnis ordnet T-104 der Funktion F-7 und Version R-22 zu, findet aber die Freischaltung ausgesetzt. Warte und versende nichts.

Kopiere diesen Prompt nach Bereitstellung der freigegebenen Datensätze:

Prüfe nur die Anfrage-, Versions- und Kontaktdatensätze, die ich bereitstelle. Gleiche anhand stabiler Funktions- und Kontakt-IDs ab, nicht allein anhand der Formulierung. Zeige je Kandidat Ticket-ID, Funktions-ID, Versions-ID, Freigabe der zuständigen Person, Verfügbarkeit für das Konto, freigegebenen Kommunikationszweck und Sperrstatus. Kennzeichne fehlende oder widersprüchliche Belege als blockiert. Entwirf eine kurze sachliche Antwort nur für eine bestätigte, verfügbare Version. Beschreibe anhand der bereitgestellten Fakten, was sich geändert hat, wo die Kundschaft es nutzen kann und wo sie Hilfe erhält. Leite keine Marketingeinwilligung ab, ergänze keine Werbeaussagen, erstelle oder ändere keine Kontakte, versende keine Nachricht und schließe kein Ticket. Gib Belegtabelle und Entwurf hier zur Prüfung aus.

Prüfung: Eine zuständige Produktperson gleicht den Entwurf mit dem Versionsdatensatz ab und testet die Verfügbarkeit im anfragenden Konto. Die zuständige Supportperson prüft Empfängeridentität und Kommunikationszweck. Schlägt eine Prüfung fehl, bleibt der Entwurf im Chat. Der Einstiegsleitfaden zu Grok Bot und Brevo erklärt die dokumentierte MCP-Verbindung und warum verfügbare Operationen weiterhin geprüft werden müssen; dieser Workflow wurde nicht in einem Grok-Bot-Konto ausgeführt.

Einmal senden und den Beleg erfassen

Berechne vor dem Einreihen einer freigegebenen Nachricht einen Duplikatschlüssel aus feature_id + contact_id + release_id und reserviere ihn atomar in einem dauerhaften Protokoll. Ein bereits reservierter, ausstehender, unbekannter oder erfolgreicher Schlüssel verhindert weiteres Einreihen. Zwei Prozesse dürfen keine getrennte Lesen-dann-Schreiben-Prüfung bestehen. Nach einer Zeitüberschreitung gleiche Ereignis- und Anbieterbelege ab, bevor du eine Wiederholung erwägst; eine fehlende Antwort beweist keine Nichtzustellung.

Richte nach der Prüfung den freigegebenen Weg in Brevo ein. Wenn dein Konto unter Automations > Workflows > Create an automation einen Auslöser für benutzerdefinierte Ereignisse und eine E-Mail-Aktion bietet, ordne dein vorgeschlagenes Ereignis feature_followup_approved einer für den Supportzweck freigegebenen Vorlage zu. Das Ereignis braucht eine geprüfte Kontakt-ID; Funktions- und Versions-IDs sind vorgeschlagene Ereigniseigenschaften, keine Brevo-Standardfelder. Teste vor der Aktivierung mit einem internen Kontakt. Löse erst nach Freigabe und erfolgreicher Schlüsselreservierung genau ein Ereignis aus. Andernfalls antworte manuell über den Support. Brevo dokumentiert benutzerdefinierte Ereignisse und die Einrichtung von Workflows; prüfe verfügbare Aktionen in deinem Konto. Grok Bots Entwurf erlaubt keine Ausführung. Der Brevo-API-Leitfaden behandelt den gesonderten API-Weg. Erfasse Ereignisannahme und Nachrichten-Versandbeleg getrennt. Ein angenommenes Ereignis beweist keine versendete E-Mail. Speichere genaue empfangende Person, freigegebenen Text, Versionsbeleg, Zweck, Kanal, Anbieter-Versand-ID und Zeitstempel. Markiere das Supportticket erst nach einem bestätigten Versandbeleg oder einer dokumentierten manuellen Supportantwort als nachbereitet. Brevos MCP-Dokumentation belegt eine mögliche Integrationsoberfläche, nicht die Verfügbarkeit jeder Schreiboperation oder Berechtigung in deinem Client.

Lege für jede Version einen Beobachtungsstichtag fest, etwa sieben Tage nach bestätigter Verfügbarkeit. Miss dann den Abschluss als zulässige Anfragen mit genau einer bestätigten Rückmeldung geteilt durch zulässige Anfragen zu dieser Version. Zähle blockierte und unerreichbare Anfragen separat. Zustellstatus und Antworten helfen, Fehler zu finden; Öffnungen beweisen weder, dass die Person die Funktion gesehen noch genutzt hat. Eine Version ohne geprüfte empfangende Person bleibt offene Arbeit. Dieselbe Belegdisziplin gilt für ein Kampagnenexperiment, auch wenn dessen Ergebnis anders gemessen wird.