CRM
O primeiro pilar e a espinha dorsal: leads de Ads, contatos de Social e execuções de agentes AI todos desaguam aqui. Cada Conquista (client) tem seu próprio CRM.
Mapa de entidades
company ──1:N── contact ──M:N── deal ──N:1── stage ──N:1── pipeline
│ │ │ │
└─ contact_company │ └─ deal_contact (papéis)
│
activity / task / note (timeline polimórfica)
tag · list / segment · custom_field_def
Entidades núcleo
Todas herdam o Base Table Template (id, workspace_id, custom, version, timestamps, deleted_at).
Multi-canal: contact_email / contact_phone em child tables (não JSONB) — porque precisamos buscar e deduplicar por e-mail. contact_company é M:N com papel.
Pipelines & deals
pipeline / stage
Múltiplos pipelines por client (ex: "Vendas", "Onboarding"). Cada stage tem probability (forecast) e rot_days (alerta de deal esquecido).
deal_contact
Associação com papéis: decision_maker, champion, influencer, user. Um deal envolve várias pessoas.
Listas & segmentos
list · estática
Membros fixos (list_member). Útil pra campanhas pontuais e importações.
segment · dinâmico
Um filter jsonb resolvido em runtime (ex: lifecycle=customer AND source.channel=meta_ads). Base pras automações.
Amarrações com o Core
O CRM não é uma ilha — ele consome e alimenta os outros pilares.
Source cross-pillar
O webhook Meta Lead Ads → contact.created (Core #5/#7) preenche source.connection_id automático. Ads alimenta o CRM em tempo real.
Eventos emitidos
Para o Event Bus (Core #7), disparando automações, agentes e analytics sem acoplamento.
Dedup / merge
Chave natural = e-mail normalizado por client (unique parcial). Merge reatribui activities/deals ao sobrevivente e loga no audit_log.
Consent → Notifications
consent jsonb alimenta o stream de marketing (Core #11); do_not_contact é respeitado por todo envio.
Protótipo de telas
Mockups de produto (dados fictícios) para discutir layout, densidade e fluxo.
Próximos blocos
Serviços / API
tRPC, operações-chave: merge, convert-lead-to-deal, forecast, máquina de automações.
planejado