# VALIA × RD Station — Consolidado: Operação, Treinamento e Identidade de Contatos

**Versão:** 1.0 (consolidado)  
**Data:** 01/06/2026  
**Fontes:**

- `VALIA_RD_Station_Nova_Etapa_Treinamento_Uso_Assistido_v2.md`
- [`analise-rdstation-identidade-contatos-2026-06-01.md`](analise-rdstation-identidade-contatos-2026-06-01.md)
- Transcrição reunião Valia × M2BR (jun/2026)
- MVP sandbox [`mvp/`](mvp/) (testes API 01/06/2026)

**Responsáveis M2BR:** Thiago, Bernardo  
**Responsáveis Valia:** Priscila, Bruno Thales, operação comercial, TI Valia

---

## 0. Visão em duas frentes (não misturar)

| Frente | Objetivo | Status | Onde vive |
|--------|----------|--------|-----------|
| **Operação & adoção** | CRM + Marketing em rotina (Priscila, pós-disparo) | Em andamento | Painel RD, treinamento |
| **Identidade & integração** | CPF/FSS, saída Responsys, automações por evento | Estudo/MVP | `mvp/`, análise técnica |
| **Produção M2BR (webhook)** | Leads de LPs → notificação intranet | **Não tocar** no MVP | `intranet-m2br` → `RdStationService` |

```mermaid
flowchart TB
  subgraph operacao [Frente Operacional - prioridade agora]
    MKT[RD Marketing - disparos]
    CRM[RD CRM - views e negociacoes]
    TRN[Treinamento Priscila]
    MKT --> TRN --> CRM
  end

  subgraph tecnico [Frente Tecnica - paralelo controlado]
    VALIA[ERP ou API Valia]
    MID[Middleware identity - futuro]
    MVP[MVP sandbox smoke-test]
    VALIA --> MID
    MVP -.->|valida regras| MID
    MID --> RDAPI[RD Station API]
  end

  subgraph prod [Producao M2BR - intacta]
    RDWH[Webhook RD]
    INTRA[Intranet notificacoes]
    RDWH --> INTRA
  end
```

---

## 1. Mudança de fase do projeto

### Fase anterior (encerrada em espírito)

- Setup Marketing + CRM
- Campos, views, dashboard MVP, reporting inicial
- Integração webhook → intranet (tags de LPs)

### Fase atual (v2 + consenso reunião)

- **Tração operacional:** treinamento, uso assistido, rotina Priscila
- **Pós-disparo:** quem trata lead, negociação, próxima ação, SLA
- **Regras de cadastro** antes de escalar automações “estilo Responsys”
- **Estudo técnico** de identidade (paralelo, sem impactar produção)

> Sucesso agora = **adoção**, não mais “configurar por configurar”.

---

## 2. O que já está feito

### Operação (v2)

- [x] RD Marketing disparando e-mails (Valia)
- [x] Dashboard inicial validado
- [x] Pipeline, campos e views — primeira rodada
- [x] Mapeamento inicial de relatórios, origem, grupo/categoria, funil
- [x] Plano B de reporting se RD limitar campos customizados

### Integração M2BR (produção)

- [x] Webhook `rdstation.php` + `RdStationService` (filtro por tags de LP)
- [x] OAuth Valia no `.env` intranet (`RDSTATION_VALIA_*`)
- [x] Base sanitizada via API (contexto Priscila — aguardando DNS/disparo final quando aplicável)

### Técnico / estudo (M2BR, jun/2026)

- [x] Smoke tests ST-01 a ST-06 na conta real Valia
- [x] 43 campos customizados mapeados (`cf_cpf`, `cf_fss`, `cf_plano`, `cf_data_de_admissao`, `cf_estado_civil`, …)
- [x] MVP sandbox: cenários A, B, C **PASS** (`mvp/reports/`)
- [x] Protótipo identity resolver + cleanup por manifest

---

## 3. Prioridades atuais (ordem recomendada)

| # | Prioridade | Dono principal | Bloqueia |
|---|------------|----------------|----------|
| 1 | Treinamento CRM + narrativa pós-disparo | Bernardo + Thiago | Escala operação |
| 2 | Regra de cadastro (emails/planos) — **versão Valia** | Bruno (doc Responsys) + M2BR | Automações avançadas |
| 3 | Views/dashboard ajustados com Priscila | Thiago | Uso diário |
| 4 | Validação manual painel (tag `smoke-test` só no MVP) | M2BR | — |
| 5 | Middleware Valia→RD (futuro) | M2BR + TI Valia | API tempo real Valia |

---

