Grok Bot e Brevo: da solicitação de recurso à resposta ao cliente

Um ticket de suporte pode mostrar «concluído» enquanto o cliente ainda não consegue usar o recurso. Numa solicitação hipotética de exportação CSV, o código do ticket T-104 foi mesclado, mas a liberação continua desligada. «Seu recurso já está disponível» seria uma promessa quebrada.

Associe um pedido a um lançamento confirmado e uma pessoa alcançável. O exemplo GTM Loop Closer da xAI descreve como encontrar compromissos, mostrar provas e preparar resposta. Aqui o compromisso exige teste mais rigoroso: a pessoa responsável pelo produto deve confirmar o que foi entregue e quem pode usar.

Comece quando houver prova do lançamento

Use o registro de lançamento do produto como gatilho, não a mudança de status do ticket. Ele precisa de feature_id estável, release_id, comportamento entregue, data de lançamento, estado de liberação e responsável identificado. Essa pessoa deve confirmar que o recurso está disponível para a conta ou plano do cliente solicitante. Código mesclado, demonstração em ambiente de testes ou nota planejada não bastam.

Relacione pedido e lançamento pelo ID do recurso, e pedido e cliente pelo ID de contato armazenado no suporte. Guarde só mapeamento e estado. O Grok Bot não precisa da caixa de entrada inteira nem do catálogo. Se algum ID estiver ausente, devolva um item de revisão em vez de adivinhar pelo nome parecido.

Entrada	Campos mínimos	O que verificar
Solicitação	ID ticket, ID recurso, data do pedido, ID contato solicitante	A pessoa pediu mesmo esse recurso
Lançamento	ID lançamento, ID recurso, comportamento entregue, disponibilidade, aprovação do responsável	Esta conta pode usá-lo agora
Contato	ID contato, canal de suporte aprovado, estado de supressão	A pessoa pode receber esse tipo de resposta

O pedido não é consentimento de marketing. Use o canal de suporte aprovado para uma resposta factual àquela solicitação. Se o rascunho divulgar outros recursos, oferecer venda adicional ou mirar pessoas que nunca pediram, trate como campanha de marketing distinta com regras próprias de elegibilidade. Respeite descadastros e supressões do canal escolhido. O guia de dupla confirmação explica por que ticket não substitui registro de inscrição.

Redija uma resposta com prompt delimitado

Uma saída hipotética liga T-104 a F-7 e R-22, mas descobre a liberação desligada. Espere; não envie.

Copie este prompt após fornecer registros aprovados:

Inspecione apenas os registros de solicitação, lançamento e contato que eu fornecer. Associe por IDs estáveis de recurso e contato, não só pelas palavras. Para cada candidato, mostre ID do ticket, do recurso e do lançamento, aprovação do responsável, disponibilidade para a conta, finalidade aprovada da comunicação e estado de supressão. Marque evidência ausente ou conflitante como bloqueada. Redija uma resposta curta e factual apenas para lançamento confirmado e disponível. Diga o que mudou, onde o cliente pode usar e onde obter ajuda, usando só fatos fornecidos. Não deduza consentimento de marketing, acrescente afirmações promocionais, crie ou altere contatos, envie mensagem ou feche ticket. Devolva aqui a tabela de evidências e o rascunho para revisão.

Verificação: a pessoa responsável pelo produto compara o rascunho ao registro do lançamento e testa disponibilidade na conta solicitante. A pessoa responsável pelo suporte confere identidade do destinatário e finalidade. Se algum teste falhar, o rascunho fica no chat. O guia inicial de Grok Bot e Brevo explica a conexão MCP documentada e por que as operações disponíveis ainda precisam ser inspecionadas; este fluxo não foi executado em uma conta Grok Bot.

Envie uma vez e registre o recibo

Antes de enfileirar um envio aprovado, calcule uma chave de deduplicação de feature_id + contact_id + release_id e reserve-a atomicamente em registro durável. Chave já reservada, pendente, desconhecida ou bem-sucedida bloqueia novo enfileiramento. Dois processos não devem passar por verificação separada de leitura e escrita. Após um timeout, reconcilie recibos do evento e do provedor antes de considerar nova tentativa; falta de resposta não prova não entrega.

Após a revisão, configure o caminho aprovado no Brevo. Se sua conta oferecer gatilho de evento personalizado e ação de email em Automations > Workflows > Create an automation, mapeie o evento proposto feature_followup_approved a um modelo aprovado para suporte. O evento exige identificador de contato verificado; IDs de recurso e lançamento são propriedades de evento propostas, não padrões do Brevo. Teste com contato interno antes de ativar. Emita um evento apenas após aprovação e reserva bem-sucedida da chave. Caso contrário, use uma resposta manual do suporte. O Brevo documenta eventos personalizados e configuração de fluxos; inspecione as ações na sua conta. O rascunho do Grok Bot não autoriza execução. O guia de API do Brevo trata da rota API separada. Registre aceitação do evento e recibo do envio separadamente. Evento aceito não prova que email foi enviado. Guarde destinatário exato, texto aprovado, prova do lançamento, finalidade, canal, ID do envio do provedor e horário. Marque o ticket como respondido só após recibo de envio confirmado ou resposta manual documentada. A documentação MCP do Brevo estabelece uma possível superfície de integração, não que toda escrita ou permissão esteja disponível no seu cliente.

Defina uma data limite de observação para cada lançamento, por exemplo, sete dias depois da disponibilidade confirmada pelo responsável. Nessa data, meça conclusão como solicitações elegíveis com um retorno confirmado divididas por solicitações elegíveis daquele lançamento. Conte separadamente solicitações bloqueadas e pessoas inalcançáveis. Estado de entrega e respostas ajudam a identificar falhas; aberturas não provam que o cliente viu ou usou o recurso. Um lançamento sem destinatário verificado ainda é trabalho pendente. A mesma disciplina vale para um experimento de campanha, embora o resultado seja medido de outro modo.