Você já respondeu o RFP deles. Você só não consegue achar.
Uma resposta de RFP não é escrita, é recuperação e montagem de tudo que sua empresa já disse, contra um prazo. O agent rascunha fundamentado nas suas próprias respostas passadas, não em prosa em branco.
Apollo Space Research
Apollo Space
Um request for proposal aterrissa às 16h de uma quinta. Quarenta perguntas, um prazo duro, um portal que não aceita anexos depois do meio-dia de sexta. Você lê a pergunta dezessete, “descreva seus controles de residência de dados”, e sente o pavor específico de alguém que sabe que a resposta existe. Você a escreveu. Seis meses atrás, para um comprador diferente, num documento que você teria que ser um detetive para achar. Então você abre uma caixa em branco e a escreve de novo, ligeiramente pior, às 16h de uma quinta.
Esse é o trabalho inteiro, e quase nada dele é escrita.
Você já respondeu o RFP deles. Você só não consegue achar. Tire a formatação e o portal e o pânico, e uma resposta de RFP são três trabalhos mecânicos vestindo um sobretudo: achar o que você já disse, montá-lo no formato deles, e não perder o prazo. Este post desmonta os três, e mostra por que o agent que os faz bem não é um escritor melhor, mas um bibliotecário melhor.
A maneira ingênua: uma caixa em branco e sua pior memória
Aqui está como de fato vai, em quase toda empresa que concorre por trabalho.
O RFP chega. Alguém, frequentemente a pessoa que você menos quer gastando um dia nisso, abre um documento e começa a responder do zero. Não porque as respostas são novas. O comprador está perguntando as mesmas coisas que todo comprador pergunta: sua postura de segurança, sua história de uptime, seu cronograma de implementação, suas referências, sua lógica de preços. Você já respondeu cada uma dessas antes, em boa prosa, depois de pensamento cuidadoso, provavelmente mais de uma vez. A informação não está faltando. Ela está espalhada, na resposta do trimestre passado, numa apresentação de vendas, num email longo que um engenheiro sênior escreveu à meia-noite, numa cláusula de contrato, no questionário de segurança que você preencheu para um comprador que ficou quieto.
Então o trabalho não é escrita. O trabalho é lembrar onde você pôs a resposta, e a maioria de nós é ruim nisso.
O que você ganha no lugar é reinvenção sob pressão de tempo. A pessoa respondendo não sabe que o parágrafo de residência de dados já existe numa forma polida, então escreve um novo, mais fino, hedgeado, faltando o único detalhe que ganhou o último deal. Multiplique isso por quarenta perguntas e a resposta que sai pela porta é uma versão pior de coisas que você já disse bem, costurada pelo seu eu mais esgotado na noite antes de o portal fechar.
O custo não são as horas, embora as horas sejam brutais. O custo é que sua melhor resposta está num arquivo que ninguém abriu, e o comprador ganha sua segunda-melhor. Você não perde RFPs porque te falta a resposta. Você os perde porque a resposta morava em lugar nenhum que você conseguisse alcançar a tempo.
O reframe: uma resposta de RFP é recuperação, não autoria
Vamos declarar a ideia claramente, porque tudo mais decorre dela.
Você já respondeu o RFP deles. Você só não consegue achar. O que significa que o gargalo nunca foi sua capacidade de escrever uma boa resposta, você já provou isso, repetidamente. O gargalo é recall. A coisa entre você e uma resposta forte não é uma página em branco; é um problema de busca disfarçado de problema de escrita.
Isto importa porque os dois problemas têm soluções completamente diferentes. Se o trabalho fosse autoria, a correção seria um escritor melhor, um modelo mais esperto, um prompt mais afiado, mais eloquência. Essa é a jogada óbvia, e é a errada. Um modelo mais eloquente escrevendo do zero ainda não sabe o que seu engenheiro sênior disse sobre failover naquele email da meia-noite. Ele vai escrever uma resposta fluente que está faltando o detalhe que ganha. Fluência não é o gap. Fundamentação é.
A jogada certa é tratar a resposta como montagem. Em algum lugar da sua empresa há um corpus de tudo que você já disse sobre si mesmo, propostas, questionários, contratos, apresentações, os threads onde alguém explicou a coisa direito. O trabalho de responder a pergunta dezessete é recuperar a resposta existente mais forte, adaptá-la à redação deste comprador, e apresentá-la para um humano aprovar. Não gerar. Recuperar, depois montar.
O sistema ingênuo inventa. O sistema certo lembra.
Como o agent de fato a rascunha: um brain, não uma página em branco
Então imagine a versão que funciona, e note no que ela está fundamentada.
O agent não começa na caixa em branco. Ele começa num company brain, a memória acumulada e buscável de cada resposta que sua empresa já deu. O último RFP que você ganhou. O questionário de segurança que você preencheu três vezes. As cláusulas de contrato que definem o que você de fato promete. A apresentação onde alguém finalmente explicou o cronograma de implementação em linguagem simples. Nada disso é conteúdo novo. Tudo isso é conteúdo que você já produziu e então perdeu de vista.
Quando a pergunta dezessete chega, “descreva seus controles de residência de dados”, o agent faz o que o humano cansado não consegue às 16h: ele busca tudo que você disse, acha os três lugares onde você já respondeu isto antes, e rascunha a partir daqueles, não da imaginação do modelo. O rascunho que ele produz está fundamentado nas suas próprias palavras anteriores, com a fonte anexada, para que um humano possa ver exatamente de onde cada afirmação veio e confiar nela, ou corrigi-la.
Essa última parte é a diferença entre uma ferramenta e um colega de trabalho. Um agent que escreve um parágrafo fluente, confiante, e sem fundamentação é um passivo, ele vai declarar seu número de uptime com total certeza e errar, e você não vai pegar até o comprador pegar. Um agent fundamentado no seu brain só consegue dizer o que você já disse, e mostra seu trabalho. Quando ele não tem uma resposta anterior real, ele diz, e sinaliza a pergunta para um humano, em vez de inventar uma. Um rascunho fundamentado que você consegue verificar vence um rascunho fluente que você tem que fact-checkar, toda vez.
A resposta honesta para “descreva seus controles de residência de dados” é a que você já deu ao último comprador que perguntou, achada, não fabricada.
Este é o mesmo motor, aliás, que deixa uma empresa parar de se reexplicar toda vez que alguém sai ou um novo comprador pergunta. O RFP é só a versão mais afiada de um problema que toda empresa tem: a resposta existe, e a pessoa que precisa dela não consegue alcançá-la. Um RFP vem com um prazo anexado, que é por que é o caso que dói.
O terceiro trabalho que ninguém especifica: o prazo persegue você de volta
Os dois trabalhos acima, achá-lo, montá-lo, são sobre qualidade. O terceiro é sobre se você submete afinal.
Todo RFP é uma corrida contra um relógio que não liga para sua semana. Há um portal que trava. Há uma janela de perguntas de esclarecimento que fecha dias antes do prazo, então a jogada esperta é perguntar cedo, o que significa que alguém tem que notar que há uma pergunta que vale a pena fazer enquanto ainda há tempo. Há quarenta respostas, cada uma das quais pode precisar de uma pessoa diferente para confirmar um número. E há o modo de falha silencioso que mata mais propostas do que escrita ruim já matou: a resposta estava 90% pronta, e aí um deal esquentou, e quinta virou próxima quinta, e a janela simplesmente fechou. Ninguém decidiu perder aquele RFP. Ele caducou.
O sistema ingênuo lida com isto com um lembrete de calendário e uma reza. Alguém configura uma trava para “RFP vence sexta” e torce que o humano certo olhe no momento certo. Mas uma data que mora na cabeça de uma pessoa compete com tudo mais naquela cabeça, e perde nos dias corridos, que são exatamente os dias em que um RFP chega.
A versão do agent é observar o prazo do jeito que observa tudo: continuamente, e falar primeiro. A janela de esclarecimento fecha em dois dias e três perguntas ainda não têm resposta fundamentada, revele isso na terça, não lamente no sábado. A resposta de preços precisa do sign-off de um humano e não tem, sinalize enquanto há pista. O portal trava ao meio-dia e o rascunho está completo, diga, com o passo de submeter enfileirado atrás de uma aprovação humana. Não um lembrete que dispara uma vez e se foi. Uma vigília permanente que segue perseguindo os threads abertos até que fechem.
Porque aqui está a coisa que a especificação geralmente perde: um RFP que você não submeteu e um que você submeteu mal parecem idênticos no placar. Ambos são uma perda. O prazo não é um detalhe administrativo parafusado na escrita, é um terceiro trabalho, co-igual, e é o que tem mais chance de afundar uma resposta que de outra forma ia ganhar.
A virada: este nunca foi o trabalho para o qual você foi contratado
Dê um passo atrás do mecanismo e olhe quem está fazendo isto hoje.
Na maioria das empresas, o RFP aterrissa sobre um founder, um operador, um head de vendas, alguém cujo trabalho de verdade é julgamento, e que em vez disso gasta um dia e uma noite sendo um motor de busca para suas próprias palavras passadas. Eles são bons na parte que importa: decidir em que concorrer, saber qual comprador vale o esforço, achar o único enquadramento que transforma uma resposta commodity numa razão para escolher você. E gastam quase nada do seu tempo de RFP nisso, porque tudo é comido pelos trabalhos mecânicos, o achar, o montar, o não-perder-o-prazo.
Esse trabalho parece diligência. É um imposto. Cada hora gasta reescrevendo uma resposta que você já tinha bem é uma hora não gasta na única parte da proposta que uma máquina não consegue fazer: o julgamento de se este é o deal certo, nas palavras certas, para este comprador em particular. Você virou o bibliotecário de RFP da sua empresa porque nenhum sistema faria isso por você. Isso nunca foi um bom uso de você.
A promessa aqui não é um chatbot que escreve mais rápido. É que o primeiro rascunho já está montado das suas próprias melhores respostas quando você senta, fundamentado, com fonte, com as perguntas abertas sinalizadas e o prazo observado, para que a pessoa mais capaz da empresa pare de ser quem reconstrói o passado, e consiga ser quem decide o que vale a pena ganhar.
É isso que estamos construindo na Apollo Space, não uma caixa em branco mais esperta, mas um company brain que lembra o que você já disse e um agent que o monta no formato que o comprador pediu, no prazo. Então a Apollo consegue escrever sua resposta de RFP? A maior parte dela já estava escrita. A parte difícil nunca foram as palavras. Era achá-las antes do meio-dia de sexta, e então decidir qual deal valia a vitória.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaA morte lenta da voz de um marketeiro
Você publica uma peça real por semana e silenciosamente a traduz em dez, e cada tradução é uma pequena chance de soar um pouco menos como você mesmo. Construímos o OS porque nada no mercado estava guardando isso.
Pensamento de ProdutoNo dia em que alguém pede demissão, sua empresa esquece como ela funciona
Onboarding não está quebrado porque o treinamento é ruim. Está quebrado porque sua empresa não consegue lembrar, e cansamos de ver a resposta sair pela porta.
Pensamento de ProdutoA primeira coisa que um novo contratado deveria fazer é ler a empresa
Um ótimo onboarding não te entrega docs, ele já sabe quem você é quando você faz login.