## 4. Cadastros: e-mail igual para pessoas diferentes (resposta consolidada)

> Substitui e expande a **§4.1** do relatório v2.

### 4.1 O que o RD Station faz (confirmado API + docs)

| Pergunta | Resposta |
|----------|----------|
| Dois contatos com o **mesmo e-mail**? | **Não.** `POST` retorna `EMAIL_ALREADY_IN_USE`. |
| E-mail é identificador único? | **Sim.** Chave nativa; API usa `email` ou `uuid`. |
| CPF como chave primária? | **Não.** Apenas campo customizado `cf_cpf`. |

### 4.2 O que a Valia precisa (mais complexo que “e-mail duplicado”)

| Cenário | Exemplo | Impacto no RD |
|---------|---------|---------------|
| **A** | Mesma pessoa, e-mails diferentes por plano/ano | Risco de **2 contatos** se não houver middleware |
| **B** | E-mail do pai no plano do filho (Pré-Valer) | Mesmo e-mail, **pessoas diferentes** → bloqueio nativo |
| **C** | Mesmo e-mail, vários planos (FSS) | **1 contato** OK; discriminar por `cf_fss` + eventos |
| **D** | Comunicação por plano sem “vazar” para outro | Segmentação por `cf_fss` + evento `admissao_plano` |

**Identificadores de negócio Valia:** CPF (pessoa) + FSS (contrato/plano). E-mail é **informativo**, não chave de negócio.

### 4.3 Regras operacionais recomendadas (treinamento + importação)

**Curto prazo (operação / CRM B2B):**

- E-mail **pessoal** → um contato por e-mail; revisar duplicata antes de importar.
- E-mail **genérico** (`comercial@…`) → tratar como **empresa** ou regra explícita (não misturar histórico de pessoas).
- Casos “mesmo e-mail, pessoas diferentes” → **revisão manual** ou fluxo TI; não forçar segundo contato no RD.

**Médio prazo (automações participantes / saída Responsys):**

- Middleware com resolução CPF → e-mail canônico + eventos (`admissao_plano`, `mudanca_estado_civil`).
- Dependente (cenário B): alias técnico `{cpf}@smoke.valia-m2br.test` (padrão MVP) + metadata no campo `bio` (JSON) — campos `cf_email_real` **não existem** na conta hoje.
- **Não escalar** automações de participante até Bruno enviar lógica Responsys + volume de edge cases.

### 4.4 Evidência MVP (01/06/2026, sandbox isolado)

- Tag obrigatória: `smoke-test`; domínio `@smoke.valia-m2br.test`
- Cenários A, B, C: PASS na API real
- Limitações: tags em minúsculas; `cf_plano` com lista fechada (PREVALER, VALIAPREV, …); cenário A pode gerar **2 contatos** no RD

Detalhe técnico: [`analise-rdstation-identidade-contatos-2026-06-01.md`](analise-rdstation-identidade-contatos-2026-06-01.md) e [`mvp/README.md`](mvp/README.md).

**Protótipo visual (workshop Bruno):** **https://mockupvalia.m2br.com/** — cenários A–D, matriz RULE_*, docs em `/docs/`. Deploy: [`mvp/visual/DEPLOY.md`](mvp/visual/DEPLOY.md).

### 4.5 Pendências Valia (dever de casa Bruno)

- [ ] Documentar solução Responsys (concatenação de chaves, tabelas)
- [ ] Volume: % multi-plano, % e-mail do responsável no dependente
- [ ] API Valia em tempo real para admissão / estado civil
- [ ] Mapa estado civil sistema Valia → valores RD (`CASADO`, `SOLTEIRO`, `VIÚVO`, …)

---

## 5. Automações discutidas (reunião + validação técnica)

| Fluxo | Modelo no RD | Status técnico |
|-------|-------------|----------------|
| Admissão (data → evento) | Conversão `admissao_plano` + segmentação “últimos 30 dias” | Viável (Thiago + API) |
| **E — Ciclo mensal dias 1–5** | `cf_dia_ciclo_mensal` (proposta) + workflow recorrente mensal | **Modelado no mockup** ([cenario-e](mvp/visual/cenario-e.html)); campo RD pendente Valia |
| **F — Estado civil + upgrade + dependente** | `mudanca_estado_civil` + elegibilidade `cf_plano` + alias dependente (B) | **Modelado no mockup** ([cenario-f](mvp/visual/cenario-f.html)); payload dependente API pendente Bruno |
| Casamento / estado civil | Evento `mudanca_estado_civil` + `cf_estado_civil` (último valor) | Viável; histórico só no sistema Valia |
| Notificação API → automação direta | Webhook/middleware dispara evento | Viável se Valia notificar middleware |
| Substituir Responsys “como está” | Middleware + campos + eventos | Projeto; não nativo RD |

