Playbook interno: como registrar as decisões da empresa

Playbook interno é o registro das decisões da empresa e do motivo de cada uma, escrito para que outra pessoa consiga aplicar e adaptar sem precisar reconstruir o raciocínio do zero. Ele é diferente de um manual de procedimento, e essa diferença é o que faz um sobreviver e o outro virar arquivo morto.

Procedimento responde "como fazer". Playbook responde "como decidir". Procedimento envelhece a cada mudança de contexto; playbook continua útil, porque quem entende o critério consegue recalcular. Sobre escrever o procedimento em si, veja Como criar um POP (procedimento operacional padrão).

Por que manual de procedimento não resolve

Todo manual descreve o caso previsto. A operação real é feita de casos não previstos, e é neles que a pessoa precisa decidir sozinha. Sem o critério registrado, ela decide pelo próprio julgamento, e o resultado passa a variar conforme quem estava de plantão.

O custo de o conhecimento não estar registrado é conhecido. O Workplace Knowledge and Productivity Report da Panopto estimou que grandes empresas americanas perdem em média US$47 milhões por ano em produtividade por compartilhamento ineficiente de conhecimento, e que uma empresa de mil funcionários perde cerca de US$2,4 milhões por ano com as ineficiências do dia a dia causadas por perda de conhecimento.

Em empresa pequena a conta é diferente e mais dolorosa: a perda não se dilui, ela recai sobre a agenda de quem sabe. Sobre o ritmo que sustenta esse registro, veja Melhoria contínua em empresa pequena: como criar o ritmo.

A estrutura de um registro de decisão

Cada entrada do playbook tem cinco linhas. Não mais que isso, ou ninguém escreve.

O campo "por quê" é o que dá durabilidade. "Conferimos o cadastro antes de emitir porque erro nessa etapa gera nota cancelada e cliente irritado" resiste a mudança de sistema; "confira o cadastro" não resiste a nada.

O campo "quando revisar" é o que evita que o playbook se torne uma coleção de regras obsoletas com aparência de autoridade, que é pior que ausência de registro.

O que entra no playbook (e o que não entra)

Entra:

• Decisões que definem qualidade da entrega.
• Critérios de exceção: quando fugir do padrão é permitido e quem autoriza.
• Escolhas de ferramenta e o motivo, para não se refazer a discussão a cada ano.
• Regras de negócio que uma automação executa. Isso é essencial: automação sem a regra registrada em linguagem humana é uma decisão de negócio escondida dentro de uma configuração.
• Combinados com cliente ou fornecedor que não estão em contrato.

Não entra:

• Passo a passo de interface de ferramenta, que muda e desatualiza rápido.
• Informação que já vive melhor em outro lugar (contrato, sistema, planilha oficial).
• Decisão que ninguém vai consultar. Se você não consegue imaginar quem lerá aquilo nas próximas semanas, pode esperar.

Como construir sem projeto de documentação

O erro clássico é abrir uma iniciativa de "documentar a empresa". Ela produz uma pasta grande que ninguém abre. O caminho que funciona é incremental e reativo.

1. Registre no momento da decisão. Quando algo for decidido em reunião ou conversa, escreva as cinco linhas na hora. Depois ninguém lembra do porquê.
2. Registre no momento da pergunta. Toda dúvida repetida da equipe é uma entrada que faltava. Responder por escrito uma vez economiza responder verbalmente dez.
3. Registre depois do erro. O que deu errado e o que se decidiu a respeito é o tipo de conhecimento mais caro de adquirir e mais fácil de perder.
4. Guarde onde a equipe já trabalha. Playbook em ferramenta nova não é consultado.

Em algumas semanas isso produz um documento pequeno e usado, que vale mais que um manual completo e ignorado.

Documentar como legado, não como burocracia: playbooks e artefatos que ficam no negócio quando o projeto termina.

As dez primeiras entradas, para não travar no começo

A folha em branco é o maior obstáculo. Estas dez entradas cobrem a maior parte do que gera dúvida em negócio pequeno, e servem como ponto de partida.

1. Que tipo de cliente aceitamos, e qual recusamos. Com o motivo, que é o que permite avaliar um caso novo.
2. Como definimos prazo de entrega. O critério, não a tabela. Inclui o que fazemos quando o cliente pede prazo menor.
3. Até onde vai o escopo padrão, e o que caracteriza pedido extra.
4. Qual desconto pode ser dado, por quem, em qual situação. Esta é a dúvida mais repetida em quase toda equipe comercial.
5. O que fazemos quando um fornecedor atrasa. Quem avisa o cliente, em quanto tempo, e com qual mensagem.
6. Como priorizamos quando dois clientes precisam ao mesmo tempo. O critério, explicitado. Sem ele, prioriza quem cobra mais alto.
7. O que precisa de aprovação antes de sair, e de quem.
8. Quais dados nunca saem da empresa, incluindo o que não pode ser colado em ferramenta de IA.
9. Por que escolhemos as ferramentas principais, e quando reavaliaríamos.
10. As regras de negócio que cada automação executa, em linguagem humana.

A décima merece destaque. Automação carrega decisões de negócio dentro de configurações que ninguém lê. Quando a regra não está escrita em português em nenhum lugar, ela deixou de ser uma decisão da empresa e passou a ser uma característica de um sistema, o que é uma forma silenciosa de perder controle.