Modelo de relatório de status de projeto: formato semanal, exemplo — e como o relatório se monta sozinho a partir dos recaps (2026)

Um relatório de status de projeto é uma página curta e de formato fixo que diz a quem está fora do trabalho diário onde o projeto está: no prazo ou não, o que mudou desde o último relatório, o que pode dar errado e o que se pede que o leitor decida. Ele é escrito em uma cadência — semanal na maioria dos projetos — e é sempre a mesma página, então o leitor compara esta semana com a anterior em vez de ler tudo do zero.

Este guia começa pela técnica — o formato, um modelo que você pode copiar, um exemplo preenchido e uma versão semanal mais curta para o líder de equipe que reporta para cima — e depois passa à mecânica: quando o relatório basta e quando ainda vale convocar uma reunião de status, onde o relatório é escrito nas ferramentas que sua equipe já usa e o que acontece entre as reuniões e a página. Porque a parte mais difícil do relatório não é a escrita. É a meia hora anterior, quando o líder volta a uma semana de chamadas e conversas para descobrir o que de fato foi combinado.

O que é um relatório de status de projeto — e o que ele não é

Quatro documentos orbitam um projeto, e o relatório é o que mais se confunde com os outros:

O recap é por reunião; o relatório é por semana, abrangendo todas elas. Um stand-up leva os bloqueios a quem pode removê-los; o relatório diz a quem está mais longe se esses bloqueios ameaçam a data. O registro de decisões guarda o porquê; o relatório apenas diz que uma decisão foi tomada ou ainda é necessária. Se o relatório é difícil de escrever, a causa quase sempre está antes: as reuniões da semana não deixaram registro dos resultados, e o líder os reconstrói de memória na tarde de sexta-feira.

O formato semanal: seis blocos, uma página

Um relatório lido toda semana precisa caber em uma tela e manter sempre a mesma forma. Seis blocos, nesta ordem:

1. Cabeçalho. Projeto, período do relatório, autor, data do próximo relatório. O leitor procura o período primeiro — um relatório sem período é uma página de afirmações sem um "desde quando".
2. Status geral em uma linha. Verde, amarelo ou vermelho — ou dentro do plano, em risco, fora do plano — mais uma frase que diz o porquê. A cor é um resumo dos blocos abaixo, não uma impressão; se o bloco de riscos diz que um fornecedor atrasou duas semanas, a linha não pode dizer verde.
3. Progresso desde o último relatório. De três a seis linhas do que foi concluído, cada uma como resultado e não como atividade. "Fluxo de checkout em revisão com o cliente" é um fato; "trabalhei no checkout" não é.
4. Próximo período. O que a equipe se compromete a concluir antes do próximo relatório, cada item com um responsável. Este bloco é aquilo contra o qual o bloco de progresso da semana seguinte será conferido.
5. Riscos, problemas e decisões necessárias. Um risco é algo que pode acontecer; um problema é algo que já aconteceu. Cada linha: o quê, o efeito sobre prazo ou orçamento, o responsável e o que se pede ao leitor — inclusive "nada, apenas para informação". As decisões necessárias têm linha própria, com a data em que o projeto precisa da resposta.
6. Ações em aberto. Toda ação ainda aberta de qualquer reunião do período, com responsável e prazo, e uma marca nas que estão atrasadas. É o bloco que a maioria dos relatórios omite, e o que o leitor usa para julgar se a cor do bloco 2 é honesta.

Três coisas a deixar de fora: diálogo (quem disse o quê), registros de atividade (horas, chamadas realizadas) e tudo aquilo sobre o qual o leitor não poderia agir. O relatório é para alguém que vai gastar quatro minutos com ele. Cada linha deve sobreviver à pergunta "o que o leitor faria diferente sabendo disto?"

Modelo de relatório de status de projeto

Copie isto para um documento, uma mensagem de canal ou um canvas. Os colchetes são placeholders.

