Buzz Control, Operações

Playbook do RevOps de Operações (v3)

Sistema de gestão operado sobre a camada de automação do BuzzControl
Dono: Leandro (RevOps de Operações)
Patrocinador: Dodo (COO)
Versão v3 · agosto/2026

Natureza deste documento

Documento interno de referência operacional da Buzz. Descreve como o sistema de gestão funciona, quais são os rituais e quais números a operação persegue. Serve de orientação e treinamento.

Este playbook não é documento contratual e não integra contrato de prestação de serviços. Escopo contratado, entregáveis, prazos e critérios de aceite do RevOps vivem exclusivamente no Anexo I do contrato (Escopo e Nível de Serviço). Em caso de divergência entre este playbook e o Anexo I, prevalece o Anexo I.
Motivo: o playbook descreve rotina interna, horário e cadência de time. Vincular isso a contrato de prestação de serviço PJ cria risco de descaracterização da natureza do contrato. Os dois documentos existem, com funções separadas.

Missão

Garantir previsibilidade, eficiência e qualidade de execução nos processos ponta a ponta da Buzz (vendas, locação, contratos, atendimento e pós), operando o sistema de gestão em cima da camada de automação do BuzzControl: governança de dados, cadência de rituais, SLAs e melhoria contínua.

Regra de ouro 1: nenhum ritual ou rotina deste playbook pode depender do COO para acontecer. Se depende, está mal desenhado.
Regra de ouro 2 (nova na v3): nenhum ritual pode depender de uma única pessoa, inclusive do próprio RevOps. Toda rotina crítica tem substituto designado e documentação suficiente para outra pessoa rodar o dia. Ver a seção Continuidade do RevOps.
Documentação oficial: projeto RevOps no Bitrix24. Todo o trabalho do RevOps é formalizado exclusivamente em um projeto específico no Bitrix24: processos documentados, avanços, atas, amostragens, backlog e todo registro que este playbook exigir. Nenhuma outra ferramenta é usada para formalização, atualização ou anotação. O IntelBuzz Hub segue apenas como canal de comunicação de mudanças e treinamento.
Como o RevOps é medido
A v2 media a operação inteira e não media o RevOps. Estes são os seis números do próprio RevOps. Metas marcadas como calibrar 30d são propostas e serão fechadas com dados reais nos primeiros 30 dias.
R1 · Devolutiva da fila
100%
das inconsistências novas do Guardião devolvidas ao responsável em até 1 dia útil
R2 · Fila envelhecida calibrar 30d
≤ 15 itens
em aberto há mais de 48h, no fechamento de cada semana
R3 · Aderência a SLA calibrar 30d
≥ 90%
de cumprimento de SLA nos funis sob governança, a partir do 2º mês
R4 · Cadência de rituais
100% / 95%
governanças semanais realizadas com ata no mesmo dia · dias úteis com rotina diária registrada
R5 · Ações no prazo
≥ 85%
das ações abertas na governança concluídas dentro do prazo acordado
R6 · Redução de reincidência calibrar 30d
-20% / trimestre
na taxa de reincidência do mesmo campo pela mesma pessoa
Regra de suspensão. Meta do RevOps que dependa de entrega do núcleo de tech fica suspensa enquanto a dependência estiver aberta e registrada no projeto RevOps com data. Sem dependência registrada, não há suspensão.
Papéis e donos

O RevOps opera o sistema. O COO define estratégia, patrocina mudanças e é o último nível de escalada. O núcleo de tech constrói e conserta.

FrenteRevOps (Leandro)COO (Dodo) e times
Rotina operacional diáriaExecuta sozinho e cobra direto os responsáveisGerentes e corretores respondem às cobranças no prazo
Fila do GuardiãoTrata e devolveCorretores e gestores corrigem na origem
Governança semanalPrepara e apresentaDodo participa e decide o que empata
Review mensalApresenta tendências e backlogDodo prioriza projetos estruturantes
Mudanças de regra e processoPropõe e implantaDodo aprova quando afeta comissão, meta ou estrutura
Onboarding e certificação de corretorAplica trilha, audita e certificaGerente da frente responde pelo plano de correção do não certificado
Incidentes de infraestruturaComunica os times e ativa contingênciaNúcleo de tech resolve
Construção de automação, dashboard e regra do GuardiãoEscreve a spec e valida a entregaNúcleo de tech implementa
Núcleo de tech: dono e prazos

A v2 citava "núcleo de tech" quatro vezes sem definir quem é nem em quanto tempo atende. Três das quatro entregas dos 61 a 90 dias dependem dele. Sem nome e prazo, a meta do RevOps não é cobrável.

