Pe această pagină
Un tichet de suport poate spune „rezolvat”, deși clientul nu poate folosi funcționalitatea. Într-o cerere ipotetică de export CSV, codul pentru tichetul T-104 a fost integrat, dar lansarea funcționalității este încă dezactivată. „Funcționalitatea ta este disponibilă” ar fi o promisiune falsă.
Leagă o cerere de o singură versiune confirmată și de o persoană contactabilă. Exemplul GTM Loop Closer de la xAI descrie găsirea angajamentelor, arătarea dovezilor și pregătirea răspunsului. Aici promisiunea trece printr-un test mai strict: responsabilul produsului trebuie să confirme ce s-a livrat și cine poate folosi funcționalitatea.
Începe când există dovada lansării
Declanșatorul este înregistrarea lansării produsului, nu schimbarea stării tichetului. Îți trebuie un feature_id stabil, release_id, comportamentul livrat, data lansării, starea disponibilității și un responsabil numit. Responsabilul trebuie să verifice dacă funcționalitatea este disponibilă contului sau planului clientului solicitant. Codul integrat, un demo în mediul de test sau o notă de lansare planificată nu sunt suficiente.
Leagă cererea de lansare prin ID-ul funcționalității, iar cererea de client prin ID-ul contactului din sistemul de suport. Stochează doar maparea și starea. Grok Bot nu are nevoie de întreaga căsuță de mesaje sau de tot catalogul. Dacă lipsește oricare ID, întoarce un element pentru revizie în loc să ghicești din asemănarea numelor.
| Intrare | Câmpuri minime | Ce verifici |
|---|---|---|
| Cerere | ID tichet, ID funcționalitate, data cererii, ID contact solicitant | Persoana a cerut într-adevăr această funcționalitate |
| Lansare | ID lansare, ID funcționalitate, comportament livrat, disponibilitate, aprobare responsabil | Acest cont o poate folosi acum |
| Contact | ID contact, rută de suport aprobată, stare de blocare | Persoana poate primi acest tip de răspuns |
Cererea nu este acord de marketing. Folosește canalul de comunicare al suportului aprobat pentru un răspuns factual la acea cerere. Dacă textul promovează alte funcționalități, cere trecerea la un plan superior sau vizează persoane care nu au cerut nimic, tratează-l ca pe o campanie de marketing separată, cu reguli proprii de eligibilitate. Respectă dezabonarea și blocarea pe canalul ales. Ghidul de confirmare dublă explică de ce un tichet nu înlocuiește o înregistrare a abonării.
Redactează un răspuns cu un prompt delimitat
Un rezultat ipotetic leagă T-104 de F-7 și R-22, dar descoperă că lansarea este dezactivată. Așteaptă; nu trimite.
Copiază acest prompt după ce furnizezi înregistrările aprobate:
Examinează numai înregistrările de cerere, lansare și contact pe care ți le ofer. Potrivește-le după ID-ul stabil al funcționalității și ID-ul contactului, nu doar după cuvinte similare. Pentru fiecare candidat, arată ID-ul tichetului, al funcționalității și al lansării, aprobarea responsabilului, disponibilitatea pentru cont, scopul aprobat al comunicării și starea de blocare. Marchează dovezile lipsă sau contradictorii ca blocate. Redactează un răspuns scurt și factual numai pentru o lansare confirmată și disponibilă. Folosește doar faptele oferite ca să spui ce s-a schimbat, unde poate folosi clientul funcționalitatea și unde primește ajutor. Nu deduce acord de marketing, nu adăuga afirmații promoționale, nu crea sau actualiza contacte, nu trimite un mesaj și nu închide tichetul. Returnează tabelul de dovezi și ciorna aici pentru revizie.
Verificare: responsabilul produsului compară textul cu înregistrarea lansării și testează disponibilitatea în contul solicitantului. Un responsabil de suport verifică identitatea destinatarului și scopul comunicării. Ține ciorna în chat dacă oricare verificare eșuează. Ghidul de pornire Grok Bot și Brevo explică legătura MCP documentată și de ce operațiunile disponibile tot trebuie examinate. Acest flux concret nu a fost rulat într-un cont Grok Bot.
Trimite o dată, apoi înregistrează dovada
Înainte de a pune o trimitere aprobată în coadă, calculează o cheie de deduplicare din feature_id + contact_id + release_id și rezerv-o atomic într-un registru persistent. O cheie deja rezervată, în așteptare, cu stare necunoscută sau reușită blochează o nouă adăugare în coadă. Doi lucrători nu trebuie să treacă amândoi de o verificare separată de citire, urmată de scriere. După o expirare, reconciliază evenimentul și dovezile furnizorului înainte de orice reîncercare; lipsa răspunsului nu dovedește nelivrarea.
După revizie, configurează ruta aprobată în Brevo. În Automations > Workflows > Create an automation, dacă acel cont oferă declanșator de eveniment personalizat și acțiune de e-mail, mapează evenimentul propus feature_followup_approved la un șablon aprobat pentru scopul de suport. Evenimentul necesită un identificator de contact verificat; ID-urile funcționalității și lansării sunt proprietăți propuse de tine, nu valori Brevo implicite. Testează cu un contact intern înainte de activare. Emite un singur eveniment doar după aprobare și rezervarea cu succes a cheii. Altfel, folosește un răspuns manual de suport. Brevo documentează evenimentele personalizate și configurarea fluxurilor; verifică acțiunile disponibile în cont. Ciorna Grok Bot nu autorizează execuția. Ghidul Brevo API prezintă ruta API separată. Înregistrează acceptarea evenimentului separat de dovada trimiterii mesajului. Un eveniment acceptat nu dovedește că s-a trimis un e-mail. Notează destinatarul exact, textul aprobat, dovada lansării, scopul, canalul, ID-ul de trimitere al furnizorului și ora. Marchează tichetul ca urmărit numai după confirmarea trimiterii sau un răspuns manual de suport documentat. Documentația MCP a Brevo arată o posibilă suprafață de integrare, nu că toate operațiunile de scriere și permisiunile există în clientul tău.
Stabilește o dată-limită de observație pentru fiecare lansare, de exemplu șapte zile după ce responsabilul confirmă disponibilitatea. Atunci măsoară finalizarea ca cererile eligibile cu un singur mesaj de urmărire confirmat împărțite la cererile eligibile ale acelei lansări. Ține separat cererile blocate și persoanele imposibil de contactat. Starea livrării și răspunsurile clienților ajută la găsirea erorilor; deschiderile nu dovedesc că un client a văzut sau folosit funcționalitatea. O lansare fără destinatar verificat este încă o sarcină deschisă. Aceeași disciplină a dovezilor se aplică unui experiment de campanie, deși rezultatul se măsoară altfel.
Întrebări Frecvente
Când este pregătită funcționalitatea cerută pentru un mesaj către client?
Numai după ce responsabilul confirmă ID-ul lansării, disponibilitatea pentru contul clientului și comportamentul exact livrat. Un tichet închis, cod integrat sau o notă de lansare în ciornă nu dovedesc că acel client o poate folosi.
O cerere de suport permite un e-mail de marketing?
Nu. Răspunde factual la cererea clientului prin procesul aprobat al suportului. O campanie promoțională mai largă are nevoie de propriul public permis și o bază de abonare; tichetul nu le creează.
Poate Grok Bot trimite automat notificarea de lansare prin Brevo?
Ghidul folosește Grok Bot pentru a potrivi dovezi și a redacta răspunsul. Orice scriere sau trimitere în Brevo cere o conexiune verificată separat, verificarea permisiunii și aprobare. Compatibilitatea MCP documentată nu a fost testată aici într-un cont activ.