O orçamento de software e o orçamento de folha de pagamento estão virando uma linha só

Abra o orçamento de qualquer empresa e você vai encontrar duas linhas que nunca uma vez conversaram entre si. Uma diz software: as licenças, os assentos, o SaaS por-usuário que a TI assina. A outra diz pessoas: os salários, o quadro de pessoal que o time financeiro aprova uma requisição por vez. Duas linhas, dois donos, dois caminhos de aprovação, dois conjuntos completamente diferentes de perguntas que você faz antes de dizer sim.

Elas eram separadas por uma razão, e a razão foi verdadeira por quarenta anos: uma ferramenta e um trabalhador eram tipos diferentes de coisa. Você comprava a ferramenta para que um trabalhador pudesse usá-la. Agora você pode comprar uma coisa que é o trabalhador.

O orçamento de software e o orçamento de folha de pagamento estão virando uma linha só. Isso não é um slogan sobre o futuro do trabalho, é uma afirmação concreta sobre uma planilha, e muda quem aprova o quê, o que você pergunta antes de comprar, e o que a palavra “procurement” sequer significa. Este post é sobre por que essas duas linhas um dia foram separadas, o que as colapsa, e o que quebra no dia em que elas se tocam.

Por que as duas linhas eram separadas em primeiro lugar

Comece com a versão burra, porque todos vivemos nela. Uma ferramenta é algo que uma pessoa opera. Uma planilha não se preenche sozinha; um CRM não faz as ligações; um app de design não entrega o design. A ferramenta é alavancagem sobre as mãos de um humano. Então a lógica de orçamento era limpa: você comprava capacidade (as pessoas) numa linha, e comprava alavancagem sobre essa capacidade (o software) em outra.

Essa separação fazia toda decisão a jusante fazer sentido. Software era comprado por assento, porque o valor de uma ferramenta escalava com quantas mãos a tocavam. Pessoas eram compradas por função, porque o valor de um trabalhador escalava com o que ele conseguia decidir e fazer. Software era decisão da TI, ele integra, é seguro, qual o preço por-usuário. Pessoas eram decisão do gestor de contratação, ele consegue fazer o trabalho, ele se encaixa, qual a remuneração. As duas linhas nunca se encontravam porque as duas perguntas nunca se sobrepunham.

Uma ferramenta é alavancagem sobre mãos. Um trabalhador é as mãos. A divisão de orçamento seguiu a divisão de trabalho.

E a divisão era estrutural. É por isso que procurement de software e contratação são tocados por funções diferentes, em cadências diferentes, com papelada diferente. Você não entrevista uma licença de SaaS. Você não faz uma revisão de segurança num novo analista. O aparato todo assume que a coisa que você está comprando é ou uma ferramenta ou uma pessoa, e por quarenta anos, sempre foi.

Então a coisa que você está comprando parou de escolher um lado.

A coisa que faz o trabalho é as duas

Aqui está a mudança, posta claramente. Um agent é software, é uma assinatura, roda na nuvem, integra por uma API, a TI consegue raciocinar sobre ele do jeito que raciocina sobre qualquer outro fornecedor. E um agent também é um trabalhador, ele faz o trabalho, não a ferramenta para o trabalho. Ele lê a caixa de entrada e a responde. Ele não ajuda alguém a construir o relatório; ele constrói o relatório. Não é alavancagem sobre as mãos de um humano. É as mãos.

Então em qual linha ele entra?

A resposta ingênua é “software, óbvio, você paga mensalmente, é um fornecedor, arquive sob TI”. E é aí que a maioria das empresas vai começar, porque o faturamento parece software. Mas veja o que isso faz. No momento em que você arquiva o agent sob software, você silenciosamente escondeu o fato mais importante sobre ele: ele não está tornando alguém mais rápido, ele está fazendo uma unidade de trabalho que costumava exigir uma contratação. Você vai medi-lo como uma ferramenta, assentos, uptime, integração, e vai perder completamente a coisa que você perguntaria sobre um trabalhador: o que ele realizou, e foi bom.

A outra resposta ingênua é “folha de pagamento, ele faz um trabalho, trate como uma contratação”. Isso está mais perto da verdade e ainda errado, porque um agent não tem salário, nem teto, nem função única. Você pode rodar um ou mil, ligá-los por uma tarde e desligá-los até o jantar, apontar o mesmo para vendas hoje e finanças amanhã. O modelo todo da folha de pagamento, uma pessoa, um assento, um custo fixo, uma função fixa, não cabe numa coisa que você provisiona como compute.