ItemDefiniçãoStatus
Dono nomeadoPessoa ou fornecedor responsável por implementar spec, corrigir fluxo quebrado e manter a VPSa nomear pelo COO
Canal único de demandaToda demanda entra como tarefa no projeto RevOps do Bitrix24, nunca por mensagem avulsadefinido
P1: fluxo quebrado ou serviço fora do arResposta em 2h úteis, correção ou contingência em 1 dia útilproposto
P2: fluxo calculando erradoDiagnóstico em 2 dias úteis, correção em 5 dias úteisproposto
P3: nova regra do Guardião ou automaçãoParecer de viabilidade em 3 dias úteis, entrega em até 15 dias úteis após priorizaçãoproposto
Dashboards e BIConstrução é do núcleo de tech. O RevOps especifica, valida e usa. Manutenção de conteúdo e conferência de números é do RevOpsdefinido
Dependência aberta há mais de 2x o prazo acima vira pauta nomeada da governança semanal, com o nome do item e o tempo parado.
Arquitetura operacional
0
Automação (BuzzControl)
Base do sistema. A máquina cobre 100% dos registros e o humano trata exceção.
  • Guardião do Cadastro: validação automática Vista x Bitrix24, gera fila de inconsistências
  • Agentes IA de WhatsApp: primeira resposta e qualificação de leads dos lançamentos (Oceanview, Vergê, Villas Setai, La Mare)
  • Escalada automática de leads: corretor, gerente, COO, com registro de tempo
  • Coach Semanal: relatório automático de performance por corretor via WhatsApp
  • Buzz Score: ranking ponderado com regras de elegibilidade e bloqueio
  • Reserva de unidades via WhatsApp com timestamp automático
  • Dashboards BI: vendas, propostas, negócios perdidos, ranking
1
Execução diária
Rotina operacional de fila, SLA e cobrança de exceção. Executada pelo RevOps, sem reunião.
2
Governança semanal
Qualidade, cumprimento de SLA, gargalos e ações corretivas.
3
Performance mensal
Tendências, coortes, projetos estruturantes e recalibração.
Funis sob governança

Cada funil tem definição documentada de entrada e saída por etapa, motivo de perda padronizado e dono.

  • Atendimento e qualificação (leads gerais)
  • Ágilis (leads de campanha)
  • Locação residencial e comercial (inclui MED401 e Baía Sul Mulher)
  • Contratos: cadastro e checagem, minuta, assinatura eletrônica, pós-assinatura
  • NPS e pós-atendimento
Governança de dados

Modelo: auditoria por exceção

O Guardião varre todos os registros e aponta inconsistências. O trabalho humano é tratar a fila, não caçar erro.

  • Diário: Leandro revisa a fila do Guardião e devolve correções aos responsáveis com prazo de 24h
  • Semanal: análise de reincidência por pessoa e por campo. Reincidência vira pauta de treinamento ou ajuste de regra
  • Amostragem manual estratificada: somente nos pontos que o Guardião ainda não cobre
Metas da fila (novas na v3). A v2 dava prazo ao responsável e nenhum ao RevOps, então a fila podia crescer sem ninguém descumprir nada.
· 100% das inconsistências novas devolvidas em até 1 dia útil
· Fila em aberto há mais de 48h: ≤ 15 itens no fechamento da semana calibrar 30d
· Item na fila há mais de 7 dias: escalada obrigatória ao gerente da frente
· Fila total em crescimento por 2 semanas seguidas: pauta obrigatória da governança

Campos críticos por processo

  • Origem do lead, canal e campanha/UTM quando aplicável
  • Responsável atual
  • Etapa atual e data de entrada na etapa
  • Motivo de perda padronizado (taxonomia do dashboard de negócios perdidos)
  • Próxima ação e data

Regras

  • Campo obrigatório tem justificativa documentada no dicionário de dados
  • Padrão de nomes para imóveis, condomínios, proprietários e contratos
  • Proibido em campo-chave: traço, "ok", "a definir"

Escada de reincidência

A v2 dizia que reincidência "impacta o Buzz Score quando recorrente", sem definir o que é recorrente nem o quanto impacta. Regra sem número vira negociação caso a caso com o corretor. Contagem por pessoa e campo, dentro do mês corrente.

OcorrênciaConsequênciaQuem executa
1ª no mêsDevolutiva individual com prazo de 24h. Sem penalidadeRevOps
2ª do mesmo campoRegistro no projeto RevOps + devolutiva nominal no Coach SemanalRevOps
3ª do mesmo campoPenalidade no Buzz Score peso a definir com o COO + treinamento dirigido obrigatório (15 a 30 min)RevOps aplica, COO valida o peso
4ª ou maisPauta nomeada da governança semanal. O gerente da frente apresenta plano de açãoGerente da frente
O contador zera todo mês. Correção dentro do prazo de 24h na 1ª e 2ª ocorrência não conta para a escada: o objetivo é corrigir, não punir.

Amostragem manual estratificada

A v2 pedia 10 a 20 itens por semana para 5 funis, sem critério de seleção. Amostra pequena e sem estrato dá viés e não permite estimar taxa de erro real.

  • Volume mínimo: 25 registros por semana, somente em trechos sem cobertura do Guardião
  • Estrato por funil: mínimo de 5 registros por funil sem cobertura automática
  • Estrato por pessoa: mínimo de 2 registros por responsável ativo a cada mês
  • Seleção: aleatória entre os registros movimentados na semana, nunca escolhida a dedo
  • Registro: campo, tipo de erro, responsável, funil e data, no projeto RevOps do Bitrix24
  • Virou candidato a regra do Guardião quando: o mesmo padrão aparece 3 vezes ou em 2 responsáveis distintos
  • Depois de a regra entrar em produção, a amostragem manual daquele ponto é encerrada
Integridade dos fluxos automatizados

O RevOps é dono da integridade de todos os fluxos automatizados: mapeia cada processo, verifica se o dado está fluindo correto de ponta a ponta e trata desvios como inconsistência de dados. Toda verificação e ocorrência é registrada no projeto RevOps do Bitrix24.

