Bundling e unbundling, por dentro: a lente que estratégia ignora dentro de casa

Toda vez que bundling e unbundling entram numa conversa de estratégia, o tema fica pequeno. Vira decisão de pricing: vou vender o pacote inteiro (caso Trainee, suíte de telefonia) ou vou vender peça por peça (caso Zoho, trinta produtos que competem em frentes diferentes)? Citam disposição a pagar, citam heterogeneidade de cliente, fecham o slide.

A lente é boa. O uso é curto. O erro mais caro de bundling não é o de embalar produto pra vender. É o de embalar capacidade dentro da própria casa.

Esse texto é sobre essa segunda aplicação — a mais cara, a menos discutida, e a que toda empresa de médio porte que opero carrega sem perceber. O caso de criar empresa nova a partir de uma capacidade interna existe, é interessante e cabe no fim. Mas o jogo principal acontece dentro do organograma que já está em pé.

#Bundling e unbundling não é escolha, é ciclo

Jim Barksdale, ex-CEO da Netscape, deixou uma das frases mais úteis sobre o tema: só existem duas formas de ganhar dinheiro — bundling e unbundling. Não é uma escolha entre duas estratégias rivais. É um ciclo que se alterna, e que a maioria das indústrias percorre mais de uma vez.

Jornal era bundle. Por um valor mensal você comprava notícia, classificado, opinião, esporte, obituário e palavras cruzadas. O Craigslist tirou o classificado. Blog e Twitter tiraram a opinião. Podcast e YouTube tiraram a entrevista longa. Substack rebundlou — assinatura única que junta dezenas de autores que tinham desbundlado em newsletters próprias. Apple News rebundla de novo, agora com algoritmo no meio. Cada movimento foi correto pra quem leu o ciclo certo.

Música fez o mesmo: bundle físico (álbum) → unbundle digital (música por R$ 0,99 no iTunes) → rebundle por assinatura (Spotify). Telecom fez o mesmo. TV a cabo fez o mesmo. Bancos estão fazendo agora, com fintech desbundlando cada serviço e neobank rebundlando os que sobraram.

Tradução pro empresário: a pergunta não é “qual estratégia escolho hoje”. É em que ponto do ciclo eu estou. Meu bundle envelheceu e tá pedindo cirurgia? Meu mercado desbundlou e tá pedindo cola? A resposta certa depende do momento, não da convicção.

Essa mesma dinâmica acontece dentro da empresa, só que mais devagar e sem nome. Áreas bundlam por inércia, desbundlam quando alguém grita alto o suficiente, rebundlam quando chega a próxima onda de “vamos centralizar pra controlar”. Sem framework, o resultado é ciclo de reorg sem direção, a cada três anos, sempre custando caro e quase nunca mudando o que deveria.

#A lente em uma linha

O recap honesto do framework, sem rebater a aula de consultor: quando seus clientes têm valoração heterogênea — um valoriza muito o produto A, outro valoriza muito o B —, o bundle ganha porque captura a média. Cada um compra o pacote inteiro, mesmo pagando “demais” por uma metade. Quando os clientes têm valoração homogênea, o unbundle ganha porque cada peça precisa provar valor sozinha, sem subsidiar nada.

Agora a tradução pra dentro da empresa. O “cliente” do bundle interno é o cliente interno — a outra área, o líder, o processo a jusante que recebe a entrega. E a “disposição a pagar” interna não é dinheiro. É atenção da liderança, prioridade política, alocação de headcount, velocidade de desbloqueio, prioridade na fila do time técnico, presença no comitê que decide trade-off.

A matemática é exatamente a mesma. Só que ninguém aplica, porque ninguém percebeu que a empresa tem mercados internos com economia equivalente à de mercados externos — clientes, preços (em atenção), oferta escassa, concorrência por recursos. O CFO disputa headcount com o COO igual cliente disputa SKU em prateleira.

#O bundle invisível que toda empresa carrega

Toda área é um bundle. “Financeiro” é bundle: contas a pagar, fluxo de caixa, fechamento contábil, DRE gerencial, planejamento, tributário, relacionamento bancário. “Comercial” é bundle: prospecção, fechamento, customer success, operações de venda, pricing. “TI” é bundle: infraestrutura, dado, sistema, segurança, suporte interno, automação, integração.