[Projeto] — relatório de status de [período, p. ex. 20–24 de outubro]
Autor: [nome] · Enviado: [data] · Próximo relatório: [data]
Geral: [dentro do plano / em risco / fora do plano] — [uma frase que diz o porquê]

Concluído desde o último relatório
– [Resultado, como um fato] — [responsável]
– [Resultado] — [responsável]
– [Resultado] — [responsável]

Próximo período (até [data do próximo relatório])
– [Entregável] — [responsável]
– [Entregável] — [responsável]

Riscos e problemas
– [Risco ou problema] — efeito: [prazo / orçamento / escopo] — responsável: [nome] — pedido: [decisão necessária até a data / para informação]

Decisões necessárias
– [Pergunta, com as opções na mesa] — necessária até [data] — de [nome]

Ações em aberto
– [Tarefa] — [responsável] — prazo [data] — [em aberto / atrasada desde a data]
– [Tarefa] — [responsável] — prazo [data] — [em aberto]

A ordem é deliberada. O patrocinador que lê apenas as três primeiras linhas fica com a cor e o motivo; quem lê até o fim fica com as ações que explicam a cor. Mantenha os títulos idênticos de uma semana para outra — o valor do formato está na comparação.

Exemplo: um relatório de status semanal preenchido

Um pequeno projeto de software, equipe de dois idiomas, um cliente que lê o relatório toda segunda-feira:

Portal de pedidos v2 — relatório de status de 20 a 24 de outubro
Autor: Mateusz · Enviado: 24 de outubro · Próximo relatório: 31 de outubro
Geral: em risco — o sandbox do provedor de pagamentos chegou com quatro dias de atraso; a data de lançamento só se mantém se o teste de integração passar até 29 de outubro.

Concluído desde o último relatório
– Fluxo de checkout em revisão com o cliente; dois comentários em aberto — Ana
– Importação de produtos do ERP roda toda noite no staging — Priya
– Strings de UI em espanhol e romeno concluídas; francês em 80% — Luca

Próximo período (até 31 de outubro)
– Teste de integração de pagamento no sandbox do provedor — Priya
– Aprovação do checkout pelo cliente — Ana
– Strings em francês concluídas, os três idiomas revisados — Luca

Riscos e problemas
– Atraso do sandbox de pagamento (problema) — efeito: o lançamento em 7 de novembro só se mantém se o teste passar até 29 de outubro; caso contrário, 14 de novembro — responsável: Priya — pedido: para informação, decisão abaixo
– Tempo de resposta do cliente na revisão (risco) — efeito: cada rodada leva 3 dias; uma terceira rodada empurra a aprovação para depois da janela de teste — responsável: Ana — pedido: que o cliente reúna os comentários em uma única rodada

Decisões necessárias
– Se o teste falhar em 29 de outubro: lançar em 14 de novembro com pagamentos, ou em 7 de novembro com pagamento apenas por boleto/fatura e cartão adicionado depois — necessária até 30 de outubro — do cliente

Ações em aberto
– Enviar ao provedor a lista de IPs permitidos — Priya — prazo 21 de outubro — atrasada desde 21 de outubro
– Confirmar a janela de go-live com o parceiro de hospedagem — Mateusz — prazo 28 de outubro — em aberto
– Responder aos dois comentários do checkout — Ana — prazo 27 de outubro — em aberto

Repare no que o exemplo não diz: quantas reuniões foram realizadas, quem falou, quantas horas foram gastas. O leitor descobre em uma linha que a data está em risco e em um bloco o que se pede que ele decida.

Modelo de relatório semanal para líder de equipe

O relatório semanal de um líder de equipe para o próprio gestor é um primo mais curto do relatório de projeto. O leitor é uma só pessoa, geralmente com menos de dois minutos, e as perguntas são três: a equipe está cumprindo o que prometeu, o que está atrapalhando e o que você precisa de mim. Quatro blocos cabem em uma mensagem de chat:

