O nome do arquivo deve permitir que outra pessoa descubra o conteúdo, o projeto, o estado e a versão sem precisar abri-lo. “final-agora-vai-2.pdf” falha porque “final” virou opinião, não status.
Uma convenção útil para entregáveis é:
AAAA-MM-DD_cliente-projeto_peca_status_vNN.ext
Exemplo:
2026-08-31_acme-campanha_proposta_revisao_v03.pdf
Você não precisa usar todos os campos em toda situação. Precisa manter a mesma ordem e o mesmo vocabulário quando eles forem usados.
O que cada campo responde
| Campo | Pergunta | Regra sugerida |
|---|---|---|
| Data | Quando esta versão foi gerada? | AAAA-MM-DD, formato que ordena corretamente |
| Cliente ou área | A quem pertence? | Nome curto e estável |
| Projeto | Em qual trabalho entra? | Um identificador, sem variações de apelido |
| Peça | O que há no arquivo? | Proposta, roteiro, contrato, relatório |
| Status | Em que etapa está? | Rascunho, revisão, aprovado ou entregue |
| Versão | Qual iteração é esta? | v01, v02, v03 |
Use minúsculas, hífen dentro de um campo e sublinhado para separar campos. Evite acentos e caracteres especiais quando os arquivos circulam entre sistemas diferentes.
Quatro status, sem “final final”
Defina o significado antes de aplicar:
rascunho: conteúdo ainda está sendo construído;revisao: está pronto para comentário ou aprovação;aprovado: a pessoa autorizada confirmou o conteúdo;entregue: a cópia exata foi enviada ou publicada.
“Aprovado” e “entregue” não são sinônimos. Um arquivo pode ser aprovado e ainda aguardar exportação, assinatura ou envio. Ao usar status como fatos verificáveis, você evita renomear o mesmo arquivo várias vezes por expectativa.
Doze nomes antes e depois
| Antes | Depois | O que ficou explícito |
|---|---|---|
proposta.pdf |
2026-08-31_acme-site_proposta_revisao_v01.pdf |
Cliente, projeto e etapa |
proposta nova.pdf |
2026-09-01_acme-site_proposta_revisao_v02.pdf |
Nova versão identificável |
logo-final.ai |
acme-marca_logo_aprovado_v04.ai |
Aprovação, não promessa de final |
logo-final.pdf |
2026-09-02_acme-marca_logo_entregue_v04.pdf |
Cópia entregue da versão aprovada |
contrato joao.docx |
2026-08-31_joao-consultoria_contrato_revisao_v02.docx |
Pessoa, serviço e estado |
planilha atual.xlsx |
2026-08_financeiro_fluxo-caixa_rascunho_v03.xlsx |
Período e assunto |
post 3.png |
2026-09-05_acme-lancamento_post-03_aprovado_v02.png |
Campanha, número e versão |
reuniao.txt |
2026-08-31_acme-site_reuniao-decisoes_v01.txt |
Data e finalidade |
relatorio corrigido.pdf |
2026-08_acme-midias_relatorio_revisao_v02.pdf |
Correção vira versão |
backup.zip |
2026-08-31_acme-site_arquivos-entregues_v01.zip |
Conteúdo e data do pacote |
video certo.mp4 |
acme-curso_aula-04_aprovado_v05.mp4 |
Produto, aula e estado |
documento (7).docx |
2026-08-31_interno-processos_checklist_rascunho_v01.docx |
Identidade recuperada |
Os exemplos são uma transformação demonstrativa. Adapte os campos à operação, mas preserve a lógica.
Versão no nome ou histórico da nuvem?
Use os dois para funções diferentes.
O histórico do Google Drive, do Microsoft 365 ou do OneDrive ajuda a recuperar alterações dentro de um arquivo mantido no mesmo ambiente. Ele é valioso durante a colaboração.
O número no nome ajuda quando você exporta, anexa, envia por WhatsApp, sobe em um portal ou congela um marco. Fora do ambiente original, o histórico interno pode não acompanhar a cópia.
Uma regra prática:
- documento colaborativo vivo: um arquivo principal e histórico da plataforma;
- marco de revisão ou entrega: exportação com status e versão no nome;
- pacote enviado: registro da versão exata, data, destinatário e canal.
Quando aumentar a versão
Suba de v02 para v03 quando o conteúdo mudar de forma que afete revisão, aprovação ou uso. Não aumente só porque o arquivo foi aberto, baixado ou movido.
Comentários sem aplicação não criam versão nova. Comentários incorporados, mudança de preço, troca de texto, alteração de escopo ou nova imagem criam.
Se duas pessoas editarem cópias separadas, não finja que ambas são a próxima versão. Nomeie temporariamente com o responsável, compare as alterações e consolide uma única sequência oficial.
Fluxo de aprovação
- O responsável cria
rascunho_v01. - Ao enviar para avaliação, muda para
revisao_v01. - A alteração aceita vira
revisao_v02. - A confirmação registrada gera
aprovado_v02. - A cópia efetivamente enviada vira
entregue_v02.
O número acompanha o conteúdo. O status acompanha a etapa. Assim, aprovado_v02 e entregue_v02 podem ser o mesmo conteúdo em dois momentos operacionais.
Onde guardar
O nome não compensa uma pasta caótica. Defina uma pasta principal por projeto e poucas subpastas previsíveis, como 01-briefing, 02-trabalho, 03-aprovados e 04-entregues.
Evite duplicar o mesmo arquivo em cinco lugares. Use atalhos ou links quando a plataforma permitir. Para uma organização mais ampla, combine a convenção com o guia de mensagens, cobranças e arquivos.
Auditoria de dez minutos
Escolha um projeto ativo e verifique:
- outra pessoa identifica a versão atual sem perguntar?
- existe um único arquivo principal?
- a aprovação tem registro?
- o arquivo enviado pode ser reproduzido?
- o histórico da nuvem está disponível?
- versões antigas estão preservadas sem competir com a atual?
Renomeie primeiro os arquivos em circulação. Depois, documente a convenção em uma página e aplique-a aos novos trabalhos. Uma regra pequena, usada sempre, funciona melhor que uma taxonomia perfeita que ninguém consegue lembrar.
Fontes externas
- Google Drive: verificar a atividade e as versões de arquivos
- Microsoft: restaurar versão anterior no OneDrive
- Microsoft: ver versões anteriores de arquivos do Office
Vídeo relacionado
Version History in Google Workspace
Fonte:Opennetworks