Grok Bot och Brevo: från produktönskemål till bekräftat kundsvar

Ett supportärende kan visa ”klart” fast kunden inte kan använda funktionen. I ett hypotetiskt önskemål om CSV-export är koden för ärende T-104 sammanslagen, men utrullningen är fortfarande avstängd. ”Din funktion finns nu” vore ett brutet löfte.

Koppla en begäran till en bekräftad lansering och en nåbar person. xAI:s GTM Loop Closer-exempel beskriver hur löften hittas, belägg visas och svar förbereds. Här är kravet striktare: En produktansvarig måste bekräfta vad som levererats och vem som kan använda det.

Börja när lanseringsbevis finns

Använd produktens lanseringspost som utlösare, inte en ändrad ärendestatus. Den behöver stabil feature_id, release_id, levererad funktion, lanseringsdatum, utrullningsstatus och namngiven ansvarig. Den ansvariga måste verifiera att funktionen finns för den begärande kundens konto eller abonnemang. Sammanslagen kod, demo i testmiljö eller planerad versionsnyhet räcker inte.

Matcha begäran till lanseringen med funktions-ID och till kunden med kontakt-ID i supportsystemet. Spara bara koppling och status. Grok Bot behöver inte hela inkorgen eller katalogen. Saknas något ID, lämna en granskningsuppgift i stället för att gissa utifrån liknande namn.

Indata	Minsta fält	Vad du ska kontrollera
Begäran	Ärende-ID, funktions-ID, datum, begärande kontakt-ID	Personen bad faktiskt om denna funktion
Lansering	Lanserings-ID, funktions-ID, levererad funktion, tillgänglighet, ansvarigs godkännande	Kontot kan använda den nu
Kontakt	Kontakt-ID, godkänd supportväg, spärrstatus	Personen får ta emot den här typen av svar

Begäran är inte marknadsföringssamtycke. Använd godkänd supportväg för ett sakligt svar på just begäran. Om utkastet marknadsför andra funktioner, erbjuder merförsäljning eller når personer som aldrig frågade, behandla det som separat kampanj med egna regler för behörighet. Respektera avregistreringar och spärrar för vald kanal. Guiden om dubbel opt-in förklarar varför ett ärende inte ersätter en prenumerationspost.

Skriv ett svar med en avgränsad prompt

Ett hypotetiskt resultat kopplar T-104 till F-7 och R-22 men ser att utrullningen är avstängd. Vänta; skicka inget.

Kopiera denna prompt efter att du gett godkända poster:

Granska bara de poster för begäran, lansering och kontakt som jag ger. Matcha med stabila funktions- och kontakt-ID:n, inte bara ordval. Visa för varje kandidat ärende-ID, funktions-ID, lanserings-ID, ansvarigs godkännande, tillgänglighet för kontot, godkänt kommunikationssyfte och spärrstatus. Markera saknade eller motstridiga belägg som blockerande. Skriv ett kort sakligt svar bara för en bekräftad, tillgänglig lansering. Beskriv vad som ändrades, var kunden kan använda det och var hjälp finns, enbart utifrån givna fakta. Härled inte marknadsföringssamtycke, lägg inte till reklamclaims, skapa eller ändra inte kontakter, skicka inga meddelanden och stäng inga ärenden. Lämna bevistabell och utkast här för granskning.

Kontroll: En produktansvarig jämför utkastet med lanseringsposten och testar tillgänglighet i det begärande kontot. En supportansvarig kontrollerar mottagarens identitet och kommunikationssyftet. Om något misslyckas stannar utkastet i chatten. Startguiden för Grok Bot och Brevo beskriver den dokumenterade MCP-anslutningen och varför tillgängliga åtgärder ändå måste undersökas; det här flödet har inte körts i ett Grok Bot-konto.

Skicka en gång och spara kvittot

Innan ett godkänt utskick läggs i kö beräknar du en dubblettnyckel från feature_id + contact_id + release_id och reserverar den atomärt i en varaktig logg. En redan reserverad, väntande, okänd eller lyckad nyckel blockerar ny köläggning. Två processer får inte båda klara en separat läs-och-skrivkontroll. Efter tidsgräns, stäm av händelse- och leverantörskvitton innan nytt försök övervägs; uteblivet svar bevisar inte att mejlet inte levererades.

Ställ in den godkända vägen i Brevo efter granskning. Om kontot under Automations > Workflows > Create an automation har utlösare för anpassad händelse och e-poståtgärd, koppla din föreslagna feature_followup_approved till en mall godkänd för support. Händelsen behöver verifierat kontakt-ID; funktions- och lanserings-ID:n är föreslagna händelseegenskaper, inte Brevo-standarder. Testa med intern kontakt före aktivering. Skicka en enda händelse efter godkännande och lyckad nyckelreservation. Annars svarar support manuellt. Brevo dokumenterar anpassade händelser och uppsättning av flöden; granska tillgängliga åtgärder i kontot. Grok Bots utkast ger inte tillstånd att köra dem. Brevo API-guiden beskriver den separata API-vägen. Registrera godkännande av händelsen skilt från meddelandets sändningskvitto. En godkänd händelse bevisar inte att mejlet skickades. Spara exakt mottagare, godkänd text, lanseringsbevis, syfte, kanal, leverantörens sändnings-ID och tid. Markera supportärendet som uppföljt först efter bekräftat sändningskvitto eller dokumenterat manuellt supportsvar. Brevos MCP-dokumentation visar en möjlig integrationsyta, inte att varje skrivåtgärd eller behörighet finns i din klient.

Sätt en observationsgräns för varje lansering, exempelvis sju dagar efter ansvarigs bekräftelse av tillgänglighet. Mät då slutförandet som berättigade begäranden med en bekräftad uppföljning delat med berättigade begäranden om lanseringen. Räkna blockerade och onåbara begäranden separat. Leveransstatus och kundsvar hjälper dig hitta fel; öppningar bevisar inte att kunden såg eller använde funktionen. En lansering utan verifierad mottagare är fortfarande öppet arbete. Samma beviskrav gäller ett kampanjexperiment, även om utfallet mäts annorlunda.