Grok Bot a Brevo: uzavřete smyčku produktové zpětné vazby

Požadavek na podporu může mít stav „hotovo“, zatímco zákazník funkci ještě nemůže použít. U hypotetického požadavku na export CSV, tiket T-104, je kód sloučen, ale zpřístupnění zůstává vypnuté. Věta „Vaše funkce je nyní dostupná“ by byla porušeným slibem.

Propojte jeden požadavek s jedním potvrzeným vydáním a jednou dosažitelnou osobou. Příklad GTM Loop Closer od xAI popisuje nalezení závazků, doložení důkazů a přípravu odpovědi. Zde je kontrola přísnější: vlastník produktu musí potvrdit, co bylo vydáno a kdo to může používat.

Začněte až s důkazem o vydání

Spouštěčem je záznam o vydání produktu, nikoli změna stavu tiketu. Potřebuje stabilní feature_id, release_id, popis skutečně vydaného chování, datum vydání, stav zpřístupnění a určeného vlastníka. Vlastník musí ověřit, že funkce je dostupná účtu nebo tarifu zákazníka, který o ni požádal. Sloučená změna kódu, ukázka v testovacím prostředí ani plánovaná poznámka k vydání nestačí.

Požadavek s vydáním propojte podle ID funkce a požadavek se zákazníkem podle ID kontaktu v systému podpory. Ukládejte jen mapování a stav. Grok Bot nepotřebuje celou schránku ani katalog. Pokud některé ID chybí, vraťte položku ke kontrole místo hádání podle podobného názvu.

Vstup	Minimální pole	Co ověřit
Požadavek	ID tiketu, ID funkce, datum požadavku, ID kontaktu žadatele	Tento člověk o funkci skutečně požádal
Vydání	ID vydání, ID funkce, vydané chování, dostupnost, schválení vlastníkem	Tento účet ji nyní může používat
Kontakt	ID kontaktu, schválený kanál podpory, stav potlačení	Tento člověk smí dostat takovou odpověď

Požadavek není marketingový souhlas. Pro věcnou odpověď na konkrétní požadavek použijte schválený kanál podpory. Pokud návrh propaguje další funkce, nabízí doplňkový prodej nebo cílí na lidi, kteří se neptali, považujte jej za samostatnou marketingovou kampaň s vlastními pravidly způsobilosti. Respektujte odhlášení a potlačení pro zvolený kanál. Náš průvodce dvojitým potvrzením vysvětluje, proč tiket nenahrazuje záznam o odběru.

Připravte jednu odpověď s omezeným pokynem

Hypotetický výstup spojuje T-104 s F-7 a R-22, ale zjišťuje, že zpřístupnění je vypnuté. Počkejte; nic neodesílejte.

Po dodání schválených záznamů zkopírujte tento pokyn:

Prohlédněte pouze záznamy o požadavku, vydání a kontaktu, které dodám. Párujte podle stabilního ID funkce a kontaktu, ne pouze podle podobného znění. U každého kandidáta uveďte ID tiketu, funkce a vydání, schválení vlastníkem, dostupnost pro účet, schválený účel komunikace a stav potlačení. Chybějící nebo rozporné důkazy označte za blokující. Krátkou věcnou odpověď připravte pouze pro potvrzené dostupné vydání. Popište, co se změnilo, kde to zákazník může použít a kde získá pomoc, pouze z dodaných faktů. Neodvozujte marketingový souhlas, nepřidávejte reklamní tvrzení, nevytvářejte ani neměňte kontakty, neodesílejte zprávu ani neuzavírejte tiket. Tabulku důkazů a návrh vraťte sem ke kontrole.

Kontrola: vlastník porovná návrh se záznamem vydání a vyzkouší dostupnost v účtu žádajícího zákazníka. Pracovník podpory ověří totožnost příjemce a účel komunikace. Pokud některá kontrola nevyjde, nechte návrh v chatu. Úvodní průvodce Grok Bot a Brevo vysvětluje dokumentované propojení MCP i nutnost zkontrolovat dostupné operace; tento konkrétní postup jsme v účtu Grok Bot nespustili.

Odešlete jednou a uložte potvrzení

Před zařazením schváleného odeslání do fronty vypočítejte deduplikační klíč z feature_id + contact_id + release_id a atomicky jej rezervujte v trvalém registru. Dříve rezervovaný klíč, ať čekající, s neznámým stavem či úspěšný, brání dalšímu zařazení. Dva procesy nesmějí projít oddělenou kontrolou čtení a následným zápisem. Po vypršení časového limitu srovnejte událost a potvrzení poskytovatele, než zvážíte opakování; chybějící odpověď nedokazuje nedoručení.

Po kontrole nastavte schválenou cestu v Brevo. V Automations > Workflows > Create an automation, pokud Váš účet nabízí spouštěč vlastní události a e-mailovou akci, namapujte navrženou událost feature_followup_approved na schválenou šablonu pro účel podpory. Událost potřebuje ověřený identifikátor kontaktu; ID funkce a vydání jsou Vámi navržené vlastnosti události, nikoli výchozí pole Brevo. Před aktivací vyzkoušejte interní kontakt. Jednu událost vyšlete až po schválení a úspěšné rezervaci klíče. Jinak odpovězte ručně přes podporu. Brevo dokumentuje vlastní události a nastavení workflow; dostupné akce zkontrolujte ve svém účtu. Návrh Grok Bot neopravňuje k provedení. Průvodce Brevo API popisuje samostatnou cestu API. Přijetí události evidujte odděleně od potvrzení odeslání zprávy. Přijatá událost není důkazem odeslaného e-mailu. Uložte přesného příjemce, schválený text, důkaz vydání, účel, kanál, ID odeslání od poskytovatele a čas. Tiket označte za vyřízený následnou komunikací až po potvrzeném odeslání nebo zdokumentované ruční odpovědi podpory. Dokumentace Brevo MCP ukazuje možnou integraci, nikoli dostupnost všech zapisovacích operací či oprávnění ve Vašem klientovi.

Pro každé vydání stanovte konec pozorování, například sedm dní od potvrzení dostupnosti vlastníkem. K tomuto okamžiku měřte dokončení jako způsobilé požadavky s jednou potvrzenou následnou zprávou dělené způsobilými požadavky pro dané vydání. Blokované a nedosažitelné požadavky vykazujte zvlášť. Stav doručení a odpovědi zákazníků pomáhají najít chyby; otevření neprokazuje, že zákazník funkci viděl nebo použil. Vydání bez ověřeného příjemce zůstává nevyřešenou prací. Stejná kázeň důkazů platí i pro experiment s kampaní, i když jeho výsledek se měří jinak.