FluxoO que o RevOps verificaStatus no escopo
Escalada de leads prioritáriosLeads prioritários repassados ao corretor certo, no tempo certo, e fallback funcionando quando o corretor não assumeem rotina
Buzz ScoreMétricas calculando corretamente, sem código quebrado: conferência periódica dos números do ranking contra a baseem rotina
Coach CarteiraRotina de alertas de carteira rodando na cadência prevista e chegando aos corretores certosnovo no escopo
Rotina do HubNova rotina do IntelBuzz Hub incluída no acompanhamento do RevOpsnovo no escopo
Painel V3 dos agentesAtualização de tabelas e disponibilidades dos agentes IA em diajá gerenciado
Agente do Funil ÁgilisPreenchimento automático do campo Campanha nos leads rodando sem falha e sem lead ficando para trásem rotina
Contratos: checagem, minuta e assinaturaAlerta de estouro de SLA em cada etapa e follow-up automático de assinatura pendente a cada 48ha instrumentar
Locação: chamados e primeira respostaAlerta de estouro de SLA de primeira resposta e de resolução de chamado padrãoa instrumentar
NPSDisparo automático nos gatilhos definidos e abertura de tarefa para detratora implantar
Fluxo automatizado parado ou calculando errado é inconsistência de dado em escala. Entra na fila do dia com a mesma prioridade da fila do Guardião.
Correção da v2: a tabela de SLA prometia cobertura de contratos e locação, mas nenhum fluxo desses dois funis era monitorado. Enquanto estiverem marcados como "a instrumentar", o acompanhamento é manual e a meta R3 não os inclui.
SLAs

Números iniciais propostos. Calibrar com dados reais do BuzzControl nos primeiros 30 dias e revisar trimestralmente. A coluna de monitoramento diz se o estouro dispara alerta sozinho ou depende de olho humano.

ProcessoRegraSLAMonitoramento
Leads de lançamentoPrimeira respostaImediata via agente IAautomático
Corretor assume a conversa15 min em horário comercialautomático
Escalada ao gerente30 min sem ação do corretorautomático
Escalada ao COO2h sem ação após escalada ao gerenteautomático
Funil comercialProposta registrada no CRM4h úteis após negociaçãomanual
Proposta sem movimentaçãoAlerta em 48hautomático
ContratosChecagem de cadastro completa1 dia útila instrumentar
Emissão de minuta2 dias úteis após checagem aprovadaa instrumentar
Follow-up de assinatura pendenteA cada 48ha instrumentar
LocaçãoPrimeira resposta a solicitação2h úteisa instrumentar
Resolução de chamado padrão3 dias úteisa instrumentar
NPSDisparo após o gatilhoConforme tabela de gatilhosa implantar
Tratamento de detratorTarefa aberta ao gerente em 24ha implantar
Toda regra de SLA define quando o relógio começa e para, exceções (feriado, fora de horário, dependência externa) e gatilho de alerta automático. SLA sem alerta automático é meta de intenção, não de sistema: instrumentar é prioridade do backlog.
KPIs, metas e consequências

Métrica sem consequência é decoração. E meta sem número não dispara consequência nenhuma. A v2 tinha as métricas e as consequências, mas nenhuma meta. Estes são os números.

BlocoMétricaMetaConsequência quando fura
Performance comercialConversão etapa a etapa por funilNão cair mais de 10% contra a média móvel de 90 dias calibrarBuzz Score: ranking, elegibilidade de leads prioritários, bloqueio por performance
Tempo médio por etapa e idade do backlogDentro do SLA da etapa; idade média do backlog ≤ 15 dias calibrar
VGV realizado x meta≥ 100% da meta mensal
Qualidade de dadosRegistros sem inconsistência no Guardião≥ 95% calibrarDevolutiva no Coach Semanal e escada de reincidência a partir da 3ª ocorrência
Taxa de reincidência por corretor e por campo≤ 8% dos registros do responsável no mês calibrar
Eficiência operacionalCumprimento de SLA por funil≥ 90% nos funis instrumentadosPauta obrigatória e nomeada da governança semanal, com plano do gerente da frente
Backlog por etapaNenhuma etapa com mais de 20% do total parado calibrar
Satisfação e adoçãoNPS por etapa e por time≥ 70, a partir da implantaçãoPlano de ação nomeado no review mensal. Sistema que ninguém usa é gargalo do RevOps, não do time
Leitura do Coach Semanal≥ 80% dos corretores ativos
Correções devolvidas no prazo de 24h≥ 90%
Metas marcadas com calibrar são propostas iniciais e serão fechadas ao fim dos primeiros 30 dias, com aprovação do COO registrada em ata da governança.
Escada de escalada quando a cobrança é ignorada

A v2 dava ao RevOps o poder de cobrar corretor e gerente, mas não dizia o que fazer quando a cobrança é ignorada. A única saída era "vira pauta da governança", ou seja, até 7 dias de atraso. Responsabilidade sem autoridade é o jeito mais rápido de queimar um RevOps.