Equipe [nome] — semana de [data]
Status: [dentro do plano / em risco] — [uma linha]
Entregue: [dois ou três resultados, cada um com um nome]
No caminho: [um ou dois bloqueios, cada um com quem pode removê-lo]
Preciso de você: [uma decisão ou recurso, com data] — ou "nada esta semana"

Duas regras que tornam o relatório legível ao longo dos meses. Primeiro, "Preciso de você" nunca fica vazio por acaso: escreva "nada esta semana" para que o gestor saiba que o silêncio é deliberado. Segundo, "Entregue" lista nomes de pessoas — o relatório semanal também é onde o líder torna visível o trabalho da equipe para quem não o vê no dia a dia. Se a equipe já faz um stand-up diário com bloqueios nomeados, "No caminho" é uma cópia dos que ainda estão de pé na sexta-feira.

O relatório semanal substitui a reunião semanal de status naquilo que a reunião carregava — a informação. O que ele não pode substituir é tratado a seguir.

Quando uma reunião de status ainda é necessária

Uma reunião de status é a forma ao vivo do relatório: cada pessoa conta ao líder ou ao patrocinador onde as coisas estão, em uma sala, ao custo de todos. Existindo um relatório escrito, a reunião só se justifica quando a página não dá conta do recado. Quatro casos:

• Uma decisão com trade-off. O relatório pode apresentar as opções; não pode negociá-las. Quando "Decisões necessárias" tem uma entrada cuja resposta depende do que dois stakeholders aceitam ceder, trinta minutos com os dois na sala valem mais que duas semanas de responder a todos.
• Uma data está se movendo. Um atraso raramente é aceito a partir de uma página. A conversa sobre o que se move junto — escopo, orçamento, o início de outro projeto — é uma reunião, com o relatório como leitura prévia.
• Um risco ultrapassou seu limite. Na semana em que um risco vira problema, as pessoas que respondem pela consequência precisam ouvir isso do líder e fazer perguntas, não ler na segunda-feira.
• Um novo stakeholder. Quem não leu os seis relatórios anteriores precisa de uma sessão para entender o formato do projeto; depois disso, a página basta.

Uma reunião de status não serve para ler o relatório em voz alta. Se todo item da pauta é "atualização de fulano", cancele-a e envie a página; o guia de cadência de reuniões trata de quais reuniões recorrentes merecem seu espaço. Quando a reunião acontece, conduza-a a partir do relatório — os blocos de riscos e decisões são a pauta, e uma reunião eficaz termina com esses itens marcados como decididos, em aberto ou adiados. Com stakeholders que falam idiomas diferentes, a sala tem três opções para a reunião em si: um intérprete humano — o guia de intérprete no Zoom mostra como isso é configurado —, as legendas da própria plataforma ou um espaço que traduz para cada participante; o relatório, escrito uma única vez, é outra questão.

Onde o relatório é escrito nas ferramentas que você já usa

Cada plataforma importante deixa algo depois de uma reunião a partir do qual um relatório de status pode ser montado, e cada uma para em um ponto diferente. Apenas comportamento documentado, das páginas dos próprios fornecedores, com o mês em que cada página foi verificada:

Duas coisas são iguais em todos os casos. O que uma reunião deixa é um documento por reunião, no único idioma que a sala usou; e saber se os próximos passos da semana passada foram cumpridos não é algo que o documento sabe — o líder vai e confere antes de escrever "concluído". O lado de legendas ao vivo das plataformas — o que o Teams e o Google Meet mostram na tela durante uma chamada — não muda o documento depois. Os notetakers são a mesma categoria, um passo adiante: os comparados em alternativas ao Otter.ai escrevem um resumo por reunião, e um relatório que abrange um mês de reuniões continua sendo uma página à parte.

Como o relatório se monta sozinho a partir dos recaps

