A oferta do deployer, na íntegra: configure empresas no afka e receba pagamento por doze meses

Existe uma lacuna no mercado com uma forma que todos reconhecem e um nome que quase ninguém usa. As empresas querem agentes de IA a funcionar: a fila de suporte está a crescer, o pipeline está parado, o fundador responde a tickets à noite. E essas mesmas empresas não têm a pessoa que vai sentar-se, ligar as ferramentas, definir os limites e acompanhar o primeiro trabalho até ao fim. O software existe. As mãos, não.

Essa lacuna é um emprego. Chamamos deployer à pessoa que o faz: uma pessoa ou agência que instala empresas no afka dentro do seu próprio workspace e recebe por cada mês que o cliente permanece. Este artigo é a oferta completa, escrita. Não é um teaser para uma chamada, nem um portal de parceiros atrás de um formulário. Os termos, o método e o raciocínio, em público.

O que um deployer faz na prática

Um deployment não é um projeto de integração. São uma ou duas sessões de trabalho com um ritmo que os playbooks descrevem passo a passo.

A primeira hora é de perguntas. Quais os dez tipos de ticket que enchem a caixa de entrada. Quais os negócios que ficaram em silêncio. Quais são realmente os critérios indispensáveis para a função em aberto. O cliente tem estas respostas; ninguém as escreveu alguma vez. O deployer escreve-as, porque a lista decide o que o agente trata primeiro e o que fica com uma pessoa.

Depois, as ferramentas são ligadas através de conectores geridos. O afka nunca recebe palavras-passe de terceiros: o cliente autoriza cada ferramenta e pode revogar essa autorização desligando-a. Este é o passo que as pessoas esperam que seja difícil, e é o mais fácil da lista.

Depois vem a conversa que separa um deployment de uma instalação: autonomia e limites, acordados em voz alta. O agente começa em Revisão, os reembolsos aguardam aprovação, os limites são números que o cliente diz com a própria boca, e o deployer mostra que esses limites são aplicados em código e não num prompt. Um limite que pode ser contornado não é um limite.

Depois vem o momento em que o cliente compreende o produto: um trabalho real, do início ao fim, enquanto observa. Um ticket real resolvido. Um pipeline visivelmente mais limpo. Uma shortlist classificada onde cada pontuação tem a sua citação. Não uma demo com dados de exemplo: a fila deles, o negócio deles, a função deles.

O artefacto de entrega é o próprio registo de auditoria.

A entrega é o último passo, e é feita com o registo de auditoria aberto: quem fez o quê, quando, a que custo e quais as decisões que aguardaram uma pessoa. O cliente sai com o controlo da autonomia nas mãos. O deployer sai com um cliente que viu o trabalho acontecer em vez de o ouvir descrever.

Os termos, ditos uma vez

Ganha 30 por cento da subscrição do cliente durante doze meses a partir da primeira fatura paga, com atribuição de primeiro contacto durante 90 dias. A sua taxa de implementação é o seu negócio e fica consigo. O afka não publica projeções de rendimento: os termos são os termos.

Esse parágrafo aparece palavra por palavra em todas as páginas dos playbooks, e é deliberadamente curto. Não há uma escada de níveis para subir, nenhuma quota a defender, nenhuma taxa de certificação. Quer um deployment lhe tome uma tarde ou uma semana, o que cobra pelo seu próprio tempo é entre si e o seu cliente.

Os cinco playbooks, publicados

O método não está bloqueado, porque o método é a oferta. Um playbook por função de negócio, cada um com o perfil do cliente, o mapa da equipa, a entrevista de skill-pack, os cinco passos da primeira sessão, o ritmo semanal, a secção financeira e as perguntas que os clientes fazem de facto:

Instalar o agente de suporte: de uma caixa de entrada cheia a tickets resolvidos. Instalar o agente de vendas: trabalho de pipeline que corre sem uma pessoa a conduzi-lo. Instalar o agente de recrutamento: uma shortlist triada em vez de uma avalanche de candidatos. Instalar o agente de loja: compradores respondidos e o back office tratado. Instalar o agente de conteúdo: o LinkedIn gerido como infraestrutura de GTM.

Por que razão o método é público

Um documento bloqueado pode prometer qualquer coisa. Uma página pública tem de ser verdadeira, porque qualquer pessoa pode confrontá-la com o produto que descreve. Publicar os playbooks custa-nos o misticismo de um programa de parceiros e compra algo melhor: um deployer que leu exatamente o que é o trabalho antes de se comprometer, e um cliente que leu exatamente o que está a comprar. Ambos chegam com as expectativas certas, que é a única base em que uma relação de doze meses pode assentar.

Há uma segunda razão, e não é segredo. Um futuro deployer pesquisa como configurar um agente de suporte de IA para um cliente, e o playbook é a resposta que encontra. Recrutar deployers é uma tarefa de conteúdo, e a própria oferta é o conteúdo.

Para quem serve, e para quem não serve

Serve agências que já têm a confiança dos clientes: agências de marketing cujos clientes continuam a perguntar sobre IA, consultores de operações, empresas de serviços de TI cujo trabalho de retainer está a diminuir. Serve operadores que configuraram um agente dentro da própria empresa e perceberam que agora têm uma competência que os seus pares continuam a pedir emprestada. O fio condutor não é uma formação técnica. É estar à frente de um cliente, fazer as perguntas da primeira hora e ser de confiança para receber as respostas.

Não serve quem procura rendimento passivo. Os 30 por cento são recorrentes; o trabalho que os ganha não é passivo. Um deployment é trabalho real com um cliente a observar, e os playbooks não fingem o contrário em lado nenhum.

A página de deployers tem o acordo e o seu link. Os playbooks têm o método. Entre os dois, essa é a oferta completa.