MomentoAçãoRegistro
D0Cobrança individual e direta ao responsável, com prazo de 24h e critério de conclusão. Nunca em grupoProjeto RevOps no Bitrix24
D+1, venceuSegunda cobrança ao responsável, com cópia ao gerente da frente. Novo prazo de 24hMesma tarefa, comentário
D+2, venceu de novoEscalada ao COO com nome, item, histórico das duas cobranças e impactoTarefa escalada + aviso ao COO
Gerente não responde em 24hEscalada direta ao COO no mesmo dia, sem esperar a governançaTarefa escalada
3 vencimentos no mês da mesma pessoaPauta nomeada da governança semanal e entrada na escada de reincidênciaAta da governança
O RevOps não tem poder disciplinar e não é chefe de ninguém. O que ele tem é o direito de escalar em prazo definido e o dever de registrar. A decisão sobre a pessoa é sempre do gerente da frente ou do COO.
Rituais

Rotina operacional diária · Leandro executa · Sem reunião

Não é reunião. É um checklist que o RevOps roda sozinho, todo dia útil, na primeira metade da manhã. A cobrança de rotina já é automatizada (alerta de feedback de visita atrasado, cobrança de conferência de visitas, escalada de leads): o papel do RevOps é tratar a exceção, ou seja, quem ignorou o alerta. Cobrança é sempre individual e direta com o responsável, nunca em grupo.

Checklist diário, na ordem
#BlocoO que fazerOndeEssencial
1Filas e SLAsAbrir o painel operacional: o que estourou ou está prestes a estourar. Escalar direto ao gerente responsável, na horaBuzz Controlsim
2Fila do GuardiãoDevolver as inconsistências novas aos responsáveis com prazo de 24h. Cobrar nominalmente o que venceuBuzz Control + Bitrix24sim
3VisitasConferir o alerta de feedback de visita atrasado e a cobrança de conferência de visitas: quem não respondeu ao alerta automático é cobrado diretoAlertas WhatsApp + Bitrix24não
4Fluxos automatizadosChecagem rápida de integridade: agentes IA respondendo, escalada de leads rodando, Ágilis preenchendo campanha, Coach e Buzz Score na cadênciaBuzz Controlsim
5RegistroRegistrar as ações e cobranças do dia (dono, prazo, critério) até o fim da manhãProjeto RevOps no Bitrix24sim
A coluna Essencial define o checklist reduzido que o substituto roda em caso de ausência do RevOps. Ver Continuidade do RevOps.
Regras da rotina. Todo dia útil, na primeira metade da manhã. O que a automação já cobra, o RevOps não cobra de novo: só trata quem ignorou o alerta. Cobrança individual e direta, com prazo, nunca em grupo. Virou tema de decisão, impedimento entre times ou reincidência: vira pauta da governança semanal, não conversa avulsa.
Saída obrigatória: a rotina só termina quando as ações e cobranças do dia estão registradas no projeto RevOps do Bitrix24 (dono, prazo e critério de conclusão) até o fim da manhã, e as escalações de SLA foram feitas na hora.

Governança semanal

30 a 60 min · Dodo participa · dia e hora fixos
  • Números da semana, abertos por funil e com conversão por etapa
  • Top 3 gargalos com causa provável e o dado que a prova
  • Ações com responsável, prazo e critério de conclusão
  • Ajustes de regra e necessidades de treinamento
  • Dependências de tech abertas além do prazo
Pronto quando: material enviado até 4h antes e ata publicada no mesmo dia.

Review mensal

60 a 90 min · Dodo prioriza
  • Tendências e coortes de VGV
  • Painel de metas do RevOps (R1 a R6) do mês fechado
  • Backlog de melhorias priorizado por score
  • NPS por etapa e por time, com motivos de detratores
  • Recalibração de SLAs e metas quando necessário

Trimestral

Dono: RevOps propõe · COO aprova
  • Revisão de etapas de funil, taxonomia de dados e deste playbook
  • Revisão das trilhas de treinamento no IntelBuzz Hub
  • Teste de continuidade: substituto roda a rotina por 1 dia útil
  • Teste de restauração do backup
Pronto quando: nova versão do playbook publicada com aprovação do COO registrada em ata.
O diagnóstico das perguntas-guia (apêndice) chega pronto antes da governança, gerado pelo agente de BI. A reunião começa na decisão, não no levantamento.
Onboarding e certificação de corretor entrante

Frente inteira que não existia na v2 e que hoje não acontece de forma estruturada. Gatilho: entrada de corretor novo, comunicada pelo gerente da frente ao RevOps no mesmo dia.

MarcoO que aconteceCritério
D0 a D7Liberação de acessos nominais, trilha no IntelBuzz Hub, dicionário de dados e regras dos funis em que vai atuarTrilha concluída e registrada no Hub
D7Prova prática acompanhada: cadastrar lead, mover etapa, registrar proposta e fechar com motivo de perda padronizadoExecuta os 4 passos sem erro de campo crítico
D301ª auditoria dirigida de todos os registros dele, com devolutiva individualDevolutiva entregue e pendências corrigidas em 48h
D60Certificação de aderência ao funil≤ 5% de inconsistência no Guardião nos últimos 30 dias calibrar e 100% dos campos críticos preenchidos
Não certificado no D60Plano de 15 dias construído com o gerente da frentePlano registrado no projeto RevOps
Não certificado no D75Perde elegibilidade a leads prioritários até certificarDecisão do COO, aplicada via Buzz Score
Registro da certificação: campo no Bitrix24 do corretor + tarefa no projeto RevOps. Meta de cobertura: 100% dos entrantes certificados até o 60º dia.
NPS: rotina de coleta