O InterMIND é um espaço de comunicação em que um projeto vive em um canal, de modo que a matéria-prima do relatório tem um lugar óbvio. Toda reunião no canal termina com um recap — um resumo, as decisões, os itens de ação com responsáveis e datas — escrito a partir da própria reunião e entregue por e-mail, como mensagem no canal e como link no evento do calendário. Cada membro conectado o lê no próprio idioma: o registro é traduzido por leitor, não escrito uma vez no idioma que a sala por acaso usou, e o mesmo vale para o chat do canal ao redor, digitado por cada membro no próprio idioma. Qualquer membro pode editar o recap, toda edição mantém autor e histórico de revisões, e o canal guarda o recap de cada sessão passada — então "concluído desde o último relatório" é rolar pelos recaps da semana, e não uma reconstrução.

Os itens de ação carregam seu status consigo. Um item aparece como a fazer, feito ou não feito com um motivo, e, em uma organização com as páginas de status da equipe ativadas, os itens em aberto das sessões anteriores são avaliados quando o recap seguinte é escrito: um item que alguém informou como concluído é marcado como feito, um item discutido mas não concluído é marcado como não feito com o motivo nas palavras da reunião, e um item que ninguém mencionou continua em aberto. Esse é o bloco "ações em aberto" do modelo, mantido pelas reuniões em vez de pelo líder.

As páginas de status da equipe são de onde vem o resto do relatório. Uma página sobre os últimos 7, 28 ou 90 dias lista as tarefas, os problemas, o que é importante e urgente e o dinheiro em jogo na organização, e cada linha traz a citação literal do recap em que se baseia; uma tarefa permanece até que alguém a feche e, depois de quatro semanas sem movimento, é marcada como parada. O líder escreve a linha de tendência e a cor — o julgamento — sobre uma página que as reuniões já preencheram. A mesma página pode ser lida por meio de um assistente conectado: um líder que trabalha no Claude, no ChatGPT, no Copilot ou no Gemini pede as tarefas e os problemas em aberto da semana e recebe as linhas com suas citações. As páginas de status da equipe são um recurso em preview nos planos pagos: o administrador da organização as ativa em Settings → Advanced depois de aceitar os termos alfa (a página Recursos em preview descreve cada um).

Quando o relatório precisa chegar a um sistema de registro, o host adiciona uma cópia do recap a qualquer endereço — a caixa de entrada de um CRM ou de uma ferramenta de acompanhamento de projetos — e todo recap da reunião ou do canal também é enviado para lá, após uma confirmação única do endereço; a mecânica está em uma cópia de cada recap de reunião no seu CRM, por e-mail, e o mesmo recap chega como webhook ou gatilho do Zapier para as equipes que preferem publicá-lo elas mesmas em uma ferramenta de acompanhamento.

Um stakeholder do cliente que deve ver os recaps é convidado ao canal por e-mail e entra com uma conta gratuita, lendo no próprio idioma; participantes externos em um canal não custam nada ao host. Um convidado de uma reunião entra por link, sem conta e sem custo — pelo celular, no navegador — e ouve a reunião ao vivo no próprio idioma. Não há registro para um convidado depois — a conta é gratuita, e é ela que torna o registro acessível. O host oferece o espaço e, em um plano pago, paga apenas pelos membros ativos nos 28 dias anteriores; os membros que ficam inativos mantêm o acesso sem custo.

• Abrir um recap completo — um registro real, gerado pelo mesmo código que escreve os seus.
• Testar a demo ao vivo — sem cadastro; fale e ouça a sala traduzida para cada ouvinte.

O relatório como ofício sobrevive a qualquer ferramenta: alguém ainda precisa dizer se o projeto está dentro do plano e por quê. O que não precisa sobreviver é a meia hora de sexta-feira — voltar a uma semana de chamadas, em um só idioma, para descobrir o que foi combinado e se alguém fez.

FAQ

O que é um relatório de status de projeto?

