# Feature Impact Analysis — SAR

**Phase 2 — Trigger Mapping · Workshop 5**
**Created:** 2026-05-27

> Matriz **Features × Driving Forces × Personas** que prioriza o MVP. Resolve a tensão "concept ambicioso + solo founder + 3-4 meses" do Constraints (Step 10).

---

## Princípios de priorização

1. **Feature de alto impacto** = atende driving forces de **alta score** (Freq × Int × Fit) de **múltiplas personas**.
2. **Feature de unfair advantage** (Step 9) = atende força que **só o SAR resolve bem** no mercado.
3. **Feature P0** = atende **medo absoluto** (ex: R-3 "Perder pedido por bug ou sem sinal" do Rafael). Falhar aqui é morte instantânea do produto.
4. **Feature pós-MVP** = atende força importante mas **não bloqueia validação do PMF** (north star MVP é renovação, não cobertura completa).

---

## Mapa de features pilares do MVP

### 🔴 P0 (absoluto — produto não roda sem)

| Feature | Personas atendidas | Forças (top hits) | Por quê P0 |
|---|---|---|---|
| **Lançamento de pedido offline com sync (PWA + IndexedDB queue)** | Rafael | R-3 (5/5×5/5) · R+4 · R-5 | Perder pedido = perda de confiança catastrófica do Rafael. North star MVP impossível sem isso. |
| **Multi-tenancy BD-por-workspace (ADR 0006)** | Todos (arquitetural) | Habilita BG-4 (coexistência ERPs) | Fundacional. Não pode ser retrofit. |
| **Auth via master-login + RBAC por cockpit** | Todos | Pre-req de todas as personas | Sem segmentação por papel, não existe "4 cockpits". |
| **Real-time entre cockpits (Socket.IO + Valkey)** | Sandra · Daniel · Rafael | S-1 · S+2 · D-1 | Sem real-time, promessa-mãe "visibilidade em tempo real" quebra. |
| **Idempotency-Key em todos POST críticos** | Rafael · Sandra | R-3 · S-1 | Pedido duplicado é falha de produção. |

### 🟢 MVP core (Rafael + Sandra completos)

| Feature | Personas | Forças (top hits) | Score impacto |
|---|---|---|---|
| **Visão 360° do cliente** (timeline, histórico, contatos, pedidos, comissão) | Rafael · Sandra · Daniel | R+2 · S-4 · D-4 | ALTO — 3 personas, todas com score alto |
| **Lançamento de pedido < 60s mobile** | Rafael · Sandra (vê em tempo real) | R+2 · R+4 · R+5 · S+2 | ALTO — central pro PMF |
| **Comissão visível em tempo real (rep + FLEX rateio)** | Rafael | R-4 (5/5×4/5×5/5) | ALTO — força com freq máxima |
| **Funil de propostas (kanban pessoal)** | Rafael | R+2 · R+5 | MÉDIO-ALTO — diferencial vs concorrentes |
| **Lista de inativos com alerta proativo (>60d)** | Rafael · Sandra · Daniel | R-1 · S-4 · D-4 | ALTO — promessa-mãe materializada |
| **Agenda + check-in GPS** | Rafael · Sandra (visão consolidada) | R-2 · R+4 · S+2 · S+6 | MÉDIO-ALTO |
| **WhatsApp nativo (envio de notificações ao cliente final)** | Rafael · Sandra · cliente final | R+5 · R-6 · S-2 | ALTO — diferencial declarado |
| **Share API (compartilhar pedido via WhatsApp do celular)** | Rafael | R+5 · R-6 | MÉDIO |
| **Push notifications (Sandra: aprovação; Rafael: pedido aprovado)** | Rafael · Sandra | S-1 · S-2 · R-2 | ALTO — substitui WhatsApp informal |
| **Fila de aprovações com contexto** | Sandra | S-2 · S+3 | ALTO — diferencial declarado |
| **Mapa de calor da equipe (privado, só pra Sandra)** | Sandra | S+6 · S+1 · S-5 | MÉDIO — cuidado com R-7 (não punitivo) |
| **Watchlist de clientes-chave com alerta automático** | Sandra · Daniel | S-4 · D-4 | ALTO |
| **Dashboard "tela do dia" (Sandra)** | Sandra | S+2 · S+4 · S-1 | ALTO — UX central da Sandra |
| **Dashboard executivo (Daniel) simplificado** | Daniel | D+1 · D+2 · D-1 | ALTO — mas simplificado no MVP |