A v2 tratava NPS como funil sob governança e como KPI, mas nenhuma rotina o coletava. KPI sem coleta é campo vazio. Implantação depende do núcleo de tech.

GatilhoQuando disparaPúblico
Visita realizada48h após o feedback de visitaCliente visitante
Contrato de venda assinado7 dias após a assinaturaComprador
Contrato de locação assinado7 dias após a assinaturaLocatário
Chamado de manutenção resolvido24h após o encerramentoLocatário ou proprietário
  • Canal: WhatsApp automático via BuzzControl, escala de 0 a 10 mais campo aberto
  • Detrator (0 a 6): abre tarefa automática para o gerente da frente em até 24h, com o texto da resposta
  • Consolidação: mensal no review, aberta por etapa e por time, com os motivos agrupados
  • Meta: NPS ≥ 70 a partir do primeiro trimestre completo de coleta
Acessos, sigilo e proteção de dados

A v2 não tinha uma linha sobre isso, apesar de o RevOps ter acesso nominal à base inteira de leads, clientes, proprietários e contratos. A Buzz é controladora dos dados; quem opera responde perante ela.

Nível de acesso
SistemaNível
Bitrix24Leitura e edição nos funis sob governança
Vista CRMSomente leitura
IntelBuzz BISomente leitura
Buzz ControlOperação do painel, sem acesso a credenciais
VPS e banco de dadosSem acesso. Exclusivo do núcleo de tech
Regras inegociáveis
  • Acesso nominal, nunca compartilhado. Princípio do menor privilégio
  • Proibido exportar base de leads, clientes ou contratos para arquivo local, e-mail pessoal ou nuvem pessoal
  • Nenhuma automação, token ou webhook em conta pessoal. Tudo roda em infra da Buzz
  • Dado pessoal tratado apenas para a finalidade da governança operacional
  • Incidente (vazamento, acesso indevido, exportação não autorizada): comunicar o COO em até 2h
  • Ao término da relação: revogação de todos os acessos em 24h e declaração de exclusão de cópias em 5 dias
  • Sigilo permanece após o fim da relação
Todo artefato produzido no exercício da função (dashboards, queries, specs, automações, documentação) pertence à Buzz.
Continuidade do RevOps

A v2 dizia que nenhum ritual pode depender do COO. Correto. Mas todos passaram a depender do RevOps: férias, doença ou saída e a operação inteira para. O gargalo só mudou de nome.

Ausência planejada ou não planejada
  • Substituto designado: a nomear pelo COO
  • Checklist reduzido: blocos 1, 2, 4 e 5 da rotina diária (os marcados como essenciais)
  • Governança semanal: mantida, conduzida pelo substituto com material do último ciclo
  • Escalada: na ausência, tudo que passaria pelo RevOps vai direto ao gerente da frente
  • Teste trimestral: o substituto roda a rotina por 1 dia útil, com o RevOps disponível mas sem intervir
Handover em caso de saída
  • Transferência assistida durante todo o período de aviso
  • Entrega de: documentação de processos, dicionário de dados, specs pendentes, backlog pontuado e atas
  • Lista de dependências abertas com o núcleo de tech
  • Devolução de acessos e declaração de exclusão de cópias
  • Sessão de passagem com o substituto e com o COO, registrada em ata
Critério de documentação viva: outra pessoa consegue rodar um dia completo da operação lendo apenas o projeto RevOps do Bitrix24. Se não consegue, a documentação está incompleta.
Gestão de mudanças · Ciclo de 3 semanas

Toda mudança de regra ou processo segue o ciclo de 3 semanas, com o IntelBuzz Hub como canal oficial.

MomentoO que acontece
Dia 0Card no IntelBuzz Hub com uma página: o que mudou, por quê, quando vale, como será medido. Treinamento de 15 a 30 min com exemplos
Semana 1Acompanhamento ativo e correção em tempo real
Semana 2Verificação via Guardião ou auditoria dirigida, com devolutiva
Semana 3Estabilização. Se a regra não pegou, o problema é a regra ou o treinamento, nunca só a cobrança
Mudança que afeta comissão, meta ou estrutura só entra no ciclo após aprovação formal do COO.
Continuidade e incidentes de infraestrutura

O sistema roda sobre infraestrutura própria (BuzzControl no VPS Hetzner). Indisponibilidade é risco operacional direto.

  • Monitoramento com alerta automático de queda dos serviços críticos: agentes de WhatsApp, Guardião, escalada de leads, dashboards
  • Runbook de incidente: quem é acionado, em que ordem, e o que comunicar aos times
  • Contingência comercial: se o agente IA cair em horário de plantão, leads de lançamento vão direto para distribuição manual com notificação ao gerente do empreendimento
  • Backup verificado do banco (PostgreSQL) e das configurações, com teste de restauração trimestral
  • Todo incidente gera registro: causa, tempo de indisponibilidade, impacto e prevenção

Priorização de melhorias

Score = Impacto × Frequência ÷ Esforço

Critérios de impacto (receita, experiência ou eficiência):

  • Reduz SLA
  • Aumenta conversão
  • Reduz retrabalho
  • Reduz perda por erro de processo