A resposta honesta é a desconfortável: ele não pertence a nenhuma linha, porque a linha que cabe nele ainda não existe. Os dois orçamentos eram separados porque o trabalho e a ferramenta eram separados. Um agent faz o trabalho com a ferramenta fundida numa única coisa faturável, então os dois orçamentos se fundem com ela.

O que uma linha fundida de fato mede

Quando você aceita que o agent fica nas duas linhas, você tem que decidir o que a linha fundida mede, e é aqui que ela para de ser uma curiosidade contábil e começa a ser uma mudança de verdade.

A velha linha de software media acesso: quantos assentos, a que preço, com que uptime. A velha linha de folha de pagamento media capacidade: quantas pessoas, em que funções, a que custo. Nenhuma dessas é a pergunta certa para uma coisa que faz trabalho e fatura como uma utility.

A linha fundida mede uma coisa que as velhas duas nunca conseguiram juntar: custo contra trabalho feito. Não “quantas licenças temos” e não “quantas cabeças temos”, mas “o que gastamos, e o que foi realizado com isso”. Uma unidade de resultado, um deal movido, um relatório entregue, um ticket de fato fechado, e o que custou produzi-la, quer o produtor tenha sido uma pessoa, um agent, ou uma pessoa e um agent juntos.

Esta é a parte que quebra a velha organização. A linha de software nunca perguntou “o trabalho foi bom”, porque software não faz trabalho. A linha de folha de pagamento nunca perguntou “quanto isso custou por unidade de saída”, porque você não fatura uma pessoa assalariada por relatório. A linha fundida pergunta os dois, da mesma coisa, ao mesmo tempo, e a maioria das empresas não tem nenhuma função cujo trabalho seja respondê-la. A pessoa que aprova licenças não consegue avaliar qualidade de trabalho. A pessoa que avalia qualidade de trabalho nunca aprovou um fornecedor. A fusão não só combina duas linhas de orçamento; ela exige um tipo de julgamento para o qual nenhum dos velhos donos foi contratado.

Então quem aprova o agent? Essa é a pergunta real escondida dentro da pergunta de orçamento, e é onde procurement quebra.

Onde procurement quebra

Imagine os dois caminhos de aprovação como existem hoje, porque a quebra é mais fácil de ver como uma colisão.

Para comprar software, você vai à TI e ao procurement. As perguntas são sobre o fornecedor: É seguro? Integra? Qual o preço por-assento e o prazo do contrato? Você está avaliando uma ferramenta que vai entregar às suas pessoas.

Para contratar, você vai ao gestor de contratação e ao financeiro. As perguntas são sobre o trabalhador: Ele consegue fazer o trabalho? O que ele vai possuir? Qual o custo, e a função vale a pena? Você está avaliando capacidade que vai apontar para um problema.

Agora alguém quer trazer um agent que rascunha o outbound, qualifica os leads e agenda as reuniões. Qual caminho? Rode pelo procurement de software e você vai avaliá-lo como uma ferramenta, segurança, integração, preço-por-assento, e nunca uma vez perguntar a coisa que de fato importa: o trabalho dele é bom o suficiente para colocar na frente de um cliente? Rode pela contratação e você vai avaliar o encaixe-no-trabalho lindamente e não ter framework nenhum para um “trabalhador” que também é um fornecedor multi-tenant com uma API e uma superfície de acesso a dados.

Cada caminho é meio-cego ao agent, porque cada caminho foi construído para avaliar exatamente uma das duas coisas que o agent é.

A correção ingênua é escolher um caminho e parafusar nele as perguntas do outro caminho. Faça o procurement perguntar “o trabalho é bom?” Faça a contratação perguntar “é seguro?” Não se sustenta, pela mesma razão que as linhas de orçamento não se sustentam: você tem uma função tentando fazer dois trabalhos para os quais nunca foi estruturada, com dois conjuntos de expertise que não vivem na mesma sala. O revisor de segurança não consegue avaliar copy de vendas. O líder de vendas não consegue ler uma política de acesso a dados. Grampear os checklists juntos te dá um checklist mais longo, não uma decisão melhor.

A correção real é parar de tratar “ferramenta” e “trabalhador” como a pergunta. A pergunta vira: aqui está uma coisa que vai fazer trabalho real e gastar acesso real, o que ela realiza, e podemos confiar nela com o que ela toca? Isso é uma avaliação, não duas grampeadas juntas, e precisa de um lugar para acontecer que não é nem a velha mesa de software nem a velha mesa de contratação.

