Grok Bot y Brevo: cerrar el ciclo de solicitudes de producto

Un ticket de soporte puede indicar «resuelto» mientras el cliente aún no puede usar la función. En una solicitud hipotética de exportación CSV, el código del ticket T-104 ya se integró, pero la activación sigue deshabilitada. «Tu función ya está disponible» sería una promesa falsa.

Relaciona una solicitud con una versión confirmada y una persona localizable. El ejemplo GTM Loop Closer de xAI describe cómo encontrar compromisos, mostrar pruebas y preparar una respuesta. Aquí el compromiso requiere una prueba más estricta: la persona responsable del producto debe confirmar qué se publicó y quién puede usarlo.

Empieza cuando existan pruebas del lanzamiento

Usa el registro de lanzamiento del producto como activador, no un cambio de estado del ticket. Necesita feature_id estable, release_id, comportamiento publicado, fecha del lanzamiento, estado de despliegue y responsable con nombre. Esa persona debe verificar la disponibilidad para la cuenta o plan del cliente solicitante. Un cambio de código integrado, una demostración en pruebas o notas de lanzamiento previstas no bastan.

Relaciona la solicitud con la versión mediante ID de función, y con el cliente mediante el ID de contacto del sistema de soporte. Guarda solo la correspondencia y el estado. Grok Bot no necesita todo el buzón ni el catálogo. Si falta alguno de los IDs, devuelve una tarea de revisión en vez de adivinar por nombres parecidos.

Entrada	Campos mínimos	Qué comprobar
Solicitud	ID de ticket, ID de función, fecha de solicitud, ID del contacto solicitante	La persona realmente pidió esta función
Lanzamiento	ID de versión, ID de función, comportamiento publicado, disponibilidad, visto bueno del responsable	La cuenta puede usarla ahora
Contacto	ID de contacto, canal de soporte aprobado, estado de supresión	La persona puede recibir esta respuesta

La solicitud no es consentimiento de marketing. Usa el canal de soporte aprobado para responder con hechos a esa petición. Si el borrador promociona otras funciones, ofrece una venta adicional o se dirige a quienes no pidieron nada, trátalo como campaña de marketing separada con sus propias normas de elegibilidad. Respeta bajas y supresiones del canal elegido. Nuestra guía de doble opt-in explica por qué un ticket no sustituye al registro de suscripción.

Redacta una respuesta con un prompt delimitado

Un resultado hipotético relaciona T-104 con F-7 y R-22, pero encuentra el despliegue apagado. Espera; no envíes nada.

Copia este prompt después de proporcionar registros aprobados:

Revisa solo los registros de solicitud, lanzamiento y contacto que proporcione. Relaciona por ID estable de función y contacto, no solo por la redacción. Para cada candidato muestra ID de ticket, ID de función, ID de versión, aprobación del responsable, disponibilidad para la cuenta, propósito de comunicación aprobado y estado de supresión. Marca pruebas ausentes o contradictorias como bloqueadas. Redacta una respuesta breve y factual solo para una versión confirmada y disponible. Indica qué cambió, dónde puede usarlo el cliente y dónde obtener ayuda, usando solo los datos proporcionados. No deduzcas consentimiento de marketing, añadas afirmaciones promocionales, crees o actualices contactos, envíes mensajes ni cierres tickets. Devuelve aquí la tabla de pruebas y el borrador para revisión.

Comprobación: la persona responsable del producto compara el borrador con el registro de lanzamiento y prueba la disponibilidad en la cuenta solicitante. Una persona de soporte comprueba destinatario y propósito de comunicación. Si falla algo, el borrador permanece en el chat. La guía inicial de Grok Bot y Brevo explica la conexión MCP documentada y por qué todavía deben inspeccionarse las operaciones disponibles; este flujo no se ha ejecutado en una cuenta de Grok Bot.

Envía una vez y guarda el recibo

Antes de poner en cola un envío aprobado, calcula una clave de deduplicación con feature_id + contact_id + release_id y resérvala atómicamente en un registro duradero. Una clave reservada, pendiente, desconocida o exitosa impide otra puesta en cola. Dos procesos no deben superar una comprobación separada de lectura y escritura. Tras un tiempo de espera agotado, reconcilia recibos del evento y del proveedor antes de considerar otro intento; que no haya respuesta no prueba que no se entregó.

Tras la revisión, configura la ruta aprobada en Brevo. Si tu cuenta ofrece activador de evento personalizado y acción de correo en Automations > Workflows > Create an automation, relaciona el evento propuesto feature_followup_approved con una plantilla aprobada para soporte. El evento necesita un identificador de contacto verificado; IDs de función y versión son propiedades de evento propuestas, no valores predeterminados de Brevo. Prueba con un contacto interno antes de activar. Emite un solo evento únicamente tras aprobación y reserva exitosa de la clave. De lo contrario, usa una respuesta manual de soporte. Brevo documenta eventos personalizados y configuración de flujos; inspecciona acciones disponibles en tu cuenta. El borrador de Grok Bot no autoriza la ejecución. La guía API de Brevo explica la ruta API aparte. Registra la aceptación del evento separada del recibo de envío. Que se acepte un evento no demuestra que se envió un correo. Guarda destinatario exacto, texto aprobado, prueba de lanzamiento, propósito, canal, ID de envío del proveedor y hora. Marca el ticket como respondido solo tras un recibo de envío confirmado o una respuesta manual de soporte documentada. La documentación MCP de Brevo establece una posible superficie de integración, no que todas las escrituras o permisos estén disponibles en tu cliente.

Fija una fecha límite de observación para cada versión, por ejemplo, siete días después de la disponibilidad confirmada. Entonces mide la finalización como solicitudes elegibles con un seguimiento confirmado dividido entre solicitudes elegibles de esa versión. Cuenta las solicitudes bloqueadas y sin destinatario localizable por separado. El estado de entrega y las respuestas ayudan a detectar fallos; una apertura no demuestra que el cliente viera o utilizara la función. Una versión sin destinatario verificado sigue siendo trabajo pendiente. La misma disciplina probatoria sirve en un experimento de campaña, aunque su resultado se mida de otro modo.