O backlog priorizado vive no projeto RevOps do Bitrix24 e é revisado no review mensal. Mínimo de 10 itens pontuados, com os 3 primeiros trazendo impacto estimado.
Plano 30-60-90 do RevOps (Leandro)
Clique em cada item para abrir o passo a passo: o que fazer, onde, de quem depende e quando está pronto. Item com dependência externa só é cobrável se a dependência foi registrada e atendida no prazo.
0 a 30 dias
Assumir o sistema
Dominar a fila do Guardião e o painel operacional
O que é

O Guardião varre Vista e Bitrix24 todos os dias e gera uma fila de inconsistências (campo faltando, dado divergente, anexo ausente, nome fora do padrão). O painel operacional do Buzz Control mostra essa fila, os alertas de SLA e o status das automações.

Como fazer
  1. Acessar o painel Buzz Control com login próprio e abrir a fila do Guardião
  2. Entender cada tipo de inconsistência: o que a regra valida, de onde vem o dado (Vista ou Bitrix) e quem é o responsável pela correção
  3. Rodar o ciclo diário: revisar a fila pela manhã, devolver cada pendência ao responsável com prazo de 24h, marcar as tratadas
  4. No dia seguinte, conferir o que foi corrigido e cobrar o que venceu
  5. Abrir os dashboards BI e localizar os painéis de funil, leads, vendas e ranking
Depende de
Liberação de acessos nominais
Onde
Buzz Control (painel operacional) Bitrix24: buzz.bitrix24.com.br IntelBuzz BI: intelbuzz.com.br/bi
Pronto quando: conduz o ciclo completo de um dia da fila sem apoio e sabe explicar cada tipo de inconsistência e seu responsável.
Calibrar SLAs e fechar as metas numéricas
O que é

Os SLAs e todas as metas marcadas com "calibrar" neste playbook são propostas iniciais. A tarefa é medir os números reais e fechar as metas com o COO.

Como fazer
  1. Nos dashboards BI, extrair tempo médio e P90 de cada etapa dos 5 funis (primeira resposta, corretor assume, proposta no CRM, checagem, minuta, assinatura)
  2. Medir a linha de base das metas do RevOps (R2, R3, R6) e das metas de KPI marcadas como "calibrar"
  3. Propor o número calibrado: regra prática é partir do P75 real e apertar gradualmente
  4. Levar a tabela revisada à governança semanal para aprovação do COO
  5. Publicar a v3.1 do playbook com os números aprovados e a data de vigência
Onde
IntelBuzz BI: /bi/funil e /bi/leads Buzz Control (tempos de escalada) Este playbook (SLAs e KPIs)
Pronto quando: nenhuma meta deste playbook continua marcada como "calibrar", e a aprovação do COO está registrada em ata.
Assumir a rotina diária e a governança semanal
O que é

Os dois rituais centrais passam a ser do RevOps, sem depender do COO: o checklist diário (sem reunião) e a governança semanal.

Como fazer
  1. Semana 1: rodar o checklist diário acompanhado, conhecendo o painel, a fila do Guardião e os alertas automáticos existentes
  2. Semana 2 em diante: rodar sozinho, com registro diário no projeto RevOps do Bitrix24
  3. Governança semanal: semanas 1 e 2 preparar o material e assistir, semana 3 conduzir com o COO presente, semana 4 em diante conduzir sozinho
  4. Registrar ata curta de cada governança (decisões e ações) e cobrar as pendências na rotina diária
Onde
Agenda fixa (seção Rituais) Projeto RevOps no Bitrix24 (atas e ações)
Pronto quando: duas semanas seguidas rodando a rotina diária e conduzindo a governança sem depender do COO, com R4 em 100%.
Mapear os pontos que o Guardião ainda não cobre
O que é

O Guardião cobre cadastro de imóveis e parte dos dados do CRM. Contratos, locação, cessão e pós ainda têm trechos sem validação automática. Esses buracos são onde o erro passa despercebido.

Como fazer
  1. Listar, funil por funil, quais campos críticos têm validação automática e quais não têm
  2. Rodar a amostragem estratificada (25 registros por semana, mínimo de 5 por funil e 2 por responsável) nos trechos sem cobertura
  3. Anotar todo padrão de erro encontrado (campo, tipo de erro, frequência, responsável)
  4. Transformar em candidato a regra do Guardião o padrão que aparecer 3 vezes ou em 2 responsáveis distintos
Onde
Bitrix24 (registros dos funis) Vista CRM Projeto RevOps no Bitrix24 (amostragens)
Pronto quando: mapa de cobertura documentado com pelo menos 5 candidatos a nova regra.
Estruturar a trilha de onboarding do corretor entrante
O que é

Frente que não existia. Montar a trilha, a prova prática do D7 e o critério de certificação do D60, conforme a seção de onboarding deste playbook.

Como fazer
  1. Montar a trilha no IntelBuzz Hub com os módulos de CRM, funis e dicionário de dados
  2. Escrever o roteiro da prova prática do D7 (4 passos, critério objetivo de aprovação)
  3. Definir com o COO o percentual de corte da certificação do D60
  4. Criar o campo de certificação no Bitrix24 e o modelo de tarefa de acompanhamento
  5. Aplicar no primeiro corretor entrante e ajustar
Depende de
Campo no Bitrix24 (núcleo de tech)
Pronto quando: trilha publicada, critério aprovado pelo COO e primeiro entrante rodando o fluxo.
31 a 60 dias
Padronizar e fechar buracos
Documentar entrada e saída de cada etapa dos 5 funis
O que é