O novo procurement é uma decisão de confiança, não uma compra

Então o que substitui dois caminhos de aprovação? Não um terceiro checklist. Uma pergunta diferente, feita num lugar diferente.

A velha pergunta de software era conseguimos pagar os assentos. A velha pergunta de contratação era essa pessoa consegue fazer o trabalho. A pergunta fundida é a que um gestor faz sobre qualquer um a quem delega: o que você vai deixá-lo fazer sem checar, e o que ele sempre tem que passar por um humano primeiro?

Isso não é uma negociação de preço. É uma decisão de confiança. Você não dá a um agent novo as chaves da empresa inteira no dia um, do mesmo jeito que você não entrega a um novo contratado a autoridade de transferir dinheiro na primeira semana. Você o começa em trabalho onde um erro é barato e reversível. Você observa o que ele faz. Você lê a saída. E conforme ele conquista, conforme o trabalho prova ser bom e o julgamento prova ser sólido, você amplia o que ele tem permissão de tocar sem perguntar. Confiança é uma escada que você sobe, não um interruptor que você liga na assinatura.

É por isso que a linha de orçamento fundida e o novo caminho de procurement são a mesma ideia vestindo dois chapéus. A linha mede custo contra trabalho feito. O caminho decide quanta autonomia esse trabalho conquistou. Ambos estão perguntando a mesma coisa fundamental que as velhas duas linhas nunca tiveram que perguntar: não “quanto essa ferramenta custa” e não “quanto essa função custa”, mas “essa coisa está fazendo bom trabalho, e podemos confiar nela com mais?” Você só pergunta isso sobre algo que é ao mesmo tempo software e um trabalhador. Que é exatamente o que um agent é.

Suponha, para tornar concreto, que uma empresa traga um agent para lidar com uma fatia do follow-up de vendas. Sob o velho modelo ele cairia na linha de software como mais uma assinatura, seria avaliado como uma ferramenta, e desapareceria na profusão de SaaS. Sob o modelo fundido, ele cai como trabalho: ele custa algo, produz algo mensurável, recebe um escopo estreito e reversível para começar, e sobe, ou não, com base em se os follow-ups que ele manda são daqueles que você teria orgulho de ter mandado. O custo e a qualidade e a confiança são uma decisão, revisada junto, possuída por alguém que consegue ver as três. Essa é a linha que não existe no orçamento de hoje. É a linha que está prestes a existir.

A virada: a pessoa que costumava aprovar as duas

Aqui está a parte que não é sobre planilhas.

Em algum lugar da sua empresa, duas pessoas passaram anos dizendo sim e não nessas duas velhas linhas. Uma avaliava as ferramentas, mantinha a stack sã, os fornecedores honestos, o acesso apertado. A outra avaliava as pessoas, lia o trabalho, julgava o encaixe, decidia quem possuiria o quê. As duas estavam fazendo uma versão do mesmo trabalho o tempo todo: decidindo o que a empresa deveria deixar entrar, e quanto deveria confiar nisso. O orçamento só dividiu esse julgamento ao meio e entregou cada metade a uma sala diferente.

Quando as duas linhas se fundem, essas duas metades de julgamento têm que se fundir também. E isso não é uma perda de trabalho, é uma promoção dele. A pergunta para de ser conseguimos pagar o assento ou essa pessoa consegue fazer o trabalho, e vira a mais difícil, mais humana: isso é bom trabalho, e confiamos na coisa que o fez? Isso é uma decisão de gosto. É a parte do procurement e a parte da contratação que um checklist nunca conseguiu alcançar, a leitura sobre qualidade, a leitura sobre confiança, a disposição de dizer ainda não, prove em algo menor primeiro. A fusão não substitui as pessoas que seguraram essas linhas. Ela finalmente lhes faz a única pergunta que sempre valeu a pena fazer.

O orçamento de software e o orçamento de folha de pagamento estão virando uma linha só, e a pessoa parada onde elas se encontram não é um contador reconciliando duas colunas. É quem decide com o que a empresa está disposta a confiar seu trabalho. Esse é um trabalho melhor do que qualquer um dos dois que ele substitui.

---

Isso é parte do que estamos construindo na Apollo, um lugar onde o trabalho que um agent faz, o que ele custa, e o quanto ele é confiado a tocar vivem todos numa só visão, porque sempre foram uma decisão fingindo ser duas. Se você já encarou uma fatura de SaaS e se perguntou qual daqueles itens de linha estava silenciosamente fazendo o trabalho de uma pessoa, você já sente as duas linhas começando a se tocar.