Quase nenhum desses bundles foi desenhado. Eles cresceram por inércia. Alguém boa em planilha virou “financeiro”, aí o sócio contratou um analista, depois um gerente, depois separou contas a receber porque virou volume, depois o gerente virou diretor e contratou um controller. Vinte anos depois isso é “a área financeira”. Não é arquitetura — é arqueologia de contratação.

O sintoma do bundle por inércia é específico e fácil de reconhecer quando você sabe o que olhar: cliente interno reclama, mas não consegue articular o que falta. Ele só sabe dizer que “tá demorando”, que “não atende”, que “tá ruim”. Não consegue nomear a peça que compraria isolada — porque essa peça nunca existiu formalmente dentro do bundle. Ela está difusa, atendida com a mão esquerda por alguém que tem outra prioridade no topo do dia.

Exemplo concreto, do tipo que vejo se repetir no portfólio: contas a pagar atrasa, fornecedor liga reclamando, o operacional sente friccionalmente todo dia. Mas o que dá visibilidade do CFO pro board é DRE fechado, é projeção de caixa, é covenant bancário. Então a peça que pesa pra operação fica empurrada com a mão esquerda dentro do bundle financeiro, e nunca vai ser prioridade até virar incidente. O bundle escondeu a peça do radar de quem decide.

Multiplique isso por cinco áreas e você tem uma empresa onde quase toda fricção operacional é fricção de bundle mal-desenhado, e quase ninguém chama pelo nome.

Toda área é um bundle. A pergunta é se foi desenhada — ou se virou bundle por inércia.

#Cinco camadas onde o bundle existe (e onde a maioria só mexe em uma)

Bundle interno não é só “departamento”. O bundle de uma capacidade vive em pelo menos cinco camadas, e cada uma pode estar bundled ou unbundled de forma independente:

1. Produto/serviço. O que efetivamente é entregue ao cliente interno. (Um único relatório consolidado, ou três relatórios separados?)
2. Processo. Como o trabalho flui. (Uma única fila de demandas, ou três filas com SLAs diferentes?)
3. Dado. Qual fonte de verdade alimenta a decisão. (Um único data warehouse, ou três planilhas que ninguém concilia?)
4. Time/organograma. Quem reporta pra quem. (Uma única diretoria, ou três squads autônomos?)
5. Decisão. Quem decide o quê, com qual cadência. (Comitê único semanal, ou decisão delegada por escopo?)

O erro mais comum que vejo no portfólio: empresário faz reorg — mexe na camada quatro, organograma —, e acha que mudou o bundle. Não mudou. Trocou o nome da caixa no slide do RH. Processo continua o mesmo. Dado continua na mesma planilha. Decisão continua passando pela mesma pessoa. O cliente interno continua sentindo a mesma fricção, agora com um título de gerente diferente no topo do e-mail.

Reorg não é mudança de bundle. Reorg sem mexer em processo, dado e decisão é mudança de papel de parede.

Bundle de verdade muda quem é dono do quê, qual cliente interno é servido, qual KPI vale, qual SLA existe, qual decisão deixou de subir e qual passou a subir. Sem isso, é teatro de organograma — caro, demorado, e com a vantagem perversa de parecer que algo aconteceu. Por seis meses ninguém cobra de novo, porque “acabamos de reestruturar”.

A boa notícia é que, uma vez que você enxerga as cinco camadas, fica difícil errar. Você pergunta, pra cada camada, se faz sentido bundlada ou desbundlada — e quase sempre a resposta é diferente em cada uma. Time pode bundlar enquanto processo desbundla. Dado pode bundlar enquanto decisão desbundla. O desenho ganha resolução.

#Quando desbundlar uma capacidade interna

O critério é simples: clientes internos heterogêneos pedindo coisas materialmente diferentes da mesma capacidade.

O caso típico, que aparece em quase todo portfólio: BI dentro de TI. O comercial quer dashboard rápido pra fechar deal — tolera dado aproximado, exige velocidade. O financeiro quer relatório mensal auditável — exige rigor absoluto, tolera demora. Operações quer alerta em tempo real — exige latência baixa, tolera escopo estreito. Mesmo bundle, três velocidades incompatíveis, três níveis de rigor incompatíveis, três horizontes de tempo incompatíveis.