### 🔵 MVP suporte (Alice e Daniel simplificados)

| Feature | Personas | Forças | Score impacto |
|---|---|---|---|
| **Cadastro completo de produto (form denso)** | Alice | A+1 · A-2 | ALTO — produto não roda sem catálogo |
| **Cadastro completo de cliente** | Alice · Rafael (também cria no campo) | A+1 · R+2 | ALTO |
| **Cadastro de rep (permissões, região, comissão)** | Alice | A+1 | MÉDIO-ALTO |
| **Pauta de preço com versionamento** | Alice | A+4 · A-2 · A-4 | ALTO — auditoria habilita confiança |
| **ICMS-ST manual por UF (sem assistente IA)** | Alice | A-3 | MÉDIO — viabiliza operação, mas não brilha |
| **Auditoria em entidade (histórico de mudanças)** | Alice · Daniel · Sandra | A+4 · A-4 · D-7 · S+3 | ALTO — transversal |
| **Timeline 360° do cliente (versão Daniel: estratégico)** | Daniel | D+1 · D-4 · D+6 | MÉDIO-ALTO |
| **Faturamento mês×mês com tendência (Chart.js)** | Daniel | D+6 · D-1 | MÉDIO-ALTO |
| **Limite de crédito automático + bloqueio cliente** | Sandra · Alice · Rafael | S-1 · A-2 · R-2 | ALTO — central no fluxo de pedido |

### 🟡 MVP-light (existe mas sem brilho) — completar pós-MVP

| Feature MVP-light | Pós-MVP (versão rica) |
|---|---|
| Dashboard Daniel sem IA estratégica | **IA explicável proativa** (D+4 · D-6) — DIFERENCIAL DECLARADO |
| Tela direta de promoção (1 a 1) | **Editor visual de campanhas no-code** (A+5 · A-1) — DIFERENCIAL DECLARADO |
| ICMS-ST manual | **Assistente IA por NCM+UF** (A-3) |
| WhatsApp apenas notificação outbound | **Conversa bidirecional + aquecimento de lead** (R+5 · S-2) — promessa de positioning |
| Bulk operations básico (CSV import) | **Bulk edit em massa + edição inline** (A+2 · A-5) |

### ⚪ Pós-MVP (entram conforme tração)

| Feature | Personas | Forças | Quando |
|---|---|---|---|
| **Comparativo período (mês×mês, ano×ano)** | Daniel | D+6 · D+5 | Y1 conforme dado acumular |
| **Análise de concentração de carteira (D+5)** | Daniel | D+5 · D-4 | Y1 |
| **Benchmarking setorial (cross-tenant anonimizado)** | Daniel | D+3 · D-2 | Y2 |
| **Onboarding white-glove com tour interativo** | Cliente novo | D-3 | NÃO (excluído Step 17a — brand Apple) |
| **Chat-com-cliente in-app** | — | — | NÃO (excluído Step 17a) |
| **App nativo iOS/Android (sobre backend SAR)** | Rafael | R+3 · R-5 | Y1-Y2 conforme PWA validar limites |
| **Adaptação app Android legado para backend SAR** | Reps Android atuais | Continuidade | Pós-MVP (Step 10a) |
| **Programa de indicação (referral)** | Daniel buyer | BG-2 | Y1 quando 5+ clientes |
| **Marketplace de templates WhatsApp** | Alice | A+5 · A-1 | Y1+ |