**Integração mínima para automações atuais:** só API + dados corretos (Bruno confirmou); sem módulos extras RD.

---

## 6. Treinamento — desdobramento do relatório v2

### 6.1 Objetivo e público

- **Objetivo:** transformar setup em **rotina** (não apresentação técnica).
- **Público a confirmar:** Priscila só / operação / ambos.
- **Saída da reunião:** data, escopo, critérios de aceite do treinamento.

### 6.2 Blocos (v2) com dependências técnicas/operacionais

| Bloco | Conteúdo (v2) | Desdobramento / dependência |
|-------|----------------|-----------------------------|
| **1 — Visão do fluxo** | MKT → e-mail → conversão → CRM | Alinhar com tags LPs reais e quem recebe notificação intranet |
| **2 — CRM dia a dia** | Views, negociações, interações | Views já estruturadas; ajustes via feedback Priscila |
| **3 — Views essenciais** | Pipeline, sem próxima ação, parados… | Thiago evolui conforme uso; checklist pós-treinamento |
| **4 — Campos obrigatórios** | Origem, categoria, potencial, SLA… | Separar campos **CRM B2B** vs **participante** (`cf_cpf`, `cf_fss`) |
| **5 — Dashboard** | Funil, gargalos, origem | Dashboard MVP ok; validar com Priscila; plano B reporting |
| **6 — Rotina diária/semanal** | Leads novos, negócios parados… | Ligar ao **fluxo pós-disparo** (§7) |

### 6.3 Conteúdo dos blocos (referência v2)

**Bloco 1 — Visão geral:** origem dos leads, entrada Marketing, disparo, conversão/resposta, CRM, interação, próxima ação, dashboard.

**Bloco 2 — CRM dia a dia:** abrir CRM, views, empresas/contatos/negociações, etapa, campos, tarefa follow-up, notas, contatos sem próxima ação.

**Bloco 3 — Views:** pipeline executivo, operação do dia, novos leads, sem próxima ação, negociações paradas, origem/categoria, responsável.

**Bloco 4 — Campos:** origem, grupo/categoria, potencial, responsável, etapa, próxima ação, status, motivo de perda.

**Bloco 5 — Dashboard:** volume por etapa, gargalos, origem/categoria, filtros, ação operacional.

**Bloco 6 — Rotina:**

- Diária: novos leads, tarefas do dia, negociações sem próxima ação, interações, mover etapas.
- Semanal: negócios parados, campos incompletos, oportunidades sem responsável, dashboard com Priscila, lista de ajustes.

### 6.4 Roteiro sugerido de sessão (2h)

1. **30 min** — Bloco 1 + 6 (fluxo e rotina)
2. **45 min** — Bloco 2 + 3 (CRM prático hands-on)
3. **30 min** — Bloco 4 + 5 (campos + dashboard)
4. **15 min** — Dúvidas; regra provisória de e-mail (§4.3); próximos passos

### 6.5 Material M2BR (entregas)

| # | Entrega | Conteúdo | Status |
|---|---------|----------|--------|
| E1 | Pauta do treinamento | Blocos 1–6, objetivos | Rascunho neste doc (§6) |
| E2 | Guia rápido CRM | 1–2 páginas operação | A fazer |
| E3 | Regras operacionais | Cadastro, follow-up, e-mail (§4.3) | Rascunho neste doc |
| E4 | Revisão dashboard | Com Priscila | A fazer |
| E5 | Status semanal | Feito / andamento / bloqueio / próxima ação | Recorrente |
| E6 | One-pager técnico identidade | Bruno / TI | [`analise-rdstation-identidade-contatos-2026-06-01.md`](analise-rdstation-identidade-contatos-2026-06-01.md) |

---

## 7. Operação pós-disparo de e-mails (definições em aberto)

Confirmar com Priscila / Bruno:

| Tema | Perguntas |
|------|-----------|
| Ownership | Quem acompanha abertura, clique, resposta, conversão? |
| CRM | Quando vira negociação; etapa inicial do funil |
| SLA | Tempo de retorno; responsável por follow-up |
| Marketing vs CRM | Lead MKT permanece no CRM ou só oportunidades qualificadas? |

**Critério:** cada negociação com **responsável + próxima ação**.

---

## 8. Papel da Priscila (checklist de confirmação)

- [ ] Views usadas diariamente
- [ ] Indicadores obrigatórios
- [ ] Campos úteis vs ruído
- [ ] Relatórios recorrentes
- [ ] Etapas que geram dúvida no time