Manter junto significa que todos esperam o ritmo do mais lento. E o mais lento, quase sempre, é o que tem risco regulatório associado — porque ninguém quer ser o responsável por relatório errado pra Receita. Então o calendário do financeiro dita o ritmo do comercial. Que dita o ritmo das operações. Que reclama. Que monta a própria planilha por fora. Que duplica capacidade. Que recria o problema em outro lugar do organograma.

Desbundlar, nesse caso, é criar squad com KPI próprio, autonomia de prioridade e contrato de SLA explícito com cada cliente interno. Não precisa ser necessariamente três times distintos no organograma — pode ser três frentes dentro do mesmo time, com regras de prioridade públicas e tempo alocado por escopo. O que importa é que cada cliente interno tenha rota direta e previsível, sem entrar na mesma fila do outro.

O sinal de que desbundlou bem é discreto: o cliente interno deixa de reclamar e passa a ter opção. Ele sabe quanto custa, quanto demora, quem responde. Não tem fila. Tem contrato.

Cuidado que vale sinalizar: desbundlar sem governança vira silo. A capacidade fica autônoma, mas perde a coerência — três squads de BI usando ferramentas diferentes, sem reconciliar definições, e em seis meses três fontes de verdade conflitantes. O remédio não é voltar a bundlar; é contrato explícito de interface entre as peças, padrão comum onde faz sentido, autonomia onde não muda nada.

Anti-padrão a evitar antes que vire moda interna: “criar um squad” como sinônimo de desbundlar. Squad sem KPI próprio, sem autonomia real de prioridade e sem cliente interno definido é só um nome novo pra um grupo de WhatsApp. O bundle continua intacto embaixo, agora com um título mais bonito no Notion.

#Quando bundlar capacidades espalhadas

O critério oposto, igualmente claro: mesma demanda, atendida em pedaços por times diferentes, ninguém é dono do resultado integrado.

O caso clássico no portfólio é dado. Dado mora em três áreas. Comercial faz seu BI. Financeiro faz o dele. Operações faz o terceiro. Cada um tem sua planilha, sua definição de “cliente ativo”, sua régua de “receita reconhecida”. Toda decisão de board começa com vinte minutos de debate sobre qual planilha vale, e geralmente termina sem conclusão porque o dado nunca foi reconciliado de verdade.

Bundling interno, nesse caso, é centro de excelência, plataforma compartilhada, time único com mandato cruzado. Torre de controle. Uma única definição de cada métrica, um único pipeline de dado, uma única superfície onde todo mundo bate quando precisa de número.

O cuidado é específico e importante: bundling interno mal-feito vira gargalo político. O time central vira o vilão de todo mundo, porque herda todas as reclamações sem herdar nenhum dos contextos. Comercial reclama que a “área de dados” não entende velocidade. Financeiro reclama que não entende rigor. Operações reclama que não entende prioridade. O time central tenta agradar os três, falha com os três, e em dezoito meses alguém propõe “vamos federar isso de novo”.

O sinal de que bundlou bem é o oposto do anterior: o cliente interno final pede uma coisa e recebe. Não escolhe qual time acionar. Não monta a planilha por fora. Não duplica esforço.

Bundling interno só funciona quando reduz a quantidade de decisões que o cliente interno precisa tomar — não quando reduz a quantidade de times que entregam.

Bundlar pra “ter um único ponto de contato” sem reduzir a decisão do cliente é só mudar a porta onde ele bate. O ranger continua, agora redirecionado. A medida certa não é o número de times nem o tamanho do organograma — é o número de decisões que sumiu do prato do cliente interno final.

#A sequência que funciona: desbundle pra entender, bundle pra escalar

Empresa que tenta resolver bundle interno em um movimento só quase sempre erra. A sequência que vejo funcionar no portfólio é dois tempos, em ordem específica:

