In questa pagina
Un ticket di supporto può indicare «fatto» anche se il cliente non può usare la funzionalità. In una richiesta ipotetica di esportazione CSV, il codice del ticket T-104 è stato integrato, ma il rilascio resta disattivato. «La tua funzione è disponibile» sarebbe una promessa sbagliata.
Collega una richiesta a un rilascio confermato e a una persona raggiungibile. L’esempio GTM Loop Closer di xAI descrive come trovare impegni, mostrare prove e preparare una risposta. Qui il controllo è più rigoroso: chi è responsabile del prodotto deve confermare che cosa è stato rilasciato e chi può usarlo.
Parti quando esiste una prova del rilascio
Usa il record del rilascio del prodotto come trigger, non il cambio di stato del ticket. Servono feature_id stabile, release_id, comportamento rilasciato, data del rilascio, stato di disponibilità e persona responsabile nominata. Questa deve verificare che la funzione sia disponibile per l’account o piano del cliente richiedente. Codice integrato, demo in staging o nota di rilascio programmata non bastano.
Associa la richiesta al rilascio tramite ID della funzione e al cliente tramite ID del contatto nel sistema di supporto. Conserva solo mappatura e stato. Grok Bot non ha bisogno dell’intera casella di posta o del catalogo. Se manca un ID, restituisci una voce da verificare invece di indovinare da un nome simile.
| Input | Campi minimi | Che cosa verificare |
|---|---|---|
| Richiesta | ID ticket, ID funzione, data richiesta, ID contatto richiedente | La persona ha davvero chiesto quella funzione |
| Rilascio | ID rilascio, ID funzione, comportamento rilasciato, disponibilità, approvazione della persona responsabile | L’account può usarla ora |
| Contatto | ID contatto, via di supporto approvata, stato di soppressione | La persona può ricevere questo tipo di risposta |
La richiesta non è consenso marketing. Usa la via di supporto approvata per rispondere in modo fattuale alla richiesta. Se la bozza promuove altre funzioni, offre un upsell o prende di mira persone che non hanno chiesto nulla, trattala come campagna marketing separata con proprie regole di idoneità. Rispetta disiscrizioni e soppressioni del canale scelto. La guida al double opt-in spiega perché un ticket non sostituisce la registrazione dell’iscrizione.
Scrivi una risposta con un prompt circoscritto
Un risultato ipotetico associa T-104 a F-7 e R-22, ma trova il rilascio disattivato. Aspetta; non inviare.
Copia questo prompt dopo aver fornito i record approvati:
Esamina solo i record di richiesta, rilascio e contatto che fornisco. Associa tramite ID stabili di funzione e contatto, non solo dalle parole. Per ciascun candidato mostra ID ticket, ID funzione, ID rilascio, approvazione della persona responsabile, disponibilità per l’account, scopo della comunicazione approvato e stato di soppressione. Segna le prove mancanti o in conflitto come bloccanti. Scrivi una breve risposta fattuale solo per un rilascio confermato e disponibile. Indica che cosa è cambiato, dove il cliente può usarlo e dove ottenere aiuto, usando solo i fatti forniti. Non dedurre il consenso marketing, aggiungere promesse promozionali, creare o aggiornare contatti, inviare messaggi o chiudere ticket. Restituisci qui la tabella delle prove e la bozza per revisione.
Controllo: la persona responsabile del prodotto confronta la bozza con il record del rilascio e testa la disponibilità nell’account richiedente. La persona responsabile del supporto controlla identità del destinatario e scopo della comunicazione. Se un controllo fallisce, la bozza resta in chat. La guida introduttiva a Grok Bot e Brevo spiega la connessione MCP documentata e perché le operazioni disponibili richiedano comunque verifica; questo flusso non è stato eseguito in un account Grok Bot.
Invia una sola volta e registra la ricevuta
Prima di accodare un invio approvato calcola una chiave di deduplicazione da feature_id + contact_id + release_id e riservala atomicamente in un registro persistente. Una chiave già riservata, in attesa, sconosciuta o completata blocca altri accodamenti. Due processi non devono superare un controllo separato di lettura e scrittura. Dopo un timeout riconcilia ricevute dell’evento e del fornitore prima di valutare un nuovo tentativo; l’assenza di risposta non prova il mancato recapito.
Dopo la revisione configura la via approvata in Brevo. Se l’account presenta un trigger di evento personalizzato e un’azione email in Automations > Workflows > Create an automation, associa l’evento proposto feature_followup_approved a un modello approvato per il supporto. L’evento richiede un identificatore di contatto verificato; ID di funzione e rilascio sono proprietà proposte, non predefinite in Brevo. Prova con un contatto interno prima di attivare. Emetti un solo evento solo dopo approvazione e riserva riuscita della chiave. Altrimenti usa una risposta manuale del supporto. Brevo documenta eventi personalizzati e configurazione dei workflow; verifica le azioni disponibili nel tuo account. La bozza di Grok Bot non autorizza l’esecuzione. La guida alle API Brevo tratta la via API separata. Registra l’accettazione dell’evento separatamente dalla ricevuta d’invio del messaggio. Un evento accettato non prova che l’email sia stata inviata. Registra destinatario esatto, testo approvato, prova del rilascio, scopo, canale, ID d’invio del fornitore e orario. Segna il ticket come seguito solo dopo una ricevuta d’invio confermata o una risposta manuale del supporto documentata. La documentazione MCP di Brevo indica una possibile superficie d’integrazione, non che ogni scrittura o permesso sia disponibile nel tuo client.
Fissa per ogni rilascio una data limite di osservazione, per esempio sette giorni dopo la disponibilità confermata dalla persona responsabile. A quel punto misura il completamento come richieste idonee con un follow-up confermato divise per richieste idonee di quel rilascio. Conta separatamente richieste bloccate e persone irraggiungibili. Stato di consegna e risposte aiutano a trovare problemi; le aperture non provano che il cliente abbia visto o usato la funzione. Un rilascio senza destinatario verificato è ancora lavoro aperto. La stessa disciplina delle prove serve a un esperimento di campagna, anche se il risultato viene misurato diversamente.
Domande frequenti
Quando si può informare un cliente della funzione richiesta?
Solo dopo che la persona responsabile conferma ID di rilascio, disponibilità per l'account specifico e comportamento effettivamente pubblicato. Ticket chiuso, codice integrato o bozza delle note di rilascio non provano che il cliente possa usarla.
Una richiesta al supporto consente un'email di marketing?
No. Rispondi in modo fattuale a quella richiesta tramite il processo di supporto approvato. Una campagna promozionale più ampia richiede un proprio pubblico autorizzato e una base di iscrizione; il ticket non la crea.
Grok Bot può inviare automaticamente l'avviso tramite Brevo?
Qui Grok Bot confronta prove e scrive una risposta. Ogni scrittura o invio Brevo richiede connessione verificata, controllo dei permessi e approvazione separati. La compatibilità MCP documentata non è stata testata in un account reale per questo flusso.