Cada etapa de cada funil precisa de critério objetivo: o que faz um negócio entrar nela e o que precisa estar feito para sair. Sem isso, conversão por etapa vira número sem significado.

Como fazer
  1. Abrir cada funil no Bitrix24 e listar as etapas reais em uso
  2. Para cada etapa, escrever: critério de entrada, critério de saída, campos obrigatórios e dono
  3. Padronizar os motivos de perda com a taxonomia do dashboard de negócios perdidos
  4. Validar cada funil com o gerente responsável em 30 minutos de conversa
  5. Publicar no projeto RevOps do Bitrix24 e comunicar via IntelBuzz Hub
Onde
Bitrix24 (funis) Projeto RevOps no Bitrix24 IntelBuzz Hub (comunicação)
Pronto quando: os 5 funis publicados e validados pelos gerentes de cada frente.
Consolidar o dicionário de dados
O que é

Documento único que define cada campo crítico: o que significa, formato aceito, por que é obrigatório e exemplos certos e errados. É a referência do Guardião e dos treinamentos.

Como fazer
  1. Partir da lista de campos críticos da seção Governança de dados
  2. Para cada campo: nome, definição, formato, justificativa da obrigatoriedade, exemplos válidos e inválidos
  3. Incluir o padrão de nomes de imóveis, condomínios, proprietários e contratos
  4. Revisar com quem preenche no dia a dia (corretores, contratos, locação) para pegar ambiguidades
  5. Publicar e vincular à trilha de onboarding
Onde
Projeto RevOps no Bitrix24 (dicionário) Bitrix24 (campos reais)
Pronto quando: dicionário publicado e citado como referência pelas regras do Guardião e pelos treinamentos.
Instrumentar os SLAs de contratos e locação
O que é

Correção de uma inconsistência da v2: a tabela de SLA promete cobertura de contratos e locação, mas nenhum desses fluxos tem alerta automático. Hoje o acompanhamento é manual e fura.

Como fazer
  1. Escrever a spec de alerta para cada SLA: checagem de cadastro, emissão de minuta, follow-up de assinatura, primeira resposta de locação e resolução de chamado
  2. Definir para cada um: quando o relógio começa, quando para, exceções e destinatário do alerta
  3. Entregar a spec ao núcleo de tech e acompanhar a implantação
  4. Validar com 2 semanas de dados antes de contar na meta R3
Depende de
Núcleo de tech (P3: até 15 dias úteis)
Pronto quando: os 5 alertas rodando e os funis de contratos e locação entrando no cálculo de R3.
Rodar o primeiro ciclo completo de gestão de mudanças
O que é

Estrear na prática o ciclo de 3 semanas, com uma mudança real de regra ou processo.

Como fazer
  1. Escolher uma mudança real e de escopo pequeno (ex.: novo campo obrigatório ou novo motivo de perda)
  2. Dia 0: publicar o card no IntelBuzz Hub (o que mudou, por quê, quando vale, como será medido) e treinar em 15 a 30 min
  3. Semana 1: acompanhar de perto e corrigir em tempo real
  4. Semana 2: verificar adoção via Guardião ou auditoria dirigida e dar devolutiva
  5. Semana 3: estabilizar e registrar aprendizados do ciclo
Onde
IntelBuzz Hub (canal oficial) Guardião (verificação)
Pronto quando: ciclo fechado com medição de adoção e aprendizados registrados.
Montar o backlog de melhorias priorizado
O que é

Lista única e pontuada de tudo que pode melhorar o sistema, ordenada pelo score de priorização. É o que alimenta o review mensal.

Como fazer
  1. Coletar dores da rotina diária, da governança semanal e das amostragens
  2. Pontuar cada item: Score = Impacto x Frequência / Esforço
  3. Ordenar e publicar no projeto RevOps do Bitrix24
  4. Levar o topo do backlog ao review mensal para o COO priorizar os estruturantes
Onde
Projeto RevOps no Bitrix24 (backlog)
Pronto quando: backlog com 10 ou mais itens pontuados, com os 3 primeiros trazendo impacto estimado, revisado no primeiro review mensal.
61 a 90 dias
Escalar
Ativar o diagnóstico automático das perguntas-guia
O que é

As 5 perguntas-guia do apêndice passam a ser respondidas automaticamente pelo agente de BI toda segunda-feira, antes da governança semanal. A reunião começa na decisão, não no levantamento.

Como fazer
  1. Especificar com o núcleo de tech cada pergunta como consulta automática (fonte de dado, cálculo, formato da resposta)
  2. Definir o envio: toda segunda de manhã, via WhatsApp, para Leandro e Dodo
  3. Rodar 2 ciclos de validação conferindo os números contra os dashboards
  4. Ajustar o que vier errado ou sem contexto e só então considerar ativo
Depende de
Núcleo de tech (P3: até 15 dias úteis)
Pronto quando: relatório chega sozinho toda segunda, com números batendo com os dashboards.
Implantar monitoramento e runbook de incidentes
O que é

Sistema de alerta automático de queda dos serviços críticos e documento que define quem faz o quê durante um incidente.

Como fazer
  1. Listar com o núcleo de tech os serviços críticos: agentes de WhatsApp, Guardião, escalada de leads, dashboards
  2. Definir alerta automático de queda para cada um (destino: grupo de incidentes)
  3. Escrever o runbook: quem é acionado, em que ordem, o que comunicar aos times e quando ativar a contingência
  4. Testar a contingência comercial uma vez: agente IA fora do ar em plantão leva lead direto para distribuição manual com aviso ao gerente
  5. Confirmar rotina de backup do banco com teste de restauração trimestral agendado
