Skip to main content
O modelo de linguagem que a Flunora usa é de fronteira, mas o julgamento não é dele. O que decide o que conta como critério de decisão, o que conta como objeção respondida e quando um negócio está qualificado é um playbook de vendas versionado, escrito por gente, com regras identificadas uma a uma.

Como o playbook é escrito

O playbook é um conjunto de módulos de regras. Cada regra tem um identificador estável, uma condição de aplicação e um texto normativo. Elas vão para o contexto do modelo em blocos, e o bloco que entra depende do perfil da sua organização.
Regra com identificador não é burocracia. É o que permite dizer, meses depois, que um campo foi produzido por uma regra específica, e reabrir a discussão sobre aquela regra sem reabrir a discussão sobre o produto inteiro.

Modo de operação por perfil

Três perguntas sobre a sua operação decidem quais regras se aplicam: o tamanho do cliente típico, quanto tempo dura um ciclo de venda e quantas pessoas participam da decisão do outro lado. As respostas derivam um modo, pme, mid ou enterprise, e o modo escolhe o conjunto de regras. Uma venda de duas semanas para um dono de empresa não é julgada com as regras de um comitê de compras de seis meses, e forçar uma sobre a outra produz análise que soa sofisticada e não descreve nada.

Perfil de vendas

As três perguntas ficam em Configurações e podem ser mudadas a qualquer momento.

O que acontece antes de uma versão entrar no ar

1

A mudança é escrita no playbook

Nunca no prompt direto. Ajustar a instrução do modelo para consertar um caso é como consertar um teste mudando o teste: funciona uma vez e some no histórico.
2

A versão é incrementada

A versão do playbook e a versão do prompt passam a viajar na proveniência de todo campo produzido dali em diante. Qualquer registro do CRM diz que regras o produziram.
3

A suíte de regressão roda inteira

Um conjunto de calls sintéticas com resultado esperado escrito à mão. A análise real roda contra cada uma e o resultado é comparado com o esperado. Casos marcados como obrigatórios que falham bloqueiam a subida.
4

Desvios de fronteira vão para arbitragem

Quando o resultado fica na fronteira entre duas leituras defensáveis, o caso vai para decisão humana registrada, e não para um ajuste no texto do prompt até o caso passar. Ajustar até passar é como um modelo aprende a acertar o teste e errar a realidade.

O que isso te dá

Comportamento reproduzível

A mesma evidência produz o mesmo resultado. Duas reuniões parecidas não recebem leituras opostas porque o modelo acordou diferente.

Auditoria de verdade

Um campo estranho na ficha de um contato é rastreável até a reunião, a fala e a regra. A pergunta “de onde saiu isso” tem resposta.

Mudança sem susto

Uma versão nova não pode piorar em silêncio o que já funcionava, porque a suíte roda antes e o caso obrigatório reprovado impede a subida.

Correção que dura

O que você corrigiu na ficha continua valendo depois da nova versão. Veja Decisão humana.

O que o playbook não faz

Ele não substitui o seu processo comercial e não obriga o seu time a vender de outro jeito. As etapas do funil continuam sendo as suas, com os nomes que vocês usam, e o playbook opera sobre elas. O que ele padroniza é a leitura da evidência, não a operação.