---

## 9. Checklists imediatos (fusão v2 + técnico)

### Thiago

- [ ] Confirmar fluxos/campanhas com e-mails disparando
- [ ] Dashboard: leituras já possíveis
- [ ] Ajustes Priscila (views, campos, filtros)
- [ ] Bloqueios operacionais no CRM
- [ ] Levar **§4.3** (regra e-mail/plano) para decisão com Bruno
- [ ] Público e data do treinamento
- [ ] Lista: feito / ajuste / dúvida / bloqueio / próximo passo

### Bernardo

- [ ] Esqueleto e narrativa do treinamento (E1, E2)
- [ ] Apoiar regra cadastros (§4) com evidência MVP/análise
- [ ] Operação pós-disparo clara (§7)
- [ ] Dono, prazo e aceite por entrega
- [ ] Separar: treinamento | ajuste CRM | evolução Responsys/middleware
- [ ] Não alterar produção intranet; MVP só `smoke-test`

### Valia (Bruno / TI)

- [ ] Doc Responsys (insumo middleware)
- [ ] Volume edge cases cadastro
- [ ] API tempo real (admissão, estado civil)

---

## 10. Critérios de aceite — fase “uso assistido”

**Operação**

- [ ] Priscila usa views principais sem depender da M2BR
- [ ] Time sabe o que fazer após disparos
- [ ] Negociações com responsável e próxima ação
- [ ] Campos essenciais padronizados
- [ ] Dashboard usado para decisão
- [ ] Rotina diária/semanal acordada
- [ ] Treinamento realizado ou agendado com pauta fechada

**Cadastro / automação** (não bloqueia treinamento B2B; bloqueia escala Responsys)

- [ ] Regra escrita e-mail/plano (§4.3) aprovada por Valia
- [ ] Doc Responsys recebida e mapeada
- [ ] Decisão go/no-go middleware documentada

---

## 11. Roadmap desdobrado (12 semanas sugeridas)

| Semana | Operacional | Técnico (sandbox) |
|--------|-------------|-------------------|
| S1 | Reunião: treino + pós-disparo + §4.3 | Apresentar análise + resultados MVP a Bruno |
| S2 | Treinamento + guia rápido (E2) | Valia envia doc Responsys |
| S3–S4 | Uso assistido Priscila; ajustes views/dashboard | Segmentação/automação teste interna (`smoke-test`) |
| S5–S6 | Status semanal; plano B reporting se necessário | Esboço arquitetura middleware (Opção C) |
| S7+ | Rotina estável | Piloto integração só após regras + API Valia |

---

## 12. O que NÃO fazer agora

- Não misturar contatos MVP (`smoke-test`) com base operacional / campanhas Priscila
- Não alterar `RdStationService` / webhook sem demanda explícita
- Não prometer substituição Responsys sem middleware e regras Valia
- Não criar campos RD novos sem necessidade (43 campos já existem)
- Não escalar automações participante antes da §4.5

---

## 13. Referências no repositório

| Documento | Uso |
|-----------|-----|
| [`valia-rd-station-consolidado-2026-06-01.md`](valia-rd-station-consolidado-2026-06-01.md) | Este documento — visão única |
| [`analise-rdstation-identidade-contatos-2026-06-01.md`](analise-rdstation-identidade-contatos-2026-06-01.md) | Análise API, opções A–D, smoke tests |
| [`mvp/README.md`](mvp/README.md) | Sandbox, comandos, isolamento |
| [`mvp/reports/`](mvp/reports/) | Evidência cenários A/B/C |
| `_projetos/intranet-m2br/docs/rdstation/` | Webhook produção (HANDOFF, ARCHITECTURE) |
| [`smoke-tests-rdstation.sh`](smoke-tests-rdstation.sh) | Scripts manuais ST-01–06 |

---

## 14. Pontos para próxima reunião

1. E-mails disparando → foco em **uso e tração**, não mais setup.
2. Dashboard ok → validar com **necessidade Priscila**.
3. Treinamento = prioridade para rotina.
4. Regra e-mail/plano: apresentar **§4.1–4.5** (não só “duplicado”).
5. Responsys: caminho é **middleware + eventos**, não nativo RD.
6. Sair com **data, público e escopo** do treinamento.
7. Separar ajustes imediatos vs evolução Responsys.
8. MVP: só `@smoke.valia-m2br.test`; cleanup via `python3 -m mvp.cleanup --confirm` quando necessário.

---

*Consolidado M2BR — 01/06/2026. Integra operação (relatório v2) e estudo técnico (análise + MVP).*