Depende de
Núcleo de tech (acesso à VPS)
Pronto quando: alerta disparando em teste, runbook publicado e uma simulação de contingência executada.
Propor as 3 primeiras regras novas do Guardião
O que é

Transformar os padrões de erro encontrados nas amostragens em regras automáticas, ampliando a cobertura do Guardião e reduzindo trabalho manual.

Como fazer
  1. Pegar os padrões mais recorrentes do mapa de lacunas (tarefa dos primeiros 30 dias)
  2. Escrever a spec de cada regra: campo validado, condição de erro, mensagem gerada e responsável pela correção
  3. Priorizar as 3 primeiras pelo score de priorização
  4. Entregar as specs ao núcleo de tech e acompanhar a implantação
  5. Depois de ativa, a amostragem manual daquele ponto deixa de existir
Depende de
Núcleo de tech (P3: até 15 dias úteis por regra)
Pronto quando: 3 specs entregues e pelo menos 1 regra rodando em produção.
Implantar a coleta de NPS
O que é

O NPS é funil sob governança e KPI desde a v2, mas nunca teve rotina de coleta. Sem disparo, o indicador é campo vazio.

Como fazer
  1. Especificar os 4 gatilhos da seção NPS: pós-visita, pós-venda, pós-locação e pós-chamado
  2. Definir a mensagem, a escala de 0 a 10 e o campo aberto
  3. Especificar a abertura automática de tarefa ao gerente quando a nota for de 0 a 6
  4. Rodar 2 semanas de piloto em um funil antes de abrir para todos
  5. Levar a primeira consolidação ao review mensal
Depende de
Núcleo de tech (disparo via BuzzControl)
Pronto quando: os 4 gatilhos disparando, detrator gerando tarefa e primeira leitura apresentada no review.
Primeiro teste de continuidade e review trimestral
O que é

Fechamento do ciclo de 90 dias: provar que a operação roda sem o RevOps por um dia, olhar os dados do trimestre e recalibrar.

Como fazer
  1. Rodar o teste de continuidade: o substituto designado executa o checklist reduzido por 1 dia útil, com o RevOps disponível mas sem intervir
  2. Registrar o que travou e corrigir a documentação nos pontos que faltaram
  3. Consolidar 90 dias de dados: SLA por funil, conversão por etapa, qualidade de dados, reincidência e metas R1 a R6
  4. Recalibrar os SLAs e metas que ficaram frouxos ou inalcançáveis
  5. Propor a v4 do playbook e submeter ao aceite do COO
Onde
IntelBuzz BI (dados do trimestre) Este playbook (v4) IntelBuzz Hub
Pronto quando: teste de continuidade executado com registro, e v4 publicada com aceite do COO em ata.
Controle de versão e aprovação

Para ser referência de treinamento e de cobrança, o playbook precisa de versão, data de vigência e aprovador. A v2 era revisada pelo próprio RevOps, o que significava aprovar o próprio trabalho.

VersãoDataO que mudouAprovação
v2julho/2026Sistema de gestão sobre a camada de automação, rituais, plano 30-60-90-
v3agosto/2026Metas numéricas em todos os KPIs, painel de metas do RevOps (R1 a R6), escada de reincidência e de escalada, amostragem estratificada, núcleo de tech com prazos, onboarding e certificação de corretor, rotina de NPS, seção de acessos e proteção de dados, continuidade do RevOps, separação entre playbook e anexo contratualpendente COO
v3.1previsto: 30 diasFechamento das metas marcadas como "calibrar" com dados reais-
v4previsto: 90 diasRecalibração trimestral completa-
Regra de alteração. Mudança é proposta pelo RevOps, aprovada pelo COO em ata da governança, publicada com número de versão e data, e comunicada no IntelBuzz Hub. A regra vale a partir da comunicação, nunca retroativamente. Revisão trimestral é obrigatória e exige aceite registrado do COO.
Apêndice · Perguntas-guia

Respondidas automaticamente toda segunda-feira pelo agente de BI com dados do BuzzControl, enviadas a Leandro e Dodo antes da governança semanal.

  • Qual é o gargalo número 1 da semana e qual dado prova isso?
  • Qual etapa de qual funil tem mais tempo parado?
  • Onde a qualidade de dados está quebrando e quem reincide?
  • Qual SLA foi mais estourado e por quê?
  • Qual mudança recente melhorou ou piorou os KPIs?
Pendências de decisão do COO
#DecisãoImpacto se não decidir
1Nomear o núcleo de tech e validar os prazos P1, P2 e P3Três das cinco entregas de 61 a 90 dias ficam sem prazo cobrável
2Nomear o substituto designado do RevOpsOperação inteira para em férias, doença ou saída
3Definir o peso da penalidade no Buzz Score na 3ª reincidênciaEscada de reincidência não é aplicável
4Definir o percentual de corte da certificação do corretor no D60Certificação vira avaliação subjetiva
5Aprovar as metas marcadas como calibrar após os 30 diasKPI sem meta não dispara consequência
6Confirmar se locação, contratos e NPS integram o escopo contratado do RevOpsPlaybook e contrato descrevem trabalhos diferentes