Testei o Overclock por 30 dias
O gancho (adapte com a tua voz): "30 dias atrás eu comecei a usar o Overclock todo dia. Esse é o review que eu gostaria de ter visto: o que funciona, o que ainda não, e pra quem NÃO é."
Checklist de preparação
Tudo isso pronto antes de ligar a câmera — grava com confiança, não improviса.
- Lista dos projetos feitos nos 30 dias — nome, data, resultado em 1 linha. Essa lista é a prova de uso que aparece no vídeo.
- Separar os pontos que funcionaram dos que não funcionaram — idealmente com exemplos específicos de cada categoria.
- A decisão "continuo usando?" formada antes de gravar. Review sem posição é review sem valor.
- Screenshots ou gravações de momentos específicos dos 30 dias — não vai lembrar dos detalhes sem registro.
- A página /comparacao do Overclock aberta pra referenciar como recurso complementar.
A estrutura que segura view até o fim
Proporções sobre a duração total — num vídeo de 10 min, 10% ≈ 1 min.
Promessa do review honesto + prova concreta de que os 30 dias aconteceram.
- Fala a promessa olhando pra câmera — e menciona explicitamente que vai dizer o que não funciona.
- Mostra a prova de uso: histórico de sessões no Overclock, lista de projetos com datas, ou qualquer registro real dos 30 dias.
- Anuncia a estrutura do vídeo: "o que funciona, o que ainda não, pra quem é e pra quem não é — nessa ordem."
- 💡 O credencial é o que diferencia esse review dos outros. Sem prova de uso real, é só opinião.
3-4 pontos fortes com demo curta real de cada — não lista falada.
- Escolhe 3-4 pontos fortes baseados nos 30 dias — os que mudaram seu fluxo de verdade.
- Pra cada ponto: 1 frase do que é + demo de 1-2 minutos mostrando na tela + estimativa de impacto ("economizo X min/dia com isso").
- Usa exemplos concretos dos 30 dias, não hipotéticos: "aqui, quando fiz [projeto X], isso resolveu assim..."
- 💡 Cada ponto precisa ter demo — vídeo de review que só fala sem mostrar perde credibilidade imediatamente.
- 💡 Começa pelo ponto mais forte — o espectador fica quando o primeiro ponto é o melhor.
2-3 fricções reais com a tela mostrando. Sem drama, sem minimizar.
- Escolhe 2-3 problemas reais que encontrou — com exemplos específicos do que aconteceu.
- Pra cada fricção: mostra (ou recria) o problema na tela. "Aqui, quando tentei fazer X, aconteceu Y."
- Não minimiza com "mas é só um detalhe" — deixa o problema ser o que é.
- Se souber o workaround, mostra depois da demo do problema.
- 💡 Essa seção vem ANTES do veredito — obrigatoriamente. Se vier depois, parece desculpa, não honestidade.
- 💡 Fricções específicas ("o provider X cai quando há mais de 5 panes simultâneos") geram comentários e discussão. Fricções genéricas ("às vezes é lento") não.
Perfis concretos de cada lado — a seção que mais gera confiança e compartilhamento.
- Pra quem É: 2-3 perfis específicos com o motivo — "se você faz [X] e tem [situação Y], o Overclock resolve [problema Z]."
- Pra quem NÃO É: 2-3 perfis igualmente específicos — "se você precisa de [X específico], o Overclock hoje não é a solução."
- Não generaliza: "iniciantes" não é perfil, "alguém que nunca programou e precisa de ajuda pra entender o output do agente" é perfil.
- 💡 A seção "pra quem NÃO é" é a mais compartilhada de qualquer review. Ela sinaliza honestidade ao espectador que ainda não conhece você.
A decisão pessoal + fecho puxando o próximo.
- Diz a decisão diretamente: "continuo usando? Sim/não/depende" — e explica o porquê em 2 frases.
- Diz se trocaria algo: "se o Overclock resolver [fricção X], seria definitivo pra mim."
- Fecho: próximo vídeo da série de updates.
O número que ancora o vídeo
A lista de projetos reais feitos nos 30 dias — com datas. O review é lastreado em uso, não em opinião.
A limitação dita de frente
A seção "o que ainda não funciona" é obrigatória e vem ANTES do veredito — não como nota de rodapé, mas como bloco próprio com demos.
Puxando o próximo vídeo
"Mês que vem tem o update desse review. Entre um e outro, eu documento tudo em vídeo — se inscreve."
O que trava — e como sair
Todo builder bate nesses pontos. Saber antes economiza uma regravação.
| O erro | O fix |
|---|---|
| O review ficou sem posição — "tem prós e contras" sem veredito claro. | Decide antes de gravar: você continua usando ou não? Se a resposta for "depende", explica o que ela depende — mas tem que ter uma posição. Review sem posição não gera confiança nem compartilhamento. |
| A seção "o que funciona" virou promoção — sem crítica, parece patrocinado. | Cada ponto positivo deve ter uma ressalva ou contexto: "isso funciona muito bem quando X, mas quando Y não é a melhor opção." Nenhum ponto forte é universal — encontrar a exceção é o que torna o review confiável. |
Como saber que ficou bom
O vídeo está pronto quando: (1) prova de uso real (lista de projetos com datas) aparece nos primeiros 2 minutos, (2) a seção "o que não funciona" aparece ANTES do veredito, (3) os perfis "pra quem é/não é" têm descrições específicas, não genéricas. Assiste uma vez perguntando: "isso parece review ou promoção?" Se for promoção, adiciona mais fricção.
Outras formas de gravar este roteiro
- Versão 90 dias: espera mais tempo de uso pra ter exemplos mais variados. O número maior no título ajuda no CTR.
- Versão comparação: "testei o Overclock por 30 dias vs [ferramenta X]" — para quem não conhece nenhum dos dois, a comparação é um ângulo de entrada mais forte.
Três títulos prontos
Escolhe um, ou usa como base — número e promessa concreta sempre na frente.
| 01 | Usei o Overclock por 30 DIAS — review sem patrocínio |
| 02 | 30 dias de time de IA: o que funciona e o que ainda não |
| 03 | Overclock depois de 1 mês: vale a pena? |
Publicou e bateu 1.000 views? Comprova antes dos outros.
São 5 assinaturas Ultra pros 5 primeiros — 4 vídeos com 1.000+ views cada (ou 10.000+ num Shorts) e a vaga é sua.