Cruzamento entre o processo real (7 canvases oficiais do Slack + canvas upstream de Detecção de Crise NewByte) e o projeto da Carol (plano em 5 fases de 01/10 + status 21/08/2026 revisado pela Fabíola). O objetivo é identificar onde está o esforço, o que já está contemplado e o que ficou de fora — sem propor automação além do que o cruzamento sustenta.
Rayanne Oliveira · BackOffice Franquias · 01 de outubro de 2026
FATO extraído dos materiais
ANÁLISE cruzamento / dedução
ND informação não disponível
A. Plano Carol (01/10/2026)
B. 7 canvases de Danos (set/2026)
C. Canvas Detecção de Crise NewByte (jul/2026)
D. Melhorias no processo de danos · 21/08/2026 (Fabíola)
Fontes lidas
8
+1 status 21/08
Cards no kanban
141
em 30/09 · todas as fases
Taxa de pagamento
63%
histórico de danos encerrados
Automações no backlog
19
+ 4 Pedidos à Tech em aberto
Resumo executivo
O que mudou com a leitura do processo e do status 21/08
O projeto da Carol cobre bem as duas principais dores apontadas pela Fabi — finalização no Airbnb e contatos com hóspedes — e a área já possui 4 automações próprias em diferentes estágios de maturidade.
O cruzamento com o processo real, porém, evidencia 5 fluxos operacionais ainda não contemplados, 4 padrões já existentes que o plano ignora ou acaba reinventando, 1 risco de regressão ainda não mapeado e 4 Pedidos à Tech em aberto desde junho/julho de 2026, alguns há mais de 60 dias. Esses pedidos já estão sendo cobrados pela área e permanecem como pendências para evolução do processo.
Fluxos não contemplados
Dano Esdrúxulo (5 critérios de escalada)
Multas Airbnb (fluxo próprio de 72h)
Monitor diário AirCover por e-mail delegado
EasyCover caminho Proprietário
Seguros RC Airbnb/Booking (Crawford)
Padrões já existentes ignorados
Lista oficial de 3+10 motivos (encerramento)
Tags [Danos] ... da NewByte
3 templates aprovados pela Meta
Regra "último comentário = relato do hóspede" (Olimpo)
Duas frentes do projeto de automação da área · status 21/08/2026
A frente própria ataca o meio do fluxo; cada Pedido à Tech ataca uma etapa específica
Nomenclatura do próprio projeto (fonte D): Extensão 1-3 + Automação 4 (frente própria, não depende da fila da Tech) · Pedidos 1-4 à Tech (exigem mudança no Sapron). Esta tabela reconcilia com as Fases 1-5 do plano repassado em 01/10.
Etapa 1
Lançamento
Franquia · Seazone Host
Dano entra com descrição curta, print de conversa no lugar de foto do item e sem motivo do acionamento.
Pedido 1Pedido 4
Etapa 2
Validação
Analista de Danos (Fabi)
Valida sem o contexto que precisa. A tratativa acontece na NewByte, fora do card.
Pedido 4
Etapa 3
Acionamento
AirCover · EasyCover · hóspede
Formulário longo preenchido à mão, um por dano. Franquia não sabia se o imóvel tinha EasyCover.
Pedido 3Ext 1·2·3
Etapa 4
Finalização e reembolso
Analista + franquia
Marcar como pago é uma tela, registrar o reembolso é outra. Sem campo de origem do dinheiro.
Pedido 2Pedido 3Automação 4
Frente própria · extensões
O que estamos construindo por conta própria
Quatro automações que não dependem da fila da Tech. Encurtam o trabalho repetitivo de acionar cobertura, falar com o hóspede e repassar o caso — onde a Fabi gasta a maior parte do tempo. Nenhuma substitui os Pedidos à Tech.
01
Extensão 1 · AirCover Autofill
Preenche automaticamente o formulário do AirCover a partir do "Capturar dano" no Sapron. 5/7 passos automatizados; anexo de imagem ainda manual; tela de revisão instável.
EM TESTE
02
Extensão 2 · Abertura de sinistro EasyCover
Mesmo princípio aplicado ao formulário do seguro. Complexidade menor que a primeira. Em 21/08 era "próxima da fila"; evolução pós-21/08 colocou em produção.
EM PRODUÇÃO
03
Extensão 3 · Comunicação com hóspedes outras OTAs
Sugere resposta a partir do contexto do dano e do histórico de tratativas. Equivale às Fases 3 e 4 do plano atual.
PLANEJADA
04
Automação 4 · Lançamento automático para o Jurídico
Thread no Slack marcando o Jurídico com os dados do dano quando entra em Cobrança Judicial. Olimpo entrou em produção entre 21/08 e 27/08.
EM PRODUÇÃO
Ganho principal
Tira a passagem de bastão manual do fim do fluxo
Em desenvolvimento
Extensão 1 em segundo plano · estabilizar tela de revisão
Ideia a testar
Quando franquia lança item como "Outros", inferir o item real pela descrição
Frente dependente · 4 Pedidos à Tech em aberto
01
Excluir card de dano lançado incorretamente
Solicitado em 22/06/2026 · 60 dias em aberto · afeta Etapa 1 — Lançamento
Backlog sem previsão
O que trava hoje
Sistema não permite excluir card de dano lançado errado — só cancelar. Cancelamento mantém vínculo de "dano existente" na reserva, o que bloqueia o lançamento correto. A Fabi corrige o card à mão.
O que foi pedido
Permitir excluir o card, não apenas cancelar
Ao excluir, liberar a reserva para novo lançamento correto
Como isso ajuda o processo
Devolve a correção para quem errou. Hoje o erro da franquia vira trabalho manual da analista.
Sherlog Holmes classificou como solicitação operacional (Sapron) e repassou para investigação de banco. Karol respondeu que não é alta prioridade.
02
Finalização do dano com reembolso e origem do pagamento na mesma tela
Solicitado em 22/06/2026 · 60 dias em aberto · afeta Etapa 4 — Finalização
Escalado ao board
O que trava hoje
Finalizar o dano como "Pago" e registrar o reembolso são dois momentos separados. Não existe campo para dizer quem pagou — um dano pago pelo AirCover e um pago pelo hóspede ficam idênticos na base.
O que foi pedido
Unificar em uma única tela a finalização "Pago" + registro do reembolso
Campo obrigatório origem do pagamento: AirCover, Hóspede, EasyCover, Outro
Campo aberto quando a resposta for "Outro"
Como isso ajuda o processo
Dois ganhos: um passo a menos por dano finalizado + passa a existir o dado de quem realmente paga os danos (preenchível também retroativamente).
David Soares reforçou que ajuda a mapear a origem do pagador. Karol escalou para o board.
03
Visibilidade do EasyCover — cobertura no Host e valor pago para a franquia
Solicitado em 16/06/2026 · 66 dias · 1 dos 2 itens entregue · afeta Etapas 3 e 4
Parcialmente entregue
O que trava hoje
O Seazone Host não trazia a informação de cobertura. Franquia não sabia se o imóvel tinha EasyCover nem que podia chamar a Assistência 24h. E a franquia vê o valor cobrado no dano, mas não o valor efetivamente pago.
O que foi pedido
Entregue Exibir no Host quais imóveis têm seguro
Pendente Mostrar à franquia valor efetivamente pago (cobrado × pago)
Como isso ajuda o processo
Coloca a informação onde a decisão é tomada. A transparência cobrado × pago tira da analista o papel de responder caso a caso quanto entrou de cada dano.
Ralph Breno confirmou inclusão no backlog. Item de cobrado × pago segue pendente.
04
Qualidade do lançamento e da validação — evidência, prints e conversa vinculada
Solicitado em 14/07/2026 · 38 dias em aberto · pacote de 7 itens · nenhum entregue · afeta Etapas 1 e 2
Internalizado no roadmap
O que trava hoje
Dano chega sem o material que a validação exige. Tratativa até fechar isso acontece na NewByte, fora do card, misturada com outros assuntos.
Pacote de 7 itens
Descrição obrigatória, mínimo 30 caracteres
Campo separado para prints de conversa
Impedir print nos campos de Evidências e Orçamentos
Validação de evidência: foto do item completo + close
Criar conversa na Central de Atividades vinculada ao card
Campo obrigatório "Motivo do acionamento" como primeira mensagem
Exibir a conversa na própria tela do dano
Como isso ajuda o processo
Age na entrada, corrige a causa e não o efeito. Evidência completa no lançamento = cobrança sai na primeira tentativa.
Ajuste pendente no próprio pedido. Bloquear print no campo de Orçamentos não funciona: muitas franquias enviam print de loja como orçamento. O bloqueio precisa mirar print de conversa (WhatsApp), não captura de tela em geral. Precisa voltar à Tech e detalhar.
Karol internalizou e priorizou no roadmap. Nenhum dos 7 itens implementado até agora.
Só a Tech resolve
Liberar a reserva travada (Pedido 1)
Criar o dado de origem do pagamento (Pedido 2) — schema de banco
Mostrar à franquia cobrado × pago (Pedido 3 pendente)
Obrigar evidência no lançamento (Pedido 4)
Vincular conversa ao card (Pedido 4)
Estamos resolvendo por fora
Preencher o formulário do AirCover (Ext 1)
Abrir o sinistro no EasyCover (Ext 2)
Redigir a comunicação com o hóspede (Ext 3)
Repassar o caso ao Jurídico (Automação 4)
Reforço mútuo
As duas frentes se reforçam: quanto melhor a evidência que entra (Pedido 4), mais a extensão consegue preencher sozinha sem rodada de complementação. E a origem do pagamento (Pedido 2) fecha o ciclo que a extensão abre no acionamento.
Arquitetura de processos de Danos
12 processos de Danos + 1 upstream (Detecção de Crise NewByte)
Macroprocesso Gestão de Danos de Hóspede — da identificação do dano pelo franqueado ao encerramento financeiro no Sapron.
Nível 2 · 12 processos de Danos + 1 adjacente
P1 Entrada
P5 Cobrança · Multas Airbnb
P9 Seguro RC · Booking
P2 Triagem & Validação
P6 Cobrança · Hóspede (NewByte/PayPal)
P10 Extrajudicial / Judicial
P3 Roteamento
P7 Seguro · EasyCover
P11 Encerramento & Reembolso
P4 Cobrança · AirCover
P8 Seguro RC · Airbnb
P12 Controle de prazos (transversal)
P0 upstream
Detecção de Crise em Conversas do NewByte — processo adjacente, dono é o Gerente de Relacionamento a Franquias. Gera alerta em #alertas-crise-franquias quando franquia envia mensagem com palavra-gatilho. Uma das rotas de encaminhamento é o Processo de Danos (SAPRON). Serve como novo canal de entrada para P1. FATO Canvas atualizado em 21/07/2026. ND se automação já está em produção ou é desenho futuro.
Nível 3 · subprocessos, regras e pontos manuais
Detecção de Crise NewByte
P0 · upstream · Gerente de Relacionamento
Objetivo
Identificar relato de crise no NewByte em tempo real e alertar o gerente
Franquia escreve no NewByte→P0 Detecção de Crise→ alerta em #alertas-crise-franquias → (rota: Danos)
↓Franquia abre dano no Sapron→P2 Triagem↓Esdrúxulo?─sim→ Base de Conhecimento (fora da automação)
↓ nãoEvidências OK?─não→ NewByte pedir info ──loop
↓ simP3 Roteamento↓
┌──────────────┬────┴─────┬───────────────┬────────────────────┐
↓↓↓↓↓P4 AirCoverP5 MultasP6 NewByteP7 EasyCoverP8/P9 RC↓Pago?─não→P10 Extra/Judicial (se ≥R$250)
↓ simP11 Encerramento
Principais pontos manuais e retrabalhos
Códigos M## referenciados no backlog final
ID
Ponto manual
Processo
Natureza
M01
Clique final da Extensão 1 + resolver ⚠ ortografia + anexar foto
P4
Manual + conferência
M02
Redigir justificativa (ChatGPT) no "Pedir ajuda ao Airbnb" após 24h
P4
Julgamento humano
M03
Login diário no e-mail delegado anfitriao@seazone com 2FA via gestor Slack
P4
Repetição + dependência de pessoa
M04
Buscar conversa NewByte pelo código da reserva
P6
Cópia/cola
M05
Enviar template NewByte e registrar tratativa no Sapron
P6
Preenchimento + 2 sistemas
M06
Criar fatura PayPal com dados do dano
P6
Preenchimento manual
M07
Abrir ticket em #suporte-financeiro para cartão
P6
Preenchimento manual
M08
Anexar documentos no portal EasyCover
P7
Preenchimento manual
M09
Copiar protocolo NS do EasyCover para o Sapron
P7
Cópia/cola
M10
Consultar Pipefy CS para dados do proprietário (caminho EasyCover Proprietário)
P7
Múltiplos sistemas
M11
Baixar anexos do Sapron e colar na thread Slack do jurídico
P10
Download/upload manual
M12
Preencher formulário Liability Airbnb
P8
Preenchimento manual
M13
Preencher aviso de sinistro Booking (sem código de reserva)
P9
Preenchimento + risco de erro
M14
Finalização no Sapron (status + motivo texto livre + reembolso em telas separadas)
P11
Múltiplas telas + texto livre
M15
Mudar card para "Cobrança Judicial" garantindo último comentário = relato
P10
Disciplina humana
M16
Monitorar prazos (24h/14d AirCover · 72h multa · 7d jurídico)
P12
Acompanhamento manual
M17
Decidir se dano é Esdrúxulo
P2
Julgamento humano
Retrabalhos recorrentes
ID
O que acontece
Causa
R1
Franquia envia info incompleta na Validação
Lançamento sem evidência/NF — depende da franquia
R2
Travamento da Extensão 1 → excluir pedido Airbnb e refazer
Aba Airbnb em segundo plano · instabilidade do portal
R3
Comentário entrou depois do move p/ Judicial → Olimpo pega texto errado
Regra "último comentário = relato" depende de disciplina humana
R4
Variação ortográfica do motivo → relatório inconsistente
Campo texto livre no encerramento (Pedido 2 resolveria)
Controles paralelos
Drive com apólices EasyCover
Drive com comprovantes de sinistro
Planilha de bilhetes EasyCover (coluna O)
Pipefy CS Base de proprietários
Vault para credenciais PayPal e código 2FA
Dependências de pessoa
Gestor → código 2FA do e-mail anfitriao@seazone
Kremer (PF) → recebe pagamentos dos Seguros RC e repassa
Ana Pivanti → jurídico
Fabi → GPT pessoal usado para elaborar respostas
Cruzamento com o plano Carol
Já coberto · parcial · fora · conflitos
Já contemplado
Processo
Correspondência
Finalização Airbnb M14
Fase 1
Prazos 24h/14d M16 parcial
Fase 2
Contatos NewByte M04+M05
Fase 3
Assistente respostas NewByte
Fase 4
Anexos jurídico M11
Fase 5
Extensão 1 AirCover Autofill
Automação atual (lacuna fechamento 22/06)
Extensão 2 sinistro-easycover
Automação atual (só caminho Seazone)
Extensão 3 Assistente NewByte
Qualidade inferior ao GPT da Fabi
Automação 4 Olimpo
Anexos manuais pós-27/08
Parcialmente contemplado
Processo
Cobre
Falta
Lista de motivos
Fase 1 fala em "lista fixa"
Não cita a lista oficial do canvas (3+10)
Tags NewByte
Fase 3 fala em registro Sapron
Não cita [Danos] Primeiro/Segundo/Terceiro contato
EasyCover
Plano diz "nenhuma lacuna"
Só caminho Seazone — Proprietário ainda manual
Rollback das extensões
"Versão anterior disponível"
Sem detalhe de como
Prazos
Fase 2 cobre 24h/14d
Não cobre 72h multas, 7d jurídico, 2-3d 2º contato
Não contemplado
Processo
Evidência
Dano Esdrúxulo
Canvas Validação · 5 critérios · Base de Conhecimento
Multas Airbnb
Canvas Cobrança 2.2 · fluxo próprio 72h
Monitor diário AirCover por e-mail delegado
Canvas Cobrança 2.3 · "precisa ser diário"
PayPal
Canvas Cobrança 3.1
Ticket cartão
Canvas Cobrança · #suporte-financeiro
Seguro RC Airbnb
Canvas Airbnb inteiro
Seguro RC Booking
Canvas Booking inteiro
Reconciliação reembolso ↔ financeiro
Não aparece em canvas nem no plano
Baseline de métricas
Plano não define
Log local de auditoria
Plano não define
Guard-rail para R3
Risco não mapeado no plano
Interface com P0 Detecção de Crise
Plano não considera esse canal como entrada
Conflitos a esclarecer com Fabi.1) Templates NewByte — plano Carol diz "texto livre está sendo entregue"; canvas Cobrança diz "não podem ser editados, devem ser utilizados exatamente como configurados". 2) Plano diz que canvas cita "Blip e templates WhatsApp que não existem"; os canvases atuais citam NewByte e 3 templates ativos aprovados pela Meta. ANÁLISE Canvas é mais recente — vale rechecar.
Arquitetura comum: a extensão opera na sessão autenticada do usuário, fazendo as mesmas chamadas que a tela faz — padrão da sinistro-easycover. Nada é gravado sem clique humano.
A1A2A3A4+A5A7A8A9A10A11A12A13A14A15A16A17A18A19
Frente Tech · Sapron
Item
Natureza
Status
A6 Hospedagem assistente
Infra (Hub Seazone)
Não aberto · Henry
A5 Tag no NewByte (parcial)
ND NewByte ou Tech
Validar antes
Pedido 1 Excluir card
Schema/banco
60d · sem previsão
Pedido 2 Finalização + origem
Schema + UI
60d · escalado
Pedido 3 Cobrado × pago no Host
Exposição no Host
66d · pendente
Pedido 4 Qualidade lançamento
Formulário + vínculo
38d · nenhum entregue
Revisão
A afirmação "nenhum item exige mudar Sapron" vale só para o backlog A1-A19. O projeto como um todo depende dos 4 Pedidos à Tech, abertos desde jun-jul. A Fase 1 do plano atual (finalização via extensão) parece ter sido a decisão da Carol de resolver por fora o que o Pedido 2 à Tech resolveria no Sapron.
Não viável atualmente
Item
Por quê
Fechamento totalmente autônomo
Risco de erro irreversível em reembolso · restrição do próprio plano
Automação do 2FA do e-mail delegado
Depende do gestor via Slack (política de segurança)
Automação do loop de e-mails com Crawford
Fora do escopo de extensão · A1-A10 cobrem só o lado "abrir sinistro"
Envio em massa pelo WhatsApp
Bloqueio Meta
Repasse Kremer → Seazone (RC)
Processo financeiro externo
A20 Reconciliação reembolso
Fonte autoritativa financeira ND
Atividades que devem permanecer manuais
Atividade
Por quê
Decisão Dano Esdrúxulo
Julgamento humano. Automação só deve detectar e impedir outros automatismos (A8)
Decisão de contestar recusa de AirCover
Avaliação de evidências disponíveis
Clique "GRAVAR" das extensões
Restrição do plano — nada é gravado sem clique humano
Decisão de ir para extrajudicial
Pondera valor, histórico, posição do hóspede
Interlocução por e-mail com Crawford
Risco e julgamento — extensão não deve escrever e-mail em nome da pessoa
Escolha do hóspede certo no filtro Booking
Risco de pegar hóspede errado — exige conferência
Backlog final de automações
Prioridade sem notas numéricas · critério na própria legenda
Alta frequência/volume confirmados no canvas, baixo risco técnico, redução direta de passos manuais · Média sem baseline confirmado ou com dependência a validar · Baixa frequência não quantificada ou valor marginal.
ID
Prio
Proc.
Automação
Resolve
Carol?
Solução
Ext
Sap
Tech
Dep.
A1
Alta
P11
Finalização Airbnb
M14
SIM Fase 1
Painel + lista oficial 3+10 → humano confere → grava
Acesso de leitura ao Sapron para analista do jurídico
Governança + segurança
Carolina + admin
Hospedagem do servidor do assistente
Infra
Carolina + Henry
Capacidade de extensão operar no NewByte
Técnica
Validar antes de A5
Fonte autoritativa do financeiro para A20
Governança
Carolina
Extração do conhecimento do GPT da Fabi
Conhecimento
Fabi + Henry
Baseline por fase (tempo médio, taxa por motivo)
Dados
A17 + A19 habilitam
Rechecar com Fabi se canvas ainda cita "Blip"
Conteúdo
Fabi
Status atual do P0 Detecção de Crise NewByte
Técnica
Gerente de Relacionamento
Checagem final · alguma atividade manual relevante sem proposta?
Sim. Três, com justificativa:
Interlocução por e-mail com Crawford (Seguros RC) — A1-A10-A12-A13 reduzem o lado "abrir sinistro"; o loop seguinte permanece manual por decisão de risco (§8).
Preenchimento do dano pelo franqueado (P1 Entrada) — fora do escopo do plano Carol. Candidato futuro. Pedido 4 à Tech endereça parcialmente.
Decisão de contestar recusa do AirCover — preservada como manual deliberadamente (§8).
Mapa consolidado concluído. Nenhuma automação foi adicionada ou alterada em relação às etapas anteriores — apenas consolidação, padronização de nomenclatura e eliminação de redundâncias.