---

## Score por Business Goal × Features

| Business Goal | Features que mais contribuem |
|---|---|
| **BG-1 PMF MVP** | Lançamento offline · Real-time · Visão 360° · Comissão tempo real · Dashboard Sandra "tela do dia" · WhatsApp notif |
| **BG-2 Referenciabilidade** | Mesma lista do BG-1 (sem PMF não há referenciabilidade) + Alertas inativos (cumprir promessa-mãe) |
| **BG-3 Modernidade visual** | Visual DNA do Block C aplicado em todo cockpit · PWA polido · Dark mode |
| **BG-4 Coexistência ERPs** | Multi-tenancy BD/workspace · API REST + OpenAPI · Adapter por ERP (pós-MVP por demanda) |
| **BG-5 Fundação para escala** | OTel + Pino + Sentry · Test coverage · ADRs documentados · Vault rotação · Backup Proxmox |

---

## Tensões e trade-offs do MVP

### Tensão A: IA estratégica não entra no MVP, mas é diferencial de venda

- **Problema:** D+4 (IA segundo cérebro) é argumento de venda forte, mas solo founder + 3-4 meses não comporta IA explicável bem feita
- **Resolução:** MVP entrega Dashboard Daniel **sem IA**; demo de venda mostra **roadmap IA** com data prevista (pós-renovação 1º cliente)
- **Risco:** Daniel comprou esperando IA, MVP entrega menos
- **Mitigação:** 1º cliente é parceiro próximo — aceita roadmap, recebe condição especial

### Tensão B: Editor no-code de campanhas é diferencial Alice, mas pós-MVP

- **Problema:** A+5 (campanhas sem dev) é o que **deveria** liberar Alice — mas exige UI complexa que solo founder não entrega no MVP
- **Resolução:** MVP entrega tela direta de promoção (Alice mexe 1 a 1) + cadastro/pauta robustos. Editor visual entra pós-renovação.
- **Risco:** Alice fica achando o produto "só OK"
- **Mitigação:** Alice não pesa na decisão de compra (Step 6). Risco aceitável.

### Tensão C: WhatsApp conversa bidirecional vs notificação outbound

- **Problema:** "WhatsApp nativo" no positioning sugere conversa completa, mas MVP entrega só notificação outbound
- **Resolução:** Linguagem de marketing deixa explícito "notificações via WhatsApp Business API" + roadmap "conversa bidirecional Y1"
- **Risco:** Cliente comprou esperando chatbot completo
- **Mitigação:** Demo + proposta especificam escopo

### Tensão D: Sandra vs Rafael — visibilidade não pode virar vigia

- **Problema:** S+6 (Sandra quer ver quem produz) ↔ R-7 (Rafael teme ser substituível/vigiado)
- **Resolução:** SAR mostra **outputs** (pedidos, faturamento, % meta) — NÃO inputs punitivos (tempo logado, geolocation contínua, % tela ativa)
- **Risco:** Rep boicota produto se sentir vigiado
- **Mitigação:** UI design explicitamente alinhada com tom canônico "consultor sênior, não Big Brother"

### Tensão E: Daniel vs Sandra — dashboards sobrepostos

- **Problema:** Os dois precisam ver dados de equipe e clientes
- **Resolução:** Sandra vê **operacional do dia** · Daniel vê **estratégico do período**. Mesma fonte, camadas distintas.
- **Risco:** Ambos veem mesma tela e dashboards ficam confusos
- **Mitigação:** Cockpits separados desde dia 1 — RBAC por papel

---

## Próximos passos

- **Phase 3 (PRD):** este Feature Impact vira backlog priorizado
- **Phase 4 (UX Specs):** features de alta score viram pages específicas
- **Phase 6 (Design System):** componentes emergem das features pilares