Primeiro, desbundle pra mapear. Separa as peças que o bundle escondia. Cada peça ganha dono, KPI, cliente interno definido e SLA explícito. É feio. É granular. Parece fragmentação. Vai gerar reclamação interna do tipo “agora tá tudo separado, ficou pior”. Aguenta. Esse momento é onde você descobre quais peças existiam mas estavam invisíveis, quais ninguém tinha — e quais não precisam existir.

Depois, rebundla conscientemente pra escalar. Com cada peça já provada (ou não) isoladamente, você decide quais combinar. Agora com desenho, não por inércia. Algumas voltam ao mesmo bundle original. Outras viram bundle novo com peças que vieram de áreas diferentes. Outras ficam autônomas de vez. E algumas — as mais valiosas dessa fase — descobrem-se desnecessárias e morrem sem que ninguém sinta falta.

Quem só faz a primeira metade vive em sopa de squads sem coesão, com custo administrativo subindo e ninguém respondendo pelo todo. Quem só faz a segunda — rebundla sem antes desbundlar — não sabe o que tá embalando. Empacota disfunção e chama de plataforma. Por seis meses parece organizado. No sétimo, o bundle novo recriou todos os problemas do bundle velho, com nome diferente.

Esse padrão de dois tempos é o que separa reformulação organizacional de verdade do ciclo eterno de reorg. E é também o que distingue empresário que desenha empresa do empresário que reage a ela.

#Quando uma capacidade interna vira empresa

Esse é o caso que o material original tratava como tema principal — usar bundling/unbundling pra criar empresa nova a partir de uma capacidade interna. Tem lugar. É raro.

O padrão Amazon/AWS é o exemplo manjado: a capacidade interna de infraestrutura ficou tão boa, tão desbundlada e tão demandada — primeiro por outras áreas da Amazon, depois por terceiros que tomavam conhecimento — que limitar ela ao bundle interno virou desperdício óbvio. O spin-out fez sentido porque os três critérios abaixo estavam satisfeitos antes do anúncio, não depois.

No Brasil o padrão aparece em escala menor mas existe. Software interno de gestão de obra que vira SaaS pra outras construtoras. Método proprietário de previsão de demanda que vira braço de consultoria. Time de growth que vira agência. Squad de pricing que vira ferramenta licenciada. São casos reais, mas raros — e quase sempre o que torna o spin-out viável é o critério, não a vontade.

Os três critérios que separam o spin-out real do “vamos ter uma startup interna” por moda:

1. Demanda externa já existe e tá batendo na porta. Não é hipótese. Alguém de fora já pediu pra comprar, repetidamente, sem que vocês tivessem feito esforço de venda. Se a demanda precisa ser construída do zero, o caso é de produto novo, não de spin-out.
2. Governança consegue separar. Contrato com a empresa-mãe definido, conflito de interesse mapeado, alocação de equity decidida antes do PowerPoint. Se essas três coisas não tão escritas, o spin-out vai criar fricção interna que custa mais do que rende.
3. Time consegue se autonomizar. Tem captação própria de cliente, decisão própria de roadmap, P&L separado de verdade. Não depende do bundle materno pra sobreviver no primeiro ano. Se a sobrevivência depende de contrato cativo com a mãe, é divisão, não spin-out.

O sinal de erro mais comum é spin-out por desejo de status — “vamos ter uma startup no portfólio”, o sócio quer aparecer em foto de demo day. Vira incubação cara, distrai a operação principal, e em doze ou dezoito meses volta pro bundle com cicatriz interna: o time queimou, o cliente externo recém-conquistado fica órfão, o organograma original tem buraco.

O critério honesto, sem romance: a capacidade interna vira empresa quando manter ela amarrada ao bundle interno tá custando mais do que cuidar de uma empresa nova. Não antes. E quase sempre é mais tarde do que parece — porque cuidar de empresa nova é caro, e a capacidade interna, mesmo subaproveitada, ainda tá te servindo todo dia.

#O diagnóstico em quatro perguntas

Pra operador que quer aplicar a lente sem reorganizar a empresa inteira de cara, quatro perguntas resolvem 80% dos casos.

A primeira: esse bundle interno foi desenhado, ou virou bundle por inércia de contratação? Se a resposta honesta é “nem sei como ele se formou”, já é diagnóstico. Bundle que ninguém desenhou raramente está no formato que faz sentido hoje.

