Skip to content

Seu primeiro bundle OKF em 5 minutos

Você vai sair daqui com um bundle OKF funcional. O exemplo: um pacote de conhecimento sobre métricas SaaS — MRR, churn e NPS. Três conceitos interligados, com index e log. O tipo de coisa que um agente de IA consegue ler, navegar e usar pra te dar respostas decentes.

O que é um bundle, em 10 segundos

Uma pasta com arquivos .md. Cada arquivo é um conceito. Todo conceito tem frontmatter YAML com pelo menos um campo type. Pronto, isso é OKF.

Sem SDK, sem schema registry, sem build step. Se roda cat, roda OKF.

Estrutura final

Isso é o que a gente vai montar:

saas-metrics/
├── index.md          ← lista o que tem no bundle
├── log.md            ← histórico de mudanças
├── mrr.md            ← conceito: Monthly Recurring Revenue
├── churn.md          ← conceito: Churn Rate
└── nps.md            ← conceito: Net Promoter Score

Flat. Sem subpastas. Pra um bundle pequeno, não precisa de mais.

Passo 1 — Cria a pasta

mkdir saas-metrics && cd saas-metrics

Passo 2 — Primeiro conceito: MRR

Cria mrr.md:

---
type: Metric
title: MRR — Monthly Recurring Revenue
description: Receita recorrente mensal normalizada. O heartbeat financeiro de qualquer SaaS.
tags: [revenue, saas, finance]
timestamp: 2026-06-13T10:00:00Z
---

MRR é a soma de toda receita recorrente normalizada para um mês. Não inclui one-time fees, serviços ou descontos pontuais.

# Fórmula

MRR = Σ (valor mensal de cada assinatura ativa)


# Variações

| Tipo | O que mede |
|------|-----------|
| New MRR | Receita de clientes novos |
| Expansion MRR | Upgrades e add-ons |
| Contraction MRR | Downgrades |
| Churned MRR | Receita perdida por cancelamento — ver [churn](./churn.md) |

# Relação com outros conceitos

- Churn impacta diretamente o MRR. Detalhes em [churn rate](./churn.md).
- [NPS](./nps.md) é um leading indicator: NPS caindo hoje = MRR caindo em 60-90 dias.

# Citations

[1] [SaaS Metrics 2.0 — David Skok](https://www.forentrepreneurs.com/saas-metrics-2/)

Repara nos cross-links — [churn](./churn.md) e [NPS](./nps.md). Links relativos entre conceitos do mesmo nível. Isso é o grafo de conhecimento do OKF.

Passo 3 — Segundo conceito: Churn

Cria churn.md:

---
type: Metric
title: Churn Rate
description: Percentual de clientes (ou receita) perdidos em um período.
tags: [retention, saas, health]
timestamp: 2026-06-13T10:00:00Z
---

Churn é a métrica que ninguém quer olhar mas todo mundo precisa. Mede a velocidade com que você perde clientes ou receita.

# Fórmulas

**Logo churn (clientes):**

Churn Rate = (clientes perdidos no período / clientes no início do período) × 100


**Revenue churn (receita):**

Revenue Churn = churned MRR / MRR no início do mês × 100


Revenue churn é mais honesto. Um cliente enterprise cancelando dói mais que dez freemium.

# Benchmarks

| Estágio | Churn mensal aceitável |
|---------|----------------------|
| Early-stage | < 5% |
| Growth | < 3% |
| Scale | < 1% |

# Relação com outros conceitos

- Churn destrói [MRR](./mrr.md). Net MRR negativo = empresa morrendo devagar.
- [NPS](./nps.md) detractors (0-6) são candidatos a churn. Monitore a correlação.

# Citations

[1] [What is Good SaaS Churn Rate — Lenny Rachitsky](https://www.lennysnewsletter.com/p/what-is-good-retention-rate)

Passo 4 — Terceiro conceito: NPS

Cria nps.md:

---
type: Metric
title: NPS — Net Promoter Score
description: Score de -100 a 100 que mede a probabilidade de recomendação do produto.
tags: [satisfaction, saas, product]
timestamp: 2026-06-13T10:00:00Z
---

NPS pergunta uma coisa só: "de 0 a 10, qual a chance de você recomendar a gente?". Simples, imperfeito, mas universalmente comparável.

# Fórmula

NPS = % promoters (9-10) − % detractors (0-6)


Passives (7-8) não entram no cálculo. Existem mas são invisíveis. Tipo aquele colega que nunca opina no code review.

# Segmentação

| Grupo | Score | Significado |
|-------|-------|-------------|
| Promoters | 9-10 | Evangelistas. Trazem referrals. |
| Passives | 7-8 | Satisfeitos mas vulneráveis a concorrentes. |
| Detractors | 0-6 | Risco de [churn](./churn.md). Podem fazer barulho negativo. |

# Relação com outros conceitos

- Detractors viram churn. Correlacione NPS por cohort com [churn rate](./churn.md).
- NPS em queda é early warning de impacto no [MRR](./mrr.md).

# Citations

[1] [The One Number You Need to Grow — HBR](https://hbr.org/2003/12/the-one-number-you-need-to-grow)

Passo 5 — index.md

O index é o “ls bonito” do bundle. Sem frontmatter (é arquivo reservado). Lista o conteúdo com links e descrições curtas.

Cria index.md:

# SaaS Metrics Bundle

Conceitos fundamentais de métricas para empresas SaaS.

## Métricas

* [MRR — Monthly Recurring Revenue](./mrr.md) - Receita recorrente mensal normalizada
* [Churn Rate](./churn.md) - Percentual de clientes/receita perdidos por período
* [NPS — Net Promoter Score](./nps.md) - Score de recomendação (-100 a 100)

Passo 6 — log.md

O log é o changelog do bundle. Entradas mais recentes primeiro, agrupadas por data ISO 8601.

Cria log.md:

# Bundle Update Log

## 2026-06-13

* **Creation**: Bundle inicial com três métricas SaaS core.
* **Creation**: Adicionado [MRR](./mrr.md) com fórmulas e variações.
* **Creation**: Adicionado [Churn Rate](./churn.md) com benchmarks por estágio.
* **Creation**: Adicionado [NPS](./nps.md) com segmentação e correlações.

Validação rápida

Seu bundle tá conformante com OKF v0.1 se:

  1. ✅ Todo .md que não é index.md nem log.md tem frontmatter YAML parseável
  2. ✅ Todo frontmatter tem campo type preenchido
  3. ✅ index.md e log.md seguem a estrutura da spec

São esses três checks. Só isso. O resto (title, description, tags, timestamp) é recomendado mas não quebra conformidade se faltar.

O que você acabou de construir

Um grafo de conhecimento navegável. Qualquer agente que entenda markdown + YAML consegue:

  • Listar conceitos via index.md
  • Entender o tipo de cada um via type
  • Navegar relações pelos cross-links
  • Ver o que mudou via log.md

O lance do OKF é que não precisa de nada além de um editor de texto e git. Sem database, sem API, sem vendor lock-in. Conhecimento portátil como um repo qualquer.

Próximos passos

  • Adicione subpastas quando o bundle crescer (operational/, financial/, product/)
  • Coloque resource: no frontmatter quando a métrica tiver um dashboard real
  • Versione com git — cada commit vira um snapshot do estado do conhecimento
  • Rode o validador em okf.md pra garantir conformidade

Tempo total real: provavelmente menos que 5 minutos. Se demorou mais, culpa do seu editor, não do formato.