CRM da bLOw

O CRM reúne informações de clientes, histórico de contatos e tarefas da equipe de relacionamento em um só lugar. Nesta fase ilustrativa, o objetivo é substituir planilhas dispersas e dar contexto antes de cada atendimento. Será usado pelas equipes de relacionamento e operação; não é uma ferramenta aberta ao cliente.

Próximo marco ilustrativo: piloto com 5 pessoas da equipe de relacionamento em 15/10/2026. Bloqueio atual: regra de acesso a contatos sem responsável ainda precisa de decisão. Decisão necessária até: 30/09/2026. As datas só demonstram como registrar o andamento; não são compromisso da bLOw.

Dentro desta fase: contatos, busca, histórico de atendimento, responsável pelo contato, tarefas e permissões básicas. Fora desta fase: campanhas de marketing, integração financeira, pontuação automática de leads e IA que responda ou altere registros sem revisão humana. Mudanças de escopo devem apontar para um pedido aprovado, não aparecer silenciosamente nesta lista.

O exemplo usa entregas pequenas: cada função passa por revisão de código, teste automatizado e teste com alguém da operação antes de chegar ao piloto. O quadro de trabalho mostra A fazer → Em desenvolvimento → Em revisão → Em teste → Pronto. A equipe registra decisões duradouras separadamente, com contexto e motivo, para que o próximo desenvolvedor entenda por que a solução foi escolhida.

Os caminhos a seguir são um exemplo de mapa, não links nem nomes de repositórios existentes. Na versão real, substituir por URLs de acesso interno, caminho exato, branch principal e pessoa responsável. Não colocar tokens, credenciais ou arquivos de ambiente nesta ficha.

Na ficha real, acrescentar: links dos repositórios, caminho dos pipelines, convenção de branches, arquivo de configuração de infraestrutura, local dos contratos da API e link para o quadro de tarefas. O README do Git ensina a executar o código; esta ficha oferece a visão geral e aponta para a fonte técnica.

Integrações externas do exemplo: importação inicial de contatos por arquivo aprovado; integração com atendimento ainda em análise. Na ficha real, listar origem e destino dos dados, quem é dono da integração, frequência, modo de falha e link do contrato. Se uma plataforma não estiver escolhida, escrever “a definir”, com dono e prazo, em vez de inventar uma escolha.

O CRM pode conter dados pessoais e histórico de relacionamento. Cada perfil deve acessar somente o necessário para seu trabalho. Exportação, exclusão e alteração precisam de regras e trilha de auditoria. A ficha real deve apontar para a política aprovada de retenção, base legal, resposta a pedidos de titulares e tratamento de incidentes de dados — sem copiar dados de clientes para a documentação.

Pendente neste exemplo: definir matriz de permissões por função e prazo de retenção com as pessoas responsáveis por segurança e privacidade. Nenhuma dessas regras deve ser tratada como aprovada só por aparecer aqui.

Na versão real, registrar quais ferramentas foram aprovadas, para que tarefas, com qual política de dados, quem autoriza e quando a decisão foi revisada. Não listar “usamos IA” sem explicar o que ela faz; também não afirmar que uma ferramenta é usada pela bLOw sem confirmação.

Exemplo: desenvolvimento local → ambiente de teste → piloto → produção. A publicação exige revisão, testes e migrações compatíveis. A página real deve ter links internos dos ambientes, pipeline de implantação, instruções de acesso, checklist de liberação e procedimento de rollback. Não publicar senhas nem URLs privadas de administração numa página aberta.

Antes do piloto, validar importação, permissões, restauração de backup e o que acontecerá com dados criados durante um rollback. A pessoa que autoriza a ida a produção e o horário de suporte da primeira semana devem estar escritos aqui.

Na versão real, completar: canal de suporte, horário de atendimento, pessoa de plantão ou rota de escalonamento, painel de saúde, alertas, logs, instruções de rollback, runbooks e prazos de resposta acordados. No exemplo, esses contatos ainda não existem; não use esta tabela como runbook de produção.

Decisões importantes devem ter registro próprio e estável; quando uma decisão mudar, criar um novo registro que substitua o anterior e ligar os dois. A ficha resume e aponta para esses registros, sem esconder o histórico.

1. Toda semana durante a construção: atualizar estado por frente, próximo marco, bloqueios, dono e data da revisão.
2. A cada mudança técnica relevante: atualizar mapa do Git, plataformas, integrações, ambientes e link da decisão.
3. Antes de produção: preencher sustentação, contatos, acessos, observabilidade, backup e rollback; obter revisão de quem vai operar o sistema.
4. Depois do lançamento: revisar ao menos mensalmente e sempre após incidente, troca de responsável ou alteração de arquitetura.

Regra de manutenção: quem muda o sistema atualiza a parte afetada da ficha no mesmo trabalho; a pessoa responsável pela ficha confere se os links continuam válidos. Se uma informação ainda é desconhecida, marcar “a definir” com responsável e prazo. Não deixar uma data antiga parecer informação atual.

Esta ficha combina a orientação do GitHub para README e orientação de repositório, o registro de decisões de arquitetura descrito pela Microsoft e a atenção à operação e ao suporte do Google SRE. É uma adaptação para a necessidade da bLOw, não um formulário oficial dessas organizações.