Antes de qualquer fórmula, porém, existe uma condição que nenhum design de planilha resolve: os OKRs do trimestre precisam ter scores atualizados por alguém com dono definido. Se você está em dúvida sobre isso, leia a seção de governança antes de continuar. A maioria das empresas de médio porte chega ao fechamento do trimestre com OKRs desatualizados, e o gap não é de design de planilha: é de processo.
Se seus OKRs já têm dono claro e cadência de atualização, as fórmulas a seguir conectam esses scores direto ao seu modelo financeiro. Se não têm, a segunda seção mostra como montar essa governança antes de construir qualquer coisa.
O que o guia de OKRs do Google re:Work realmente prescreve
O que analistas financeiros costumam ignorar no guia é a distinção entre committed e aspiracional. Um OKR committed é binário: ou você bate ou não bate, com meta de score 1,0. Um OKR aspiracional já pressupõe que a meta não será atingida integralmente: o guia trabalha com 0,6 a 0,7 como faixa de sucesso, e um score consistente de 1,0 sinaliza que o objetivo estava fácil demais.
A linguagem exata do guia: "Se um objetivo tem consistentemente score 1,0, deve ser revisitado - provavelmente não é ambicioso o suficiente."
John Doerr reforça esse ponto em Measure What Matters: OKRs aspiracionais existem para puxar a organização além do que ela considera possível. A falha parcial é esperada e informativa. Já os committed são os OKRs que a organização se compromete a entregar independentemente do que aconteça - equivalem a um contrato interno.
Para KRs committed (o que o guia chama de "roofshots", em contraste com os "moonshots" aspiracionais), a lógica se inverte. Falhar em um KR committed significa que algo material saiu errado: uma contratação não aconteceu, uma renovação escorregou, um sistema ficou fora do ar.
Essa distinção importa porque os dois tipos recebem tratamentos financeiros distintos. OKRs committed sustentam as premissas do orçamento base. OKRs aspiracionais alimentam cenários de upside. Se você colapsar os dois em uma única coluna de pontuação, perde os dois sinais.
O problema real: seus scores vivem na cabeça de outra pessoa
Antes de montar qualquer fórmula de premissa ponderada, você precisa responder a uma pergunta simples: quem é o dono de cada KR e em que frequência ele atualiza o score?
Na prática, o time de CS atualiza o NRR quando lembra ou quando você cobra. O comercial preenche o tracker de contratos antes do board pack e em nenhum outro momento. O time de produto não sabe que existe uma coluna de score. O resultado é um modelo financeiro construído sobre dados com 6 a 8 semanas de defasagem, e a "premissa ponderada" na aba Assumptions reflete o estado do mundo em janeiro.
A solução não é técnica. É de processo, e precisa acontecer antes de qualquer fórmula.
O que funciona na prática:
Primeiro, defina um dono por KR - uma pessoa, não um time. A coluna Dono no KR_Tracker precisa ter um nome próprio, não "Customer Success". Quando o score não é atualizado, você sabe exatamente quem acionar.
Segundo, sincronize a cadência de atualização de score com algo que o dono já faz. Se o CS faz reunião semanal de pipeline, o score de NRR entra nessa reunião. Se o comercial já preenche o CRM toda sexta, o score de contratos vem de lá. Não crie um processo paralelo: acople ao que já existe.
Terceiro, mostre para cada dono o que o score dele move. Quando o gerente de CS vê que atualizar o score de 0,73 para 0,81 muda a premissa de NRR do board pack de 113,1% para 113,6%, ele entende por que o número importa. Sem essa visibilidade, o tracker é mais uma planilha de RH que ninguém leva a sério.
Estrutura mínima de governança:
| Coluna | Conteúdo |
|---|---|
Dono | Nome completo, não área |
Última atualização | Data da última edição do score |
Próxima revisão | Data acordada para o próximo update |
Status | Ativo / Cancelado / Revisado |
Com essa estrutura, você consegue adicionar uma flag condicional: se Última atualização tiver mais de 30 dias, a linha fica em laranja no tracker. O dono recebe um e-mail automático via Apps Script ou uma mensagem no Slack. Sem isso, a defasagem é invisível até o board perguntar.
Como o re:Work distingue OKRs committed e aspiracionais no modelo financeiro
Com a governança no lugar, a distinção entre os tipos de KR passa a ter valor prático.
| Committed (Roofshot) | Aspirational (Moonshot) | |
|---|---|---|
| Meta de score | 1,0 | 0,6 a 0,7 |
| Interpretação do miss | Algo quebrou | Normal; recalibrar |
| Tratamento financeiro | Sustenta orçamento base | Alimenta cenário de upside |
| Padrão de fórmula | MIN(1, real/meta) | real/meta (pode superar 1,0) |
| Exemplos típicos | Renovar 95% do ARR, fechar 100 contratos, entregar até 31 de março | NRR ≥ 115%, R$ 21M de ARR, 3 integrações enterprise |
| Resposta ao miss | Variância orçamentária; escalar imediatamente | Esperado; documentar e ajustar |
Controle de mudanças no meio do ciclo
Esse é o ponto que o guia re:Work não endereça e que gera mais problema em modelos financeiros: o que fazer quando uma meta muda em agosto porque um cliente relevante deu churn.
Se o KR "NRR ≥ 115%" for revisado para "NRR ≥ 110%" sem nenhum controle, você tem um problema de auditoria: o modelo foi construído sobre 115%, o board recebeu atualização do T2 citando 115%, e o KR mudou em silêncio. Não é uma falha de design de OKR. É uma falha de controle de mudanças.
A solução: bloqueie as metas dos KRs no início do ciclo com uma coluna KR_Lock que registra a meta original e a data de bloqueio. Se uma meta mudar, crie uma nova linha com status "Revisado" e mantenha a linha original visível. O modelo referencia a linha bloqueada para análise de variância histórica e a linha revisada para projeções futuras. O board pack inclui uma nota explicando o gap.
Esse rastro de auditoria é o que o board vai pedir quando o score de NRR no T4 for diferente do que foi prometido no T2.
A camada de mapeamento: OKRs para premissas do modelo financeiro
Com governança no lugar e metas bloqueadas, a tradução do score para o modelo financeiro é direta.
Aba KR_Tracker - uma linha por resultado-chave:
| Depto | Resultado-Chave | Baseline | Stretch | Score T2 2026 | Premissa Ponderada |
|---|---|---|---|---|---|
| Customer Success | NRR ≥ 115% até T4 2026 | 108% | 115% | 0,73 | 113,1% |
| Comercial | Novos contratos ≥ R$ 9M no T2 | R$ 7M | R$ 9M | 0,85 | R$ 8,7M |
| Produto | 3 integrações enterprise ativas até T3 | 1 | 3 | 0,60 | 2,2 integrações |
A coluna "Premissa Ponderada" é o que alimenta o modelo financeiro. A fórmula:
// Assumptions!B3 - premissa de NRR, ponderada pelo score do OKR
=KR_Tracker!E4 * KR_Tracker!G4 + (1 - KR_Tracker!E4) * KR_Tracker!F4
// No score 0,73: (0,73 × 115%) + (0,27 × 108%) = 113,1%
E4 é o score vivo do OKR. F4 é o NRR baseline. G4 é o NRR stretch. À medida que o score é atualizado a cada mês, a premissa de NRR no modelo se ajusta automaticamente.
Para um KR committed como novos contratos, o mesmo padrão: (0,85 × R$ 9M) + (0,15 × R$ 7M) = R$ 8,7M como premissa viva de bookings alimentando a linha de novo ARR.
Uma observação sobre o board pack: o número que sai do modelo para o board é 113,1% de NRR, não "premissa ponderada por score de OKR". A metodologia fica documentada no modelo interno para auditoria, mas o output para investidores é o número em si, com a nota de que ele é atualizado mensalmente conforme os dados reais do trimestre chegam. Nenhum investidor precisa conhecer a mecânica de interpolação: precisa confiar que o número é atual e rastreável.
NRR a 115% vs. 108%: o que esse KR faz no cronograma de retenção
Com ARR inicial de R$ 62,5M, a diferença entre NRR baseline e stretch se compõe ao longo de quatro trimestres. Waterfall de retenção por cenário, apenas a coorte de abertura:
| Trimestre | Baseline (NRR 108%) | Stretch (NRR 115%) | Delta vs. Baseline |
|---|---|---|---|
| T1 2026 | R$ 63,75M | R$ 64,8M | +R$ 1,1M |
| T2 2026 | R$ 65,0M | R$ 67,3M | +R$ 2,3M |
| T3 2026 | R$ 66,3M | R$ 69,8M | +R$ 3,5M |
| T4 2026 | R$ 67,6M | R$ 72,4M | +R$ 4,8M |
| Delta de receita no ano | +R$ 11,6M |
A fórmula em ARR_Bridge!C8 (ARR retido no T1, ponderado pelo score):
// ARR_Bridge!C8 - ARR retido no trimestre usando NRR ponderado
=ARR_Bridge!B8 * (1 + (Assumptions!$B$3 - 1) / 4)
// B8 = ARR inicial (R$ 62,5M), B3 = NRR ponderado de 113,1%
// Resultado: R$ 62,5M × 1,0328 = R$ 64,5M
Arraste para T2 a T4. Quando o gerente de CS atualiza o score de NRR de 0,73 para 0,81 em KR_Tracker!E4, Assumptions!B3 recalcula para (0,81 × 115%) + (0,19 × 108%) = 113,6%, e todo o cronograma de retenção é reprecificado no mesmo refresh. O delta de R$ 11,6M no ano é um número vivo, não um julgamento congelado desde janeiro.
Fórmulas de score que tratam os dois tipos de KR
Para KRs committed, limite em 1,0:
// KR_Tracker!E4 - KR committed (ex.: meta de novos contratos)
=MIN(1, Actuals!D4 / KR_Tracker!D4)
// Actuals!D4 = contratos fechados no T2; D4 = meta de R$ 9M
Para KRs aspiracionais, deixe o score superar 1,0 para que o overachievement fique visível:
// KR_Tracker!E7 - KR aspiracional (ex.: NRR)
=Actuals!D7 / KR_Tracker!D7
// Com NRR real de 118% vs. meta de 115%: score = 1,02
Média do departamento, excluindo KRs cancelados, filtrada pelo ciclo atual:
// Aba Summary - score médio de Customer Success, ciclo atual
=AVERAGEIFS(
KR_Tracker!$E$2:$E$50,
KR_Tracker!$B$2:$B$50, "Customer Success",
KR_Tracker!$F$2:$F$50, "<>Cancelado",
KR_Tracker!$G$2:$G$50, Assumptions!$B$1
)
// B1 = rótulo do ciclo atual, ex.: "T2 2026"
O filtro de "Cancelado" é o detalhe que a maioria esquece. Sem ele, remover KRs que foram mal inflaciona o score médio do departamento sem que o número tenha mudado na realidade.
Para mais de 3 departamentos, adicione uma coluna Peso que soma 1,0 por objetivo e substitua o AVERAGEIFS por SUMPRODUCT para os scores em nível de departamento. Com 6 a 8 departamentos, o volume de linhas ainda é gerenciável em uma única aba de tracker.
Puxando dados reais para o tracker
A camada de mapeamento só funciona se a coluna de dados reais se mantiver atualizada. O ModelMonkey consegue puxar dados do Stripe, HubSpot ou do seu data warehouse diretamente para o KR_Tracker, de forma que Actuals!D4 (contratos fechados no T2) se atualize sem que ninguém precise exportar um CSV. Isso mantém a premissa de NRR ponderada pelo score em Assumptions!B3 viva entre as reuniões de revisão, em vez de refletir um número de três semanas atrás.
A automação dos dados reais resolve metade do problema de defasagem. A outra metade - os scores que dependem de julgamento humano, como "quantas integrações enterprise estão de fato ativas" - ainda exige o processo de governança descrito acima.
Se você está construindo o tracker do zero, o template de OKRs no Google Sheets cobre a configuração completa em 5 abas, incluindo a estrutura do KR_Tracker que essas fórmulas pressupõem. Para manter o status dos OKRs atualizado durante o ciclo, veja como atualizar o status dos OKRs no Sheets.
Perguntas frequentes
O guia de OKRs do Google re:Work recomenda alguma frequência de atualização de score?
O guia não prescreve uma cadência específica, mas descreve OKRs como ferramentas de alinhamento contínuo, não de avaliação anual. Na prática, equipes de finanças que conectam scores a modelos financeiros atualizam os KRs mensalmente. Qualquer intervalo maior deixa as premissas do modelo obsoletas antes da próxima reunião de board.
Qual a diferença entre score de OKR e grade de OKR?
Score (0,0 a 1,0) é a métrica quantitativa do progresso do resultado-chave. Grade é uma avaliação qualitativa opcional que alguns times adicionam para capturar contexto que o número não conta: um KR de 0,6 impactado por churn imprevisto recebe grade diferente de um 0,6 por execução fraca. Para fins de modelo financeiro, trabalhe com o score numérico. A grade fica como nota de rodapé no board pack.
Como tratar um OKR cancelado no meio do ciclo no modelo financeiro?
Mantenha a linha no KR_Tracker com status "Cancelado" e exclua-a dos AVERAGEIFS de score. No modelo financeiro, reverta a premissa ponderada para o valor baseline do período anterior e documente a mudança no log de variância. Apagar a linha elimina o rastro de auditoria que o board vai pedir.
O framework do guia re:Work funciona para OKRs anuais ou apenas trimestrais?
O guia descreve ciclos anuais e trimestrais como complementares: objetivos anuais definem direção, OKRs trimestrais definem execução. Para modelos financeiros, os KRs trimestrais são os mais úteis porque coincidem com o ciclo de fechamento e permitem atualização de premissas antes de cada revisão de board.
E se o time que preenche o tracker não achar que isso é responsabilidade dele?
Esse é o problema mais comum. A solução mais eficaz não é argumentar sobre processo: é mostrar o número que muda. Quando o gerente de CS vê que o score dele de 0,73 aparece como 113,1% de NRR no board pack, e que atualizar para 0,81 move esse número para 113,6%, ele entende o impacto direto. Comece com um departamento, mostre o output no board, e a adoção dos outros vem por pressão lateral.
Ver planos do ModelMonkey e conecte seus dados ao KR_Tracker sem exportar CSV.