A segunda: quem é o cliente interno desse bundle, e ele consegue articular o que precisa? Se o cliente interno só sabe dizer que “tá ruim” mas não consegue nomear a peça que falta, o bundle escondeu as peças do próprio cliente. Cirurgia provável.

A terceira: as peças desse bundle têm clientes internos diferentes com necessidades materialmente incompatíveis? Velocidades, rigor, horizonte de tempo, tolerância a erro. Se sim, candidato a desbundle, no formato dois tempos descrito acima.

A quarta: tem demanda da mesma capacidade espalhada em vários times sem dono claro? Se sim, candidato a bundle — desde que o objetivo seja reduzir decisões do cliente final, não reduzir caixas no organograma.

Não é checklist completo. É filtro pra separar bundle ok de bundle precisando de cirurgia. A maioria dos bundles internos passa no filtro sem problema. Os que falham geralmente são os que estão custando caro há anos sem nome — porque ninguém parou pra perguntar.

#O custo de errar pra dentro

Errar pra fora — bundling de pricing, decisão de portfólio externo — significa receita perdida, geralmente reversível com mudança de tabela em uma semana. Custa, mas é cirúrgico.

Errar pra dentro custa diferente e cumulativamente. Time desmotivado servindo cliente interno errado. Capacidade que poderia valer muito atrofiada amarrada no bundle errado. Decisão lenta porque três times empurram a mesma bola e ninguém é dono. Capex de software duplicado porque cada área comprou o seu — a comercial achou que TI demorava, então comprou a própria ferramenta de BI; o financeiro fez igual; agora são três contratos e nenhum integra. Retrabalho permanente porque o dado mora em três fontes que ninguém reconcilia. Turnover de gente boa cansada de empurrar bola dentro de bundle mal-desenhado.

O bundle interno mal-desenhado é o imposto invisível mais alto que vejo no portfólio — e o único que ninguém vê na DRE.

Reformular pra dentro não custa mais que reorganizar. Mas raramente entra em pauta de estratégia porque o bundle parece “natural” — ninguém olha pra “departamento financeiro” e pensa “isso é uma decisão de bundling que alguém tomou, ou deixou de tomar, há quinze anos”. Trata como geografia da empresa, não como desenho. E geografia, por definição, não se discute.

O custo é insidioso justamente porque não aparece em uma linha do P&L. Aparece em velocidade de decisão, em qualidade de execução, em quantidade de incêndio operacional por mês, em turnover do top quartil de gente que cansou de explicar a mesma coisa. Tudo coisa que pesa muito e que ninguém atribui à raiz certa — porque a raiz não tem nome no balanço.

#Resumo

A lente é simples e sempre foi: heterogeneidade de demanda favorece bundle; homogeneidade favorece unbundle. O ciclo se alterna porque demanda muda — e quem ler o ciclo certo se mexe primeiro.

Aplica pra fora, no sentido clássico de portfólio e pricing — o caso Zoho versus Trainee que toda escola de negócio ensina, e que tá certo. Aplica pra dentro, no desenho das capacidades internas — o uso mais valioso da lente e o menos discutido, e o foco deste texto. Aplica pra muito longe, no caso raro do spin-out — interessante, sexy em deck, e quase sempre menos viável do que parece nos três critérios.

A pergunta de estratégia que importa raramente é “como vamos vender isso?”. É outra, mais simples e mais desconfortável: esse bundle aí na sua empresa foi desenhado, ou virou bundle por inércia?

Bundle bem desenhado é pré-requisito de operação redonda. Antes da reunião que decide (cadência operacional), vem o desenho do bundle que define quem decide o quê — sem ele, a reunião certa convida as pessoas erradas. Antes do sistema operacional que orquestra motores de IA (modelo é combustível), vem o desenho de quais motores ele orquestra — e cada motor é, ele mesmo, uma decisão de bundling sobre quais peças de trabalho ficam juntas.

A camada de desenho vem antes da camada de operação. Quem opera bundle errado nunca alcança operação redonda — não importa quão boa seja a reunião, quão sofisticado seja o sistema operacional, quão preciso seja o número que chega no board.