Uma página curta, de formato fixo, enviada em uma cadência — geralmente semanal — que diz a quem está fora do trabalho diário onde um projeto está: um status geral em uma linha com o motivo, o que foi concluído desde o último relatório, o que está planejado até o próximo, os riscos e problemas com seu efeito sobre o prazo ou o orçamento, as decisões que se pede ao leitor que tome e as ações ainda em aberto com responsáveis e prazos. É sempre a mesma página, para que o leitor compare semanas em vez de ler do zero.

O que um relatório de status semanal deve incluir?

Seis blocos: um cabeçalho com o período do relatório; uma linha de status geral com o motivo; o progresso desde o último relatório como resultados, não atividades; os compromissos para o próximo período com responsáveis; riscos, problemas e decisões necessárias, cada um com seu efeito e um pedido; e toda ação em aberto com responsável e prazo, com as atrasadas marcadas. Deixe de fora diálogo, horas e tudo aquilo sobre o qual o leitor não pode agir.

Como escrever um relatório de status de projeto?

Comece pelo relatório anterior: o bloco "próximo período" dele é o checklist desta semana, e as ações em aberto ou foram concluídas ou continuam abertas. Depois percorra os recaps das reuniões da semana para ver o que foi decidido e o que foi acrescentado. Escreva a linha de status por último, depois do bloco de riscos, para que a cor combine com os fatos. Envie no mesmo dia toda semana, para a mesma lista, e mantenha os títulos idênticos de um relatório para o outro.

Qual é a diferença entre um relatório de status e uma reunião de status?

Um relatório de status é escrito e lido de forma assíncrona; uma reunião de status é a mesma informação entregue ao vivo, ao custo do tempo de todos na sala. Existindo um relatório, a reunião se justifica quando a página não dá conta: uma decisão com trade-off entre stakeholders, uma data que está se movendo, um risco que acabou de virar problema ou um novo stakeholder que precisa entender o formato do projeto uma única vez. Uma reunião cuja pauta é "atualização de cada pessoa" é um relatório lido em voz alta.

Um modelo de relatório semanal para líder de equipe é diferente de um relatório de status de projeto?

É mais curto e dirigido a uma só pessoa. O relatório semanal de um líder de equipe para o gestor responde a três perguntas em quatro blocos — status em uma linha, o que a equipe entregou com nomes, o que está atrapalhando e quem pode removê-lo, e o que é necessário do gestor e até quando — e cabe em uma mensagem de chat. Um relatório de status de projeto é mais longo, abrange um período e um conjunto de stakeholders e traz riscos, decisões e ações em aberto de todas as reuniões do projeto.

Com que frequência um relatório de status de projeto deve ser enviado?

Semanalmente na maioria dos projetos: com frequência suficiente para que um atraso seja percebido em até uma semana, e rara o bastante para que cada relatório traga algo novo. A cadência quinzenal serve a projetos longos e estáveis, com poucas decisões; relatório diário pertence a uma semana de lançamento ou a um incidente e é outro documento, mais curto. Seja qual for a cadência, o dia e a lista de destinatários não devem mudar — um relatório que chega em um dia diferente a cada semana não é lido como uma série.

O cliente deve receber o relatório de status?

Sim, se o cliente paga pelo projeto e uma decisão do relatório cabe a ele — o bloco "decisões necessárias" é escrito para ele. Sempre que possível, escreva um único relatório para todos, em vez de uma versão para o cliente e outra interna; um relatório com duas versões se afasta uma da outra, e a interna acaba virando a verdadeira. O que fica fora de um relatório compartilhado são os detalhes internos da equipe — desempenho individual, estimativas em negociação —, que pertencem às anotações do próprio líder.

Fontes: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" suggests next steps; Slack — Meeting agenda template (canvas). As páginas da Microsoft sobre notas, do Google Meet sobre notas e do Slack foram verificadas em outubro de 2026; o anúncio do Google sobre próximos passos, em setembro de 2026; as páginas do recap da Microsoft e do resumo de reunião do Zoom, em agosto de 2026. Os fornecedores mudam planos, recursos e listas de idiomas com o tempo; consulte as páginas deles para saber o estado atual.