chore: initial monorepo scaffold + WDS Phase 1+2 artifacts
- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
170
design-artifacts/A-Product-Brief/00-handover-summary.md
Normal file
170
design-artifacts/A-Product-Brief/00-handover-summary.md
Normal file
@@ -0,0 +1,170 @@
|
||||
# Phase 1 Handover Summary — SAR
|
||||
|
||||
**Phase 1 Status:** ✅ COMPLETO
|
||||
**Última atualização:** 2026-05-27
|
||||
**Próxima fase:** Phase 2 — Trigger Mapping (Saga)
|
||||
**Cliente:** JCS Sistemas · PO: Julian
|
||||
|
||||
---
|
||||
|
||||
## 🎯 O essencial em uma página
|
||||
|
||||
### Vision
|
||||
|
||||
> SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.
|
||||
|
||||
### Product Concept (ideia organizadora)
|
||||
|
||||
> **Plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.** Metáfora: equipe de Fórmula 1 — cada papel tem seu próprio dashboard, mas todos veem o mesmo carro com a mesma telemetria.
|
||||
|
||||
### Primary Audience (4 user personas)
|
||||
|
||||
| | Persona | Device | Volume | Frustração #1 |
|
||||
|---|---|---|---|---|
|
||||
| 🟢 **PRIMÁRIA** | **Rafael (Representante)** | Mobile-first PWA iOS | 70-90% | Cliente esfria sem ele saber |
|
||||
| 🟡 | Sandra (Supervisora) | Desktop + mobile | 5-15% | Reps "somem" no campo |
|
||||
| 🔵 | Daniel (Dono) | Desktop + iPad first-class | 1-5% | Recebe passado, não próximo passo |
|
||||
| 🟣 | Alice (Admin) | Desktop-only | 1-5% | "Promoção exige pedir pro dev" |
|
||||
|
||||
**Buyer persona:** "Dono Empresário B2B" — 35-60a, sócio-fundador, gerencia "no peito", critério principal = fé que vai funcionar (não TCO).
|
||||
|
||||
### Positioning
|
||||
|
||||
**Para** distribuidoras, indústrias, RCAs e PMEs brasileiras com **5-50 representantes externos**, que precisam de visibilidade em tempo real do que está acontecendo na rua, **o SAR é** uma plataforma SaaS de força de vendas com **3 experiências distintas por papel + WhatsApp nativo + inteligência ativa de carteira**, instalada em minutos como SaaS web e **coexistindo com ERPs existentes** em vez de exigir migração.
|
||||
|
||||
### Key Differentiators (5 estruturais com alto moat)
|
||||
|
||||
1. **Concept "4 cockpits"** — concorrentes monolíticos precisariam reescrever tudo
|
||||
2. **Multi-tenancy BD-por-workspace** desde dia 0 (ADR 0006)
|
||||
3. **Stack moderna JCS** (Node 24 + Nest 11 + Prisma 7 + React 19)
|
||||
4. **IA desenhada estruturalmente** — não bolt-on
|
||||
5. **Velocidade de iteração JCS** — decisão fast-individual
|
||||
|
||||
**+ 6º diferencial (Step 19):** estética moderna em mercado visualmente medíocre.
|
||||
|
||||
### Business Model
|
||||
|
||||
**B2B SaaS multi-tenant, per-seat, sales-led, trial 14-30 dias, contrato híbrido (mensal sem fidelização OU anual prepago -15%).**
|
||||
|
||||
ARR Y1 projetado: R$ 200k-600k (10-20 clientes).
|
||||
|
||||
### Success Criteria
|
||||
|
||||
**North Star MVP:** 1º cliente real paga e renova sem cancelar nos primeiros 3 meses pós go-live.
|
||||
|
||||
**Timeline crítico:**
|
||||
- MVP em produção com 1º cliente: **3-4 meses** (solo founder mode)
|
||||
- MVP validado (renovação): mês 6-7
|
||||
- 10 clientes pagantes: mês 12
|
||||
|
||||
**Métricas em 4 camadas** definidas (negócio JCS · cliente · comportamento usuário · qualidade técnica).
|
||||
|
||||
### ⚠️ Tensão estratégica flagueada
|
||||
|
||||
Concept ambicioso + 3-4 meses + solo founder = **matemática não fecha sem MVP minimalista**:
|
||||
- ✅ Rafael (Rep) + Sandra (Supervisora) completos
|
||||
- 🟡 Daniel (Dono) dashboard simples; **IA estratégica entra pós-MVP**
|
||||
- 🟡 Alice (Admin) cadastros essenciais; **editor no-code de campanhas entra pós-MVP**
|
||||
- WhatsApp em versão básica (notificações no MVP, conversa bidirecional pós)
|
||||
|
||||
---
|
||||
|
||||
## 📦 Artefatos gerados (todos em `design-artifacts/A-Product-Brief/`)
|
||||
|
||||
### Documentos canônicos
|
||||
|
||||
| Arquivo | Conteúdo |
|
||||
|---|---|
|
||||
| `00-handover-summary.md` | ⭐ Este arquivo — entrada para Phase 2 |
|
||||
| `01-product-brief.md` | ⭐ Brief estratégico (Block A — Steps 1-12) |
|
||||
| `02-content-language.md` | Tom, personalidade, idioma, SEO, content structure (Block B — Steps 13-18) |
|
||||
| `03-visual-direction.md` | Identidade visual, design style, layout, imagery (Block C — Steps 19-26) |
|
||||
| `04-platform-requirements.md` | Stack, integrações, contato, multilingual técnico, maintenance (Block D — Steps 27-32) |
|
||||
|
||||
### Diálogos (histórico detalhado de cada decisão)
|
||||
|
||||
| Arquivo |
|
||||
|---|
|
||||
| `dialog/00-context.md` |
|
||||
| `dialog/client-profile.md` |
|
||||
| `dialog/vision.md` |
|
||||
| `dialog/positioning.md` |
|
||||
| `dialog/business-model.md` |
|
||||
| `dialog/business-customers.md` |
|
||||
| `dialog/target-users.md` |
|
||||
| `dialog/product-concept.md` |
|
||||
| `dialog/success-criteria.md` |
|
||||
| `dialog/competitive-landscape.md` |
|
||||
| `dialog/constraints.md` |
|
||||
| `dialog/platform-strategy.md` |
|
||||
| `dialog/tone-of-voice.md` |
|
||||
| `dialog/inspiration-analysis.md` |
|
||||
| `dialog/decisions.md` (log cronológico) |
|
||||
| `dialog/progress-tracker.md` (status dos 36 steps) |
|
||||
|
||||
### Materiais referenciados (existentes)
|
||||
|
||||
| Arquivo | Onde |
|
||||
|---|---|
|
||||
| `brand.md` | raiz do repo |
|
||||
| `STACK.md v2.2` | raiz do repo |
|
||||
| `CODING-RULES.md v2.0` | raiz do repo |
|
||||
| Logos SAR | `frontend/img/SAR_*.png` |
|
||||
| Logos JCS | `design-artifacts/_references/jcs-logo/` |
|
||||
| Mockup HTML legado | `design-artifacts/_references/legacy-screens-html/` |
|
||||
|
||||
---
|
||||
|
||||
## 🔓 Decisões abertas (pendências para resolver depois)
|
||||
|
||||
| Pendência | Resolver quando |
|
||||
|---|---|
|
||||
| Provider de **IA generativa** (Anthropic / OpenAI / Local / Multi) | Antes da feature de IA entrar — Y1+ pós north star MVP |
|
||||
| **Preço per-seat exato** | Validar com primeiras vendas (calibrar baseado em R$ 150/rep referência de mercado) |
|
||||
| **Setup fee / implantação paga** (opcional) | Quando 5+ clientes mostrarem demanda |
|
||||
| **Add-ons premium** (WhatsApp tier? IA tier?) | Pós-validação north star |
|
||||
| **Domínio definitivo** (`sarjcs.com.br`?) | Antes de ir ao ar — verificar disponibilidade |
|
||||
| **Contratação de 1-2 devs** | Quando 1º cliente renovar (north star atingida) |
|
||||
| **JCS team photos para `/sobre`** | Quando JCS tiver caixa para photoshoot |
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Conjunto canônico de "regras do SAR" (para todo PR e decisão futura)
|
||||
|
||||
Antes de toda feature/PR, verificar:
|
||||
|
||||
1. **Atende qual das 4 personas (Rafael/Sandra/Daniel/Alice)?** Se nenhuma, não é prioridade MVP.
|
||||
2. **Reforça "visibilidade em tempo real"?** É a promessa-mãe.
|
||||
3. **Preserva coexistência com ERPs**? Multi-tenant BD-por-workspace continua intocado?
|
||||
4. **Está dentro do range SMB (5-50 reps)?** Não cair em features enterprise nem micro.
|
||||
5. **Respeita tom canônico?** 5 atributos (Direto, Profissional sem ser frio, Confiante, Específico, Empático), 5 mood keywords (Clean, Confident, Specific, Serene, Modern), vocabulário canônico (Cliente, Rep, Orçamento, Pedido, Faturado, Visita, Carteira, Inativo, Painel, Aprovação).
|
||||
6. **Respeita Visual DNA?** Modern Flat + Minimal · JCS Blue único accent · Plus Jakarta · effects sutis · screenshots-only.
|
||||
7. **Não viola STACK.md v2.2?** Mudanças exigem RFC em `docs/adr/`.
|
||||
8. **Não viola CODING-RULES.md v2.0?** Pegadinhas 🔥 PGD-* respeitadas.
|
||||
9. **LGPD by design?** Datacenter BR + isolamento físico + redact em logs.
|
||||
10. **Solo founder pode entregar?** Se quebra o budget, vai pra pós-MVP.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Próxima fase — Phase 2: Trigger Mapping
|
||||
|
||||
**Objetivo:** Aprofundar driving forces das 4 personas em **5 workshops sequenciais**:
|
||||
|
||||
1. **Business Goals** — refinar os goals do brief
|
||||
2. **Target Groups** — confirmar 4 personas + naming aliterativo (Rafael Representante, Sandra Supervisora, Daniel Dono, Alice Admin)
|
||||
3. **Driving Forces** — motivações positivas + negativas (medos, frustrações) de cada persona
|
||||
4. **Prioritization** — score forças por Frequência × Intensidade × Fit
|
||||
5. **Feature Impact** — mapear features × forças, identificar features de alto impacto
|
||||
|
||||
**Output esperado:** `design-artifacts/B-Trigger-Map/` com:
|
||||
- `01-business-goals.md`
|
||||
- `02-rafael-representante.md` (e similares para os outros 3)
|
||||
- Feature Impact matrix
|
||||
- Mermaid diagram conectando goals → personas → forças
|
||||
|
||||
**Tempo estimado:** 2-3 horas (similar a Block A da Phase 1).
|
||||
|
||||
**Como começar:**
|
||||
- Skill: `wds-2-trigger-mapping`
|
||||
- Agente: Saga (continua sendo o BA)
|
||||
- Comando: `/wds-2-trigger-mapping` ou simplesmente continuar nesta conversa
|
||||
65
design-artifacts/A-Product-Brief/00-product-brief.md
Normal file
65
design-artifacts/A-Product-Brief/00-product-brief.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Product Brief: SAR
|
||||
|
||||
> The strategic foundation — why this product exists, who it serves, and what success looks like.
|
||||
|
||||
**Created:** 2026-05-26
|
||||
**Phase:** 1 — Product Brief
|
||||
**Agent:** Saga (Analyst)
|
||||
|
||||
---
|
||||
|
||||
## What Belongs Here
|
||||
|
||||
The Product Brief answers five strategic questions:
|
||||
|
||||
1. **Why** does this product exist? (Vision & business goals)
|
||||
2. **Who** is it for? (Target users and their context)
|
||||
3. **What** does it need to do? (Core capabilities)
|
||||
4. **How** will we know it works? (Success metrics)
|
||||
5. **What** are the constraints? (Platform requirements, tech stack)
|
||||
|
||||
Everything downstream — trigger maps, scenarios, page specs, design system — traces back to decisions made here. This is the North Star.
|
||||
|
||||
**Learn more:**
|
||||
- WDS Course Module 04: Product Brief — Your Strategic Foundation
|
||||
- WDS Course Module 05: Platform Requirements
|
||||
|
||||
---
|
||||
|
||||
## For Agents
|
||||
|
||||
**Workflow:** `skill:wds-1-project-brief`
|
||||
**Agent trigger:** `PB` (Saga)
|
||||
**Templates:** `./resources/wds-1-project-brief/templates/`
|
||||
|
||||
**Before writing anything in this folder:**
|
||||
1. Load the workflow and follow its steps
|
||||
2. Use Dialog mode for discovery — ask questions, don't assume
|
||||
3. Read existing materials if the user has them (check `wds-project-outline.yaml`)
|
||||
|
||||
**Existing materials available** (see `_progress/wds-project-outline.yaml`):
|
||||
- `brand.md` — identidade visual JCS (paleta, tipografia, layout)
|
||||
- `STACK.md` — stack canônica JCS v2.2 (Node 24, Nest 11, Prisma 7, React 19.2, AntD 6.4, Proxmox)
|
||||
- `CODING-RULES.md` — invariantes + pegadinhas 🔥 (PGD-SEC, PGD-DB, etc.)
|
||||
- `frontend/img/SAR_logo_fundo_transparente.png` + `SAR_icone_fundo_transparente.png`
|
||||
|
||||
**File naming:** Number all documents with a two-digit prefix: `01-product-brief.md`, `02-content-language.md`, etc. Platform Requirements is always last — it summarizes technical decisions that emerge from the strategic documents above. Update the Documents table below as each file is created.
|
||||
|
||||
**Harm:** Producing a brief from assumptions instead of conversation. A brief that doesn't reflect the user's actual goals forces every later phase to build on a wrong foundation.
|
||||
|
||||
**Help:** Asking the right questions, listening deeply, and documenting what the user actually said. A good brief makes every later decision easier.
|
||||
|
||||
---
|
||||
|
||||
## Documents
|
||||
|
||||
_This section will be updated as documents are created during Phase 1._
|
||||
|
||||
| # | Document | Status |
|
||||
|---|----------|--------|
|
||||
| 01 | Product Brief | Not started |
|
||||
| 02 | Platform Requirements | Not started |
|
||||
|
||||
---
|
||||
|
||||
_Created using Whiteport Design Studio (WDS) methodology_
|
||||
343
design-artifacts/A-Product-Brief/01-product-brief.md
Normal file
343
design-artifacts/A-Product-Brief/01-product-brief.md
Normal file
@@ -0,0 +1,343 @@
|
||||
# Product Brief: SAR — Força de Vendas
|
||||
|
||||
**Cliente:** JCS Sistemas
|
||||
**Status:** Product Brief completo (Block A da Phase 1 WDS)
|
||||
**Versão:** 1.0
|
||||
**Última atualização:** 2026-05-26
|
||||
**Próximo:** Block B (Content & Language) → Block C (Visual Direction) → Block D (Platform Requirements) → Phase 2 (Trigger Mapping)
|
||||
|
||||
---
|
||||
|
||||
## Resumo estratégico
|
||||
|
||||
O **SAR** é a primeira plataforma SaaS web da **JCS Sistemas**, sucessora dos produtos legados Android (força de vendas) e Desktop (ERP) num upgrade-de-tier que unifica força de vendas e ERP num único produto distribuível. Mais que produto, o SAR é a **vitrine** que posiciona a JCS como fornecedora de SaaS moderno no mercado B2B brasileiro.
|
||||
|
||||
A ideia organizadora não é "produto único com RBAC". É uma **plataforma de quatro cockpits especializados** — Rep, Supervisor, Dono e Admin — compartilhando uma camada de dados em tempo real, atravessada por WhatsApp nativo e IA contextual. Como uma equipe de Fórmula 1: cada papel tem seu próprio dashboard, mas todos veem o mesmo carro com a mesma telemetria.
|
||||
|
||||
O target é PME brasileira (distribuidora, indústria, RCA ou PME com vendas externas) com **5-50 representantes na rua**. A dor central que motiva a compra: **donos e supervisores decidem no escuro** — 5-10% da carteira esfria silenciosamente e ninguém vê. A alternativa mais comum não é Mercos ou TOTVS, é **não fazer nada** (Excel + WhatsApp + ERP sem módulo). O choque "olha o que você está perdendo silenciosamente" vence mais leads que qualquer comparativo direto.
|
||||
|
||||
---
|
||||
|
||||
## Vision
|
||||
|
||||
> SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.
|
||||
|
||||
### Três experiências distintas no mesmo produto
|
||||
|
||||
- **Representante:** clareza absoluta da carteira (quanto, pra quem, status), metas expostas e atingíveis, WhatsApp integrado, inteligência de carteira (inativos, ciclo, oportunidades).
|
||||
- **Supervisor:** "telas que apertam parafusos todos os dias" — instrumentos de ação tática diária, não dashboards contemplativos.
|
||||
- **Dono:** análise estratégica com IA proativa — não relatórios passivos, mas insights que dizem onde olhar e por quê.
|
||||
|
||||
### Sete diferenciais explícitos
|
||||
|
||||
1. Inteligência de carteira ativa (inativos, ciclo, oportunidades)
|
||||
2. WhatsApp como canal nativo (não anexo)
|
||||
3. Metas como gamificação operacional
|
||||
4. Três experiências distintas por papel (pilar de marca)
|
||||
5. IA estratégica para o dono (não decorativa)
|
||||
6. SaaS web distribuível (vs. legado instalável)
|
||||
7. Facilidade de implantação JCS-side
|
||||
|
||||
---
|
||||
|
||||
## Positioning
|
||||
|
||||
**Para** distribuidoras, indústrias e escritórios de representação brasileiros com 5-50 representantes externos,
|
||||
|
||||
**que precisam** de visibilidade em tempo real do que está acontecendo na rua para decidir com dados em vez de no escuro,
|
||||
|
||||
**o SAR é** uma plataforma SaaS de força de vendas que entrega **três experiências distintas no mesmo produto** — clareza operacional para o rep, instrumentos de decisão para o supervisor, IA estratégica para o dono — com WhatsApp como canal nativo e inteligência ativa de carteira.
|
||||
|
||||
**Diferente de** apps verticais como Mercos e Promosoft (que tratam todos os usuários igual e não têm IA estratégica), módulos de força de vendas de ERPs como TOTVS e Sankhya (burocráticos, caros e desconectados do mobile), e do stack improvisado de planilha+WhatsApp+ERP (que não dá visibilidade nenhuma),
|
||||
|
||||
**o SAR** é instalado em minutos como SaaS web, com camadas IA-first sobre cada papel — e **coexiste com ERPs existentes em vez de exigir migração total**.
|
||||
|
||||
### Mapa estratégico (posição alvo)
|
||||
|
||||
```
|
||||
Alto custo de implantação
|
||||
▲
|
||||
│
|
||||
TOTVS ● │
|
||||
Sankhya │ ● Apps caseiros
|
||||
│
|
||||
◄─────────────────────────┼─────────────────────────►
|
||||
ERP-first │ Vendas-first
|
||||
│
|
||||
│ ● Mercos
|
||||
● SAR │ ● Promosoft
|
||||
(vendas-first │
|
||||
+ low-friction) │ ● Excel + WhatsApp
|
||||
▼
|
||||
Baixo custo de implantação
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Target Users — 4 personas
|
||||
|
||||
> **Persona primária do MVP:** Rafael (Representante). 70-90% do volume de uso. SAR ganha ou perde aqui.
|
||||
|
||||
### 🟢 Rafael — Representante (PRIMÁRIA)
|
||||
|
||||
- **Quem:** 30-50a, vendedor B2B externo, comissionado, atende 50-200 clientes ativos
|
||||
- **Onde:** no carro, no posto, no fundo da loja — **mobile-first via PWA iOS**
|
||||
- **Frustração #1:** cliente esfria sem ele saber
|
||||
- **Goal:** bater meta sempre
|
||||
- **Device:** mobile (PWA)
|
||||
|
||||
### 🟡 Sandra — Supervisora
|
||||
|
||||
- **Quem:** 35-55a, gerente comercial, coordena 5-30 reps
|
||||
- **Onde:** escritório, desktop o dia todo
|
||||
- **Frustração #1:** reps "somem" no campo, aprovação vira fila de WhatsApp
|
||||
- **Goal:** time bate meta + dormir tranquila
|
||||
- **Device:** desktop + PWA mobile-light para consultas rápidas
|
||||
|
||||
### 🔵 Daniel — Dono / Diretor Comercial
|
||||
|
||||
- **Quem:** 40-65a, sócio-fundador, decide investimentos
|
||||
- **Onde:** desktop/notebook + **iPad first-class** (uso noturno em casa)
|
||||
- **Frustração #1:** dashboards mostram passado, não próximo passo
|
||||
- **Goal:** dirigir sem operar — confiar no time + IA que avisa quando algo desvia
|
||||
- **Device:** desktop/iPad (visualização-first)
|
||||
|
||||
### 🟣 Alice — Administradora / Backoffice
|
||||
|
||||
- **Quem:** 25-45a, funcionária administrativa do cliente
|
||||
- **Onde:** escritório, desktop o dia todo
|
||||
- **Responsabilidade:** cadastros, pautas, **campanhas de desconto/promoções no-code**, tributação ICMS-ST, gestão de reps
|
||||
- **Frustração #1:** "promoção exige pedir pro dev"
|
||||
- **Goal:** lançar campanha sozinha, manter catálogo+tributação sem incidente
|
||||
- **Device:** desktop-only
|
||||
|
||||
### Buyer × User mapping
|
||||
|
||||
- **Decisor (Dono ou Diretor Comercial):** overlap alto com Daniel; quem assina contrato
|
||||
- **Influenciadores que matam o deal:** Sandra (sempre) + Rafael (champion interno se já conheceu o SAR)
|
||||
- **Ausentes da decisão de compra:** financeiro, TI, jurídico — venda é operacional-emocional, não técnica-financeira
|
||||
|
||||
---
|
||||
|
||||
## Business Model
|
||||
|
||||
**B2B SaaS multi-tenant, per-seat, sales-led, com trial real.**
|
||||
|
||||
| Componente | Decisão |
|
||||
|---|---|
|
||||
| Cobrança | **Per-seat** (por representante ativo/mês) |
|
||||
| Vendas | **Sales-led** — demo + proposta + acompanhamento comercial |
|
||||
| Trial | **14-30 dias** com dados reais (workspace sandbox provisionado) |
|
||||
| Contrato | Cliente escolhe: **mensal sem fidelização** (full price) **ou** **anual prepago** (-10-20%) |
|
||||
|
||||
### Ticket médio estimado (preliminar, R$ 150/rep referência)
|
||||
|
||||
| Porte cliente | Reps | Mensal estimado | ARR |
|
||||
|---|---|---|---|
|
||||
| Pequeno | 5-10 | R$ 750-1.500 | R$ 9k-18k |
|
||||
| Médio baixo | 11-25 | R$ 1.650-3.750 | R$ 20k-45k |
|
||||
| Médio alto | 26-50 | R$ 3.900-7.500 | R$ 47k-90k |
|
||||
|
||||
### Buyer persona — "O Dono Empresário B2B"
|
||||
|
||||
35-60a, sócio-fundador ou herdeiro de negócio familiar, gerencia "no peito". Critério de avaliação principal: **fé que vai funcionar**, não TCO planilhado. Convence-se com: demo concreta + boca-a-boca + cases. Assusta-se com: "meu pessoal não vai aprender" + "mais um sistema" + "é caro pra valer?".
|
||||
|
||||
### Canais de aquisição (todos os 4 ativos)
|
||||
|
||||
1. **Indicação boca-a-boca** (canal #1; alimentado por referência forte do primeiro grupo de clientes)
|
||||
2. **Google / SEO + content marketing**
|
||||
3. **Eventos / feiras setoriais** (APAS, Fispal, Anamaco, etc.)
|
||||
4. **Parceiros** (contadores, revendedores ERP, consultorias)
|
||||
|
||||
### Ciclo de vendas por porte
|
||||
|
||||
- **Pequeno (5-10 reps):** 2-4 semanas — dono decide, demo curta, fechamento rápido
|
||||
- **Médio baixo (11-25):** 1-2 meses — dono + supervisor avaliam, comparam com 1-2 concorrentes
|
||||
- **Médio alto (26-50):** 2-4 meses — avaliação mais formal, possível POC
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### North Star do MVP
|
||||
|
||||
> **1º cliente real paga e renova sem cancelar nos primeiros 3 meses após go-live.**
|
||||
|
||||
Retenção provada > tração massiva. Prova que o produto entrega valor sustentado.
|
||||
|
||||
### Marcos timeline
|
||||
|
||||
| Marco | Quando | Critério de aceite |
|
||||
|---|---|---|
|
||||
| MVP em produção com 1º cliente real | **3-4 meses** | Cliente assinou contrato pago, usando os 4 cockpits |
|
||||
| MVP validado | + 3 meses (mês 6-7) | 1º cliente renovou → north star atingida |
|
||||
| 10 clientes pagantes | mês 12 | Conservador Y1 |
|
||||
| 20 clientes pagantes | mês 16-18 | Esticado Y1+ |
|
||||
|
||||
### Métricas em 4 camadas
|
||||
|
||||
**A. Negócio JCS:** logo churn < 3%/mês · NPS donos > 50 · CAC payback < 12m · NRR > 110% · ARR Y1 R$ 200k-600k
|
||||
|
||||
**B. Cliente:** +15-30% pedidos/rep/mês vs baseline · 10-20% inativos recuperados via alerta IA · tempo médio aprovação desconto < 30 min · % reps ativos > 80% · NPS reps > 30
|
||||
|
||||
**C. Comportamento usuário:**
|
||||
- Rafael: > 95% pedidos no SAR · pedido < 60s · DAU/MAU > 70%
|
||||
- Sandra: > 90% aprovações via SAR · acessa tela do dia > 80% dos dias úteis
|
||||
- Daniel: IA insights > 2x/semana
|
||||
- Alice: > 80% campanhas no-code sem suporte
|
||||
|
||||
**D. Qualidade técnica:** p95 tela < 800ms · p95 pedido end-to-end < 60s · uptime 99.5% · tickets resolvidos < 4h em > 80% · **pedidos perdidos = 0** (P0 imediato)
|
||||
|
||||
---
|
||||
|
||||
## Competitive Landscape
|
||||
|
||||
### Cinco alternativas (incluindo do-nothing)
|
||||
|
||||
1. **Apps verticais** (Mercos, Promosoft, MaxFV, Workforce, Mobits) — SAR ataca via 4 cockpits + IA + WhatsApp nativo + UX moderna
|
||||
2. **ERPs com módulo** (TOTVS, Sankhya, Senior, Bling, Tiny, Omie) — SAR ataca via **coexistência via API** (não migração do ERP)
|
||||
3. **Stack improvisado** (Excel + WhatsApp + ERP sem módulo) — SAR ataca via "primeira ferramenta de verdade"
|
||||
4. **Apps caseiros** (dev terceirizado) — SAR ataca via "fim do pesadelo de manutenção, roadmap contínuo"
|
||||
5. **Do nothing** (50%+ dos prospects) — SAR ataca via choque "5-10% da carteira/ano perdida silenciosamente"
|
||||
|
||||
### Cinco unfair advantages estruturais (alto moat, > 2 anos para neutralizar)
|
||||
|
||||
1. **Concept estrutural "4 cockpits"** — concorrentes monolíticos precisariam reescrever tudo
|
||||
2. **Multi-tenancy BD-por-workspace desde dia 0** (ADR 0006) — não retrofit
|
||||
3. **Stack moderna JCS** (Node 24 + Nest 11 + Prisma 7 + React 19.2) — ~3x mais rápida que legados PHP/Java/Delphi
|
||||
4. **IA desenhada estruturalmente** — não bolt-on
|
||||
5. **Velocidade de iteração JCS** (decisão fast-individual) — itera mensalmente; concorrentes corporates anualmente
|
||||
|
||||
### Vantagens não-sustentáveis (copiáveis em 6-24 meses)
|
||||
|
||||
WhatsApp nativo, editor no-code, UX moderna por papel, real-time entre cockpits. **A defesa real é a combinação estrutural dos 5 itens acima**, não feature individual.
|
||||
|
||||
### Janela de mercado
|
||||
|
||||
**2-3 anos para entrincheirar** antes de saturação SaaS força de vendas BR. Velocidade do MVP é decisão estratégica, não apenas operacional.
|
||||
|
||||
---
|
||||
|
||||
## Constraints & Context
|
||||
|
||||
### ⚠️ Tensão estratégica explícita
|
||||
|
||||
Concept ambicioso + MVP 3-4 meses + **solo founder mode** (Julian acumula PO + Tech Lead + único Champion + único dev até 1º cliente) = **a matemática não fecha sem trade-off**.
|
||||
|
||||
### Resolução proposta — MVP mínimo defensível
|
||||
|
||||
- ✅ **Rafael cockpit** (Rep — primária, mobile-first) — obrigatório
|
||||
- ✅ **Sandra cockpit** (simplificado) — obrigatório
|
||||
- ✅ **Arquitetura multi-tenant BD-por-workspace** — fundacional
|
||||
- ✅ **WhatsApp** — versão básica (notificações; conversa bidirecional pós-MVP)
|
||||
- 🟡 **Daniel cockpit** — dashboard simples; **IA estratégica entra pós-MVP**
|
||||
- 🟡 **Alice cockpit** — cadastros essenciais; **editor no-code de campanhas entra pós-MVP**
|
||||
|
||||
**Premissa:** 1º cliente é referência interna ou parceiro próximo, aceita limitações em troca de condições especiais. Quando o cliente renova (north star atingida), Julian contrata 1-2 devs e completa IA + editor no-code + cockpits ricos.
|
||||
|
||||
### Plataforma & device strategy
|
||||
|
||||
| Cockpit | Plataforma |
|
||||
|---|---|
|
||||
| 🟢 Rafael | **PWA mobile-first foco iOS** (Android continua com app legado por enquanto) |
|
||||
| 🟡 Sandra | Desktop + PWA mobile-light |
|
||||
| 🔵 Daniel | Desktop + **iPad first-class** (otimização dedicada) |
|
||||
| 🟣 Alice | Desktop-only |
|
||||
|
||||
### Offline strategy (Rafael)
|
||||
|
||||
**Read + Write com sync** — IndexedDB queue + Service Worker. Lançamento de pedido offline → sincroniza quando volta sinal. Idempotency-Key local protege contra duplicação.
|
||||
|
||||
### Native features no MVP
|
||||
|
||||
✅ Geolocation (check-in) · Web Push (Sandra: aprovação; Rafael: pedido aprovado) · Share API (compartilhar via WhatsApp do celular) · Notification API desktop. **Camera e File System Access entram pós-MVP.**
|
||||
|
||||
### Coexistência com app Android legado
|
||||
|
||||
- **MVP:** SAR PWA + backend SAR construídos. Android legado intocado.
|
||||
- **Pós-MVP (Y1+):** App Android legado é adaptado para consumir backend SAR.
|
||||
- **Futuro (Y1-Y2):** Avaliar native iOS + native Android sobre backend SAR.
|
||||
|
||||
### Stack canon JCS v2.2 (fonte da verdade)
|
||||
|
||||
Node 24 LTS · pnpm 11.1 · TypeScript 5.9 · Nx 22.7 · NestJS 11.1 · Prisma 7 · PostgreSQL 18 · React 19.2 + Vite 8 · Ant Design 6.4 · TanStack Query/Router · Zustand · Zod 4 · master-login (IdP próprio) · jose · argon2id · BullMQ 5.77 · Socket.IO 4 + SSE · MinIO · Vault · OpenTelemetry + Pino · Resend · Proxmox on-prem BR · Docker Compose · Ansible deploy · Cloudflare + Nginx.
|
||||
|
||||
**Decisões abertas (Step 29):** provider de pagamento, provider de IA, WhatsApp Business API provider, analytics de produto.
|
||||
|
||||
### Brand canon (brand.md)
|
||||
|
||||
Paleta JCS Blue `#004a99` · Plus Jakarta Sans (400-800) · Font Awesome 6.4 · Chart.js · Radius 12/20px · Sombra `0 4px 25px rgba(0,0,0,0.05)` · Topbar 80px + Sidebar 260px · Tom visual Apple-inspired clean. Dark mode desejável (Rafael uso noturno).
|
||||
|
||||
### LGPD by design (STACK.md §22)
|
||||
|
||||
Isolamento físico cluster PG por workspace · datacenter BR (sem CLOUD Act US) · PII criptografada (MinIO SSE + pgcrypto) · redact em logs · Art. 18 implementado · DPA com Meta/OpenAI obrigatório · hashar dados antes de enviar para IA · opt-in explícito do contato final no WhatsApp.
|
||||
|
||||
---
|
||||
|
||||
## Tone of Voice
|
||||
|
||||
### Cinco atributos canônicos
|
||||
|
||||
1. **Direto** — sem floreio
|
||||
2. **Profissional sem ser frio** — sério, mas humano (não burocratês)
|
||||
3. **Confiante** — afirmativo, não tentativo
|
||||
4. **Específico** — números/dados sempre que possível
|
||||
5. **Empático nos momentos difíceis** — explica problema + caminho
|
||||
|
||||
### Variações por cockpit (mesmos atributos, registros distintos)
|
||||
|
||||
- **Rafael:** mais informal, frases curtas, foco em ação ("Sem sinal. Envio depois.")
|
||||
- **Sandra:** direto + decisivo, contexto rápido ("3 aprovações pendentes.")
|
||||
- **Daniel:** executivo, foco em insight ("Faturamento +18% vs mês anterior.")
|
||||
- **Alice:** técnico-preciso, mas humano ("Pauta atualizada. 1.247 produtos afetados.")
|
||||
|
||||
### Vocabulário canônico (padrão único)
|
||||
|
||||
**Cliente** · **Representante / Rep** · **Orçamento** · **Pedido** · **Faturado** · **Visita** · **Carteira** · **Inativo** · **Painel** · **Aprovação**
|
||||
|
||||
### Don'ts
|
||||
|
||||
❌ Emoji em produção · caps lock para erros · burocratês ("operação", "registro", "movimentação") · "Por favor"/"obrigado" excessivos · trocadilhos/gírias · anglicismos desnecessários · frases dúbias ("Talvez", "Possivelmente")
|
||||
|
||||
---
|
||||
|
||||
## Riscos e mitigações
|
||||
|
||||
| Risco | Detecção | Mitigação |
|
||||
|---|---|---|
|
||||
| Rafael não adota | DAU/MAU < 50% em 60 dias | Revisão UX mobile-first; possível pivot de interação |
|
||||
| Sandra não confia | Aprovações via WhatsApp > 30% | Investigação: SAR lenta? Falta contexto? Workflow ruim? |
|
||||
| Daniel ignora IA | < 1x/semana em IA insights | IA irrelevante / pouco visível / black box demais |
|
||||
| North star falha | Cliente cancela em 3 meses | Review estrutural do MVP |
|
||||
| Pedidos perdidos por bug | > 0 incidentes em qualquer janela | P0 imediato — bloqueio de release até root cause |
|
||||
| WhatsApp/Meta muda regras | Integração quebra | Arquitetura plug-in; Telegram/SMS no roadmap |
|
||||
| IA não convence donos | NPS Daniel baixo | Manter explicabilidade; possível recuo da IA para feature secundária |
|
||||
| Solo founder esgotamento | Velocidade caindo | Contratar 1 dev mesmo antes do 1º cliente |
|
||||
|
||||
---
|
||||
|
||||
## Próximos passos
|
||||
|
||||
| Bloco da Phase 1 | Steps | Status | Conteúdo |
|
||||
|---|---|---|---|
|
||||
| **A. Product Brief** | 1-12 | ✅ **CONCLUÍDO (este documento)** | Vision · Positioning · Users · Business Model · Success · Competitive · Constraints · Platform · Tone |
|
||||
| B. Content & Language | 13-18 | ⏳ Próximo | Personality · Tone (refinamento) · Languages · SEO · Content structure |
|
||||
| C. Visual Direction | 19-26 | Fast-track via brand.md | Design style · Layout · Effects · Imagery |
|
||||
| D. Platform Requirements | 27-32 | Fast-track via STACK.md | Tech stack · Integrations · Contact strategy · Multilingual |
|
||||
| E. Wrap-up | 33-36 | Pendente | Analyze · Summary · Design log · Activation Phase 2 |
|
||||
|
||||
**Após Phase 1:** Phase 2 — Trigger Mapping (aprofundar driving forces das 4 personas).
|
||||
|
||||
---
|
||||
|
||||
## Anexos
|
||||
|
||||
- **brand.md** — identidade visual JCS
|
||||
- **STACK.md v2.2** — stack canônica
|
||||
- **CODING-RULES.md v2.0** — invariantes + pegadinhas
|
||||
- **design-artifacts/_references/legacy-screens-html/index.html** — mockup SPA do SAR (9 telas)
|
||||
- **dialog/** — histórico detalhado de cada decisão (client-profile, vision, positioning, business-model, business-customers, target-users, product-concept, success-criteria, competitive-landscape, constraints, platform-strategy, tone-of-voice)
|
||||
|
||||
---
|
||||
|
||||
_Powered JCS. Sistema SAR — Força de Vendas · Product Brief v1.0_
|
||||
550
design-artifacts/A-Product-Brief/02-content-language.md
Normal file
550
design-artifacts/A-Product-Brief/02-content-language.md
Normal file
@@ -0,0 +1,550 @@
|
||||
# Content & Language: SAR — Força de Vendas
|
||||
|
||||
**Status:** ✅ Block B COMPLETO (Steps 13-18)
|
||||
**Cliente:** JCS Sistemas
|
||||
**Última atualização:** 2026-05-26
|
||||
|
||||
> Este documento define **como o SAR fala** em todas as camadas — personalidade da marca, tom, idioma, SEO, arquitetura de conteúdo. Companion do `01-product-brief.md`.
|
||||
|
||||
---
|
||||
|
||||
## Materiais herdados (entrada para Block B)
|
||||
|
||||
- **`brand.md`** — identidade visual + tom visual "Apple-inspired, clean, minimalista"
|
||||
- **`01-product-brief.md`** — positioning, buyer persona, 4 user personas
|
||||
- **`dialog/tone-of-voice.md`** (Step 11) — 5 atributos canônicos + variações por cockpit + vocabulário canônico
|
||||
|
||||
---
|
||||
|
||||
## Personality
|
||||
|
||||
### "Se o SAR fosse uma pessoa..."
|
||||
|
||||
> **Um consultor sênior de vendas B2B brasileiro**, 40-50 anos, ex-representante que virou consultor de vendas. Conhece a rua, conhece o ERP, conhece o WhatsApp. Entra na sua empresa, observa por uma semana e começa a apontar onde está sangrando — sem julgar, sem PowerPoint, sem firula. Diz o que precisa ser dito, no momento certo, com dados na ponta da língua.
|
||||
|
||||
### 5 atributos de personalidade
|
||||
|
||||
| # | Atributo | O que significa | Como se expressa |
|
||||
|---|---|---|---|
|
||||
| **1** | **Confiável** | Não some, não erra pedido, dados não se perdem. Funciona sem drama. | "Pedido #1234 aprovado" · uptime 99.5% · pedidos perdidos = 0 |
|
||||
| **2** | **Especialista prático** | Conhece o setor de força de vendas BR de cor (anos de JCS Android+Desktop). Fala como amigo prático, não acadêmico. | Vocabulário do setor usado naturalmente · IA explicável · zero jargão academicista |
|
||||
| **3** | **Decidido** | Não fica em "talvez você queira considerar". Diz o que é, aponta o caminho. | "Cliente OPENFRIOS bloqueado: limite estourado." · botões diretos |
|
||||
| **4** | **Discreto** | Não atrapalha, não enche de modais. Faz seu trabalho sem ruído. | Apple-inspired clean · zero notificação desnecessária · empty states informativos |
|
||||
| **5** | **Aliado** | Está do lado do usuário, **não vigiando**. | Linguagem inclusiva · IA sugere não impõe · sem tom punitivo |
|
||||
|
||||
### Conexão com cada persona
|
||||
|
||||
| Persona | Como o "consultor sênior" se relaciona |
|
||||
|---|---|
|
||||
| **🟢 Rafael (Rep)** | **Colega mais experiente** — dicas práticas, mostra status na hora que precisa |
|
||||
| **🟡 Sandra (Supervisora)** | **Assessor de confiança** — prepara o que ela precisa, sem decidir por ela |
|
||||
| **🔵 Daniel (Dono)** | **Consultor estratégico** — 1 frase de insight, não relatório de 50 páginas |
|
||||
| **🟣 Alice (Admin)** | **Técnico que entende processo** — antecipa, não pergunta o óbvio |
|
||||
|
||||
### O que o SAR **não é**
|
||||
|
||||
❌ Vendedor barulhento ("Compre agora!" "Promoção!")
|
||||
❌ Burocrata ("O sistema identificou que...")
|
||||
❌ Coach motivacional ("Você consegue! Vai!")
|
||||
❌ Espião (não dedura rep, não relatório de "produtividade pessoal")
|
||||
❌ Filósofo (não explica feature em parágrafos)
|
||||
❌ Jovem descolado (sem emoji, sem gíria, sem meme)
|
||||
|
||||
### Síntese
|
||||
|
||||
O SAR tem a personalidade de um **consultor sênior brasileiro de vendas B2B** — confiável, especialista prático, decidido, discreto e aliado. Conhece o setor de cor, fala a língua de quem está na rua e de quem está no escritório, mas não ostenta saber nem enche linguiça. Aparece quando é útil, some quando não é. Diz o que precisa ser dito, com dados, no momento certo. É colega do Rafael, assessor da Sandra, consultor do Daniel, e técnico-parceiro da Alice — sem nunca virar nem vendedor barulhento, nem burocrata, nem espião, nem jovem descolado.
|
||||
|
||||
---
|
||||
|
||||
## Tone of Voice (refinamento via spectrums)
|
||||
|
||||
### Posicionamento nos 4 espectros (1-5)
|
||||
|
||||
| Espectro | Posição | Significado |
|
||||
|---|---|---|
|
||||
| **Formality** | **3** (meio-termo, levemente formal) | Profissional sem ser frio — "roupa social leve, não terno, não camiseta" |
|
||||
| **Mood** | **2** (sério-com-leveza) | Não brincalhão, mas com momentos leves nos estados vazios |
|
||||
| **Complexity** | **3** (vocabulário do setor + acessível) | Usa pauta/ICMS-ST/faturado sem traduzir, mas explica IA e erros |
|
||||
| **Energy** | **2** (reservado) | Apple-inspired calm — sem exclamações, sem emojis em produção |
|
||||
|
||||
### Mapa visual
|
||||
|
||||
```
|
||||
Formality: Formal ┤──────●──── Casual (3/5)
|
||||
Mood: Serious ┤───●──────── Playful (2/5)
|
||||
Complexity: Technical ┤──────●──── Simple (3/5)
|
||||
Energy: Reserved ┤───●──────── Enthusiastic (2/5)
|
||||
```
|
||||
|
||||
**Centro de gravidade:** levemente formal, sério-com-leveza, tecnicamente acessível, energia contida.
|
||||
|
||||
### We Say / We Don't Say (canônico)
|
||||
|
||||
#### Cumprimentos / status
|
||||
|
||||
| Contexto | ✅ We say | ❌ Formal demais | ❌ Casual demais |
|
||||
|---|---|---|---|
|
||||
| Login do Rafael | "Bom dia, Rafael" | "Prezado(a) usuário" | "E aí, Rafael!" |
|
||||
| Sandra acessa | "3 aprovações pendentes" | "Existem 3 aprovações pendentes no sistema" | "Olha só, 3 coisas pra você!" |
|
||||
| Painel do Daniel | "Faturamento em junho: R$ 1.2M (+18%)" | "Resultado consolidado de faturamento" | "Explodiu o mês!" |
|
||||
|
||||
#### Sucesso / confirmação
|
||||
|
||||
| Contexto | ✅ We say | ❌ Formal | ❌ Casual |
|
||||
|---|---|---|---|
|
||||
| Pedido enviado | "Pedido #1234 enviado" | "Sua solicitação foi processada com êxito" | "Foi! Pedido na mão." |
|
||||
| Aprovação | "Pedido #1234 aprovado pela Sandra" | "Operação validada por usuário supervisor" | "Sandra liberou!" |
|
||||
| Check-in | "Check-in registrado em **OPENFRIOS** às 14:32" | "Registro de visita armazenado com sucesso" | "Pegou o cliente!" |
|
||||
|
||||
#### Erro / problema
|
||||
|
||||
| Contexto | ✅ We say | ❌ Formal | ❌ Casual |
|
||||
|---|---|---|---|
|
||||
| Sem conexão | "Sem sinal. Seu pedido fica salvo aqui e envia quando você se conectar." | "Falha de conectividade detectada." | "Aí ó, caiu! Mas relaxa." |
|
||||
| Cliente bloqueado | "**OPENFRIOS** bloqueado: limite de crédito estourado. Peça liberação ou ajuste o valor." | "Bloqueio comercial automático ativado por restrição financeira." | "Eita, esse aí tá no vermelho!" |
|
||||
| Senha errada | "Senha incorreta. Tente de novo ou **recupere sua senha**." | "Credenciais inválidas. Verifique e tente novamente." | "Hmm, essa senha não bate" |
|
||||
|
||||
#### Empty states
|
||||
|
||||
| Contexto | ✅ We say | ❌ Formal | ❌ Casual |
|
||||
|---|---|---|---|
|
||||
| Funil vazio | "Sem propostas em andamento. Cadastre a primeira em **Nova proposta**." | "Nenhum registro foi localizado na consulta." | "Tudo vazio! Bora preencher!" |
|
||||
| Sem pedidos hoje | "Nenhum pedido lançado hoje. Bom dia para mudar isso." | "Não há registros para o período informado." | "Dia parado hoje, hein?" |
|
||||
| Inativos zerado | "Nenhum cliente inativo nos últimos 60 dias." | "Inexistem clientes em estado de inatividade." | "Tudo certo, parabéns!" |
|
||||
|
||||
#### IA / sugestão
|
||||
|
||||
| Contexto | ✅ We say | ❌ Formal | ❌ Casual |
|
||||
|---|---|---|---|
|
||||
| Daniel — descontos | "Você aprovou 3 descontos acima de 10% essa semana, todos para OPENFRIOS. Reavaliar tabela?" | "Detectada concentração de aprovações acima do padrão." | "Olha esse OPENFRIOS aí roubando seus descontos!" |
|
||||
| Rafael — cliente | "OPENFRIOS não compra há 47 dias. Visite ou ligue." | "Cliente sem atividade comercial registrada nos últimos 47 dias." | "Cliente esfriando! Corre lá!" |
|
||||
|
||||
### Reuso do Step 11
|
||||
|
||||
Os **5 atributos canônicos** (`dialog/tone-of-voice.md`) e o **vocabulário canônico** seguem como tokens — não duplico aqui. Este documento adiciona apenas a calibragem por espectro + We Say/Don't Say expandidos.
|
||||
|
||||
---
|
||||
|
||||
## Languages
|
||||
|
||||
### Estratégia canônica
|
||||
|
||||
> **pt-BR only no MVP, arquitetura i18n-ready.**
|
||||
|
||||
| Idioma | Status MVP | Prioridade futura |
|
||||
|---|---|---|
|
||||
| **pt-BR** | ✅ Único idioma do produto, site, marketing, IA | Sempre primário |
|
||||
| **en** | 🟡 Não no MVP — preparado no código (chaves i18n) | Eventual: parceiros internacionais, futuras integrações |
|
||||
| **es (LatAm)** | ❌ Fora de escopo no MVP | Possível Y2+ se houver expansão Argentina/Paraguai/Uruguai (requer adaptação fiscal por país) |
|
||||
|
||||
### Por quê pt-BR only
|
||||
|
||||
- Target = empresas brasileiras (positioning, Step 3)
|
||||
- Vocabulário do setor (carteira, faturado, pauta, ICMS-ST, NCM, NF) só faz sentido em pt-BR
|
||||
- Concorrência regional pt-BR only (Mercos, Promosoft, MaxFV)
|
||||
- JCS comunica em pt-BR (config.yaml)
|
||||
- Zero ROI imediato em traduzir antes do MVP fechar
|
||||
|
||||
### Por quê i18n-ready arquitetural
|
||||
|
||||
Custo marginal de usar chaves i18n agora é **muito menor** que retrofit depois:
|
||||
|
||||
- React-i18next ou similar (decisão técnica de Phase 3+)
|
||||
- Todas as strings de UI em arquivo `pt-BR.json` (não hardcoded em JSX)
|
||||
- Vocabulário canônico fixo no Step 11 já naturalmente vira chaves consistentes (`pedido.status.aprovado`, `cliente.estado.inativo`, etc.)
|
||||
- Preserva opção de expansão Y2+ sem reescrita
|
||||
|
||||
### Implementação prática (encaminha para Phase 3)
|
||||
|
||||
- Chaves estruturadas: `cockpit.<rafael|sandra|daniel|alice>.<area>.<elemento>`
|
||||
- Validação de output da IA: rejeitar respostas em en, fazer fallback ou retry com prompt mais firme
|
||||
- Prompts de IA em pt-BR sempre (preserva qualidade linguística)
|
||||
|
||||
---
|
||||
|
||||
## Localização (BR-only)
|
||||
|
||||
| Item | Padrão SAR |
|
||||
|---|---|
|
||||
| **Moeda** | BRL (`R$ X.XXX,XX` — vírgula decimal, ponto milhar) |
|
||||
| **Data** | DD/MM/AAAA (calendário gregoriano BR) |
|
||||
| **Hora** | 24h (HH:mm), fuso `America/Sao_Paulo` por workspace; UTC armazenado no PG |
|
||||
| **Telefone** | `+55 (XX) XXXXX-XXXX` (celular) · `+55 (XX) XXXX-XXXX` (fixo) |
|
||||
| **CEP** | `XXXXX-XXX` |
|
||||
| **CNPJ** | `XX.XXX.XXX/XXXX-XX` |
|
||||
| **CPF** | `XXX.XXX.XXX-XX` |
|
||||
| **Endereço** | Padrão BR (Logradouro, número, complemento, bairro, cidade, UF, CEP) |
|
||||
| **Pesos/medidas** | Sistema métrico (kg, g, l, ml, m, cm) |
|
||||
|
||||
### Implicação para STACK
|
||||
|
||||
- Validators no Zod para CPF/CNPJ/CEP/telefone BR (libs do ecossistema NPM)
|
||||
- Date-fns ou Day.js com locale `pt-BR`
|
||||
- `Intl.NumberFormat('pt-BR', { style: 'currency', currency: 'BRL' })` para formatação
|
||||
- Fuso por workspace armazenado no master-login (cliente em SP ≠ cliente em Manaus)
|
||||
|
||||
---
|
||||
|
||||
## Tone consistency
|
||||
|
||||
Não aplicável no MVP (idioma único). Se um dia for bilíngue, regra: **personalidade idêntica** ("consultor sênior brasileiro" continua sendo a metáfora), mas **registro adapta** à cultura do idioma destino. en seria um pouco mais formal que pt-BR (formality 3.5 vs 3).
|
||||
|
||||
---
|
||||
|
||||
## SEO Keywords
|
||||
|
||||
### Keywords por intenção
|
||||
|
||||
#### 🎯 Service / Solução (alta intent comercial)
|
||||
- `software de força de vendas` · `sistema de força de vendas` · `plataforma de força de vendas`
|
||||
- `software para representante comercial` · `sistema para representante externo` · `app para vendedor externo`
|
||||
- `SaaS força de vendas`
|
||||
|
||||
#### 🩺 Problem (leads quentes)
|
||||
- `como controlar representante externo`
|
||||
- `como saber quais clientes pararam de comprar`
|
||||
- `como organizar pedidos de representantes`
|
||||
- `como aprovar desconto vendedor externo`
|
||||
- `como integrar WhatsApp com vendas B2B`
|
||||
- `como acompanhar meta de vendedor`
|
||||
- `como saber se rep está visitando cliente`
|
||||
|
||||
#### ⚖️ Comparison (fundo de funil)
|
||||
- `alternativa ao Mercos` · `alternativa ao Promosoft`
|
||||
- `Mercos preço` · `Mercos vs MaxFV` · `Promosoft vs Mercos`
|
||||
- `software força de vendas comparativo` · `melhor software força de vendas`
|
||||
|
||||
#### 🏷️ Brand
|
||||
- `SAR JCS` · `JCS Sistemas` · `SAR força de vendas` · `JCS força de vendas`
|
||||
|
||||
#### 📚 Informational (top of funnel + autoridade)
|
||||
- `o que é força de vendas`
|
||||
- `como funciona representação comercial`
|
||||
- `diferença entre rep e vendedor interno`
|
||||
- `gestão de carteira ativa`
|
||||
- `inteligência artificial em vendas B2B`
|
||||
- `como recuperar cliente inativo`
|
||||
- `KPIs força de vendas`
|
||||
|
||||
#### 🎯 Long-tail setor-específico
|
||||
- `software para distribuidora de bebidas`
|
||||
- `sistema para indústria de alimentos vendas`
|
||||
- `ERP para representação comercial autônoma RCA`
|
||||
- `gestão de força de vendas para distribuidora alimentícia`
|
||||
- `software para indústria de produtos químicos vendas`
|
||||
|
||||
### Domínio
|
||||
|
||||
**A definir** — opções priorizadas:
|
||||
1. `sarjcs.com.br` (Recomendado — brandable + JCS-link, requer verificação de disponibilidade)
|
||||
2. `sar.jcs.com.br` (subdomain — JCS-centric)
|
||||
3. `sarforcadevendas.com.br` (SEO-rich, longo)
|
||||
4. `sar.com.br` (curto, premium — verificar disponibilidade)
|
||||
|
||||
### Padrão de URL
|
||||
|
||||
- pt-BR primário: `<dominio>/<slug>`
|
||||
- en futuro (i18n-ready): `<dominio>/en/<slug>`
|
||||
- Slug: lowercase · hífen · sem especiais · ASCII · curto
|
||||
|
||||
### Sitemap
|
||||
|
||||
```
|
||||
/ [Hero, prova social, 3 cockpits, CTA demo]
|
||||
/funcionalidades/
|
||||
/funcionalidades/cockpit-representante
|
||||
/funcionalidades/cockpit-supervisor
|
||||
/funcionalidades/cockpit-dono
|
||||
/funcionalidades/cockpit-admin
|
||||
/funcionalidades/whatsapp-nativo
|
||||
/funcionalidades/ia-estrategica
|
||||
/funcionalidades/carteira-ativa
|
||||
|
||||
/para/ [Páginas por setor]
|
||||
/para/distribuidoras
|
||||
/para/industrias
|
||||
/para/representacoes-comerciais
|
||||
/para/pequenas-empresas
|
||||
|
||||
/comparativos/ [Combate frontal]
|
||||
/comparativos/sar-vs-mercos
|
||||
/comparativos/sar-vs-promosoft
|
||||
/comparativos/sar-vs-modulo-totvs
|
||||
|
||||
/precos [Pricing transparente]
|
||||
/recursos [Hub de conteúdo]
|
||||
/recursos/blog/ [Content marketing]
|
||||
/recursos/calculadora-roi [Lead magnet]
|
||||
/recursos/kit-vendedor-externo [Lead magnet]
|
||||
/cases [Cases de cliente — alimenta canal #1]
|
||||
/parceiros [Contadores, revendedores ERP]
|
||||
/sobre [JCS + time + missão]
|
||||
/contato [Form demo — CTA principal]
|
||||
|
||||
/app/ [Produto SAR (auth via master-login)]
|
||||
```
|
||||
|
||||
### Page × Primary Keyword map (top 10)
|
||||
|
||||
| Página | Slug | Primary keyword | Secondary |
|
||||
|---|---|---|---|
|
||||
| Home | `/` | `software de força de vendas` | `SAR`, `JCS` |
|
||||
| Cockpit Rep | `/funcionalidades/cockpit-representante` | `app para representante comercial` | `app para vendedor externo` |
|
||||
| Cockpit Supervisor | `/funcionalidades/cockpit-supervisor` | `como acompanhar vendedor externo` | `controle de representantes` |
|
||||
| Cockpit Dono | `/funcionalidades/cockpit-dono` | `BI força de vendas com IA` | `inteligência artificial em vendas` |
|
||||
| WhatsApp nativo | `/funcionalidades/whatsapp-nativo` | `integração WhatsApp com vendas B2B` | `aquecimento de lead WhatsApp` |
|
||||
| Carteira ativa | `/funcionalidades/carteira-ativa` | `recuperar cliente inativo` | `gestão de carteira ativa` |
|
||||
| Distribuidoras | `/para/distribuidoras` | `software para distribuidora` | `sistema força de vendas distribuidor` |
|
||||
| SAR vs Mercos | `/comparativos/sar-vs-mercos` | `alternativa ao Mercos` | `Mercos comparativo` |
|
||||
| Preços | `/precos` | `preço software força de vendas` | `quanto custa Mercos`, `SAR preço` |
|
||||
| Blog "controlar rep" | `/recursos/blog/como-controlar-representante-externo` | `como controlar representante externo` | `app para acompanhar vendedor` |
|
||||
|
||||
### Local SEO
|
||||
|
||||
Aplicabilidade média. SAR é nacional, mas a JCS Sistemas mantém presença local.
|
||||
|
||||
- **Reivindicar** Google Business Profile da JCS Sistemas
|
||||
- **NAP consistente** no footer (Nome, Endereço, Phone)
|
||||
- **Categoria Google:** Software company
|
||||
- **Reviews** de clientes JCS alimentam credibilidade
|
||||
|
||||
### Structured data plan
|
||||
|
||||
| Página | Schema.org |
|
||||
|---|---|
|
||||
| Todas | `Organization` (JCS Sistemas) |
|
||||
| Home | `SoftwareApplication` (SAR) + `Organization` |
|
||||
| Preços | `Product` + `Offer` por tier |
|
||||
| Cases | `Article` + `Review` |
|
||||
| Comparativos | `Article` |
|
||||
| Blog | `Article` + `BreadcrumbList` |
|
||||
| Calculadora ROI | `SoftwareApplication` |
|
||||
| Páginas com FAQ | `FAQPage` |
|
||||
|
||||
### Keyword usage guidelines
|
||||
|
||||
- **Title tag:** primary keyword + brand (`SAR — Software de Força de Vendas | JCS`), 60 chars
|
||||
- **Meta description:** keyword + benefício + CTA, 150-160 chars
|
||||
- **H1:** primary keyword (pode diferir do title)
|
||||
- **Body:** mention natural, sem stuffing
|
||||
- **Alt text:** descritivo + keyword onde aplicável
|
||||
- **Slug:** curto, keyword-rich, sem stopwords
|
||||
|
||||
---
|
||||
|
||||
## Content Structure Principles
|
||||
|
||||
> Princípios (não especificações). Phase 4 (UX Design) traduz em telas concretas.
|
||||
|
||||
### 🌐 Site Marketing
|
||||
|
||||
1. **Hero entrega proposta em <5 segundos** — frase clara + visual + 1 CTA único
|
||||
2. **Demo em vídeo, não tour interativo** — Daniel assiste, não mexe; 90s com legendas
|
||||
3. **Prova social pesada** — logos de clientes, depoimentos em vídeo de **donos**, números reais
|
||||
4. **3 jornadas paralelas para 3 personas** — `/para-donos`, `/para-supervisores`, `/para-representantes` (Alice é benefício, não argumento de venda)
|
||||
5. **Setores ganham página dedicada** quando há vocabulário próprio (distribuidoras ≠ indústrias ≠ RCAs)
|
||||
6. **CTA principal único** — "Agende sua demo." (não "saiba mais" + "experimente" + "fale conosco")
|
||||
7. **Pricing visível, não escondido atrás de form** — faixa per-seat clara; fechamento final via comercial
|
||||
8. **Comparativos acessíveis, não em destaque** — `/comparativos/<x>` para quem já compara
|
||||
9. **Conteúdo SEO no `/recursos/`** separado do pitch
|
||||
10. **Cases reais publicáveis** tornam-se peça central quando há 3+ clientes pagantes
|
||||
|
||||
### 🖥️ Produto (4 cockpits)
|
||||
|
||||
1. **Cada cockpit tem sua home dedicada** — Rafael → painel rep, Sandra → "apertar parafusos", Daniel → IA insights + faturamento, Alice → fila cadastros + campanhas
|
||||
2. **Hierarquia por urgência, não categoria** — primeira tela mostra decisões de HOJE
|
||||
3. **Navegação varia por device:**
|
||||
- Rafael (mobile): bottom nav com 4-5 ícones primários
|
||||
- Sandra/Daniel/Alice (desktop): sidebar 260px fixa
|
||||
- Daniel (iPad): sidebar colapsável touch-friendly
|
||||
4. **Profundidade máxima 3 níveis** (Rafael se perde se for mais fundo no celular)
|
||||
5. **WhatsApp e IA não vivem em sub-menu** — diferenciais declarados estão no caminho principal de cada cockpit
|
||||
6. **Empty states informativos**, não placeholders
|
||||
7. **Notificações in-app + push** apenas para decisão (não para "pedido visualizado")
|
||||
8. **Tempo real visível** com micro-animação suave (não toast intrusivo)
|
||||
9. **Configurações fora do caminho principal** — Alice tem sua área (`/admin`)
|
||||
10. **Auditoria onde faz sentido** — histórico em cada entidade (pauta, produto, rep, pedido)
|
||||
11. **Onboarding discreto, Apple-inspired** — tooltips contextuais, sem tour agressivo
|
||||
|
||||
### ❌ Exclusões explícitas (NÃO no MVP)
|
||||
|
||||
| Exclusão | Por quê |
|
||||
|---|---|
|
||||
| Tutorial interativo onboarding agressivo (Intercom-style) | Brand é Apple-inspired clean — discreção é valor |
|
||||
| Gamificação visual gritante (badges, achievements, fogos) | "Supervisor amigo, não Big Brother" — sem ranking público de rep |
|
||||
| Chat-com-cliente-final dentro do produto | Share API + WhatsApp Business já cobrem |
|
||||
| Módulo de marketing email (campanhas em massa) | Resend é transacional; JCS não vira ferramenta de marketing |
|
||||
| Módulo de NF/SPED próprio | Cliente integra com ERP; SAR é vendas, não fiscal completo |
|
||||
| Wallet/pagamento de cliente final | Cliente final paga via outro meio; SAR registra |
|
||||
| CMS de blog para o cliente | SAR não é WordPress |
|
||||
| Mobile-first para Daniel/Alice | Desktop-first é decisão arquitetural (Step 7) |
|
||||
|
||||
### Clareza do PO (calibragem da latitude de Phase 4)
|
||||
|
||||
| Área | Visão |
|
||||
|---|---|
|
||||
| Site marketing | Médio-alto |
|
||||
| Produto (4 cockpits) | Alto |
|
||||
| Onboarding agressividade | Alto (explicitamente discreto) |
|
||||
| Gamificação | Alto (explicitamente sutil/ausente) |
|
||||
| Conteúdo SEO | Médio (keywords mapeadas; tom dos artigos a definir) |
|
||||
| Cases | Baixo (depende de ter clientes) |
|
||||
|
||||
Implicação para Phase 4: **bastante latitude técnica, restrições claras de tom e estilo.**
|
||||
|
||||
---
|
||||
|
||||
## Content Type Guidelines (entradas práticas para Phase 4 e marketing)
|
||||
|
||||
### 🔘 UI Microcopy (botões, labels, erros, estados)
|
||||
|
||||
- **Mantenha curto:** verbos no infinitivo (`Salvar`, `Cancelar`, `Enviar`) ou imperativo direto
|
||||
- **Voz ativa:** "Sandra aprovou", não "Foi aprovado por Sandra"
|
||||
- **Específico sobre a ação:** `Enviar pedido` > `Enviar`
|
||||
- **Vocabulário canônico** sempre (`Cliente`, `Rep`, `Pedido`, `Faturado`)
|
||||
- **Sem ponto final** em botões e labels curtos (`Salvar`, não `Salvar.`)
|
||||
- **Sem maiúsculas em sentence-case:** "Lançar pedido" (não "Lançar Pedido")
|
||||
|
||||
### 📣 Marketing Content (headlines, features, value props)
|
||||
|
||||
- **Lidere com benefício**, não feature ("Veja quantos clientes pararam de comprar" > "Sistema de carteira ativa")
|
||||
- **Frases curtas:** 1 ideia por frase
|
||||
- **Power words do tom:** clareza, controle, decisão, tempo real, visibilidade, sem-mais (Apple-inspired clean — não palavras "promocionais")
|
||||
- **Conecte com driving forces das personas:**
|
||||
- Daniel: clareza estratégica, IA, decisão
|
||||
- Sandra: controle, tempo, equipe sob comando
|
||||
- Rafael: meta, agilidade, ferramenta que respeita
|
||||
- (Alice): autonomia, lançamento sem dev
|
||||
- **Especificidade vence:** "R$ 7.5M em pedidos processados/mês" > "Milhões em vendas"
|
||||
|
||||
### 📚 Informational Content (blog, recursos, sobre)
|
||||
|
||||
- **Responda à pergunta do título logo no primeiro parágrafo** (princípio SEO + tom direto)
|
||||
- **Headings descritivos:** o leitor consegue scanear e entender o esqueleto
|
||||
- **Keywords naturalmente integradas** (sem stuffing)
|
||||
- **Inclua exemplos concretos** (números reais, cenários, vocabulário do setor)
|
||||
- **Conclusão com CTA contextual** (não "compre agora!" — algo como "Veja na prática" ou "Conheça o SAR")
|
||||
|
||||
### 📧 Notificações transacionais (email, push, in-app)
|
||||
|
||||
- **Assunto direto:** `Pedido #1234 aprovado pela Sandra` (não "Atualização do seu pedido")
|
||||
- **Corpo curto:** o que aconteceu + 1 link/ação
|
||||
- **Mesma personalidade:** "consultor sênior" continua firme em email/push
|
||||
- **Footer JCS consistente** (assinatura, contato, opt-out se aplicável)
|
||||
|
||||
### 💬 WhatsApp programático (para o cliente final do cliente SAR)
|
||||
|
||||
> ⚠️ Estas mensagens não são do SAR para o usuário — são do **cliente-empresa** para o **cliente-do-cliente**. SAR fornece templates customizáveis.
|
||||
|
||||
- **Identifique a empresa-cliente claramente:** "Pedido aprovado | OPENFRIOS"
|
||||
- **Não use jargão JCS/SAR:** o cliente final não conhece — é mensagem comercial da empresa-cliente
|
||||
- **Templates aprovados por Meta** (regra WhatsApp Business)
|
||||
- **Opt-out claro** em qualquer mensagem ("Para parar de receber, responda PARAR")
|
||||
|
||||
### 🤖 IA generativa (alertas, sugestões, insights)
|
||||
|
||||
- **Sempre em pt-BR** (validação de output)
|
||||
- **Explicável:** cada insight tem "por quê" curto ("Você aprovou 3 descontos acima de 10%, todos para OPENFRIOS")
|
||||
- **Sugestão, nunca ordem:** "Considere reavaliar..." / "Pode valer a pena..." (mas SEM cair em "talvez você queira considerar...")
|
||||
- **Específico com números:** sem "alguns", "vários", "muitos"
|
||||
- **Confiável:** se não houver dado, IA não inventa — diz "Não tenho dados suficientes para essa análise ainda"
|
||||
|
||||
---
|
||||
|
||||
## Content Ownership (quem escreve o quê)
|
||||
|
||||
> Estado MVP (solo founder mode). Refinar conforme JCS contrata.
|
||||
|
||||
| Tipo de conteúdo | Owner MVP | Owner Y1+ | Frequência |
|
||||
|---|---|---|---|
|
||||
| **UI microcopy do produto** | Julian (revisado contra este doc) | UX writer / dev + revisor | A cada feature nova |
|
||||
| **Headlines + value props do site** | Julian | Marketing/Content + revisor de tom | Estabilizado pós-launch |
|
||||
| **Blog / artigos SEO** | Julian (4-8 artigos no MVP) | Content writer freelance/full-time | 4-8/mês |
|
||||
| **Cases publicáveis** | Julian + cliente (entrevista) | Marketing/Content | Cada cliente novo (com release) |
|
||||
| **Notificações transacionais (email/push)** | Julian (revisor único) | UX writer + dev | Por feature |
|
||||
| **Templates WhatsApp** | Julian + cliente revisa | Cliente customiza, JCS aprova | Por cliente |
|
||||
| **Prompts de IA generativa** | Julian (eng + tom) | AI/ML eng + revisor | A cada melhoria de IA |
|
||||
| **Documentação técnica (changelog, API)** | Julian | Dev team | A cada release |
|
||||
| **FAQ / suporte** | Julian (depois de receber primeiras dúvidas reais) | Suporte/CS | Mensal |
|
||||
|
||||
### Princípio de ownership
|
||||
|
||||
> **Quem escreve, valida contra este doc.** Quem revisa, garante que tom + vocabulário + atributos batem.
|
||||
|
||||
Sem comitê de revisão. Solo founder = Julian é também revisor. Quando contratar, contratar revisor independente para vendas + marketing (evita viés-do-tech-founder).
|
||||
|
||||
---
|
||||
|
||||
## Writing Checklist (entra em todo PR de microcopy / artigo / email)
|
||||
|
||||
```
|
||||
- [ ] Tom: bate com os 5 atributos (Direto, Profissional sem ser frio, Confiante, Específico, Empático nos momentos difíceis)?
|
||||
- [ ] Vocabulário: usa palavras canônicas (Cliente, Rep, Orçamento, Pedido, Faturado, etc.)?
|
||||
- [ ] Espectros: dentro de Formality≈3 / Mood≈2 / Complexity≈3 / Energy≈2?
|
||||
- [ ] Sem palavras proibidas (operação, registro, sistema, movimentação como sujeito)?
|
||||
- [ ] Sem anglicismos desnecessários (Submit→Enviar, Loading→Carregando)?
|
||||
- [ ] Sem emoji em produção (exceção: empty states muito específicos)?
|
||||
- [ ] Voz ativa, não passiva?
|
||||
- [ ] Específico com números/nomes quando possível?
|
||||
- [ ] Acessibilidade: linguagem clara, sem jargão sem explicação?
|
||||
- [ ] pt-BR correto (gramática + ortografia)?
|
||||
- [ ] Variação por cockpit respeitada (Rafael informal-curto / Sandra decisivo / Daniel executivo / Alice técnico-preciso)?
|
||||
- [ ] SEO: keyword primária na presença esperada (sem stuffing)?
|
||||
- [ ] CTA único e contextual?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Resumo executivo (Content & Language)
|
||||
|
||||
```
|
||||
─────────────────────────────────────────────────
|
||||
SAR — Content & Language Summary
|
||||
─────────────────────────────────────────────────
|
||||
|
||||
Personality: Consultor sênior brasileiro de vendas B2B
|
||||
(Confiável · Especialista prático · Decidido ·
|
||||
Discreto · Aliado)
|
||||
|
||||
Tone attributes: Direto · Profissional sem ser frio · Confiante ·
|
||||
Específico · Empático nos momentos difíceis
|
||||
|
||||
Spectrums: Formality 3/5 · Mood 2/5 · Complexity 3/5 · Energy 2/5
|
||||
(levemente formal, sério-com-leveza, tecnicamente
|
||||
acessível, energia contida)
|
||||
|
||||
Languages: pt-BR only no MVP, arquitetura i18n-ready
|
||||
(IA generativa sempre em pt-BR com validação)
|
||||
|
||||
Localização: BR completo — BRL · DD/MM/AAAA · 24h America/Sao_Paulo ·
|
||||
CPF/CNPJ/CEP/telefone padrão BR
|
||||
|
||||
Top keywords: software de força de vendas · como controlar
|
||||
representante externo · alternativa ao Mercos ·
|
||||
como saber clientes inativos · BI vendas com IA
|
||||
|
||||
Sitemap: / · /funcionalidades/<cockpit|whatsapp|ia|carteira>
|
||||
/para/<setor> · /comparativos/<concorrente>
|
||||
/precos · /recursos/<blog|calculadora|kit>
|
||||
/cases · /parceiros · /sobre · /contato · /app/
|
||||
|
||||
Vocabulário canon: Cliente · Rep · Orçamento · Pedido · Faturado ·
|
||||
Visita · Carteira · Inativo · Painel · Aprovação
|
||||
|
||||
Exclusões: Tutorial agressivo · gamificação gritante ·
|
||||
chat-com-cliente · marketing email · NF/SPED ·
|
||||
wallet · CMS blog · mobile-first para outros
|
||||
|
||||
─────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Próximos passos
|
||||
|
||||
- Phase 4 (UX Specs) consome este doc para todo microcopy de cada page
|
||||
- Phase 6 (Design System) incorpora este doc no guia de microcopy
|
||||
- Prompts de IA generativa carregam atributos + vocabulário + espectros
|
||||
- Site marketing (em Phase 4 ou paralelo) segue princípios de Content Structure
|
||||
|
||||
**Block B encerrado. Próximo: Block C — Visual Direction (Steps 19-26), fast-track via brand.md.**
|
||||
420
design-artifacts/A-Product-Brief/03-visual-direction.md
Normal file
420
design-artifacts/A-Product-Brief/03-visual-direction.md
Normal file
@@ -0,0 +1,420 @@
|
||||
# Visual Direction: SAR — Força de Vendas
|
||||
|
||||
**Status:** ✅ Block C COMPLETO (Steps 19-26)
|
||||
**Cliente:** JCS Sistemas
|
||||
**Última atualização:** 2026-05-27
|
||||
|
||||
> Define a **direção visual canônica** do SAR. Companion de `01-product-brief.md` e `02-content-language.md`. Reaproveita `brand.md` como base e expande para variantes por cockpit.
|
||||
|
||||
---
|
||||
|
||||
## Materiais herdados (entrada para Block C)
|
||||
|
||||
- **`brand.md`** — identidade visual canônica (paleta, tipografia, layout, ícones, gráficos, tokens, tom visual)
|
||||
- **`frontend/img/SAR_logo_fundo_transparente.png`** + **`SAR_icone_fundo_transparente.png`** — assets de logo
|
||||
- **`design-artifacts/_references/legacy-screens-html/index.html`** — mockup com brand aplicado em 9 telas reais
|
||||
- **`dialog/inspiration-analysis.md`** (Step 19) — 4 referências externas (Apple, Linear, Stripe, Notion) + 7 padrões destilados
|
||||
- **`02-content-language.md`** — tom de voz e princípios de content structure
|
||||
|
||||
---
|
||||
|
||||
## Existing Brand Assets
|
||||
|
||||
### Inventário e decisões
|
||||
|
||||
| Asset | Status | Localização | Decisão |
|
||||
|---|---|---|---|
|
||||
| **Logo SAR** (horizontal, ícone + wordmark + tagline) | ✅ Existe (PNG transparente) | `frontend/img/SAR_logo_fundo_transparente.png` | **Keep + refresh** — gerar SVG + variantes (vertical, monocromática, dark mode) |
|
||||
| **Ícone SAR** | ✅ Existe (PNG transparente) | `frontend/img/SAR_icone_fundo_transparente.png` | **Keep + refresh** — gerar SVG; vira favicon, PWA icon, notification icon |
|
||||
| **Logo JCS Sistemas** | ✅ Existe (4 variantes PNG) | `design-artifacts/_references/jcs-logo/` (azul, preto, branco, transparente) | **Keep + refresh** — gerar SVG; usar em "Powered by JCS" no footer |
|
||||
| **Paleta de cores** | ✅ Decidida | `brand.md` § Paleta | **Keep as-is** — canônica |
|
||||
| **Tipografia Plus Jakarta Sans** | ✅ Decidida | `brand.md` § Tipografia | **Keep as-is** — self-host em produção (LGPD + performance) |
|
||||
| **Iconografia FA 6.4** | ✅ Decidida | `brand.md` § Ícones | **Keep as-is** — importar subset usado |
|
||||
| **Gráficos Chart.js** | ✅ Decidido | `brand.md` § Gráficos | **Keep as-is** — tema custom com paleta JCS |
|
||||
| **Tokens (radius 12/20px + sombra)** | ✅ Decidido | `brand.md` § Bordas/sombras | **Keep as-is** |
|
||||
| **Layout base (topbar 80 + sidebar 260)** | ✅ Decidido | `brand.md` § Layout | **Keep + adaptar por cockpit** (Rafael mobile usa bottom nav) |
|
||||
| **Mockup HTML legado** | ✅ Existe (9 telas com brand aplicado) | `design-artifacts/_references/legacy-screens-html/index.html` | **Refresh** — usar como wireframe baseline; refazer com AntD em Phase 4 |
|
||||
| **Logo dark mode (versão fundo escuro)** | ❌ Não existe | — | **Create** — em Phase 6 (Design System) |
|
||||
| **Fotos/vídeos JCS para cases e /sobre** | 🟡 A confirmar | — | **Create eventualmente** — depende de ter clientes |
|
||||
|
||||
### Análise visual das logos
|
||||
|
||||
**Logo JCS Sistemas** (`logo_azul.png`):
|
||||
- Wordmark "JCS." em JCS Blue, sans-serif moderna bold, com período distintivo
|
||||
- Elemento gráfico: seta/swoosh horizontal passando pelo "C" (sugere movimento, precisão, velocidade)
|
||||
- "sistemas" em peso lighter, lowercase, mesmo tom azul
|
||||
- Layout horizontal, clean, alinha com brand.md "Apple-inspired"
|
||||
|
||||
**Logo SAR** (`SAR_logo_fundo_transparente.png`):
|
||||
- Ícone: quadrado JCS Blue com gráfico de barras crescente em branco (metáfora analytics/dashboard)
|
||||
- Wordmark "SAR" em cinza escuro/preto, bold sans-serif
|
||||
- Tagline "FORÇA DE VENDAS" em letterspaced caps, peso médio, cinza médio
|
||||
- Hierarquia visual deliberada: SAR como produto distinto, JCS é marca-mãe
|
||||
|
||||
### Coerência marca-mãe → produto
|
||||
|
||||
A relação visual JCS ↔ SAR está bem resolvida:
|
||||
- **JCS Blue** é fio condutor (azul do ícone SAR + da wordmark JCS)
|
||||
- **Tipografias diferentes** sinalizam produtos distintos: JCS = "sistemas" (genérico, leve), SAR = "FORÇA DE VENDAS" (específico, técnico)
|
||||
- **Ícone SAR contém ícone de analytics** = comunica diferencial declarado (visibilidade + IA estratégica)
|
||||
|
||||
### Partnership / afiliações declaradas
|
||||
|
||||
| Item | Onde aparece | Estado |
|
||||
|---|---|---|
|
||||
| **"Powered by JCS Sistemas"** | Footer do produto + login screen + página `/sobre` | A implementar (logo JCS já disponível) |
|
||||
| **Selos técnicos** (LGPD compliant, futuras certificações) | Footer público + página `/sobre` | A criar/conquistar |
|
||||
| **Associações setoriais** | — | Nenhuma declarada por ora |
|
||||
| **Franquia / certificação externa** | — | N/A — SAR é produto JCS sob exclusiva propriedade |
|
||||
|
||||
### Brand constraints (não negociáveis)
|
||||
|
||||
- **JCS Blue `#004a99`** como único accent color cromático (brand.md)
|
||||
- **Plus Jakarta Sans** como única família tipográfica (brand.md)
|
||||
- **Logo SAR** deve coexistir com **Logo JCS** em todas as superfícies de marketing/contato (parental → produto)
|
||||
- **Tom visual Apple-inspired** (brand.md) — sem decoração desnecessária, sem gradientes pesados, sem ilustrações ornamentais
|
||||
- **Único destaque cromático** — não usar 5 cores fortes lado a lado; deixar a paleta funcional sem competir com o JCS Blue
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
### Referências positivas (destiladas em Step 19 + categorizadas em Step 22)
|
||||
|
||||
| Categoria | Inspiração | Aplicação no SAR |
|
||||
|---|---|---|
|
||||
| **Layout** | Apple iCloud · Linear · Notion | Sidebar fixa + área limpa · max 3 níveis · white space generoso · sem zebra agressiva |
|
||||
| **Cor** | Apple · Linear | Cinza neutro base + 1 accent (JCS Blue) · cores funcionais só em estados · sem 5 cores fortes lado a lado |
|
||||
| **Tipografia** | Apple · Stripe | Hierarquia por peso e tamanho, não cor · Plus Jakarta 400/500/600/700 · numerais bem dimensionados em dashboards |
|
||||
| **Densidade** | Linear · Stripe | Densidade respirável — tabelas com peso visual baixo, espaço confortável |
|
||||
| **Imagery** | Apple · Stripe | Photography editorial · composições com espaço · sem stock óbvio |
|
||||
| **Efeitos** | Linear · Stripe | Animações sutis funcionais — nunca decorativas |
|
||||
| **Estados** | Notion · Linear | Empty states informativos · loading com contexto · erros conversacionais |
|
||||
| **Dark mode** | Linear · Vercel | Tema escuro elegante (não cinza-meio-cinza) — Rafael à noite |
|
||||
| **Mobile** | Apple iCloud · Linear mobile | Touch 44pt · bottom nav · gestos padrão · safe area iOS |
|
||||
|
||||
Referências detalhadas em `dialog/inspiration-analysis.md`.
|
||||
|
||||
### Referências negativas (estilos a EVITAR)
|
||||
|
||||
| Estilo | Exemplo | Por quê |
|
||||
|---|---|---|
|
||||
| **Burocrata corporativo legado** | ERPs antigos (TOTVS clássico, SAP legado), portais gov | Telas densas, sombras 3D, "Confirmar Operação", azul-cinza pesado |
|
||||
| **Apps verticais BR de força de vendas** | Mercos, Promosoft, MaxFV | UI legada PHP anos 2010, zebra, abas sobrepostas, "hamburger no desktop". Oposto do positioning. |
|
||||
| **SaaS "fofo" / cartunesco** | Mailchimp, Slack-overuse, mascots | Emojis em produção, gradientes coloridos, ilustrações cartoon. SAR é consultor sênior, não meme. |
|
||||
| **Material Design pesado** | Apps Google antigos | Sombras grossas, FAB flutuante, ripple effects exagerados |
|
||||
| **Dashboards BI 2010-2015** | Power BI legado, Tableau antigo | Cores neon, gráficos 3D, layouts apertados, sidebar com 18 ícones |
|
||||
| **Sites brasileiros "exuberantes"** | E-commerces, banners promocionais BR | Blocos berrantes, "OFERTA!" em caps, badges girando, contadores regressivos |
|
||||
| **Tour interativo agressivo** | Pendo/Appcues overuse | Pop-ups, modais de boas-vindas, tooltips persistentes (já em exclusões Step 17a) |
|
||||
|
||||
### Mood keywords (5)
|
||||
|
||||
| # | Mood | Significado visual |
|
||||
|---|---|---|
|
||||
| 1 | **Clean** | White space generoso, sem ruído, foco no essencial |
|
||||
| 2 | **Confident** | Tipografia decisiva, cores assertivas, ações em destaque |
|
||||
| 3 | **Specific** | Números, nomes, dados concretos > generalidades; densidade onde faz sentido |
|
||||
| 4 | **Serene** | Apple-inspired calm — sem exclamações, sem urgência fake, animações sutis |
|
||||
| 5 | **Modern** | Tipografia variável, tokens contemporâneos, padrões 2025+ — explicitamente fora do legado do setor |
|
||||
|
||||
**Frase âncora:** *"clean, confident, specific, serene, modern — como um consultor sênior que apareceu na sua empresa e abriu o notebook."*
|
||||
|
||||
---
|
||||
|
||||
## Design Style
|
||||
|
||||
### UI Visual Style — Modern Flat + Minimal
|
||||
|
||||
Estilo das 4 referências (Apple iCloud, Linear, Stripe, Notion):
|
||||
- Superfícies planas com sombra muito sutil (`0 4px 25px rgba(0,0,0,0.05)`)
|
||||
- Sem skeumorfismo, sem 3D, sem texturas
|
||||
- Bordas com radius suave (12/20px) — moderno, não brutalista
|
||||
- Foco no conteúdo, não no chrome
|
||||
|
||||
### Design Aesthetic — Minimalism contemporâneo / Digital-native modern
|
||||
|
||||
- White space é elemento, não vazio
|
||||
- Cada elemento tem propósito (zero decoração)
|
||||
- Composição assimétrica permitida quando funcional
|
||||
- Sem ilustrações ornamentais — apenas iconografia funcional (Font Awesome 6.4)
|
||||
- Post-Apple aesthetic: produto digital nativo, não digitalização de produto físico
|
||||
|
||||
### Color Direction — Monochromatic + functional accents
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Scheme** | Monochromatic (JCS Blue tones) + functional accents (verde sucesso · laranja alerta · vermelho erro) |
|
||||
| **Temperatura** | Cool (azul + cinzas neutros frios) |
|
||||
| **Luminosidade** | Light primary + dark mode elegante (Rafael à noite) |
|
||||
| **Saturação** | Média — JCS Blue protagonista; outros tons funcionais com saturação controlada |
|
||||
| **Distribuição** | 60% neutros · 30% white space · 10% accents |
|
||||
| **EVITAR** | Vermelho como primary · laranja saturado · gradientes complexos multi-color · paletas 5+ cores fortes simultâneas · neon (BI 2010-2015) · muted (timidez) |
|
||||
|
||||
### Typography Direction — Plus Jakarta Sans (Geometric Humanist)
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Família** | Plus Jakarta Sans (única) — pesos 400-800 |
|
||||
| **Classificação** | Geometric Humanist (proporções geométricas + calor humanista — confident sem ser frio) |
|
||||
| **Headlines** | Bold (700) e ExtraBold (800), tamanhos grandes |
|
||||
| **Body** | Regular (400) e Medium (500), alta legibilidade |
|
||||
| **Numerais** | Tabular figures em dashboards (Daniel/Sandra precisam de colunas alinhadas) |
|
||||
| **Tracking** | Default em texto; expanded em CAPS (referência: `FORÇA DE VENDAS` do logo SAR) |
|
||||
| **Personalidade** | Confident, decisivo, moderno, neutro-com-leve-calor |
|
||||
| **Hierarquia preliminar (refinar Phase 6)** | h1 32-40px · h2 24-28px · h3 20px · body 14-16px · caption 12-13px |
|
||||
|
||||
---
|
||||
|
||||
## Layout & Effects
|
||||
|
||||
### 🌐 Site Marketing
|
||||
|
||||
#### Hero (home)
|
||||
**Split hero** — texto à esquerda + vídeo (thumbnail com play) à direita. Equilibra storytelling Apple-clean com o "ver SAR em 90s" do Step 17a. **Sem autoplay** — play on click para economizar dados de quem está em mobile.
|
||||
|
||||
#### Content layout por tipo de página
|
||||
|
||||
| Página | Pattern |
|
||||
|---|---|
|
||||
| `/` (home) | Single column com seções fluidas (storytelling) |
|
||||
| `/funcionalidades/*` | Card-based + grid (modular, escaneável) |
|
||||
| `/comparativos/*` | Side-by-side comparison table |
|
||||
| `/recursos/blog/*` | Single column clássico (foco em leitura) |
|
||||
| `/precos` | 3-column tier + FAQ embaixo |
|
||||
| `/para/<setor>` | Single column com sections customizadas |
|
||||
|
||||
#### Navegação site
|
||||
- Top nav sticky com 5-6 itens
|
||||
- Hamburger apenas mobile (não desktop)
|
||||
- Mega menu apenas em `Funcionalidades` e `Para`
|
||||
- CTA "Agende demo" sempre visível no header
|
||||
|
||||
---
|
||||
|
||||
### 🖥️ Produto — Layout por cockpit
|
||||
|
||||
| Cockpit | Layout principal | Pattern dominante |
|
||||
|---|---|---|
|
||||
| **🟢 Rafael (mobile)** | Single column · cards verticais · bottom nav 4-5 ícones | Stack vertical com pull-to-refresh |
|
||||
| **🟡 Sandra (desktop)** | Sidebar 260px + área de conteúdo · grid de cards + tabelas | Dense + decisão (Linear-like) |
|
||||
| **🔵 Daniel (desktop/iPad)** | Sidebar 260px + **bento box** dashboard (KPIs em tamanhos variados) | Bento moderno (Stripe-like) |
|
||||
| **🟣 Alice (desktop)** | Sidebar 260px + **table-first** + forms em modal/drawer lateral | Dense forms com assistente lateral |
|
||||
|
||||
#### Navegação produto
|
||||
- Sidebar 260px fixa para Sandra/Daniel/Alice (brand.md canon) — colapsável em iPad
|
||||
- Bottom nav para Rafael
|
||||
- Topbar 80px com search/command bar central + perfil + notificações
|
||||
- Breadcrumb opcional em profundidade > 2 níveis
|
||||
|
||||
---
|
||||
|
||||
### ✨ Visual Effects (níveis canônicos)
|
||||
|
||||
| Efeito | Nível SAR | Notas |
|
||||
|---|---|---|
|
||||
| **Shadows** | Sutil (`0 4px 25px rgba(0,0,0,0.05)` brand.md) | Único nível base; elevated card pode ter sombra ligeiramente maior |
|
||||
| **Animations** | Sutis funcionais | Linear-like — transição estado 150-250ms, easing ease-out, micro-feedback. **Nunca** decorativas/looping |
|
||||
| **Parallax** | None | Gimmick em B2B; quebra densidade |
|
||||
| **Hover effects** | Sutil | Background change, opacity, underline; **nunca** transform 3D ou scale grande |
|
||||
| **Loading** | Skeleton screens (não spinner global) | Shimmer suave, max 1-1.5s |
|
||||
| **Real-time updates** | Micro-animação suave entre cockpits | Slide-in 200ms, fade-in para itens novos. **Sem** toast intrusivo |
|
||||
| **Transitions de página** | Mínimas — fade rápido 150ms ou nenhuma | TanStack Router preserva contexto |
|
||||
| **Focus rings** | Visíveis e acessíveis (WCAG AA) | Keyboard nav clara |
|
||||
| **Reduced motion** | Respeitar `prefers-reduced-motion` | Acessibilidade obrigatória |
|
||||
|
||||
---
|
||||
|
||||
### ⚡ Performance targets
|
||||
|
||||
| Métrica | Target | Como |
|
||||
|---|---|---|
|
||||
| Lighthouse mobile | > 90 Performance/Acessibilidade/Best Practices | Padrão técnico |
|
||||
| TTI Rafael 3G | < 3s | Code-split por cockpit · lazy images |
|
||||
| First Contentful Paint | < 1.5s | SSG no marketing · SPA cache no produto |
|
||||
| Bundle inicial por entry | < 200KB gzipped | Vite tree-shaking · AntD modular imports |
|
||||
| Animações | Sempre `transform`/`opacity` | GPU-friendly |
|
||||
| Imagens | WebP/AVIF + `srcset` + lazy load | sharp (STACK §14) |
|
||||
| Code-split por cockpit | Sim — Rafael não baixa código da Sandra | Lazy routes TanStack Router |
|
||||
| Service Worker | Crítico para Rafael offline | PWA shell + IndexedDB |
|
||||
| Vídeo hero | Play on click, sem autoplay | Economiza dados |
|
||||
|
||||
---
|
||||
|
||||
## Imagery
|
||||
|
||||
> **Estratégia canônica:** MVP usa **screenshots do produto + ilustrações minimíssimas**, **sem stock humano**. Apple-style produto-primário. Fotos reais entram quando houver clientes/cases.
|
||||
|
||||
### Photography style
|
||||
|
||||
| Estilo | Status | Onde |
|
||||
|---|---|---|
|
||||
| **Authentic/Documentary** | Habilitado pós-MVP | Cases reais (donos JCS clients), /sobre eventual com time JCS |
|
||||
| **Product-focused** | ✅ MVP primário | Screenshots reais do SAR (com dados anonimizados) — hero, /funcionalidades, /para-setor |
|
||||
| **Lifestyle** | 🟡 Com moderação, pós-MVP | Rep no carro, supervisor no notebook — sem "happy team smiling" |
|
||||
| **Polished/staged** | ❌ Nunca | Estética que satura o setor |
|
||||
|
||||
### Anti-padrões absolutos
|
||||
- ❌ Executive shaking hands in suit
|
||||
- ❌ Diverse team smiling around laptop in modern office
|
||||
- ❌ Hand pointing at futuristic UI hologram
|
||||
- ❌ Gráficos 3D flutuando ao redor de pessoas
|
||||
- ❌ Senhor de meia-idade preocupado olhando planilha
|
||||
- ❌ Cidade ao fundo com gráfico de barras sobreposto
|
||||
|
||||
### MVP imagery plan
|
||||
|
||||
| Local | MVP | Pós-MVP / Y1+ |
|
||||
|---|---|---|
|
||||
| **Hero da home** | Screenshot premium do cockpit em ação | Mesmo (não trocar) |
|
||||
| **`/cases`** | Sem cases inicialmente; quando houver, fotos reais com permissão | Crescente |
|
||||
| **`/sobre`** | Apenas texto + logo JCS + valores | Foto do time JCS quando tiver |
|
||||
| **`/para-<setor>`** | Screenshots contextuais + iconografia funcional | Possível foto-ambiente do setor |
|
||||
| **Blog hero** | Ilustrações minimalistas (line art) + screenshots | Crescente |
|
||||
| **Lead magnets** | Mockup screenshot | — |
|
||||
|
||||
### Por que screenshots-only funciona (precedente Apple)
|
||||
|
||||
- Apple.com hoje: praticamente **zero foto humana** — produto, produto, produto
|
||||
- Diferencial declarado é o SAR (4 cockpits, IA, WhatsApp) — **mostrá-lo é o argumento**
|
||||
- Mercado B2B BR satura "team photos genéricos" — sair disso é diferenciação
|
||||
- Solo founder mode economiza grana de photoshoot
|
||||
- Reforça positioning "moderno em mercado medíocre"
|
||||
|
||||
### Icons
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Biblioteca** | Font Awesome 6.4 (brand.md canon) — subset only |
|
||||
| **Estilo** | **Regular/Outline** padrão; **Solid** apenas em estados (selected, success, alerta) |
|
||||
| **Tamanho** | Sistema 16/20/24px alinhado com tipografia |
|
||||
| **Cor** | Inherit do texto; accent JCS Blue só em ações primárias |
|
||||
| **Signature visual** | Ícone SAR (gráfico crescente em quadrado JCS Blue) reusado em pontos-chave |
|
||||
|
||||
### Illustrations
|
||||
|
||||
**Recomendação canônica:** Quase nenhuma no MVP. Apple-inspired clean prefere ausência a "ilustração funcional".
|
||||
|
||||
| Onde | Direção |
|
||||
|---|---|
|
||||
| Empty states sofisticados (poucos) | Line art minimalista monocromática JCS Blue — ou nenhuma (só ícone + texto) |
|
||||
| Páginas de erro 404/500 | Line art minimalista, 1 elemento + frase direta |
|
||||
| Hero de cockpit no marketing | **Screenshot, não ilustração** |
|
||||
| Onboarding | **Tooltips, não ilustração** |
|
||||
| /sobre, /parceiros | Apenas texto + logos, sem ilustração |
|
||||
|
||||
**EVITAR:** isométrico hipster · gradiente saturado · gente cartunesca · "diversity blob people" (Slack/Mailchimp style)
|
||||
|
||||
### Image guidelines técnicas
|
||||
|
||||
| Item | Padrão |
|
||||
|---|---|
|
||||
| **Aspect ratios** | 16:9 (hero/landscape) · 4:3 (cards) · 1:1 (avatars/logos) |
|
||||
| **Color treatment** | Levemente desaturado, alto contraste, temperatura fria |
|
||||
| **Alt text** | Obrigatório, descritivo (WCAG AA) |
|
||||
| **Compressão** | WebP/AVIF + JPG fallback, qualidade 80-85 |
|
||||
| **Lazy load** | Default em tudo abaixo do fold |
|
||||
| **Dimensões** | `srcset` responsivo (1x/2x/3x para DPI variável) |
|
||||
| **CDN** | Cloudflare (STACK §18) |
|
||||
| **Otimização** | Pipeline com sharp (STACK §14) |
|
||||
|
||||
---
|
||||
|
||||
## Design Constraints (compilados)
|
||||
|
||||
| Categoria | Constraint |
|
||||
|---|---|
|
||||
| **Plataforma** | Web SaaS (React 19.2 + Vite + AntD 6.4) — Step 10a |
|
||||
| **Device target** | PWA mobile-first iOS (Rafael) · Desktop-first (Sandra/Daniel/Alice) · iPad first-class (Daniel) |
|
||||
| **Offline** | Rafael Read+Write com sync (afeta UI signaling: enviando/enviado/falha sync) |
|
||||
| **Performance** | Lighthouse mobile > 90 · TTI 3G < 3s · FCP < 1.5s · bundle < 200KB gzipped |
|
||||
| **Acessibilidade** | WCAG AA mínimo · focus rings visíveis · `prefers-reduced-motion` respeitado |
|
||||
| **Idioma** | pt-BR only no MVP · i18n-ready arquitetural |
|
||||
| **Brand** | JCS Blue único accent · Plus Jakarta única família · "Powered by JCS" presente · radius 12/20 · sombra única `0 4px 25px rgba(0,0,0,0.05)` |
|
||||
| **LGPD/segurança** | Self-host fonts (não Google Fonts CDN) · sem trackers third-party invasivos · cookies essenciais only por padrão |
|
||||
| **Coexistência** | App Android legado intocado no MVP · SAR PWA + backend SAR são greenfield |
|
||||
| **Solo founder** | Custo de design baixo — nenhum photoshoot no MVP · screenshots como protagonista |
|
||||
|
||||
---
|
||||
|
||||
## Visual DNA Summary
|
||||
|
||||
```
|
||||
─────────────────────────────────────────────────────────
|
||||
SAR — Visual DNA
|
||||
─────────────────────────────────────────────────────────
|
||||
|
||||
Style: Modern Flat + Minimal
|
||||
(Apple iCloud · Linear · Stripe · Notion family)
|
||||
|
||||
Aesthetic: Minimalism contemporâneo / Digital-native modern
|
||||
|
||||
Colors: Monochromatic JCS Blue (#004a99) + functional accents
|
||||
Cool, light primary + dark mode elegante
|
||||
Distribuição 60% neutros · 30% white space · 10% accents
|
||||
|
||||
Typography: Plus Jakarta Sans (Geometric Humanist)
|
||||
Hierarquia por peso/tamanho · tabular numerals
|
||||
Confident · decisivo · moderno
|
||||
|
||||
Mood: Clean · Confident · Specific · Serene · Modern
|
||||
"Como um consultor sênior que apareceu na sua empresa
|
||||
e abriu o notebook."
|
||||
|
||||
Layout: Site: split hero, layouts variados por tipo de página
|
||||
Produto: cards Rafael · Linear-dense Sandra ·
|
||||
bento Daniel · table-first Alice
|
||||
|
||||
Effects: Sombra única sutil (brand.md) · animações funcionais 150-250ms
|
||||
SEM parallax · SEM transformações 3D · SEM toast intrusivo
|
||||
Real-time entre cockpits com micro-animação
|
||||
|
||||
Imagery: Screenshots do produto > tudo (Apple-style)
|
||||
Sem stock humano · ilustrações minimíssimas
|
||||
FA 6.4 outline + ícone SAR como signature visual
|
||||
|
||||
Key Element: 4 cockpits especializados sobre dado único em tempo real —
|
||||
o "ícone do gráfico crescente" da logo SAR como símbolo
|
||||
dessa essência.
|
||||
|
||||
─────────────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validação de completeness
|
||||
|
||||
| Seção | Status |
|
||||
|---|---|
|
||||
| ✅ Existing Brand Assets | Step 21 |
|
||||
| ✅ Visual References (positivas + negativas + mood) | Steps 19, 22 |
|
||||
| ✅ Design Style (UI + Aesthetic) | Step 23 |
|
||||
| ✅ Color Direction | Step 23 |
|
||||
| ✅ Typography Direction | Step 23 |
|
||||
| ✅ Layout Direction (site + 4 cockpits) | Step 24 |
|
||||
| ✅ Visual Effects | Step 24 |
|
||||
| ✅ Photography & Imagery | Step 25 |
|
||||
| ✅ Performance constraints | Step 24 |
|
||||
| ✅ Design Constraints (compilados) | Step 26 |
|
||||
| ✅ Visual DNA Summary | Step 26 |
|
||||
|
||||
---
|
||||
|
||||
## Como esse documento é consumido
|
||||
|
||||
| Fase | Como usa este doc |
|
||||
|---|---|
|
||||
| **Phase 3 (PRD)** | Referência para decisões de produto que tocam UI (ex: PWA strategy, dark mode) |
|
||||
| **Phase 4 (UX Specs)** | **Source of truth visual** — toda page spec referencia layout/effects/imagery |
|
||||
| **Phase 5 (Agentic Dev)** | Tokens canônicos viram CSS variables; vocabulário e tom em microcopy |
|
||||
| **Phase 6 (Design System)** | Expande tokens em componentes; mantém Visual DNA Summary como north star |
|
||||
| **Phase 7 (Go Live)** | Site marketing usa diretamente layout/effects/imagery decisions |
|
||||
|
||||
---
|
||||
|
||||
## Próximos passos
|
||||
|
||||
1. **Phase 4 (UX Specs):** Cada cockpit (Rafael/Sandra/Daniel/Alice) ganha pages individuais que **citam este doc**
|
||||
2. **Phase 6 (Design System):** Tokens compartilhados + variantes por cockpit
|
||||
3. **Marketing site:** seguir layout direction + imagery strategy
|
||||
|
||||
Visual Direction COMPLETO. Ready for Block D (Platform Requirements — fast-track via STACK.md).
|
||||
347
design-artifacts/A-Product-Brief/04-platform-requirements.md
Normal file
347
design-artifacts/A-Product-Brief/04-platform-requirements.md
Normal file
@@ -0,0 +1,347 @@
|
||||
# Platform Requirements: SAR — Força de Vendas
|
||||
|
||||
**Status:** ✅ Block D COMPLETO (Steps 27-32) — fast-track via STACK.md v2.2
|
||||
**Cliente:** JCS Sistemas
|
||||
**Última atualização:** 2026-05-27
|
||||
|
||||
> Este documento é um **espelho consolidado** de decisões já feitas em `STACK.md v2.2`, `CODING-RULES.md v2.0`, ADRs 0001-0006, e Step 10a (Platform Strategy). Não duplica conteúdo — referencia. **STACK.md continua sendo source of truth para qualquer decisão técnica.**
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder técnico
|
||||
|
||||
| Item | Valor |
|
||||
|---|---|
|
||||
| **Tech Lead** | Julian (acumulado com PO + Champion — solo founder mode até 1º cliente) |
|
||||
| **Nível técnico do PO** | Muito técnico (autor de STACK.md + CODING-RULES.md) |
|
||||
| **Time de desenvolvimento MVP** | Apenas Julian até 1º cliente; +1-2 devs depois |
|
||||
| **Cultura técnica JCS** | Tech maturity alta — 11-50 pessoas, anos de software profissional |
|
||||
|
||||
---
|
||||
|
||||
## Decisões já feitas (referência cruzada)
|
||||
|
||||
| Decisão | Onde está consolidada |
|
||||
|---|---|
|
||||
| **Stack canônica completa** | `STACK.md v2.2` (FONTE DA VERDADE) |
|
||||
| **Invariantes de código e pegadinhas críticas** | `CODING-RULES.md v2.0` |
|
||||
| **Multi-tenancy BD-por-workspace** | ADR 0006 (substituiu row-level tenantId) |
|
||||
| **master-login como IdP** | ADR 0005 (substituiu Keycloak) |
|
||||
| **Migração AWS sa-east-1 → Proxmox on-prem BR** | ADR 0004 |
|
||||
| **SLO defaults por endpoint/job/fluxo** | ADR 0001 |
|
||||
| **Tags Nx canônicas (scope / type / domain)** | ADR 0002 |
|
||||
| **PWA mobile-first iOS para Rafael** | Step 10a |
|
||||
| **Desktop-first para Sandra/Daniel/Alice** | Step 10a + brand.md |
|
||||
| **iPad first-class para Daniel** | Step 10a |
|
||||
| **Offline read+write com sync (Rafael)** | Step 10a |
|
||||
| **Coexistência com app Android legado** | Step 10a |
|
||||
| **Sem app store no MVP** | Step 10a + STACK.md §18 |
|
||||
| **pt-BR only no MVP, i18n-ready** | Step 16 |
|
||||
| **LGPD by design** | STACK.md §22 + CODING-RULES.md |
|
||||
| **brand.md** | identidade visual canônica |
|
||||
| **`03-visual-direction.md`** | direção visual completa |
|
||||
|
||||
---
|
||||
|
||||
## Tech Stack (Step 28 — espelho consolidado de STACK.md v2.2)
|
||||
|
||||
### Camadas principais
|
||||
|
||||
| Camada | Decisão canônica |
|
||||
|---|---|
|
||||
| **Runtime** | Node 24 LTS · pnpm 11.1 · TypeScript 5.9 |
|
||||
| **Monorepo** | Nx 22.7 (`apps/api` + `apps/api-worker` + `apps/web` + `apps/web-e2e` + `libs/`) com 3 tags canônicas (scope / type / domain) — ADR 0002 |
|
||||
| **Backend** | NestJS 11.1 (Express 5) · Prisma 7 · PostgreSQL 18 · `nestjs-cls` · `@nestjs/terminus` · `@nestjs/throttler` + Valkey storage |
|
||||
| **Frontend** | React 19.2 + Compiler · Vite 8 (Rolldown) · Ant Design 6.4 · TanStack Query 5.100 · TanStack Router · Zustand 5 |
|
||||
| **API** | REST + OpenAPI 3.1 + RFC 9457 Problem Details · Zod 4 (pnpm catalog) + nestjs-zod + react-hook-form (`zodResolver`) |
|
||||
| **Auth** | Guards NestJS + `jose` + **master-login** (IdP OAuth2/OIDC próprio em VM Proxmox; HS256→RS256 roadmap) · argon2id no IdP — ADR 0005 |
|
||||
| **Multi-tenancy** | **BD-por-workspace** — cluster Postgres dedicado por cliente, resolvido via `get_workspace_connection` no master-login. Sem coluna `tenantId` em modelos — isolamento físico — ADR 0006 |
|
||||
| **Secrets** | HashiCorp Vault (KV v2) self-host · Vault Agent injeta env vars no entrypoint do container |
|
||||
| **Observabilidade** | Pino + nestjs-pino 10.3 · OpenTelemetry (Traces/Metrics GA, Logs Beta) · Grafana Cloud LGTM · Sentry |
|
||||
| **Feature flags** | OpenFeature SDK + GrowthBook self-host |
|
||||
| **Filas** | BullMQ 5.77 + `@nestjs/bullmq` 11 · Bull Board · Valkey em VM/LXC Proxmox |
|
||||
| **Cache** | `@nestjs/cache-manager` v3 + cache-manager 6 + `@keyv/redis` + `cacheable` (L1) |
|
||||
| **Real-time** | Socket.IO 4 + `@socket.io/redis-adapter` (Valkey) · SSE via `@Sse()` nativo NestJS |
|
||||
| **Uploads** | MinIO (S3-compat) presigned POST policy · AWS SDK v3 · Uppy + `@uppy/aws-s3` · ClamAV worker BullMQ · sharp 0.34 |
|
||||
| **Email** | Resend (SaaS — únicas exceções SaaS são email e CDN por questão de deliverability/borda) + React Email via BullMQ |
|
||||
| **Testes** | Vitest 4.1 · Testcontainers 12 · Supertest 7.2.2 (encapsulado) · Playwright 1.60 |
|
||||
| **Qualidade** | ESLint 10.4 flat · typescript-eslint 8.59 · Prettier 3.8.3 · eslint-plugin-importx 4.16.2 · Husky 9 + lint-staged 17 · gitleaks |
|
||||
| **CI/Deploy** | GitHub Actions + Nx Cloud · Trivy gate · pin actions por SHA · Docker multi-stage `node:24-alpine` · **Ansible/SSH para VMs Proxmox** com docker-compose rolling (backend) · **Cloudflare + Nginx** servindo SPA estática (frontend) |
|
||||
| **Infraestrutura** | **Proxmox on-prem BR** — substitui AWS sa-east-1 — ADR 0004. Self-host Postgres, Valkey, MinIO, master-login, Vault, GrowthBook, PostHog (novo) |
|
||||
|
||||
### Decisões frontend específicas do SAR (decorrentes de Block C)
|
||||
|
||||
- **PWA mobile-first iOS** para Rafael — Service Worker + Web Push + manifest + offline read+write
|
||||
- **Desktop SPA** para Sandra/Daniel/Alice (mesmo bundle React, layouts diferentes)
|
||||
- **iPad first-class** para Daniel (testes regulares em iPad Safari)
|
||||
- **Code-splitting por cockpit** (TanStack Router lazy routes)
|
||||
- **Service Worker** crítico para Rafael offline (IndexedDB queue + sync)
|
||||
- **Plus Jakarta Sans self-host** (não Google Fonts CDN — LGPD + performance)
|
||||
- **Dark mode** elegante (especialmente Rafael à noite)
|
||||
- **Build target**: ES2023 (`noUncheckedIndexedAccess` ON, NodeNext module resolution)
|
||||
|
||||
### Rationale (curto)
|
||||
|
||||
A stack JCS v2.2 foi calibrada para:
|
||||
- **LGPD by design** (datacenter BR, isolamento físico multi-tenant, redact em logs)
|
||||
- **Velocidade de desenvolvimento** (Node/Nest/Prisma stack TypeScript end-to-end)
|
||||
- **Custo operacional baixo** (self-host Proxmox para tudo que não é deliverability/edge)
|
||||
- **Velocidade de iteração** (Nx affected, code-splitting, hot reload Vite Rolldown)
|
||||
- **Solo founder mode** (toolchain conhecido pelo PO, sem learning curve)
|
||||
|
||||
Para alterar qualquer decisão fora desta tabela: RFC em `docs/adr/NNN-titulo.md`.
|
||||
|
||||
---
|
||||
|
||||
## Integrations (Step 29)
|
||||
|
||||
### Decisões fechadas
|
||||
|
||||
| Integração | Provider escolhido | Por quê | Notas |
|
||||
|---|---|---|---|
|
||||
| **Pagamento** | **Iugu** | BR-focused, assinaturas recorrentes nativas, boleto/PIX/cartão suportados, ticket B2B BR padrão | Webhook handler via NestJS controller + BullMQ para retries. Receita reconhecida no momento do `paid` event. |
|
||||
| **WhatsApp Business** | **Oficial Meta (WhatsApp Cloud API)** | Sem intermediário, templates aprovados direto pela Meta, mais seguro a longo prazo | Setup mais burocrático (verificação Business + templates approval). Custo por mensagem. Templates centralizados em `libs/shared/whatsapp-templates`. |
|
||||
| **Analytics de produto** | **PostHog self-host** (Proxmox) | Self-host alinha STACK.md (BR + LGPD). Cobre product analytics, session replay, feature flags. | Roda em VM/LXC Proxmox separada. Eventos via SDK no frontend. Dashboards customizados por cockpit. |
|
||||
| **Email transacional** | **Resend** (já em STACK.md §15) | Já decidido | React Email para templates · BullMQ jobs · DPA assinado |
|
||||
| **Identidade (IdP)** | **master-login** (próprio, JCS) — ADR 0005 | Já decidido | OAuth2/OIDC, argon2id |
|
||||
| **Secrets** | **HashiCorp Vault** self-host | Já decidido | KV v2, Vault Agent no container |
|
||||
| **Object storage** | **MinIO** self-host | Já decidido | S3-compat, presigned POST policy, ClamAV worker |
|
||||
| **CDN edge** | **Cloudflare** | Já decidido em STACK.md §18 | DNS, edge cache, DDoS, certificados |
|
||||
| **Logging** | **Grafana Cloud LGTM + Sentry** | Já decidido | OTel + Pino + Sentry |
|
||||
| **Geolocation (GPS check-in)** | Browser `navigator.geolocation` nativo | Sem provider externo | Web API padrão |
|
||||
|
||||
### ⚠️ Decisão aberta: IA generativa
|
||||
|
||||
Julian quer estudar todas as opções antes de cravar. **Recomendação canônica: abstração multi-provider desde dia 1.**
|
||||
|
||||
**Arquitetura proposta:**
|
||||
- **Camada de abstração:** **Vercel AI SDK** (`ai` package) ou **LiteLLM proxy** (Node SDK)
|
||||
- Cliente NestJS chama interface única; troca de provider é configuração
|
||||
- Providers candidatos a A/B (com critérios de avaliação):
|
||||
|
||||
| Provider | Pros | Cons | Score qualitativo |
|
||||
|---|---|---|---|
|
||||
| **Anthropic (Claude)** | Excelente em raciocínio analítico + pt-BR · JSON estruturado nativo · explicabilidade forte (alinha SAR) | Custo médio · ecossistema menor que OpenAI | ⭐⭐⭐⭐⭐ alinhamento com diferencial |
|
||||
| **OpenAI (GPT)** | Ecossistema maior · mais SDKs/tools · function calling maduro | Drift de qualidade entre versões · custo competitivo | ⭐⭐⭐⭐ |
|
||||
| **Local/Ollama** | Sem custo recorrente · máximo controle/privacidade | Qualidade inferior · custo de infra Proxmox · velocidade variável | ⭐⭐ para MVP, ⭐⭐⭐⭐ se LGPD for ultra-rigoroso |
|
||||
| **Multi-provider (LiteLLM)** | Hedge total · pode usar local para tarefas simples + cloud para complexas | Complexidade de manutenção | ⭐⭐⭐⭐⭐ estratégico |
|
||||
|
||||
**Princípio:** estrutura o código para ser **provider-agnostic**. PR de IA não tem `import OpenAI from 'openai'` — usa interface JCS.
|
||||
|
||||
**Marco de decisão:** quando 1º cliente fechar e Julian tiver tempo de benchmark dedicado. Até lá, padrão temporário = **Anthropic Claude Sonnet/Opus** via SDK direto, mas isolado atrás de interface.
|
||||
|
||||
### Categorias de integração futura (mapa, sem decisão MVP)
|
||||
|
||||
| Categoria | Quando decidir | Candidatos |
|
||||
|---|---|---|
|
||||
| **CRM próprio JCS** (vender SAR com SAR — dogfood) | Y1 | O próprio SAR adaptado |
|
||||
| **Assinatura digital de contratos** | Y1 | DocuSign · ClickSign (BR) · D4Sign (BR) |
|
||||
| **NFe / NFSe (cobrança JCS para clientes)** | Y1 quando volume justifica | NFe.io · Bling · Iugu pode embutir |
|
||||
| **CDP / nurturing de leads** | Y1+ | PostHog cobre boa parte; eventualmente HubSpot/RD Station |
|
||||
| **Helpdesk / suporte ao cliente** | Pós-MVP | Crisp · Zendesk · self-host Cal.com + email |
|
||||
| **Status page pública** | Pós-MVP | Statuspage.io · Instatus · self-host Cachet |
|
||||
|
||||
### Account ownership (quem cria/gerencia)
|
||||
|
||||
| Integração | Conta de quem | Notas |
|
||||
|---|---|---|
|
||||
| Iugu, Resend, Anthropic/OpenAI, Cloudflare, Meta WhatsApp | **JCS Sistemas** | Único proprietário; cobrança vai pra JCS |
|
||||
| MinIO, master-login, Vault, GrowthBook, PostHog | **JCS Sistemas self-host** | Roda em VMs Proxmox JCS |
|
||||
| Google Business Profile (JCS) | JCS Sistemas | Reivindicar e manter |
|
||||
|
||||
---
|
||||
|
||||
## Contact Strategy (Step 30)
|
||||
|
||||
### Primary contact method
|
||||
|
||||
**Form de demo** (`/contato` no site marketing) — alinha com sales-led motion (Step 5).
|
||||
|
||||
| Campo | Obrigatório | Por quê |
|
||||
|---|---|---|
|
||||
| Nome | Sim | Personalização do follow-up |
|
||||
| Email corporativo | Sim | Canal principal · validador de "B2B real" |
|
||||
| Telefone (com DDD) | Sim | Permite ligação direta · WhatsApp follow-up |
|
||||
| Empresa | Sim | Qualificação inicial |
|
||||
| Cargo / função | Sim | Identifica se é dono/diretor (decisor) ou supervisor (influenciador) |
|
||||
| Quantos representantes externos | Sim | Qualificação principal (sweet spot 5-50) |
|
||||
| ERP atual | Sim | Identifica origem do lead (Grupo 2 da concorrência) |
|
||||
| Cidade/UF | Sim | Roteamento regional eventual |
|
||||
| Como nos conheceu | Opcional | Atribuição de canal (indicação? Google? feira? parceiro?) |
|
||||
| Mensagem | Opcional | Captura intent custom |
|
||||
|
||||
### Channels (canais de contato disponíveis)
|
||||
|
||||
| Canal | Quando aparece | Quem responde |
|
||||
|---|---|---|
|
||||
| **Form de demo** (CTA principal) | Em toda página + header sticky | SDR JCS (Julian no início) |
|
||||
| **Email** (`contato@sarjcs.com.br` ou similar) | Footer | SDR |
|
||||
| **Telefone JCS** | Footer + página `/contato` | SDR (horário comercial BR) |
|
||||
| **WhatsApp JCS Business** | Footer + página `/contato` (clica e abre app) | SDR |
|
||||
| **Página `/parceiros`** | Captura indicações de canal | Account manager (Julian no início) |
|
||||
| **Chat ao vivo** | ❌ NÃO no MVP | Volta como decisão pós-MVP |
|
||||
|
||||
### Form requirements técnicos
|
||||
|
||||
- Anti-spam: **hCaptcha** ou **Cloudflare Turnstile** (não Google reCAPTCHA — LGPD)
|
||||
- Validação client-side: Zod schema compartilhado com o backend
|
||||
- Submit → cria lead no CRM JCS · dispara notificação Slack/email para SDR · responde "Recebemos seu contato — Julian responde em até 4h úteis"
|
||||
- Rate limit: 5 submissions/email/h · 10/IP/h via `@nestjs/throttler`
|
||||
- LGPD: checkbox de consentimento explícito + link para política de privacidade
|
||||
- Idempotency: `Idempotency-Key` header (Zod + nestjs-zod já cobrem)
|
||||
|
||||
### AI opportunity em contato
|
||||
|
||||
**Pós-MVP:** chatbot pré-qualificador do lead na própria página de contato. Usa o stack de IA generativa (a definir) para responder dúvidas básicas e qualificar antes do SDR atender. **Não no MVP** — solo founder não vai operar isso bem.
|
||||
|
||||
### UX implications
|
||||
|
||||
- Form aparece em modal/drawer ao clicar "Agende demo" (não navegação a `/contato`)
|
||||
- Após submit, mensagem clara + próximos passos ("Julian envia uma proposta em até 24h úteis")
|
||||
- Email automático imediato confirmando recebimento (Resend + React Email)
|
||||
- Lead score automático no CRM (tamanho da equipe + cargo)
|
||||
|
||||
---
|
||||
|
||||
## Multilingual & SEO (Step 31)
|
||||
|
||||
### Multilingual (já decidido em Step 16)
|
||||
|
||||
- **pt-BR only no MVP** · arquitetura i18n-ready (todas strings em `pt-BR.json`)
|
||||
- **en** preparado no código, sem tradução
|
||||
- **es (LatAm)** fora de escopo (requer adaptação fiscal por país)
|
||||
|
||||
### URL structure técnica
|
||||
|
||||
- Domínio: **`sarjcs.com.br`** (proposta — verificar disponibilidade)
|
||||
- pt-BR (default): `<dominio>/<slug>`
|
||||
- en futuro: `<dominio>/en/<slug>`
|
||||
- App produto: `app.sarjcs.com.br/` ou `<dominio>/app/` (decidir em PRD)
|
||||
- Slug: lowercase, hífen, ASCII, sem stopwords desnecessárias
|
||||
|
||||
### Translation workflow (futuro)
|
||||
|
||||
- Strings vivem em `libs/shared/i18n/locales/pt-BR.json` (single source)
|
||||
- Tradução `en.json` quando ativar: copy mantido fiel ao tom "consultor sênior" + variantes culturais aplicáveis
|
||||
- Sincronização via diff de chaves: CI quebra build se chave faltar em algum locale ativo
|
||||
|
||||
### Technical SEO requirements (espelha Step 17)
|
||||
|
||||
| Item | Implementação |
|
||||
|---|---|
|
||||
| **Meta tags dinâmicas** | Vite + React Helmet por rota |
|
||||
| **Sitemap.xml** | Gerado por script no build · submit Google Search Console |
|
||||
| **robots.txt** | Permitir crawling em marketing; **noindex em `/app/`** (produto privado) |
|
||||
| **Structured data (JSON-LD)** | `Organization` (JCS) · `SoftwareApplication` (SAR home) · `Product`+`Offer` (preços) · `Article` (blog/cases) · `FAQPage` · `BreadcrumbList` |
|
||||
| **Open Graph + Twitter Cards** | Por rota, com imagem dedicada (screenshot do produto) |
|
||||
| **hreflang tags** | Não no MVP (single language); preparado quando i18n ativar |
|
||||
| **Canonical URLs** | Em toda página, mesmo o domínio principal |
|
||||
| **404 customizada** | Line art mono JCS Blue + "Voltar pra home" |
|
||||
| **Core Web Vitals** | Lighthouse > 90 · LCP < 2.5s · CLS < 0.1 · INP < 200ms |
|
||||
| **Schema.org test** | Validação no Google Rich Results Test antes de cada deploy |
|
||||
|
||||
### Performance budgets (espelha Step 24)
|
||||
|
||||
| Métrica | Target | Bloqueio |
|
||||
|---|---|---|
|
||||
| Lighthouse Performance (mobile) | ≥ 90 | CI quebra se < 85 |
|
||||
| FCP | < 1.5s | — |
|
||||
| LCP | < 2.5s | CI alerta se > 3s |
|
||||
| CLS | < 0.1 | — |
|
||||
| INP | < 200ms | — |
|
||||
| Bundle inicial por entry | < 200KB gzipped | CI alerta se > 250KB |
|
||||
| TTI Rafael 3G (PWA) | < 3s | Validação manual em dispositivo |
|
||||
|
||||
---
|
||||
|
||||
## Maintenance Ownership
|
||||
|
||||
### MVP (solo founder mode)
|
||||
|
||||
| Categoria | Owner | Frequência |
|
||||
|---|---|---|
|
||||
| Stack updates (npm deps, ADRs, RFC) | **Julian** | Trimestral (alinhar com STACK.md cadence) |
|
||||
| Deploys (backend + frontend) | **Julian** via Ansible/SSH | A cada PR mergeado |
|
||||
| Infraestrutura Proxmox (VMs, snapshots, backup) | **Julian** | Manutenção mensal, backup diário automatizado |
|
||||
| Vault rotation, master-login chaves | **Julian** | Trimestral / on-incident |
|
||||
| Monitoramento Grafana + Sentry | **Julian** | On-call 24/7 (PME pequena) |
|
||||
| Integrações (Iugu, Resend, Meta WhatsApp, Cloudflare) | **Julian** | On-issue |
|
||||
| LGPD ANPD / DPO | **Julian** (com possível advogado externo) | On-request |
|
||||
| Atualização de templates WhatsApp Meta | **Julian** + revisor de tom | On-mudança |
|
||||
|
||||
### Pós-MVP (Y1+)
|
||||
|
||||
| Categoria | Owner futuro |
|
||||
|---|---|
|
||||
| Infraestrutura | DevOps/SRE dedicado |
|
||||
| Backend dev | Time JCS (1-2 devs) |
|
||||
| Frontend dev | Time JCS (1-2 devs) |
|
||||
| QA | QA dedicado ou compartilhado com dev |
|
||||
| LGPD / Compliance | DPO formal (Julian acumula, depois separa) |
|
||||
|
||||
---
|
||||
|
||||
## Risk register
|
||||
|
||||
| Risco | Probabilidade | Impacto | Mitigação |
|
||||
|---|---|---|---|
|
||||
| Meta muda regras WhatsApp Business | Média | Alto | Arquitetura plug-in · alternativa Telegram/SMS no roadmap (Step 9, 10) |
|
||||
| Anthropic/OpenAI muda pricing ou política | Média | Alto | Abstração multi-provider (LiteLLM/AI SDK) · capacidade de trocar provider · sempre considerar local fallback |
|
||||
| Iugu instabilidade | Baixa | Alto | Multi-provider de pagamento (preparar arquitetura para alternar Pagar.me como backup) |
|
||||
| Cloudflare CDN issue | Baixa | Médio | Migrar para AWS CloudFront / Bunny CDN possível em <1 dia |
|
||||
| Proxmox failure | Baixa | Crítico | Backup snapshot diário · Plano B: re-provisionamento em outra infra (custo de RTO ~4-8h) |
|
||||
| Solo founder ausência prolongada | Média | Crítico | Documentação extensiva em CODING-RULES.md · todos os secrets em Vault recuperável · contratar 1 dev assim que possível |
|
||||
|
||||
---
|
||||
|
||||
## Final synthesis
|
||||
|
||||
### Visão executiva
|
||||
|
||||
O SAR roda na stack canônica **JCS v2.2** sem desvios. Decisões de plataforma específicas do produto vivem em **Step 10a (Platform Strategy)** e neste documento. **STACK.md é a fonte da verdade** para qualquer questão técnica não específica do SAR.
|
||||
|
||||
### Tabela síntese (entrar no Brief executivo)
|
||||
|
||||
```
|
||||
─────────────────────────────────────────────────────────
|
||||
SAR — Platform Requirements Summary
|
||||
─────────────────────────────────────────────────────────
|
||||
|
||||
Stack: Node 24 · NestJS 11 · Prisma 7 · PG 18 · React 19 + Vite 8
|
||||
+ AntD 6.4 · Zod 4 · BullMQ 5.77 · Socket.IO 4 · TanStack
|
||||
Query/Router · Zustand
|
||||
Multi-tenant: BD-por-workspace (cluster PG dedicado/cliente) — ADR 0006
|
||||
Auth: master-login (IdP próprio) — ADR 0005
|
||||
Infra: Proxmox on-prem BR — ADR 0004
|
||||
Distribução: PWA mobile-first iOS · Desktop-first · iPad first-class
|
||||
|
||||
Integrations:
|
||||
Pagamento: Iugu (boleto/PIX/cartão + assinaturas recorrentes)
|
||||
WhatsApp: Oficial Meta (Cloud API)
|
||||
IA: Decisão ABERTA — abstração multi-provider (LiteLLM/AI SDK)
|
||||
· default temporário: Anthropic Claude
|
||||
Analytics: PostHog self-host (Proxmox)
|
||||
Email: Resend (transacional)
|
||||
Storage: MinIO self-host
|
||||
Secrets: Vault self-host
|
||||
CDN: Cloudflare
|
||||
Observ.: Grafana LGTM + Sentry + OpenTelemetry
|
||||
|
||||
Contact: Form de demo (CTA único) · sem chat ao vivo no MVP
|
||||
Anti-spam: hCaptcha/Turnstile · Throttler 5/h por email
|
||||
|
||||
Lang: pt-BR only no MVP · i18n-ready · sem hreflang até ativar en
|
||||
SEO técnico: Lighthouse >90 mobile · JSON-LD · sitemap · noindex /app/
|
||||
|
||||
Maintenance: Julian (solo founder mode) até 1º cliente; depois +1-2 devs
|
||||
|
||||
─────────────────────────────────────────────────────────
|
||||
```
|
||||
|
||||
### Próximos passos
|
||||
|
||||
- **Phase 3 (PRD)**: detalhar requirements por feature consumindo este doc
|
||||
- **Phase 4 (UX Specs)**: cada cockpit referencia constraints de plataforma
|
||||
- **Phase 5 (Agentic Dev)**: scaffolding Nx + setup CI/CD via STACK.md
|
||||
|
||||
**Block D COMPLETO. Próximo: Block E — Wrap-up (Steps 33-36).**
|
||||
78
design-artifacts/A-Product-Brief/dialog/00-context.md
Normal file
78
design-artifacts/A-Product-Brief/dialog/00-context.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# Phase 1 — Dialog Context
|
||||
|
||||
**Project:** SAR — Força de Vendas
|
||||
**Owner:** Julian (Product Owner, JCS Sistemas)
|
||||
**Agent:** Saga (Business Analyst)
|
||||
**Started:** 2026-05-26
|
||||
**Brief level:** complete (36 steps)
|
||||
**Communication language:** pt-BR
|
||||
|
||||
---
|
||||
|
||||
## Working Relationship (de wds-project-outline.yaml)
|
||||
|
||||
- **Involvement:** balanceado
|
||||
- **Presentation:** recomendar com justificativa
|
||||
- **Stakes:** small-business (JCS Sistemas)
|
||||
- **Role:** Product Owner
|
||||
|
||||
---
|
||||
|
||||
## Materiais existentes (entrada Phase 1)
|
||||
|
||||
| Material | Path | Cobre |
|
||||
|---|---|---|
|
||||
| Brand identity | `brand.md` | Visual Direction quase completo + parte de tom |
|
||||
| Stack canon JCS | `STACK.md` v2.2 | Platform Requirements quase completo |
|
||||
| Coding rules | `CODING-RULES.md` v2.0 | Constraints técnicas (invariantes + pegadinhas) |
|
||||
| Logos | `frontend/img/SAR_logo_fundo_transparente.png`, `SAR_icone_fundo_transparente.png` | Assets |
|
||||
| **Mockup SPA legado** | `design-artifacts/_references/legacy-screens-html/index.html` | Estrutura funcional + 9 telas mockadas alinhadas à marca |
|
||||
|
||||
---
|
||||
|
||||
## Pré-análise do mockup legado (9 telas)
|
||||
|
||||
> Login excluído por decisão do PO (já será coberto pela stack: master-login + jose).
|
||||
|
||||
| Tela (id SPA) | Título | Função (inferida) |
|
||||
|---|---|---|
|
||||
| `indicadores` | Painel de Desempenho | Dashboard executivo: faturamento, ritmo, mix de produtos, status carteira, radar de inatividade |
|
||||
| `pedidos` | Meus Pedidos | Lista de pedidos com totais consolidados |
|
||||
| `funil` | Meu Funil de Vendas | Kanban CRM |
|
||||
| `agenda` | Agenda e Rotas | Calendário + Roteiro Otimizado |
|
||||
| `novo-pedido` | Lançamento de Pedido | Form: cliente + comercial + adicionais + total |
|
||||
| `analise-cliente` | Visão 360° do Cliente | Timeline integrada (ex.: OPENFRIOS) |
|
||||
| `clientes` | Lista de Clientes | — |
|
||||
| `cadastro-cliente` | Cadastro de Cliente | Dados principais + endereço + contatos |
|
||||
| `produtos` | Catálogo de Produtos | Detalhe + modal de produto |
|
||||
|
||||
### Observações da pré-análise
|
||||
|
||||
1. **"Painel de Desempenho" não estava em `brand.md`**. O brand.md lista 6 módulos (Vendas, Fiscal, Financeiro, Comissão/FLEX, CRM, Administrativo) e o mockup adiciona um 7º implícito (BI/Dashboard). A confirmar no brief: é módulo separado ou tela transversal a outros módulos?
|
||||
2. **CSS do mockup usa variáveis JCS** (`var(--jcs-blue)`, `var(--orange)`, etc.) — o legado já está alinhado à identidade.
|
||||
3. **Cliente 360° já está implementado** no mockup — confirma a visão de `brand.md`.
|
||||
|
||||
---
|
||||
|
||||
## Histórico do diálogo
|
||||
|
||||
### 2026-05-26 — Step 1 (Init)
|
||||
|
||||
- Saga apresentada como BA do projeto.
|
||||
- Escopo Phase 1 explicado (36 steps em 5 blocos: Brief / Content / Visual / Platform / Wrap-up).
|
||||
- Tempo previsto: 2-3h (ajuste sobre os 30-60 min default do workflow).
|
||||
- Estratégia acordada: **fast-track de Visual (via brand.md + mockup) e Platform (via STACK.md)**, foco em Product Brief (steps 1-12) e Content (steps 13-18) onde há mais lacunas.
|
||||
- Materiais adicionais: usuário disponibilizou mockup HTML do SAR (`index.html` SPA com 9 telas) — login não entra no escopo.
|
||||
- Ritmo escolhido: sessão longa contínua, até onde der.
|
||||
|
||||
---
|
||||
|
||||
## Progress Tracker
|
||||
|
||||
| Bloco | Steps | Status |
|
||||
|---|---|---|
|
||||
| A. Product Brief | 1-12 | Step 1 ✅ · Step 1a → próximo |
|
||||
| B. Content & Language | 13-18 | Pendente |
|
||||
| C. Visual Direction | 19-26 | Pendente (fast-track) |
|
||||
| D. Platform Requirements | 27-32 | Pendente (fast-track) |
|
||||
| E. Wrap-up | 33-36 | Pendente |
|
||||
114
design-artifacts/A-Product-Brief/dialog/business-customers.md
Normal file
114
design-artifacts/A-Product-Brief/dialog/business-customers.md
Normal file
@@ -0,0 +1,114 @@
|
||||
# Business Customers — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 06 — Business Customers
|
||||
|
||||
> Perfil da **empresa-cliente** (quem assina contrato e paga). Não confundir com **user personas** (quem usa diariamente — Step 7).
|
||||
|
||||
---
|
||||
|
||||
## Perfil da empresa-cliente
|
||||
|
||||
| Dimensão | Valor |
|
||||
|---|---|
|
||||
| **Porte** | PME 5-50 reps externos (sweet spot mid-SMB) |
|
||||
| **Setores** | Distribuidoras, indústrias, RCAs (representação terceirizada), PMEs com vendas externas |
|
||||
| **Geografia** | Brasil (foco regional/nacional) |
|
||||
| **Maturidade tech** | Variada — algumas com TI próprio, muitas sem |
|
||||
|
||||
---
|
||||
|
||||
## Estrutura de decisão
|
||||
|
||||
### Decisor final (assina o contrato)
|
||||
- **Dono / sócio-fundador** — PME pequena, decisão centralizada, fast-individual
|
||||
- **Diretor comercial / gerente de vendas** — PME média, delegação do dono que apenas referenda
|
||||
|
||||
### Influenciadores que matam o deal se rejeitarem
|
||||
- **Supervisor de vendas** — vai usar diariamente; se odiar a demo, dono não compra
|
||||
- **Representantes early users / champions internos** — quando um rep já conheceu SAR em outra empresa, vira advogado interno
|
||||
|
||||
### Ausentes (não pesam na decisão típica) ⚠️
|
||||
- ✗ Financeiro
|
||||
- ✗ TI interna
|
||||
- ✗ Jurídico
|
||||
|
||||
**Insight central:** SAR é venda **operacional-emocional**, não **técnica-financeira**.
|
||||
A demo precisa **brilhar para o supervisor**, não impressionar a TI ou justificar TCO no Excel.
|
||||
|
||||
---
|
||||
|
||||
## Buyer Persona — "O Dono Empresário B2B"
|
||||
|
||||
- **Idade típica:** 35-60 anos
|
||||
- **Perfil:** Sócio-fundador ou herdeiro de negócio familiar; conhece o setor profundamente; gerencia "no peito"
|
||||
- **Dor que paga:** Não consegue mais administrar pelo WhatsApp + planilha. Vê concorrente crescendo. Tem caixa para investir em ferramenta, mas não sabe qual.
|
||||
- **Critério de avaliação principal:** Fé que o produto vai funcionar — não TCO planilhado. Daí a importância de **demo concreta + boca-a-boca + cases**.
|
||||
- **O que o convence:**
|
||||
- Ver outro dono usando
|
||||
- Ver o supervisor empolgado na demo
|
||||
- Ouvir rep dizendo "muito melhor que o antigo"
|
||||
- **O que o assusta:**
|
||||
- "Meu pessoal não vai aprender"
|
||||
- "É mais um sistema que vai me dar trabalho"
|
||||
- "É caro pra valer?"
|
||||
|
||||
---
|
||||
|
||||
## Canais de aquisição (4 ativos)
|
||||
|
||||
| Canal | Esforço JCS | Velocidade | Custo | Implicação principal |
|
||||
|---|---|---|---|---|
|
||||
| **Indicação boca-a-boca** | Médio — programa de referral + cases | Lento de construir, rápido depois | Baixo (comissão referral) | Cases públicos + programa de indicação |
|
||||
| **Google / SEO + content** | Alto — blog, comparativos, calculadora ROI | 6-12 meses para crescer | Médio (time de conteúdo) | Blog + SEO técnico + landing pages por dor |
|
||||
| **Eventos / feiras** | Alto — estande, demos ao vivo, networking | Imediato no evento, follow-up demora | Alto (estandes APAS/Fispal) | Calendário de feiras + kit de evento + CRM para follow-up |
|
||||
| **Parceiros** (contadores, revendedores ERP, consultorias) | Médio — kit comercial + treinamento | Médio prazo | Comissão recorrente sobre MRR | Página de parceiros + kit comercial + onboarding de parceiro |
|
||||
|
||||
---
|
||||
|
||||
## Ciclo de vendas por porte do cliente
|
||||
|
||||
| Porte cliente | Ciclo típico | Padrão de venda |
|
||||
|---|---|---|
|
||||
| **Pequeno (5-10 reps)** | 2-4 semanas | Dono decide; demo curta; fechamento rápido (mensal flexível facilita) |
|
||||
| **Médio baixo (11-25 reps)** | 1-2 meses | Dono + supervisor avaliam; comparam com 1-2 concorrentes |
|
||||
| **Médio alto (26-50 reps)** | 2-4 meses | Avaliação mais formal; possível POC; anual prepago com desconto acelera |
|
||||
|
||||
---
|
||||
|
||||
## Implicações para site / marketing (alimenta Steps 13-26)
|
||||
|
||||
1. **Hero do site:** demo em vídeo + "Veja o SAR funcionando em 3 minutos" (não "Cadastre-se grátis")
|
||||
2. **Prova social pesada:** logos de clientes; depoimentos em vídeo de **donos** (não de TI); números reais ("R$ X em pedidos processados no SAR este mês")
|
||||
3. **Páginas dedicadas por papel:**
|
||||
- `/para-donos` — IA estratégica, dashboard de gestão, ROI
|
||||
- `/para-supervisores` — telas de decisão diária, controle de equipe
|
||||
- `/para-representantes` — clareza de carteira, metas, WhatsApp
|
||||
4. **Comparativos diretos:** `SAR vs Mercos`, `SAR vs módulo TOTVS` — combate frontal aos concorrentes mapeados em Positioning
|
||||
5. **Conteúdo SEO-relevante:**
|
||||
- "Como controlar representante externo"
|
||||
- "Software força de vendas para distribuidora"
|
||||
- "Como integrar WhatsApp com vendas B2B"
|
||||
- "Como saber quais clientes estão esfriando"
|
||||
6. **Página de parceiros:** kit comercial + comissão + treinamento — captura canal contador/ERP-revendedor
|
||||
7. **Eventos:** calendário público "encontre o SAR em X feira" + agendamento de demo presencial
|
||||
|
||||
---
|
||||
|
||||
## Implicações para o produto (alimenta Phase 3+4)
|
||||
|
||||
1. **Demo-friendliness obrigatória:** as 3 experiências precisam ser **visualmente convincentes em 5 minutos**. Não pode ser produto "que melhora com o tempo".
|
||||
2. **Onboarding self-guided no trial:** mesmo sem hand-holding, supervisor consegue se virar (porque ele é o influenciador que tem que aprovar internamente).
|
||||
3. **WhatsApp visível desde a primeira tela:** diferencial declarado, precisa estar evidente quando supervisor abre o SAR pela primeira vez.
|
||||
|
||||
---
|
||||
|
||||
## Implicações para a estrutura comercial JCS
|
||||
|
||||
1. **SDR + AE (mesmo papel inicialmente):** Julian provavelmente acumula até o primeiro fechamento; depois separar.
|
||||
2. **CRM próprio JCS:** pipeline com estágios (lead → qualificado → demo → proposta → contrato). **Possível dogfood:** usar o SAR para vender o SAR.
|
||||
3. **Material de venda padronizado:**
|
||||
- Roteiro de demo (15-20 min)
|
||||
- Proposta template (3 tiers de pricing × 2 contratos)
|
||||
- Termo de aceite + LGPD (controlador de dados é o cliente)
|
||||
4. **Pós-venda / onboarding:** definir quem ajuda na implantação inicial (especialmente para médio alto, onde POC pode ser parte do ciclo).
|
||||
103
design-artifacts/A-Product-Brief/dialog/business-model.md
Normal file
103
design-artifacts/A-Product-Brief/dialog/business-model.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Business Model — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 05 — Business Model
|
||||
|
||||
---
|
||||
|
||||
## Modelo
|
||||
|
||||
**B2B SaaS multi-tenant, per-seat, sales-led, com trial real**
|
||||
|
||||
| Componente | Decisão |
|
||||
|---|---|
|
||||
| **Tipo** | B2B SaaS (empresa-cliente paga; reps/supervisor/dono usam) |
|
||||
| **Cobrança** | **Per-seat** (por representante ativo / mês) |
|
||||
| **Vendas** | **Sales-led** — demo + proposta + acompanhamento comercial |
|
||||
| **Trial** | **14-30 dias** com dados reais do cliente (workspace sandbox provisionado) |
|
||||
| **Contrato** | Híbrido — cliente escolhe: **mensal sem fidelização** (full price) **ou** **anual prepago com desconto** (10-20%) |
|
||||
|
||||
---
|
||||
|
||||
## Definição de "rep ativo" (a refinar)
|
||||
|
||||
Per-seat exige critério canônico de "ativo" para a fatura mensal. Opções candidatas:
|
||||
|
||||
- **Login nos últimos 30 dias** (mais permissivo — captura rep que entra mesmo sem vender)
|
||||
- **Pelo menos 1 pedido lançado nos últimos 30 dias** (mais estrito — vincula a valor)
|
||||
- **Híbrido:** logou OU lançou pedido nos últimos 30 dias
|
||||
|
||||
**Decisão pendente** para Step 8 (Success Criteria) ou Phase 3 (PRD), quando definirmos métricas/billing rules.
|
||||
|
||||
---
|
||||
|
||||
## Ticket médio estimado (preliminar)
|
||||
|
||||
Premissa: R$ 150/rep/mês como referência de mercado (Mercos, Promosoft cobram nessa faixa). Refinar quando JCS validar preço.
|
||||
|
||||
| Porte cliente | Reps | Mensal estimado | Anual prepago (-15%) |
|
||||
|---|---|---|---|
|
||||
| Pequeno | 5-10 | R$ 750-1.500 | R$ 7.650-15.300 |
|
||||
| Médio baixo | 11-25 | R$ 1.650-3.750 | R$ 16.830-38.250 |
|
||||
| Médio alto | 26-50 | R$ 3.900-7.500 | R$ 39.780-76.500 |
|
||||
|
||||
**ARR potencial por cliente:** R$ 9.000 (pequeno) → R$ 90.000 (médio alto).
|
||||
|
||||
---
|
||||
|
||||
## Implicações técnicas
|
||||
|
||||
1. **Per-seat → "active rep counter" no produto**
|
||||
- Job mensal calcula ativos por workspace
|
||||
- Billing consome esse número
|
||||
- UI mostra para o dono quantos ativos estão sendo cobrados (transparência)
|
||||
|
||||
2. **Sales-led → JCS precisa de processo comercial próprio**
|
||||
- CRM próprio para pipeline
|
||||
- Templates de proposta/contrato
|
||||
- Possível dogfood: usar o próprio SAR para gerenciar a venda do SAR
|
||||
|
||||
3. **Trial com dados reais → provisioning automatizado**
|
||||
- Master-login cria workspace sandbox
|
||||
- Cluster PG dedicado (mesma arquitetura BD-por-workspace, ADR 0006)
|
||||
- Seed opcional com catálogo de exemplo
|
||||
- Função de "trial expirado" → bloqueio de escrita, dados preservados N dias para conversão
|
||||
|
||||
4. **Mensal + Anual → módulo de billing precisa suportar ambos**
|
||||
- Cobrança recorrente mensal (cartão/PIX/boleto)
|
||||
- Cobrança única anual (PIX/boleto preferencial — cashflow imediato)
|
||||
- Decidir provider em Step 29 (Integrations): Iugu, Pagar.me, Gerencianet ou Stripe
|
||||
|
||||
---
|
||||
|
||||
## Implicações de marketing/landing page
|
||||
|
||||
- **Site precisa de pricing page** explícita (per-rep + diferencial mensal vs anual)
|
||||
- **CTA principal:** "Agende sua demo" (não "Sign up free")
|
||||
- **Não há checkout no site** — venda passa por SDR/comercial
|
||||
- **Trial gate:**
|
||||
1. Visitante preenche form (empresa, contato, qtd reps, ERP atual)
|
||||
2. SDR JCS qualifica
|
||||
3. Demo (online ou presencial)
|
||||
4. Trial liberado com workspace dedicado e onboarding inicial
|
||||
5. Conversão para contrato pago
|
||||
|
||||
---
|
||||
|
||||
## Implicações para Phase 1 restante
|
||||
|
||||
- **Step 6 (Business Customers):** detalhar a empresa-cliente como **buyer persona** distinta dos 3 user personas. O dono pode ser ambos (buyer + user), mas:
|
||||
- Decisão de compra: avaliação de ROI, integração ERP, suporte JCS
|
||||
- Uso diário: dashboard estratégico + IA
|
||||
- **Step 7 (Target Users):** confirmar os 3 user personas (rep / supervisor / dono).
|
||||
- **Step 8 (Success Criteria):** métricas-chave provavelmente serão MRR/ARR, churn %, ticket médio, % reps ativos, NPS.
|
||||
- **Step 30 (Contact Strategy):** form de demo é a peça-chave do site (não chat genérico, não suporte público).
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Preço exato por rep (a validar com mercado / vendas iniciais)
|
||||
- Setup fee / implantação paga? (não decidido — pode ser bundle no Pro tier ou pago separado)
|
||||
- Treinamento avulso / consultoria como linha extra de receita? (não decidido)
|
||||
- Add-ons (WhatsApp tier premium? IA tier premium?) — possível, decidir quando produto amadurecer
|
||||
86
design-artifacts/A-Product-Brief/dialog/client-profile.md
Normal file
86
design-artifacts/A-Product-Brief/dialog/client-profile.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Client Profile: SAR — Força de Vendas
|
||||
|
||||
**Cliente:** JCS Sistemas
|
||||
**Created:** 2026-05-26
|
||||
**Updated:** 2026-05-26
|
||||
|
||||
---
|
||||
|
||||
## Organisation
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Type** | PME estabelecida — software house (foco em sistemas de gestão / ERP / SaaS B2B) |
|
||||
| **Size** | 11–50 pessoas |
|
||||
| **Industry** | Software de gestão para empresas B2B brasileiras; vertical força de vendas + ERP |
|
||||
| **Tech maturity** | **Alta** — desenvolve software profissional há anos; já tem `STACK.md` v2.2 e `CODING-RULES.md` v2.0 formalizados; produtos legados em produção (app Android + Desktop) |
|
||||
| **Design maturity** | **Iniciante** — produtos funcionam, há identidade visual definida (`brand.md`), mas SAR é o **primeiro projeto com processo UX formal** (WDS). Legado parece ter sido conduzido por dev, sem designer dedicado |
|
||||
|
||||
---
|
||||
|
||||
## People
|
||||
|
||||
### Primary Contact — Julian
|
||||
- **Role:** Product Owner + Tech Lead (acumula PO e responsabilidade técnica)
|
||||
- **Decision mandate:** **Autonomia total** — decide sozinho sobre escopo, prazo e design
|
||||
- **Notes:** Autor de `STACK.md` e `CODING-RULES.md`. Conduz o WDS pela linha de comando do Claude Code.
|
||||
|
||||
### Champion (if different)
|
||||
- **Name:** Mesmo (Julian)
|
||||
- **Role:** —
|
||||
- **Notes:** Não há champion adicional. Julian é a força motriz única do SAR. Implicação: ritmo e momentum dependem 100% dele; não há outro patrocinador interno empurrando.
|
||||
|
||||
### Technical Contact
|
||||
- **Name:** Mesmo (Julian)
|
||||
- **Role:** Tech Lead — escreveu a stack e as regras
|
||||
- **Notes:** Desenvolvimento principal ainda a definir (time JCS interno provável, dado o tamanho 11-50)
|
||||
|
||||
### Other Stakeholders
|
||||
| Name | Role | Influence |
|
||||
|------|------|-----------|
|
||||
| — | — | — |
|
||||
|
||||
Nenhum stakeholder externo mencionado nesta fase. Pode haver sócios/diretores na JCS, mas não participam diretamente do SAR.
|
||||
|
||||
---
|
||||
|
||||
## Decision Culture
|
||||
|
||||
- **Decision style:** **fast-individual** — Julian decide, segue
|
||||
- **Approval chain:** Julian → execução. Sem comitê, sem signoff externo.
|
||||
- **Timeline culture:** **fast-iterative** — velocidade preferida, mas qualidade vem primeiro (sem prazo rígido forçando atalhos)
|
||||
|
||||
---
|
||||
|
||||
## Internal Driver
|
||||
|
||||
- **What triggered this project:**
|
||||
A JCS já oferece produtos legados (app Android + Desktop) para força de vendas e ERP. Viu **oportunidade de modernizar e unificar** esses dois mundos num único SaaS web — não como "conserto" do legado, mas como **upgrade de tier do produto**, integrando força de vendas + ERP de forma nativa.
|
||||
|
||||
- **What success means internally:**
|
||||
**Tornar a JCS competitiva como SaaS de força de vendas no mercado regional/nacional.** SAR é vitrine: prova de que a JCS sabe entregar produto digital moderno multi-tenant, com chance de escalar para clientes além da base atual.
|
||||
Implicação política: SAR não é só "produto" — é **posicionamento de marca JCS**. Decisões de UX/qualidade refletem na empresa toda.
|
||||
|
||||
- **Internal deadline or pressure:**
|
||||
**Sem deadline rígido.** Preferência por momentum e velocidade, sem queimar qualidade por uma data específica. Pressuposto: progresso visível em meses (não anos).
|
||||
|
||||
---
|
||||
|
||||
## Working Style
|
||||
|
||||
- **Communication preference:** **Sessões longas focadas** neste chat (Claude Code com WDS). Profundidade num turno, sem fragmentação async.
|
||||
- **Prior agency experience:** **Nenhuma** com agência/studio de design — estreia em processo UX formal. WDS é o primeiro framework de design adotado.
|
||||
- **Notes:**
|
||||
- Comunicação em pt-BR
|
||||
- Apresentação preferida: **recomendar com justificativa** (eu indico opção + porquê)
|
||||
- Envolvimento balanceado: decisões-chave passam por ele, execução avança sem confirmação contínua
|
||||
- Trabalha diretamente em terminal/CLI (Claude Code), valoriza ferramentas que respeitam o workflow técnico
|
||||
|
||||
---
|
||||
|
||||
## Implicações para o resto da Phase 1
|
||||
|
||||
1. **Velocidade autorizada.** Sem comitê + decisão individual + sem deadline rígido = não preciso politicamente embalar recomendações; posso ser direto.
|
||||
2. **Tech-side já decidido.** Como Julian é tech lead e autor da stack, steps 27-32 (Platform Requirements) viram **consolidação documental**, não descoberta.
|
||||
3. **Design-side é o trabalho de verdade.** Steps 1-12 (Brief estratégico) + 13-18 (Content) são onde há maior lacuna a preencher.
|
||||
4. **SAR como vitrine** muda Phase 2: as personas não são só "rep externo / supervisor / admin" — incluem implicitamente **clientes-empresa em potencial** que vão avaliar a JCS pelo SAR.
|
||||
170
design-artifacts/A-Product-Brief/dialog/competitive-landscape.md
Normal file
170
design-artifacts/A-Product-Brief/dialog/competitive-landscape.md
Normal file
@@ -0,0 +1,170 @@
|
||||
# Competitive Landscape — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 09 — Competitive Landscape
|
||||
|
||||
> 5 alternativas analisadas (incluindo do-nothing). 5 unfair advantages identificados. Posição alvo: vendas-first + baixo atrito de implantação.
|
||||
|
||||
---
|
||||
|
||||
## 5 grupos de alternativa
|
||||
|
||||
### 🔴 Grupo 1 — Apps verticais de força de vendas
|
||||
|
||||
**Concorrentes:** Mercos · Promosoft · MaxFV · Workforce · Mobits
|
||||
|
||||
| Dimensão | Análise |
|
||||
|---|---|
|
||||
| **Por que cliente fica** | Já implantado, time treinado, dados migrados são caros, suporte conhecido |
|
||||
| **O que fazem bem** | Catálogo+pedido funcional, integração ERP comum, atendimento em pt-BR |
|
||||
| **Onde falham** | Tela única (sem cockpits) · IA decorativa ou inexistente · WhatsApp externo · UX antiga (legados PHP/Java/Delphi) · sem real-time · caros após 50+ reps |
|
||||
| **SAR ataca onde** | 4 cockpits + IA estrutural + WhatsApp nativo + UX moderna |
|
||||
| **SAR aceita perder** | Clientes com > 1 ano de Mercos + 100+ reps treinados (custo de migração mata o deal) |
|
||||
|
||||
### 🟠 Grupo 2 — ERPs com módulo de força de vendas
|
||||
|
||||
**Concorrentes:** TOTVS · Sankhya · Senior · Bling · Tiny · Omie
|
||||
|
||||
| Dimensão | Análise |
|
||||
|---|---|
|
||||
| **Por que cliente fica** | ERP é backbone — trocar é arriscado/caro; já tem certificações fiscais |
|
||||
| **O que fazem bem** | Contábil + fiscal + financeiro completos, NF, ICMS-ST robusto |
|
||||
| **Onde falham** | Módulo de vendas é ERP-first, não vendas-first; sem mobile real; sem IA; sem WhatsApp; UX desktop pesada |
|
||||
| **SAR ataca onde** | **Coexistência via API** — cliente não precisa trocar o ERP; SAR vira "camada de vendas" sobre TOTVS/Sankhya |
|
||||
| **SAR aceita perder** | Cliente enterprise com TOTVS full-stack ultra-integrado (raros no SMB) |
|
||||
|
||||
### 🟡 Grupo 3 — Stack improvisado
|
||||
|
||||
**Composição típica:** Excel + WhatsApp manual + ERP sem módulo de vendas
|
||||
|
||||
| Dimensão | Análise |
|
||||
|---|---|
|
||||
| **Por que cliente fica** | Custo zero de software, controle total, sem treinamento |
|
||||
| **O que faz bem** | Customização total ad-hoc, flexibilidade |
|
||||
| **Onde falha** | Zero visibilidade, zero automação, zero IA, erros humanos crescem com volume |
|
||||
| **SAR ataca onde** | "Primeira ferramenta de verdade" — ROI óbvio quando SAR mostra "você tem X clientes esfriando que ninguém viu" |
|
||||
| **SAR aceita perder** | PMEs com < 5 reps ou que veem TI como inimigo |
|
||||
|
||||
### 🟢 Grupo 4 — Apps caseiros (sob medida)
|
||||
|
||||
**Cenário típico:** dev terceirizado construiu sistema próprio há 2-5 anos
|
||||
|
||||
| Dimensão | Análise |
|
||||
|---|---|
|
||||
| **Por que cliente fica** | Custo afundado (já investiu R$ 50-200k), dev "conhece o negócio" |
|
||||
| **O que faz bem** | Customizações específicas |
|
||||
| **Onde falha** | Manutenção pesadelo, dev único = risco, sem roadmap, sem IA, sem multi-tenant, lentidão para evoluir |
|
||||
| **SAR ataca onde** | "Acabou o pesadelo de manutenção — roadmap contínuo sem custo extra" |
|
||||
| **SAR aceita perder** | Cliente cuja personalização real exige código (raro na prática) |
|
||||
|
||||
### ⚪ Grupo 5 — **Do nothing** (não decidir)
|
||||
|
||||
> A alternativa mais subestimada — provavelmente **50%+ dos prospects ficam aqui**.
|
||||
|
||||
| Dimensão | Análise |
|
||||
|---|---|
|
||||
| **Por que cliente fica** | "Tá funcionando assim, pra que mexer?" · medo de complicar · orçamento alocado a outras coisas |
|
||||
| **O que perde silenciosamente** | **5-10% carteira/ano em churn silencioso** · decisões com dados velhos · reps talentosos migram pra concorrente com ferramenta melhor · concorrente ganha 1-2% market share/ano |
|
||||
| **Janela de mercado** | Próximos 2-3 anos B2B SaaS força de vendas vai **consolidar**. Quem espera entra com gap intransponível |
|
||||
| **SAR ataca como** | **Demo com dados reais do cliente** — "Olha quantos clientes pararam de comprar nos últimos 60 dias e ninguém viu". Choque que cria urgência. |
|
||||
|
||||
---
|
||||
|
||||
## Unfair advantages do SAR
|
||||
|
||||
### Resistentes a cópia (alto moat, > 2 anos para concorrente neutralizar)
|
||||
|
||||
1. **Concept estrutural "4 cockpits"**
|
||||
Mercos/TOTVS são monolíticos; refazer pra cockpits especializados exige reescrita completa do produto. Não é roadmap, é re-arquitetura.
|
||||
|
||||
2. **Multi-tenancy BD-por-workspace** (ADR 0006)
|
||||
Arquitetura desde dia 0, não retrofit. Concorrentes em row-level `tenantId` precisam de 1-2 anos para migrar. Viabiliza integração ERP heterogênea + LGPD by design.
|
||||
|
||||
3. **Stack moderna JCS** (Node 24 + Nest 11 + Prisma 7 + React 19.2)
|
||||
Velocidade de desenvolvimento ~3x superior aos legados PHP/Java/Delphi. Não copiável sem virar a empresa toda.
|
||||
|
||||
4. **IA estratégica desenhada desde o concept**
|
||||
Concorrente que adiciona IA "bolt-on" vai ter feature, não diferencial estrutural. Atravessar os 4 cockpits exige a arquitetura cockpit-first.
|
||||
|
||||
5. **Velocidade de iteração JCS** (decisão fast-individual)
|
||||
Equipe pequena + dono-desenvolvedor pode iterar mensalmente; concorrentes corporates lançam anualmente. Vantagem de incumbent inverso (small wins fast).
|
||||
|
||||
### Não sustentáveis (precisariam de outro moat para defender)
|
||||
|
||||
| Feature | Tempo de cópia |
|
||||
|---|---|
|
||||
| WhatsApp nativo | 6-12 meses |
|
||||
| Editor de campanhas no-code | 1-2 anos |
|
||||
| UX moderna por papel | 1-2 anos |
|
||||
| Real-time entre cockpits | 6-12 meses |
|
||||
|
||||
**Conclusão:** a defesa **não é feature isolada — é a combinação estrutural** dos 5 pontos resistentes. Concorrente que copiar 1-2 features fica atrás; copiar todos requer reescrita arquitetural de 2-3 anos.
|
||||
|
||||
---
|
||||
|
||||
## Reality checks (tentando derrubar o positioning)
|
||||
|
||||
| Ameaça realista | Resposta do SAR |
|
||||
|---|---|
|
||||
| "Mercos lança IA em 2026" | IA bolt-on sobre tela única não é "4 cockpits + IA atravessando todos". Diferencial estrutural não copia em 1 ano. |
|
||||
| "TOTVS abre API gratuita do módulo deles" | SAR vira mais necessário, não menos — cliente quer trocar o módulo, não o ERP. Coexistência joga A FAVOR. |
|
||||
| "Surge novo SaaS BR com stack moderna" | Possível. Defesa: velocidade JCS + domain expertise (anos no setor) + canal de indicação. |
|
||||
| "WhatsApp Business muda regras de integração" | Risco real. Mitigação: arquitetura plug-in não acoplada + alternativa Telegram/SMS no roadmap. |
|
||||
| "IA não convence donos reais — só PMs com viés tech" | Risco real. Mitigação: IA **explicável** (cada alerta com "por que te digo isso") + validação no MVP (Daniel acessa IA 2x/semana é métrica north-star). Se falhar, IA vira feature secundária, não pilar. |
|
||||
|
||||
---
|
||||
|
||||
## Mapa estratégico
|
||||
|
||||
```
|
||||
Alto custo de implantação
|
||||
▲
|
||||
│
|
||||
TOTVS ● │
|
||||
Sankhya │
|
||||
│ ● Apps caseiros
|
||||
│
|
||||
│
|
||||
◄─────────────────────────┼─────────────────────────►
|
||||
ERP-first │ Vendas-first
|
||||
│
|
||||
│ ● Mercos
|
||||
│ ● Promosoft
|
||||
│
|
||||
● SAR │
|
||||
(vendas-first │
|
||||
+ low-friction) │
|
||||
│
|
||||
│ ● Excel + WhatsApp
|
||||
│ (do-nothing-ish)
|
||||
▼
|
||||
Baixo custo de implantação
|
||||
```
|
||||
|
||||
**Posição alvo:** **vendas-first + baixo atrito de implantação** — quadrante semi-vazio onde apps verticais (alto atrito, vendas-first) e stack improvisado (zero atrito, baixíssimo valor) deixam espaço.
|
||||
|
||||
---
|
||||
|
||||
## Implicações estratégicas
|
||||
|
||||
### Para a venda
|
||||
1. **Demo precisa atacar do-nothing primeiro, não Mercos.** A urgência ("você está perdendo silenciosamente") vence mais leads que o comparativo direto.
|
||||
2. **Comparativos públicos no site** (SAR vs Mercos, SAR vs TOTVS) só para leads quentes já comparando — segmento minoritário.
|
||||
3. **Coexistência com ERP é mensagem-chave** para clientes Grupo 2 — não "troque o TOTVS", e sim "deixe o TOTVS, troque o módulo de vendas".
|
||||
|
||||
### Para o produto
|
||||
1. **Manter os 5 unfair advantages estruturais inviolados em todas decisões** — antes de qualquer feature, perguntar: isso compromete cockpits? multi-tenant? velocidade JCS? IA estrutural? stack moderna?
|
||||
2. **IA precisa ser explicável desde MVP** — não black-box. Caso contrário diferencial não convence.
|
||||
3. **Plug-in para WhatsApp** (não acoplado) — proteção contra mudança de regras Meta.
|
||||
|
||||
### Para a estratégia
|
||||
1. **Janela de 2-3 anos para entrincheirar.** Depois, ou o SAR é referência, ou entrou tarde demais. Velocidade do MVP (3-4 meses) é decisão estratégica, não apenas operacional.
|
||||
2. **Foco em referenciabilidade** sobre tração massiva — primeiros 10 clientes precisam virar cases públicos para alimentar canal #1 (boca-a-boca).
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Benchmark de preço detalhado dos concorrentes (Mercos, Promosoft) — captura no go-to-market
|
||||
- Análise SWOT individual por concorrente — não prioritária no Brief; pode entrar em Phase 3 PRD
|
||||
- Concorrentes internacionais (Salesforce SMB, HubSpot) — fora do alcance prático no SMB brasileiro hoje
|
||||
188
design-artifacts/A-Product-Brief/dialog/constraints.md
Normal file
188
design-artifacts/A-Product-Brief/dialog/constraints.md
Normal file
@@ -0,0 +1,188 @@
|
||||
# Constraints — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 10 — Constraints
|
||||
|
||||
> Reposicionados como **parâmetros de design** — o que dá forma ao SAR. Fixo = certeza estratégica; Flexível = decidimos depois.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Tensão estratégica explícita (flagueada por Saga)
|
||||
|
||||
**O combo decidido:**
|
||||
- Concept ambicioso (4 cockpits + WhatsApp nativo + IA estratégica + multi-tenant + real-time)
|
||||
- MVP em 3-4 meses
|
||||
- **Solo founder mode** (Julian full-time até 1º cliente)
|
||||
|
||||
**A matemática não fecha sem trade-off.** Solo + 3-4 meses não comporta o concept completo no MVP.
|
||||
|
||||
### Resolução proposta (a confirmar em Phase 3 PRD)
|
||||
|
||||
**MVP mínimo defensível** (refinar em Phase 3):
|
||||
- ✅ **Rep cockpit** (Rafael — primária, mobile-first) — obrigatório
|
||||
- ✅ **Supervisor cockpit** (Sandra — influenciadora-chave da venda) — obrigatório, mas em forma simplificada
|
||||
- ✅ **Arquitetura multi-tenant BD-por-workspace** — fundacional, não dá pra adiar
|
||||
- ✅ **WhatsApp** — versão básica (envio de notificações; recebimento e conversa bidirecional pode ser fase pós-MVP)
|
||||
- 🟡 **Dono cockpit** (Daniel) — dashboard simples no MVP; **IA estratégica entra pós-MVP** (validar primeiro cliente)
|
||||
- 🟡 **Admin cockpit** (Alice) — cadastros essenciais + pautas; **editor no-code de campanhas entra pós-MVP**
|
||||
|
||||
**Justificativa:** 1º cliente do MVP é referência interna ou parceiro próximo (não cold lead). Pode aceitar limitações em troca de preço/condições especiais. Quando o 1º cliente renova (north star MVP), Julian contrata 1-2 devs e completa IA + editor no-code + cockpits ricos.
|
||||
|
||||
**Alternativa (se o trade-off for inaceitável):**
|
||||
- Reduzir solo period — contratar 1 dev mesmo antes do 1º cliente
|
||||
- OU esticar MVP para 5-6 meses
|
||||
- OU reduzir concept (sacrificar 1 cockpit ou um diferencial)
|
||||
|
||||
---
|
||||
|
||||
## Timeline
|
||||
|
||||
### Fixo
|
||||
- **MVP em produção com 1º cliente real:** 3-4 meses (a partir de 2026-05-26)
|
||||
- **North star MVP:** 1º cliente renova em mês 6-7
|
||||
- **Janela de mercado:** 2-3 anos para entrincheirar antes de saturação SaaS força de vendas BR
|
||||
- **10 clientes pagantes:** ~mês 12
|
||||
|
||||
### Flexível
|
||||
- Ordem das features dentro do MVP
|
||||
- GA público / fim de beta (depende de qualidade do MVP)
|
||||
- Sem deadline externo rígido (não há feira/contrato amarrando data)
|
||||
|
||||
### Implicação de design
|
||||
> "Build to learn, not to plan." MVP minimalista, instrumentado para medir desde dia 0.
|
||||
|
||||
---
|
||||
|
||||
## Budget
|
||||
|
||||
### Fixo
|
||||
- **Stakes:** small-business (PME software house, 11-50 pessoas) — não é Series A
|
||||
- **CAC payback < 12 meses** (Step 8) — limita o quanto se pode gastar para adquirir cada cliente
|
||||
- **Aquisição inicial baixa-fricção:** indicação + SEO antes de ads pagos pesados
|
||||
- Sem orçamento para infra de luxo — STACK.md self-host Proxmox já calibrado para isso
|
||||
|
||||
### Flexível
|
||||
- Tamanho do time escala com tração
|
||||
- Investimento em marketing escala com receita
|
||||
- Eventos/feiras escolhidos seletivamente
|
||||
|
||||
### Implicação de design
|
||||
> Stack canônica self-host (Proxmox) + multi-tenancy bem feita = custo de infra por workspace baixíssimo. Crescimento sustentável.
|
||||
|
||||
---
|
||||
|
||||
## Recursos humanos
|
||||
|
||||
### Fixo (estado atual)
|
||||
- **Julian:** PO + Tech Lead + Champion + único dev (solo founder mode até 1º cliente)
|
||||
- Sem time de design dedicado — estreia em processo UX formal via WDS
|
||||
- Atendimento/SDR inicial = Julian
|
||||
|
||||
### Premissa pós-MVP (a confirmar quando 1º cliente fechar)
|
||||
- Contratar 1-2 devs adicionais para acelerar IA + editor no-code + cockpits ricos
|
||||
- Atendimento eventualmente separado
|
||||
|
||||
### Flexível
|
||||
- Quem são os devs adicionais (interno JCS / freelance / contratação)
|
||||
- Timing de profissionalização do atendimento
|
||||
|
||||
### ⚠️ Implicação crítica
|
||||
> Solo founder mode é o **constraint mais apertado** do projeto. Toda decisão de escopo no MVP precisa respeitar isso. Tudo que "pode esperar pra fase 2" → vai pra fase 2.
|
||||
|
||||
---
|
||||
|
||||
## Técnico — STACK.md v2.2 (FIXO por escolha do PO)
|
||||
|
||||
| Camada | Decisão |
|
||||
|---|---|
|
||||
| Runtime | Node 24 LTS · pnpm 11.1 · TypeScript 5.9 |
|
||||
| Monorepo | Nx 22.7 (`apps/api` + `apps/web` + `libs/`) |
|
||||
| Backend | NestJS 11.1 · Prisma 7 · PostgreSQL 18 · BullMQ · nestjs-cls |
|
||||
| Frontend | React 19.2 · Vite 8 · Ant Design 6.4 · TanStack Query/Router · Zustand |
|
||||
| API | REST + OpenAPI 3.1 + RFC 9457 · Zod 4 (catalog) · nestjs-zod |
|
||||
| Auth | master-login (IdP próprio) · jose · argon2id |
|
||||
| Multi-tenancy | **BD-por-workspace** (ADR 0006) |
|
||||
| Real-time | Socket.IO 4 + redis-adapter (Valkey) · SSE nativo NestJS |
|
||||
| Secrets | HashiCorp Vault (KV v2) self-host |
|
||||
| Observabilidade | Pino + OpenTelemetry · Grafana Cloud LGTM · Sentry |
|
||||
| Filas | BullMQ 5.77 |
|
||||
| Uploads | MinIO (S3-compat) + ClamAV worker · sharp |
|
||||
| Email | Resend (SaaS) + React Email via BullMQ |
|
||||
| Infra | Proxmox on-prem BR (ADR 0004) · Docker Compose · Ansible deploy |
|
||||
| CDN | Cloudflare + Nginx para SPA estática |
|
||||
|
||||
### Flexível (decidir em Step 29 — Integrations)
|
||||
- **Provider de pagamento:** Stripe / Iugu / Pagar.me / Gerencianet
|
||||
- **Provider de IA:** OpenAI / Anthropic / local
|
||||
- **WhatsApp Business API:** oficial Meta vs intermediário (Z-API, Twilio, Gupshup)
|
||||
- **Analytics de produto:** PostHog self-host? Amplitude? Misto?
|
||||
|
||||
### Implicação de design
|
||||
> "STACK.md é fonte da verdade. Nada de propor PostgREST, Supabase, Next.js, trocar AntD por shadcn." Decisões fora da tabela exigem RFC.
|
||||
|
||||
---
|
||||
|
||||
## Brand — brand.md (FIXO por escolha do PO)
|
||||
|
||||
### Fixo
|
||||
- **Paleta:** JCS Blue `#004a99` como único destaque cromático
|
||||
- **Tipografia:** Plus Jakarta Sans (pesos 400/500/600/700/800)
|
||||
- **Ícones:** Font Awesome 6.4.0
|
||||
- **Gráficos:** Chart.js
|
||||
- **Radius:** 12px (md) / 20px (lg)
|
||||
- **Sombra padrão:** `0 4px 25px rgba(0,0,0,0.05)`
|
||||
- **Layout base:** topbar 80px + sidebar 260px fixa (cockpits Sandra/Daniel/Alice)
|
||||
- **Tom visual:** Apple-inspired, clean, minimalista
|
||||
|
||||
### Flexível (Phase 6 Design System detalha)
|
||||
- **Variações por cockpit** — especialmente Rafael mobile-first (navegação inferior, single-column, touch-friendly)
|
||||
- Tokens secundários (estados de feedback) dentro da paleta JCS
|
||||
- Tom de voz textual (Steps 13-15)
|
||||
- Imagery (Step 25)
|
||||
- **Dark mode** (desejável especialmente Rafael à noite)
|
||||
|
||||
### Implicação de design
|
||||
> brand.md é a base. Phase 6 (Design System) **estende** com variantes por cockpit, não substitui.
|
||||
|
||||
---
|
||||
|
||||
## Regulatório / LGPD (FIXO — STACK.md §22)
|
||||
|
||||
| Item | Decisão |
|
||||
|---|---|
|
||||
| **Base legal** | Execução de contrato (cliente-empresa é controlador; SAR é operador) |
|
||||
| **Isolamento** | Físico — cluster PG dedicado por workspace (ADR 0006) |
|
||||
| **Datacenter** | BR (Proxmox on-prem) — elimina exposição ao CLOUD Act US |
|
||||
| **PII** | Criptografada — MinIO SSE + `pgcrypto` |
|
||||
| **Logs** | Redact agressivo (CPF, cardNumber, password, authorization, cookie) |
|
||||
| **Auditoria** | Art. 18 LGPD (acesso/correção/eliminação de dados pessoais) |
|
||||
| **Hash em targeting de flags** | Para feature flags com info pessoal |
|
||||
|
||||
### Implicação adicional para WhatsApp + IA
|
||||
- DPA (Data Processing Agreement) obrigatório com providers externos (Meta, OpenAI/Anthropic)
|
||||
- Hashar dados de cliente antes de mandar para IA (não enviar nome, CPF, telefone real)
|
||||
- WhatsApp: cliente do SAR opt-in explícito do contato final (cliente-do-cliente) antes do primeiro envio
|
||||
|
||||
---
|
||||
|
||||
## Dependências externas (risco fixo, mitigação flexível)
|
||||
|
||||
| Dependência | Risco | Mitigação |
|
||||
|---|---|---|
|
||||
| Meta WhatsApp Business | Mudança de regras → integração quebra | Arquitetura plug-in; alternativas Telegram/SMS no roadmap |
|
||||
| OpenAI / Anthropic / IA externa | Mudança de pricing, quota, política | Abstração de provider; capacidade de trocar |
|
||||
| Resend (email) | SaaS pode mudar tier | Migrar para SES/Mailgun; abstração de envio |
|
||||
| Cloudflare (CDN) | SaaS muda preço/política | Migrar para outro CDN; impacto baixo |
|
||||
| Provider BR de pagamento | Falha/lentidão pode bloquear cobrança | Multi-provider com fallback (Step 29) |
|
||||
|
||||
---
|
||||
|
||||
## Resumo: o que o constraint map nos diz
|
||||
|
||||
1. **MVP precisa ser radicalmente priorizado** — solo + 3-4 meses não comporta o concept completo. Refinar em Phase 3 PRD.
|
||||
2. **Rafael + Sandra são obrigatórios** no MVP; Daniel e Alice entram em forma simplificada.
|
||||
3. **IA estratégica entra pós-MVP** — depois do 1º cliente validado.
|
||||
4. **Editor de campanhas no-code** (Alice) entra pós-MVP — pode usar tela direta no MVP.
|
||||
5. **Stack canon JCS + brand.md são parâmetros, não restrições negativas** — eliminam decisões e aceleram desenvolvimento.
|
||||
6. **LGPD by design** alinha com o concept multi-tenancy físico — não é overhead, é diferencial competitivo.
|
||||
7. **Solo founder mode é o constraint mais apertado** — todo escopo precisa respeitar isso. Tudo que pode esperar → espera.
|
||||
768
design-artifacts/A-Product-Brief/dialog/decisions.md
Normal file
768
design-artifacts/A-Product-Brief/dialog/decisions.md
Normal file
@@ -0,0 +1,768 @@
|
||||
# Decisões — Phase 1 (Project Brief)
|
||||
|
||||
> Log de decisões-chave tomadas durante a Phase 1. Append-only.
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 1a (Client Profile)
|
||||
|
||||
### Organização
|
||||
- **JCS Sistemas** é PME estabelecida (software house), 11-50 pessoas, alta maturidade técnica, design ainda iniciante.
|
||||
- SAR é o **1º projeto da JCS com processo UX formal**.
|
||||
|
||||
### People & decisão
|
||||
- **Julian** acumula 3 papéis: Product Owner + Tech Lead + único Champion.
|
||||
- **Autonomia total** para decidir escopo/prazo/design.
|
||||
- **Cultura fast-individual:** sem comitê, sem signoff externo, decisões saem rápido.
|
||||
|
||||
### Driver
|
||||
- SAR **não é "consertar legado"**. É **upgrade de tier**: unificar força de vendas (app Android) + ERP (Desktop) num **SaaS web vendável**.
|
||||
- **Sucesso = JCS competitiva como SaaS de força de vendas regional/nacional.**
|
||||
- SAR funciona como **vitrine de marca JCS** — vai além de produto, é posicionamento.
|
||||
|
||||
### Working style
|
||||
- Sem deadline rígido.
|
||||
- Sessões longas focadas no chat.
|
||||
- Velocidade > formalismo (mas qualidade > velocidade quando conflitam).
|
||||
|
||||
### Implicações
|
||||
- Posso ser direto em recomendações (sem precisar embalar politicamente).
|
||||
- Steps 27-32 (Platform) vão ser **consolidação documental** via STACK.md, não descoberta.
|
||||
- Steps 1-12 (Brief estratégico) e 13-18 (Content) são onde há trabalho real.
|
||||
- Phase 2 (Trigger Map) precisa considerar **clientes-empresa potenciais** como persona implícita, além dos 3 perfis usuários (rep / supervisor / admin).
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 2 (Vision)
|
||||
|
||||
### Vision statement aprovada
|
||||
> SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.
|
||||
|
||||
### Decisões-chave reveladas
|
||||
1. **3 experiências distintas, não 3 telas iguais.** Rep, Supervisor e Dono usam o SAR de modos qualitativamente diferentes (operacional ↔ tático ↔ estratégico).
|
||||
2. **WhatsApp é canal nativo, não integração anexa.** Implica API WhatsApp Business no escopo desde o início.
|
||||
3. **IA estratégica para o dono é diferencial declarado.** Implica decidir cedo o escopo de IA (insights generativos? alertas? recomendações?).
|
||||
4. **Inteligência de carteira ativa** (inativos, ciclo, oportunidades) — não é "relatório", é parte do produto-base.
|
||||
5. **SaaS multi-tenant é o pulo qualitativo**, não "ter mais features que o legado". Distribuição/instalação é o gargalo que o web resolve.
|
||||
|
||||
### Implicações para próximos steps
|
||||
- Step 3 (Positioning): diferenciais já mapeados (6 itens), prontos para virar positioning statement.
|
||||
- Step 7 (Target Users): rep / supervisor / dono (não "admin" do brand.md — o dono é uma persona estratégica distinta).
|
||||
- Step 9 (Competitive Landscape): SaaS força de vendas regional/nacional — Mercos, Promosoft, Workforce, etc.
|
||||
- Step 10 (Constraints): IA + WhatsApp + multi-tenant impõem escolhas técnicas e regulatórias (LGPD reforçada).
|
||||
|
||||
### Lacuna documentada
|
||||
- "Cena concreta do dia típico" (pergunta #1) ficou em aberto, será retomada na Phase 2 (Trigger Map).
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 3 (Positioning)
|
||||
|
||||
### Target customer
|
||||
- 4 perfis válidos: Distribuidoras, Indústrias, RCAs, PMEs com vendas externas
|
||||
- **Sweet spot:** 5-50 representantes na rua (mid-SMB)
|
||||
|
||||
### Categoria
|
||||
- Plataforma SaaS de Força de Vendas (SFA)
|
||||
|
||||
### Dor central
|
||||
- **Donos e supervisores decidem no escuro** — não têm visibilidade em tempo real do que acontece na rua
|
||||
|
||||
### Concorrência
|
||||
- Apps verticais: Mercos, Promosoft, MaxFV, Workforce, Mobits
|
||||
- ERPs com módulo: TOTVS, Sankhya, Senior
|
||||
- Stack improvisado: Excel + WhatsApp + ERP
|
||||
- Apps caseiros sob medida
|
||||
|
||||
### Implicações estratégicas chave
|
||||
1. **Coexistência com ERPs como diferencial** — multi-tenancy BD-por-workspace facilita integração heterogênea por cliente
|
||||
2. **WhatsApp nativo e IA estão no MVP**, não em roadmap futuro
|
||||
3. **3 experiências distintas** é pilar de marca, não detalhe
|
||||
4. **"Visibilidade em tempo real" é promessa-mãe** — implica websockets/SSE no produto desde o lançamento
|
||||
5. **Pricing range** definido pelo sweet spot 5-50 reps (mid-SMB, não enterprise nem micro)
|
||||
|
||||
### 4 estratégias de aquisição por origem
|
||||
- App vertical concorrente → ganho de IA + 3 experiências + WhatsApp
|
||||
- Módulo de ERP → coexistência, não migração
|
||||
- Stack improvisado → primeira ferramenta de verdade
|
||||
- App caseiro → fim do pesadelo de manutenção
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 5 (Business Model)
|
||||
|
||||
### Modelo escolhido
|
||||
- **B2B SaaS multi-tenant, per-seat, sales-led, com trial real**
|
||||
- Cobrança: **per-seat** (por rep ativo/mês)
|
||||
- Sales motion: **sales-led** (demo + proposta + acompanhamento comercial)
|
||||
- Trial: **14-30 dias** com dados reais (workspace sandbox)
|
||||
- Contrato: **híbrido** — mensal sem fidelização OU anual prepago com desconto (10-20%)
|
||||
|
||||
### Ticket médio estimado (R$ 150/rep referência)
|
||||
- Pequeno (5-10 reps): R$ 750-1.500/mês → ARR R$ 9k-18k
|
||||
- Médio baixo (11-25): R$ 1.650-3.750/mês → ARR R$ 20k-45k
|
||||
- Médio alto (26-50): R$ 3.900-7.500/mês → ARR R$ 47k-90k
|
||||
|
||||
### Implicações técnicas chave
|
||||
1. Precisa **active rep counter** no produto (define cobrança)
|
||||
2. Trial exige **provisioning automatizado** de workspace + seed opcional
|
||||
3. Billing suporta **cobrança mensal recorrente + cobrança anual única** (provider a decidir em Step 29 — Iugu/Pagar.me/Gerencianet/Stripe)
|
||||
4. Workspace sandbox de trial reusa arquitetura BD-por-workspace (ADR 0006) — não é caso especial
|
||||
|
||||
### Implicações de marketing
|
||||
- **CTA principal do site:** "Agende demo", não "Sign up free"
|
||||
- **Trial é gated:** form → SDR qualifica → demo → liberação
|
||||
- **Pricing page** explícita no site
|
||||
|
||||
### Lacunas conscientemente adiadas
|
||||
- Preço exato/rep (validar com mercado)
|
||||
- Setup fee / implantação paga (não decidido)
|
||||
- Add-ons premium (WhatsApp tier? IA tier?) — futuro
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 6 (Business Customers)
|
||||
|
||||
### Buyer persona — "O Dono Empresário B2B"
|
||||
- 35-60 anos, sócio-fundador ou herdeiro, gerencia "no peito"
|
||||
- Critério: **fé que vai funcionar**, não TCO planilhado
|
||||
- Convence: demo concreta + boca-a-boca + cases
|
||||
- Assusta: aprendizagem do time, complexidade, custo
|
||||
|
||||
### Estrutura de decisão
|
||||
- **Decisor:** dono OU diretor comercial (varia por porte)
|
||||
- **Influenciadores que matam o deal:** supervisor de vendas + reps champions
|
||||
- **Ausentes:** financeiro, TI, jurídico (venda operacional-emocional, não técnico-financeira)
|
||||
|
||||
### Canais de aquisição (4 ativos)
|
||||
- Indicação boca-a-boca + Google/SEO + feiras setoriais + parceiros (contadores, revendedores ERP)
|
||||
- Implica: programa de referral, blog SEO, calendário de feiras, página de parceiros
|
||||
|
||||
### Ciclo por porte
|
||||
- Pequeno (5-10 reps): 2-4 semanas
|
||||
- Médio baixo (11-25): 1-2 meses
|
||||
- Médio alto (26-50): 2-4 meses (POC possível)
|
||||
|
||||
### Implicações chave
|
||||
1. **Demo-friendliness obrigatória** — produto precisa brilhar em 5 min, sem hand-holding
|
||||
2. **Site precisa 3 páginas por papel** (`/para-donos`, `/para-supervisores`, `/para-representantes`)
|
||||
3. **Comparativos diretos** com Mercos/TOTVS no site (combate frontal)
|
||||
4. **WhatsApp visível na primeira tela** do produto (diferencial declarado)
|
||||
5. **JCS precisa de CRM próprio** para venda — possível dogfood (vender SAR com SAR)
|
||||
6. **Conteúdo SEO:** controle de rep externo, força de vendas para distribuidora, WhatsApp + B2B
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 7 (Target Users)
|
||||
|
||||
### 4 user personas confirmados
|
||||
1. **Rafael Representante (PRIMÁRIA — MVP focus)** — 30-50a, mobile-first, 70-90% do volume de uso
|
||||
2. **Sandra Supervisora** — 35-55a, desktop+mobile, "apertar parafusos diários"
|
||||
3. **Daniel Dono** — 40-65a, desktop/iPad, IA estratégica, overlap com buyer persona
|
||||
4. **Alice Admin (nova)** — 25-45a, desktop-only, pautas/promoções/tributação
|
||||
|
||||
### Decisão crítica de design
|
||||
- **Mobile-first para Rafael, desktop-first para os outros 3.** SAR não é "responsivo único" — são paradigmas de UI distintos no mesmo produto.
|
||||
- App do Rafael deve funcionar com sinal 3G/4G ruim (offline-resiliente parcial)
|
||||
- Touch-friendly + dark mode desejável
|
||||
|
||||
### Insights de produto (entram em Phase 3/4)
|
||||
- **Editor de campanhas/promoções no-code** vira diferencial declarado (foi mencionado como responsabilidade Alice)
|
||||
- **Assistente de tributação ICMS-ST** por NCM+UF — diferencial vs ERP-modules
|
||||
- **Auditoria/trilha de mudanças** em pautas, produtos, cadastros (Alice precisa, regulatório também)
|
||||
- **WhatsApp integrado** + **comissão em tempo real** + **funil kanban** são fundamentos do Rafael
|
||||
- **IA explicável** para Daniel (não black box; alertas com contexto)
|
||||
|
||||
### Insight de venda (refina Step 6)
|
||||
- Demo precisa: **brilhar para Sandra** (influenciadora), **vender para Daniel** (decisor), **encantar Rafael** (champion)
|
||||
- Alice é benefício mostrado, não argumento de venda
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 7a (Product Concept)
|
||||
|
||||
### Concept estrutural canônico
|
||||
> **SAR é uma plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.**
|
||||
|
||||
### Metáfora canônica
|
||||
- "Equipe de Fórmula 1" — cada papel tem seu próprio dashboard, mas todos veem o mesmo carro em tempo real
|
||||
|
||||
### 4 princípios de implementação
|
||||
1. **Cada cockpit tem UX/device-target próprios** (Rafael mobile-first, outros desktop-first)
|
||||
2. **Camada de dados única em tempo real** (Socket.IO + SSE, <2s entre cockpits)
|
||||
3. **WhatsApp e IA são fios horizontais**, não módulos isolados
|
||||
4. **Multi-tenancy BD-por-workspace** garante isolamento físico + facilita integração ERP heterogênea
|
||||
|
||||
### Tensões deliberadas aceitas
|
||||
- Construir 4 UX paradigmas em vez de 1 responsivo (custo alto, diferencial alto)
|
||||
- Tempo real obrigatório (custo de infra, ganho de promessa)
|
||||
- WhatsApp/IA como pilares horizontais desde MVP (não roadmap)
|
||||
|
||||
### Implicações arquiteturais
|
||||
- **Phase 6 (Design System) não é opcional** — tokens compartilhados + variantes por cockpit
|
||||
- Cada cockpit possível epic na PRD; atravessadores (WhatsApp/IA/real-time/multi-tenant) viram epics horizontais
|
||||
- Broadcast WebSocket sempre escopado a workspace (não global) — alinha com BD-por-workspace
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 8 (Success Criteria)
|
||||
|
||||
### North Star MVP
|
||||
- **1º cliente real paga e renova sem cancelar nos primeiros 3 meses após go-live**
|
||||
- Critério: retenção provada > tração massiva
|
||||
|
||||
### Y1 comercial (12 meses pós-GA)
|
||||
- **10-20 clientes pagantes** (conservador) | NPS donos > 50 | ARR R$ 200k-600k
|
||||
|
||||
### Timeline-chave
|
||||
- **MVP em produção com 1º cliente real: 3-4 meses** (a partir de 2026-05-26)
|
||||
- MVP validado: mês 6-7 (1º cliente renova)
|
||||
- 10 clientes pagantes: mês 12
|
||||
- Premissa: Julian + 1-2 devs adicionais
|
||||
|
||||
### Targets críticos por camada
|
||||
- **Negócio JCS:** logo churn < 3%/mês · NPS > 50 · CAC payback < 12m · NRR > 110%
|
||||
- **Cliente:** +15-30% pedidos/rep/mês · 10-20% inativos recuperados · aprovação desconto < 30 min · DAU/MAU reps > 80%
|
||||
- **Comportamento usuário:** Rafael > 95% pedidos no SAR + DAU/MAU > 70% · Sandra > 90% aprovações pelo SAR · Daniel > 2x/sem IA · Alice > 80% campanhas no-code
|
||||
- **Qualidade:** p95 tela < 800ms · p95 pedido < 60s · uptime 99.5% · pedidos perdidos = 0 · workspace provisionado < 5 min
|
||||
|
||||
### Implicação técnica chave
|
||||
- **Instrumentação de produto no MVP, não em Phase 2 de roadmap**:
|
||||
- OTel + Pino + Grafana (já em STACK.md §09)
|
||||
- Analytics de produto (PostHog/Amplitude/self-host)
|
||||
- Módulo de feedback in-app para NPS
|
||||
|
||||
### Riscos definidos
|
||||
- Rafael não adota → DAU/MAU < 50% em 60d
|
||||
- Sandra não confia → aprovações por WhatsApp > 30%
|
||||
- Daniel ignora IA → < 1x/semana
|
||||
- North star falha → cliente cancela em 3m
|
||||
- P0 imediato: qualquer pedido perdido por bug
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 9 (Competitive Landscape)
|
||||
|
||||
### 5 grupos de alternativa analisados
|
||||
1. Apps verticais (Mercos, Promosoft, MaxFV, Workforce, Mobits) — SAR ataca via 4 cockpits + IA + WhatsApp nativo
|
||||
2. ERPs com módulo (TOTVS, Sankhya, Senior, Bling, Tiny, Omie) — SAR ataca via **coexistência** (não migração)
|
||||
3. Stack improvisado (Excel + WhatsApp + ERP sem módulo) — SAR ataca via "primeira ferramenta de verdade"
|
||||
4. Apps caseiros — SAR ataca via roadmap contínuo + fim do pesadelo de manutenção
|
||||
5. **Do nothing** (50%+ dos prospects) — SAR ataca via choque "5-10% carteira/ano perdida silenciosamente"
|
||||
|
||||
### 5 unfair advantages estruturais (alto moat, >2 anos para concorrente neutralizar)
|
||||
1. **Concept estrutural "4 cockpits"** — reescrita completa para copiar
|
||||
2. **Multi-tenancy BD-por-workspace (ADR 0006)** — arquitetura desde dia 0
|
||||
3. **Stack moderna JCS** — Node 24 + Nest 11 + Prisma 7 + React 19.2 (~3x velocidade vs PHP/Java/Delphi)
|
||||
4. **IA desenhada desde concept** — não bolt-on
|
||||
5. **Velocidade de iteração JCS** — equipe pequena + decisão fast-individual → iteração mensal vs anual
|
||||
|
||||
### Vantagens não-sustentáveis (copiáveis em 6-24 meses)
|
||||
- WhatsApp nativo, editor no-code, UX moderna, real-time
|
||||
- **Defesa estratégica: a combinação estrutural** dos 5 itens resistentes, não feature individual
|
||||
|
||||
### Posição estratégica alvo
|
||||
- **Vendas-first + baixo atrito de implantação** — quadrante semi-vazio do mapa competitivo
|
||||
|
||||
### Implicações estratégicas
|
||||
1. **Demo ataca do-nothing primeiro**, não Mercos — urgência vende mais que comparativo
|
||||
2. **Coexistência com ERP é mensagem-chave** para Grupo 2
|
||||
3. **IA precisa ser explicável desde MVP** — black box não convence donos
|
||||
4. **WhatsApp via arquitetura plug-in** (não acoplado) — proteção contra mudanças Meta
|
||||
5. **Janela de 2-3 anos para entrincheirar** — velocidade do MVP (3-4 meses) é decisão estratégica
|
||||
6. **Foco em referenciabilidade** > tração massiva — primeiros 10 clientes viram cases públicos
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 10 (Constraints)
|
||||
|
||||
### ⚠️ Tensão estratégica explícita (flagueada)
|
||||
**Combo decidido:** concept ambicioso + MVP 3-4 meses + **solo founder mode** (Julian full-time até 1º cliente).
|
||||
**A matemática não fecha sem trade-off.**
|
||||
|
||||
### Resolução proposta (refinar em Phase 3 PRD)
|
||||
**MVP mínimo defensível:**
|
||||
- ✅ Rep cockpit (Rafael) — obrigatório
|
||||
- ✅ Supervisor cockpit (Sandra) — obrigatório, simplificado
|
||||
- ✅ Multi-tenant BD-por-workspace — fundacional
|
||||
- ✅ WhatsApp — versão básica (notificações; conversa bidirecional pós-MVP)
|
||||
- 🟡 Dono cockpit (Daniel) — dashboard simples; **IA estratégica entra pós-MVP**
|
||||
- 🟡 Admin cockpit (Alice) — cadastros essenciais; **editor no-code de campanhas entra pós-MVP**
|
||||
|
||||
**Premissa:** 1º cliente é referência interna/parceiro próximo, aceita limitações em troca de condições especiais. Quando renova (north star), Julian contrata 1-2 devs e completa.
|
||||
|
||||
### Constraints fixos
|
||||
- **Timeline:** MVP 3-4 meses, janela mercado 2-3 anos
|
||||
- **Budget:** small-business, CAC payback < 12m
|
||||
- **Time:** **solo founder mode até 1º cliente** (Julian acumula tudo)
|
||||
- **Stack:** STACK.md v2.2 é fonte da verdade (RFC para mudanças)
|
||||
- **Brand:** brand.md (paleta JCS + Plus Jakarta + AntD 6.4 + topbar/sidebar + tom Apple)
|
||||
- **Regulatório:** LGPD by design (isolamento físico multi-tenant, redact, criptografia PII)
|
||||
|
||||
### Constraints flexíveis (decisão pós-Brief)
|
||||
- Provider de pagamento (Step 29)
|
||||
- Provider de IA (Step 29)
|
||||
- WhatsApp Business API provider (Step 29)
|
||||
- Analytics de produto (Step 8 já flagueado)
|
||||
- Dark mode (desejável especialmente Rafael)
|
||||
|
||||
### LGPD adicional para WhatsApp + IA
|
||||
- DPA com Meta e OpenAI/Anthropic obrigatório
|
||||
- Hashar dados antes de enviar para IA (sem nome/CPF/telefone real)
|
||||
- Opt-in explícito do contato final no WhatsApp
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 10a (Platform Strategy)
|
||||
|
||||
### Plataforma primária
|
||||
- **Web SaaS** (React 19.2 SPA + Vite 8 + Nginx + Cloudflare) — STACK.md
|
||||
- Sem app store; deploy = rolling docker-compose em VMs Proxmox
|
||||
|
||||
### Device strategy por cockpit
|
||||
- **Rafael (Rep):** **PWA mobile-first** com foco primário em **iOS** (gap onde JCS não tem app native). Android secundário (existe legado, mas reps podem optar pelo PWA).
|
||||
- **Sandra (Supervisora):** Desktop + PWA mobile-light para consultas/aprovações rápidas.
|
||||
- **Daniel (Dono):** Desktop + **iPad first-class** (otimização dedicada).
|
||||
- **Alice (Admin):** Desktop-only.
|
||||
|
||||
### Coexistência com app Android legado
|
||||
- **MVP:** SAR PWA + backend SAR construídos do zero. Android legado intocado.
|
||||
- **Pós-MVP (Y1+):** Adaptar app Android legado para consumir backend SAR (unificar fonte da verdade).
|
||||
- **Futuro (Y1-Y2):** Avaliar native iOS + native Android sobre backend SAR (Capacitor/React Native).
|
||||
|
||||
### Offline strategy (Rafael)
|
||||
- **Nível:** Read + Write com sync
|
||||
- Lançamento de pedido offline → IndexedDB queue → Service Worker sync quando volta online
|
||||
- Conflict resolution: Last-write-wins para rascunho; pedido submetido imutável
|
||||
- Idempotency-Key por pedido (UUID local) protege contra duplicação no sync
|
||||
|
||||
### Native features no MVP
|
||||
- ✅ Geolocation (check-in Rafael)
|
||||
- ✅ Web Push (Sandra aprovação, Rafael pedido aprovado) — exige PWA + VAPID
|
||||
- ✅ Share API (Rafael compartilha pedido via WhatsApp do celular dele)
|
||||
- ✅ Notification API desktop (Sandra)
|
||||
- 🟡 Pós-MVP: Camera, File System Access, Voice (este descartado por segurança rodoviária)
|
||||
|
||||
### Acessibilidade
|
||||
- WCAG AA mínimo desde MVP
|
||||
|
||||
### Implicação de execução
|
||||
- PWA exige investimento explícito ~1-2 semanas no MVP
|
||||
- iPad first-class implica testes regulares em iPad Safari durante Phase 4
|
||||
- Web Push backend reusa BullMQ jobs (alinha com STACK.md §11)
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 11 (Tone of Voice)
|
||||
|
||||
### 5 atributos canônicos
|
||||
1. **Direto** — sem floreio
|
||||
2. **Profissional sem ser frio** — sério, mas humano (não burocratês)
|
||||
3. **Confiante** — afirmativo, não tentativo
|
||||
4. **Específico** — números/dados sempre que possível
|
||||
5. **Empático nos momentos difíceis** — problema + caminho para resolver
|
||||
|
||||
### Variações por cockpit (mesmos atributos, registros distintos)
|
||||
- Rafael: informal, frases curtas
|
||||
- Sandra: direto + decisivo
|
||||
- Daniel: executivo, foco em insight
|
||||
- Alice: técnico-preciso
|
||||
|
||||
### Don'ts
|
||||
- Emoji em produção (brand clean Apple)
|
||||
- Caps lock para erros
|
||||
- Burocratês ("operação", "registro", "movimentação")
|
||||
- "Por favor"/"obrigado" excessivo
|
||||
- Anglicismos onde tem pt-BR (Submit→Enviar)
|
||||
- Frases dúbias ("Talvez", "Possivelmente")
|
||||
|
||||
### Vocabulário canônico (padrão único)
|
||||
- Cliente · Representante/Rep · Orçamento · Pedido · Faturado · Visita · Carteira · Inativo · Painel · Aprovação
|
||||
|
||||
### Implicação
|
||||
- Vocabulário vira tokens i18n centralizados (não strings espalhadas)
|
||||
- Phase 6 Design System inclui guia de microcopy
|
||||
- Prompt de IA generativa precisa incluir esses 5 atributos + vocabulário canônico
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 12 (Create Product Brief) — BLOCK A COMPLETO
|
||||
|
||||
### Product Brief synthesis
|
||||
- **Narrativa estratégica apresentada** como história coerente (não checklist)
|
||||
- **User confirmation:** confirmado sem ajustes
|
||||
- **Brief gerado:** `design-artifacts/A-Product-Brief/01-product-brief.md`
|
||||
|
||||
### Conteúdo do brief canônico
|
||||
- Resumo estratégico
|
||||
- Vision + 3 experiências + 7 diferenciais
|
||||
- Positioning (framework Geoffrey Moore) + mapa estratégico
|
||||
- 4 personas (Rafael primária + Sandra + Daniel + Alice)
|
||||
- Buyer × User mapping
|
||||
- Business model (per-seat sales-led trial + contrato híbrido)
|
||||
- Buyer persona "Dono Empresário B2B"
|
||||
- Canais de aquisição (4) + ciclo por porte
|
||||
- Success criteria (North Star MVP + 4 camadas de métricas)
|
||||
- Competitive landscape (5 grupos + 5 unfair advantages + janela de mercado)
|
||||
- Constraints (tensão solo + 3-4 meses + concept ambicioso flagueada)
|
||||
- Platform strategy (PWA iOS + offline + native features)
|
||||
- Tone of voice (5 atributos + vocabulário canônico + don'ts)
|
||||
- Riscos + mitigações
|
||||
- Próximos passos (Blocks B, C, D, E)
|
||||
|
||||
### Status do Block A
|
||||
- **CONCLUÍDO** — Steps 1, 1a, 2, 3, 5, 6, 7, 7a, 8, 9, 10, 10a, 11, 12 (14 steps)
|
||||
- Tempo decorrido: ~2-3 horas em uma sessão
|
||||
- Próximo: Block B (Content & Language) — Steps 13-18
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 13 (Content Init) — BLOCK B INICIADO
|
||||
|
||||
### Materiais herdados
|
||||
- `brand.md` — identidade visual + tom visual "Apple-inspired"
|
||||
- `01-product-brief.md` — Block A canônico
|
||||
- `dialog/tone-of-voice.md` — 5 atributos + vocabulário canônico (Step 11)
|
||||
|
||||
### Q: Tem brand guidelines existentes?
|
||||
**A: Sim** — brand.md + tone-of-voice.md cobrem visual e microcopy. Block B vai expandir para:
|
||||
- Personalidade (Step 14)
|
||||
- Tom refinado (Step 15)
|
||||
- Idiomas (Step 16)
|
||||
- SEO (Step 17)
|
||||
- Content structure (Step 17a)
|
||||
- Documento final (Step 18)
|
||||
|
||||
### Output inicializado
|
||||
- `design-artifacts/A-Product-Brief/02-content-language.md`
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-26 — Step 14 (Personality)
|
||||
|
||||
### Metáfora canônica
|
||||
- **"Consultor sênior brasileiro de vendas B2B"** — 40-50a, ex-rep que virou consultor, conhece a rua e o ERP, sem firula
|
||||
|
||||
### 5 atributos de personalidade
|
||||
1. **Confiável** — não erra, não some
|
||||
2. **Especialista prático** — conhece o setor, fala como amigo, não acadêmico
|
||||
3. **Decidido** — diz o que é, aponta caminho
|
||||
4. **Discreto** — não atrapalha, Apple-inspired
|
||||
5. **Aliado** — do lado do usuário, não vigiando
|
||||
|
||||
### Conexão por persona
|
||||
- Rafael: colega mais experiente
|
||||
- Sandra: assessor de confiança
|
||||
- Daniel: consultor estratégico
|
||||
- Alice: técnico-parceiro
|
||||
|
||||
### O que NÃO é
|
||||
- Vendedor barulhento, burocrata, coach motivacional, espião, filósofo, jovem descolado
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 15 (Tone refinement)
|
||||
|
||||
### Posicionamento nos 4 espectros (1-5)
|
||||
- **Formality: 3** (levemente formal)
|
||||
- **Mood: 2** (sério-com-leveza)
|
||||
- **Complexity: 3** (vocabulário do setor + acessível)
|
||||
- **Energy: 2** (reservado, Apple-inspired calm)
|
||||
|
||||
### Centro de gravidade
|
||||
"Levemente formal, sério-com-leveza, tecnicamente acessível, energia contida."
|
||||
|
||||
### We Say / Don't Say expandidos
|
||||
- 5 categorias com 3 colunas (✅ SAR / ❌ formal demais / ❌ casual demais)
|
||||
- Cobre: cumprimentos · sucesso · erro · empty states · IA/sugestão
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 16 (Languages)
|
||||
|
||||
### Estratégia canônica
|
||||
- **pt-BR only no MVP, arquitetura i18n-ready**
|
||||
- en preparado no código (chaves i18n) mas sem tradução no MVP
|
||||
- es (LatAm) fora de escopo (requer adaptação fiscal por país)
|
||||
|
||||
### IA generativa
|
||||
- **Sempre pt-BR** — prompts em pt-BR + validação de output (rejeitar respostas em en, fallback)
|
||||
- Vocabulário canônico naturalmente vira chaves i18n estruturadas
|
||||
|
||||
### Localização (BR-only)
|
||||
- BRL · DD/MM/AAAA · 24h · fuso `America/Sao_Paulo` por workspace · telefone `+55 (XX) XXXXX-XXXX` · CEP/CNPJ/CPF padrão BR · sistema métrico
|
||||
|
||||
### Implicação para STACK
|
||||
- Validators Zod para CPF/CNPJ/CEP/telefone BR
|
||||
- Date-fns/Day.js com locale pt-BR
|
||||
- `Intl.NumberFormat('pt-BR', { style: 'currency', currency: 'BRL' })`
|
||||
- Fuso por workspace no master-login
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 17 (SEO Strategy)
|
||||
|
||||
### Keywords nos 6 intents
|
||||
- Service/Solução · Problem · Comparison · Brand · Informational · Long-tail setor
|
||||
|
||||
### Domínio
|
||||
- **A definir** — recomendação: `sarjcs.com.br` (brandable + JCS-link)
|
||||
|
||||
### URL pattern
|
||||
- pt-BR: `<dominio>/<slug>` · en futuro: `<dominio>/en/<slug>`
|
||||
- Slug: lowercase, hífen, sem especiais, ASCII
|
||||
|
||||
### Sitemap
|
||||
- `/` · `/funcionalidades/<cockpit|whatsapp|ia|carteira>` · `/para/<setor>` · `/comparativos/<concorrente>` · `/precos` · `/recursos/<blog|calculadora|kit>` · `/cases` · `/parceiros` · `/sobre` · `/contato` · `/app/`
|
||||
|
||||
### Structured data
|
||||
- `Organization` (todas) · `SoftwareApplication` (home) · `Product`+`Offer` (preços) · `Article`+`Review` (cases) · `Article`+`BreadcrumbList` (blog) · `FAQPage`
|
||||
|
||||
### Local SEO
|
||||
- Reivindicar Google Business Profile da JCS Sistemas
|
||||
- NAP consistente no footer
|
||||
|
||||
### Implicação técnica
|
||||
- Vite + plugin React Helmet para meta dinâmico
|
||||
- JSON-LD para structured data (não microdata)
|
||||
- Sitemap.xml gerado por script no build
|
||||
- robots.txt + meta noindex em `/app/`
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 17a (Content Structure)
|
||||
|
||||
### Site Marketing (10 princípios)
|
||||
- Hero em <5s · vídeo não tour · prova social pesada · 3 jornadas por persona · setor dedicado · CTA único · pricing visible · comparativos acessíveis (não em destaque) · `/recursos/` separado · cases viram peça central com 3+ clientes
|
||||
|
||||
### Produto / 4 cockpits (11 princípios)
|
||||
- Cada cockpit tem home própria · hierarquia por urgência · navegação por device (bottom nav rep / sidebar 260px outros) · max 3 níveis · WhatsApp+IA no caminho principal · empty states informativos · notificações só pra decisão · tempo real com micro-animação · admin fora do path · auditoria em cada entidade · onboarding discreto
|
||||
|
||||
### Exclusões explícitas (8)
|
||||
- Tutorial agressivo · gamificação gritante · chat-com-cliente in-app · marketing email · NF/SPED · wallet · CMS blog · mobile-first para Daniel/Alice
|
||||
|
||||
### Latitude Phase 4
|
||||
- Visão alta no produto, restrições claras de tom/estilo
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 18 (Create Content Document) — BLOCK B COMPLETO
|
||||
|
||||
### Output finalizado
|
||||
- `design-artifacts/A-Product-Brief/02-content-language.md` — documento canônico de comunicação
|
||||
|
||||
### Conteúdo adicional ao doc
|
||||
- **Content Type Guidelines:** UI microcopy · Marketing · Informational · Notificações transacionais · WhatsApp programático · IA generativa
|
||||
- **Content Ownership** (MVP solo + Y1+ contratações)
|
||||
- **Writing Checklist** (13 itens; entra em todo PR de microcopy/artigo/email)
|
||||
- **Resumo executivo** (snapshot completo)
|
||||
|
||||
### Status do Block B
|
||||
- **CONCLUÍDO** — Steps 13, 14, 15, 16, 17, 17a, 18 (7 steps)
|
||||
- Próximo: Block C (Visual Direction) — Steps 19-26 (fast-track via brand.md)
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 19 (Inspiration Workshop) — BLOCK C INICIADO
|
||||
|
||||
### 🌟 Insight estratégico chave revelado
|
||||
> "Não acho nada que tem no mercado de identidade como inspirador — mais uma das coisas que nos trouxe para esse projeto." (Julian)
|
||||
- Mercado B2B força de vendas BR é visualmente medíocre
|
||||
- **Estética moderna é parte do diferencial fundacional do SAR**, não detalhe
|
||||
- **Adicionar como 6º unfair advantage estrutural** no Brief (refinamento ao Step 9)
|
||||
|
||||
### 4 referências externas confirmadas
|
||||
1. **Apple iCloud** — Apple-inspired clean canon
|
||||
2. **Linear** — SaaS B2B moderno, dense + clean, atalhos, dark mode
|
||||
3. **Stripe Dashboard** — densidade + acessibilidade, dados com contexto
|
||||
4. **Notion** — flexibilidade, empty states, hierarquia tipográfica
|
||||
|
||||
### 7 padrões destilados (entram em Design Style)
|
||||
- Sidebar fixa + área limpa · Tipografia hierarquia · Único accent · Densidade respirável · Animações sutis · Dark mode · Empty states informativos
|
||||
|
||||
### Referência por cockpit (alimenta Phase 4)
|
||||
- Rafael: Linear mobile + Apple Notes
|
||||
- Sandra: Linear + Stripe Dashboard
|
||||
- Daniel: Stripe Dashboard + Apple iCloud
|
||||
- Alice: Notion + Linear
|
||||
|
||||
### Output
|
||||
- `dialog/inspiration-analysis.md`
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 21 (Existing Brand)
|
||||
|
||||
### Inventário
|
||||
- Logo SAR: PNG existe (`frontend/img/`) — refresh para SVG + variantes
|
||||
- Logo JCS: 4 PNGs colocados em `design-artifacts/_references/jcs-logo/` — refresh para SVG
|
||||
- Paleta JCS: canônica (brand.md), Keep as-is
|
||||
- Plus Jakarta Sans: canônica, Keep as-is + self-host produção
|
||||
- FA 6.4 + Chart.js + tokens radius/sombra: canônicos, Keep as-is
|
||||
- Layout topbar+sidebar: Keep + adaptar Rafael (mobile bottom nav)
|
||||
|
||||
### Análise visual da logo JCS
|
||||
- "JCS." em bold JCS Blue + seta/swoosh no "C" (movimento, precisão)
|
||||
- "sistemas" em peso light, lowercase, mesmo azul
|
||||
- Layout horizontal clean — Apple-inspired confirmado
|
||||
|
||||
### Análise visual da logo SAR
|
||||
- Ícone JCS Blue com gráfico de barras crescente em branco (metáfora analytics)
|
||||
- "SAR" em bold sans-serif cinza/preto
|
||||
- "FORÇA DE VENDAS" em letterspaced caps cinza médio
|
||||
- Hierarquia deliberada: SAR como produto distinto, JCS como marca-mãe
|
||||
|
||||
### Afiliações declaradas
|
||||
- ✅ "Powered by JCS Sistemas" no footer/login/sobre
|
||||
- ✅ Selos LGPD compliant + futuras certificações
|
||||
- Nenhuma franquia, nenhuma associação setorial obrigatória
|
||||
|
||||
### Brand constraints (não negociáveis)
|
||||
- JCS Blue `#004a99` único accent
|
||||
- Plus Jakarta única família
|
||||
- SAR coexiste visualmente com JCS sempre (parental link)
|
||||
- Tom Apple-inspired clean — sem decoração desnecessária
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 22 (Visual References)
|
||||
|
||||
### 9 categorias destiladas das 4 referências positivas
|
||||
- Layout · Cor · Tipografia · Densidade · Imagery · Efeitos · Estados · Dark mode · Mobile
|
||||
|
||||
### 7 estilos a evitar (referências negativas)
|
||||
- Burocrata corporativo legado · apps verticais BR (Mercos/Promosoft) · SaaS "fofo" · Material Design pesado · BI 2010-2015 · sites BR "exuberantes" · tour interativo agressivo
|
||||
|
||||
### 5 mood keywords canônicos
|
||||
- **Clean · Confident · Specific · Serene · Modern**
|
||||
|
||||
### Frase âncora
|
||||
"clean, confident, specific, serene, modern — como um consultor sênior que apareceu na sua empresa e abriu o notebook"
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 23 (Design Style)
|
||||
|
||||
### 4 decisões canônicas
|
||||
1. **UI Visual Style:** Modern Flat + Minimal (Apple/Linear/Stripe/Notion family) — sem skeumorfismo, sem 3D, radius 12/20px, sombra sutil
|
||||
2. **Design Aesthetic:** Minimalism contemporâneo / Digital-native modern — post-Apple, sem ilustrações ornamentais
|
||||
3. **Color Direction:** Monochromatic + functional accents — JCS Blue protagonista, cool, light + dark mode, distribuição 60/30/10
|
||||
4. **Typography Direction:** Plus Jakarta Sans Geometric Humanist — tabular numerals em dashboards, hierarquia preliminar h1 32-40 / body 14-16 / caption 12-13
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 24 (Layout & Effects)
|
||||
|
||||
### Site Marketing
|
||||
- **Hero: Split** (texto + vídeo play-on-click)
|
||||
- Layouts variados por tipo de página (single column / card grid / side-by-side / 3-column tier)
|
||||
- Top nav sticky · hamburger mobile-only · mega menu em Funcionalidades/Para · CTA demo sempre visível
|
||||
|
||||
### Produto — pattern por cockpit
|
||||
- **Rafael:** single column + cards verticais + bottom nav
|
||||
- **Sandra:** sidebar + grid de cards + tabelas (Linear-like dense+decisão)
|
||||
- **Daniel:** sidebar + **bento box** dashboard (Stripe-like KPIs)
|
||||
- **Alice:** sidebar + **table-first** + forms drawer lateral
|
||||
|
||||
### Visual Effects (nível canônico)
|
||||
- Shadows: sutil (brand.md)
|
||||
- Animations: sutis funcionais 150-250ms ease-out
|
||||
- Parallax: **none** (gimmick em B2B)
|
||||
- Hover: sutil (background/opacity, sem transform 3D)
|
||||
- Loading: skeleton (não spinner)
|
||||
- Real-time: micro-animação 200ms, sem toast intrusivo
|
||||
- Focus rings WCAG AA + reduced motion respeitado
|
||||
|
||||
### Performance targets
|
||||
- Lighthouse mobile > 90 · TTI Rafael 3G < 3s · FCP < 1.5s
|
||||
- Bundle inicial < 200KB gzipped por entry
|
||||
- Code-split por cockpit · WebP/AVIF + lazy + sharp · Service Worker para Rafael offline · vídeo hero sem autoplay
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 25 (Imagery)
|
||||
|
||||
### Estratégia canônica: **Apple-style produto-primário**
|
||||
- MVP usa **screenshots do produto + ilustrações minimíssimas**
|
||||
- **Sem stock humano** — sai do mainstream B2B saturado
|
||||
- Fotos reais entram pós-MVP quando houver cases/permissões
|
||||
|
||||
### Photography style (quando aplicar)
|
||||
- Authentic/Documentary — pós-MVP em cases
|
||||
- **Product-focused — MVP** (screenshots reais)
|
||||
- Lifestyle moderado pós-MVP (sem "team smiling")
|
||||
- Polished/staged **NUNCA**
|
||||
|
||||
### Anti-padrões absolutos
|
||||
- Executive shaking hands · diverse team smiling · UI hologram · gráficos 3D flutuando · senhor preocupado com planilha · cidade + barra sobreposta
|
||||
|
||||
### Icons
|
||||
- FA 6.4 subset · **Regular/Outline padrão**, Solid só em estados · sistema 16/20/24px · cor inherit + JCS Blue em ações primárias · ícone SAR como signature visual
|
||||
|
||||
### Illustrations
|
||||
- **Quase nenhuma no MVP** — Apple-clean prefere ausência
|
||||
- Permitido: empty states (line art mono JCS Blue) e erro 404/500
|
||||
- EVITAR: isométrico hipster · gradiente saturado · diversity blob people
|
||||
|
||||
### Image guidelines
|
||||
- 16:9 / 4:3 / 1:1 ratios · alt obrigatório WCAG AA · WebP/AVIF + JPG fallback q80-85 · lazy load · srcset 1x/2x/3x · Cloudflare CDN · sharp pipeline
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Step 26 (Create Visual Document) — BLOCK C COMPLETO
|
||||
|
||||
### Visual DNA Summary
|
||||
```
|
||||
Style: Modern Flat + Minimal (Apple/Linear/Stripe/Notion family)
|
||||
Aesthetic: Minimalism contemporâneo / Digital-native modern
|
||||
Colors: Monochromatic JCS Blue + functional accents · cool · light + dark mode · 60/30/10
|
||||
Typography: Plus Jakarta Sans Geometric Humanist · tabular numerals
|
||||
Mood: Clean · Confident · Specific · Serene · Modern
|
||||
Layout: Split hero (site) · cards/grid/bento/table por cockpit
|
||||
Effects: Sutis funcionais 150-250ms · sombra única brand.md · sem parallax
|
||||
Imagery: Screenshots-only Apple-style · sem stock humano · FA outline
|
||||
Key element: 4 cockpits sobre dado único em tempo real (ícone do gráfico crescente da logo SAR como símbolo)
|
||||
```
|
||||
|
||||
### Status do Block C
|
||||
- **CONCLUÍDO** — Steps 19, 20, 21, 22, 23, 24, 25, 26 (8 steps)
|
||||
- Documento canônico: `design-artifacts/A-Product-Brief/03-visual-direction.md`
|
||||
- Próximo: Block D (Platform Requirements) — fast-track via STACK.md (Steps 27-32)
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-27 — Block D (Platform Requirements) — CONCLUÍDO ✅
|
||||
|
||||
### Steps 27-32 batched
|
||||
- Step 27 (Init) · Step 28 (Tech Stack — espelho STACK.md v2.2) · Step 29 (Integrations) · Step 30 (Contact Strategy) · Step 31 (Multilingual & SEO) · Step 32 (Final synthesis)
|
||||
- Documento canônico: `design-artifacts/A-Product-Brief/04-platform-requirements.md`
|
||||
|
||||
### Decisões fechadas no Step 29
|
||||
- **Pagamento:** Iugu (boleto/PIX/cartão + assinaturas recorrentes BR)
|
||||
- **WhatsApp:** Oficial Meta (WhatsApp Cloud API)
|
||||
- **Analytics produto:** PostHog self-host em Proxmox
|
||||
- **Email, Storage, Secrets, CDN, Obs:** já cobertos por STACK.md (Resend, MinIO, Vault, Cloudflare, Grafana+Sentry)
|
||||
|
||||
### Decisão ABERTA — IA generativa
|
||||
- Julian quer estudar todas as opções (Anthropic / OpenAI / Local Ollama / Multi-provider)
|
||||
- **Resolução estratégica:** abstração multi-provider via Vercel AI SDK ou LiteLLM desde dia 1 — código fica provider-agnostic
|
||||
- **Default temporário:** Anthropic Claude (Sonnet/Opus) por explicabilidade e força em pt-BR, escondido atrás de interface JCS
|
||||
- Decisão definitiva: quando 1º cliente fechar e Julian tiver tempo para benchmark
|
||||
|
||||
### Contact Strategy
|
||||
- **Form de demo** como CTA único (sem chat ao vivo no MVP)
|
||||
- 8 campos obrigatórios + 2 opcionais (qualifica origem + porte + ERP)
|
||||
- Anti-spam: hCaptcha/Turnstile (não Google reCAPTCHA — LGPD)
|
||||
- Rate limit 5/h email + 10/h IP
|
||||
- SDR JCS (Julian no início) responde em até 4h úteis
|
||||
|
||||
### Multilingual & SEO técnico
|
||||
- pt-BR only MVP, i18n-ready
|
||||
- Domínio recomendado: `sarjcs.com.br`
|
||||
- JSON-LD structured data plan completo
|
||||
- noindex em `/app/` (produto privado)
|
||||
- Lighthouse > 90 mobile como CI gate
|
||||
|
||||
### Maintenance
|
||||
- Solo founder mode até 1º cliente; depois +1-2 devs JCS
|
||||
- Documentação extensiva (CODING-RULES.md) como mitigação de bus factor
|
||||
101
design-artifacts/A-Product-Brief/dialog/inspiration-analysis.md
Normal file
101
design-artifacts/A-Product-Brief/dialog/inspiration-analysis.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# Inspiration Analysis — SAR
|
||||
|
||||
**Confirmed:** 2026-05-27
|
||||
**Step:** 19 — Inspiration Workshop
|
||||
|
||||
> **Insight estratégico chave:** O mercado B2B de força de vendas brasileiro é visualmente medíocre (Mercos, Promosoft, TOTVS, etc. todos com UI antiga/burocrata). Julian declarou: "não acho nada que tem no mercado de identidade como inspirador — mais uma das coisas que nos trouxe para esse projeto". **A estética moderna é parte do diferencial do SAR**, não apenas detalhe — é motivo de origem do produto.
|
||||
|
||||
---
|
||||
|
||||
## Referência primária — Brand.md (já estabelecido)
|
||||
|
||||
Tom Apple-inspired: clean, minimalista, espaço em branco generoso, hierarquia clara, sem ruído visual.
|
||||
|
||||
---
|
||||
|
||||
## 4 referências externas (fora do setor B2B força de vendas BR)
|
||||
|
||||
### 1. Apple iCloud / Apple Settings
|
||||
|
||||
**Por quê:** Já é a referência declarada no `brand.md`. Personifica "Apple-inspired clean".
|
||||
|
||||
**O que destilar:**
|
||||
- Sidebar fixa com hierarquia clara
|
||||
- White space generoso, sem zebra
|
||||
- Tipografia decisiva (SF Pro, peso variável)
|
||||
- Sem ruído visual; ações importantes em destaque
|
||||
- Cinza neutro como base, azul Apple como único accent
|
||||
|
||||
### 2. Linear (linear.app)
|
||||
|
||||
**Por quê:** SaaS B2B moderno, dense info + clean — diretamente aplicável aos cockpits Sandra/Alice.
|
||||
|
||||
**O que destilar:**
|
||||
- Densidade de informação **sem cansar** — tabelas/listas com peso visual baixo
|
||||
- Atalhos de teclado-first (boa pista para Sandra e Alice em bulk operations)
|
||||
- Animações sutis (funcionais, não enfeite)
|
||||
- Dark mode elegante (Rafael à noite)
|
||||
- Vocabulário consistente (status, prioridade, owner)
|
||||
|
||||
### 3. Stripe Dashboard
|
||||
|
||||
**Por quê:** Densidade + acessibilidade visual — referência crítica para o cockpit Daniel (BI + IA).
|
||||
|
||||
**O que destilar:**
|
||||
- Dados importantes em destaque, secundários comprimidos
|
||||
- Métricas com contexto (não só número — comparação + tendência)
|
||||
- Tabelas de transação com hierarquia visual clara
|
||||
- Estados de erro/alerta integrados ao fluxo (não modal popup)
|
||||
- Search/command bar central (futuro acelerador)
|
||||
|
||||
### 4. Notion (notion.so)
|
||||
|
||||
**Por quê:** Flexibilidade + tom + empty states — referência para o produto se sentir poderoso sem parecer complexo.
|
||||
|
||||
**O que destilar:**
|
||||
- Empty states informativos e generosos
|
||||
- Hierarquia tipográfica que guia o olho
|
||||
- Densidade adaptável (cards × lista × tabela)
|
||||
- Tom de voz nas micro-interações (próximo do que SAR quer)
|
||||
- Apesar de poderoso, parece simples
|
||||
|
||||
---
|
||||
|
||||
## 7 padrões destilados (entram em Design Style — Step 23)
|
||||
|
||||
| Padrão | De onde | Aplicação no SAR |
|
||||
|---|---|---|
|
||||
| **Sidebar fixa + área de conteúdo limpa** | Apple, Linear, Notion | Cockpits Sandra/Daniel/Alice (alinha com brand.md topbar 80px + sidebar 260px) |
|
||||
| **Tipografia faz hierarquia, não cores fortes** | Apple, Stripe | Plus Jakarta com pesos variando (400/500/600/700/800), já no brand.md |
|
||||
| **Único accent color** | Apple, Linear | JCS Blue `#004a99` como único destaque cromático (já no brand.md) |
|
||||
| **Densidade + ar respirável** | Linear, Stripe | Sandra precisa de densidade, mas com white space que não cansa |
|
||||
| **Animações sutis funcionais** | Linear, Stripe | Real-time entre cockpits com micro-animação suave (não toast intrusivo) |
|
||||
| **Dark mode elegante** | Linear, Vercel | Desejável especialmente para Rafael à noite (carro/posto) |
|
||||
| **Empty states informativos** | Notion | Já estabelecido em Steps 11/15 ("Sem propostas. Cadastre a primeira...") |
|
||||
|
||||
---
|
||||
|
||||
## Implicações estratégicas
|
||||
|
||||
### Insight de positioning (entra no Brief, refina Step 9)
|
||||
|
||||
**Adicionar como 6º unfair advantage estrutural:**
|
||||
|
||||
> **Estética moderna em mercado visualmente medíocre.** Concorrentes (Mercos, Promosoft, módulo TOTVS) têm UI legada de PHP/Java/Delphi — visualmente datada. O SAR tem possibilidade de **diferenciar via design** num mercado onde quase ninguém prioriza isso. Apple-inspired clean + Linear-density + Stripe-data-clarity + Notion-flexibility = produto que parece de outra categoria.
|
||||
|
||||
**Cuidado:** estética isolada é copiável em 2-3 anos. O moat real é a **combinação** estética + multi-tenant físico + concept "4 cockpits" + velocidade JCS. Mas como porta de entrada, vai brilhar muito na demo.
|
||||
|
||||
### Implicação para Phase 4 (UX Specs)
|
||||
|
||||
- Cada cockpit ganha referência primária de inspiração:
|
||||
- **Rafael (Rep mobile):** Linear mobile + Apple Notes (foco em ação rápida + offline)
|
||||
- **Sandra (Supervisora):** Linear + Stripe Dashboard (densidade + decisão)
|
||||
- **Daniel (Dono):** Stripe Dashboard (métricas + insight) + Apple iCloud (calma executiva)
|
||||
- **Alice (Admin):** Notion (flexibilidade) + Linear (atalhos)
|
||||
|
||||
### Implicação para Phase 6 (Design System)
|
||||
|
||||
- Tokens compartilhados, **mas variantes por cockpit** com inspiração distinta:
|
||||
- Mesma paleta JCS
|
||||
- Mesma tipografia Plus Jakarta
|
||||
- Mas densidades, tamanhos de elementos, espaçamentos variam por persona
|
||||
169
design-artifacts/A-Product-Brief/dialog/platform-strategy.md
Normal file
169
design-artifacts/A-Product-Brief/dialog/platform-strategy.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# Platform Strategy — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 10a — Platform Strategy
|
||||
|
||||
> Estratégia de plataforma decorre da STACK.md + Product Concept + Constraints. Esta sessão consolida e abre as decisões de **device strategy** que afetam o MVP.
|
||||
|
||||
---
|
||||
|
||||
## Plataforma primária — Web SaaS (decisão fixa via STACK.md)
|
||||
|
||||
| Camada | Decisão |
|
||||
|---|---|
|
||||
| **Tipo** | Web SaaS multi-tenant |
|
||||
| **Frontend** | React 19.2 SPA via Vite 8 (Rolldown) |
|
||||
| **Distribuição** | Sem app store; deploy = rolling docker-compose em VMs Proxmox |
|
||||
| **CDN/edge** | Cloudflare + Nginx para SPA estática |
|
||||
| **Identidade** | master-login (IdP próprio) OAuth2/OIDC |
|
||||
| **Multi-tenancy** | BD-por-workspace; workspace resolvido por host/path |
|
||||
|
||||
---
|
||||
|
||||
## Device strategy por cockpit
|
||||
|
||||
### 🟢 Rafael (Rep) — **PWA mobile-first**
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Tecnologia** | **Progressive Web App (PWA)** — SPA com Service Worker + Manifest + Web Push |
|
||||
| **Device-target primário** | **iOS** (gap no mercado; vocês não têm app native iOS) |
|
||||
| **Device-target secundário** | Android (usuários que preferem PWA ao app legado) |
|
||||
| **Instalação** | "Adicionar à Tela de Início" no iOS Safari / Android Chrome |
|
||||
| **Push** | Web Push API via Service Worker (notificações de pedido aprovado, alertas) |
|
||||
| **Offline** | **Read + Write com sync** (lançamento de pedido offline + reconciliação quando volta sinal) |
|
||||
| **Native features** | Geolocation (check-in) · Web Push · Share API (compartilhar pedido) |
|
||||
| **Dark mode** | Desejável (uso noturno em carro/posto) |
|
||||
|
||||
### 🟡 Sandra (Supervisora) — Web desktop + mobile-light
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Device-target primário** | Desktop (notebook escritório) |
|
||||
| **Device-target secundário** | Mobile (PWA — consultas rápidas, aprovações via push) |
|
||||
| **Push** | Web Push para notificar aprovações pendentes |
|
||||
| **Layout** | Topbar 80px + Sidebar 260px (brand.md) com tabelas/listas densas |
|
||||
|
||||
### 🔵 Daniel (Dono) — Desktop + **iPad first-class**
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Device-target primário** | Desktop/notebook |
|
||||
| **Device-target secundário** | **iPad first-class** — testes e ajustes dedicados |
|
||||
| **Layout** | Visualização-first (gráficos amplos), tom executivo |
|
||||
| **Modo** | Claro/escuro elegante (uso noturno em casa) |
|
||||
|
||||
### 🟣 Alice (Admin) — Desktop-only
|
||||
|
||||
| Aspecto | Decisão |
|
||||
|---|---|
|
||||
| **Device-target** | Desktop apenas (sem investimento mobile/tablet) |
|
||||
| **Layout** | Dense forms com assistentes, bulk operations, auditoria visível |
|
||||
|
||||
---
|
||||
|
||||
## Coexistência com app Android legado
|
||||
|
||||
### Decisão estratégica
|
||||
|
||||
- **MVP:** SAR PWA + backend SAR construídos do zero. **App Android legado continua intocado** no curto prazo.
|
||||
- **Pós-MVP (Y1+):** Iniciar **adaptação do app Android legado para consumir backend SAR**, unificando a fonte da verdade.
|
||||
- **Futuro (Y1-Y2):** Avaliar reescrita do app Android para mobile-native sobre backend SAR (possivelmente Capacitor wrap do PWA ou React Native).
|
||||
|
||||
### Modelo evolutivo
|
||||
|
||||
```
|
||||
HOJE MVP Pós-MVP Futuro
|
||||
──── ─── ─────── ──────
|
||||
Backend [App Android legado] [App Android legado] [App Android adapt.] [Native iOS]
|
||||
│ │ [SAR backend] ▲ [Native Android]
|
||||
│ │ │ │ │
|
||||
[Backend [Backend ↓ ▼ ▼
|
||||
legado] legado] [SAR PWA iOS] [SAR backend] [SAR backend]
|
||||
(único) (único)
|
||||
```
|
||||
|
||||
### Implicação técnica
|
||||
|
||||
- **MVP:** SAR é greenfield, sem dependência do Android legado. Reps Android continuam no app legado se já o usam; clientes novos vão direto para SAR PWA.
|
||||
- **Pós-MVP:** App Android passa a consumir API SAR — necessária camada de compatibilidade temporária (provavelmente adapter no backend para mapear contratos antigos do app).
|
||||
|
||||
---
|
||||
|
||||
## Offline strategy detalhada (Rafael)
|
||||
|
||||
### Nível escolhido: **Read + Write com sync**
|
||||
|
||||
| Operação | Online | Offline |
|
||||
|---|---|---|
|
||||
| Visualizar catálogo | API + cache | Cache local (IndexedDB) |
|
||||
| Visualizar clientes | API + cache | Cache local (clientes da carteira do rep) |
|
||||
| Visualizar últimos pedidos | API + cache | Cache local (últimos N) |
|
||||
| **Lançar pedido** | API + ack imediato | **IndexedDB queue + Service Worker sync** |
|
||||
| Editar pedido em rascunho | API + cache | IndexedDB |
|
||||
| Aprovação de desconto (Sandra) | Real-time | (Não aplicável — Sandra é desktop) |
|
||||
|
||||
### Implementação (a detalhar em Phase 3 / 4)
|
||||
|
||||
- **Storage local:** IndexedDB para cache + queue de pendentes
|
||||
- **Sync layer:** Service Worker reage a `online` event; envia queue serialmente
|
||||
- **Conflict resolution:** Last-write-wins para rascunho; pedido finalizado é imutável depois de submeter
|
||||
- **UI signaling:** ícone de "modo offline" claro; toast quando sync completa; mostrar status do pedido (`enviando…` → `enviado`)
|
||||
- **Limites:** offline funciona por até X dias (configurável); depois força login + sync
|
||||
|
||||
### Risco a mitigar
|
||||
|
||||
- **Pedido duplicado:** rep lança offline, depois online sem perceber sync, lança de novo. Solução: `Idempotency-Key` por pedido (UUID gerado local) — já é padrão STACK.md §05.
|
||||
- **Catálogo desatualizado:** rep lança pedido com preço/produto que mudou. Solução: validação no sync com `If-Match` ou status `requer_revisao` se preço divergiu.
|
||||
|
||||
---
|
||||
|
||||
## Native features do MVP
|
||||
|
||||
| Feature | Cockpit | Web API | Status MVP |
|
||||
|---|---|---|---|
|
||||
| **Geolocation** (check-in agenda) | Rafael | `navigator.geolocation` + permissão | ✅ MVP |
|
||||
| **Web Push** (aprovação para Sandra; pedido aprovado para Rafael) | Sandra, Rafael | Push API + Service Worker | ✅ MVP (parte do PWA) |
|
||||
| **Share API** (Rafael compartilha pedido/orçamento via WhatsApp do celular) | Rafael | `navigator.share` | ✅ MVP |
|
||||
| **Notification API** (desktop) | Sandra | `Notification` | ✅ MVP |
|
||||
| **Camera** (foto documento/produto) | Rafael, Alice | `<input type="file" capture>` | 🟡 Pós-MVP |
|
||||
| **File System Access** (Alice import CSV) | Alice | File System API + fallback | 🟡 Pós-MVP |
|
||||
|
||||
### Diferença: Share API vs WhatsApp integrado nativo do SAR
|
||||
|
||||
- **Share API** (MVP): Rafael toca "Compartilhar pedido" → abre menu nativo do iOS/Android → cliente recebe link/PDF via WhatsApp do celular DELE
|
||||
- **WhatsApp nativo do SAR** (parcial no MVP): backend envia mensagem programática via WhatsApp Business API quando pedido é aprovado (notificação ao cliente final). Implementação Step 29.
|
||||
|
||||
Os dois coexistem. Share API é "rep compartilha como pessoa", WhatsApp nativo é "produto envia em nome do cliente-empresa".
|
||||
|
||||
---
|
||||
|
||||
## Interaction models
|
||||
|
||||
| Modelo | Cockpits | Notas |
|
||||
|---|---|---|
|
||||
| **Touch** | Rafael (primário), Sandra/Daniel/Alice (secundário) | Botões 44×44pt mínimo no Rafael |
|
||||
| **Mouse + teclado** | Sandra, Daniel, Alice | Atalhos de teclado avaliados em Phase 4 (especialmente Alice bulk ops) |
|
||||
| **Voice commands** | Nenhum no MVP | Possível futuro: Rafael ditando pedido enquanto dirige (risco de segurança rodoviária — descartado por enquanto) |
|
||||
| **Gesture** | Rafael (swipe entre clientes, pull-to-refresh) | Padrão mobile |
|
||||
| **Acessibilidade** | Todos | WCAG AA mínimo; screen reader compatível desde MVP |
|
||||
|
||||
---
|
||||
|
||||
## Implicações de design e desenvolvimento
|
||||
|
||||
1. **PWA exige Service Worker robusto** — não é "responsivo com manifest", é arquitetura cliente complexa. Investimento explícito de ~1-2 semanas no MVP.
|
||||
2. **Web Push exige certificado VAPID + backend para envio** — encaixa com BullMQ jobs já previstos.
|
||||
3. **Offline write exige UI com estados claros** — `enviando…` `enviado` `falha de sync` `aguardando reconexão` (estados visíveis ao Rafael).
|
||||
4. **iPad first-class implica testes regulares em iPad Safari** durante Phase 4 — adicionar ao matriz de QA.
|
||||
5. **Compatibilidade com Android legado é débito conhecido**, não esquecido — pós-MVP terá adapter layer ou contratos compartilhados.
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Native iOS / native Android (Capacitor / React Native) — pós-Y1
|
||||
- Voice commands para Rafael — descartado por segurança rodoviária
|
||||
- Acessibilidade avançada (WCAG AAA, switch controls) — manter WCAG AA no MVP
|
||||
- Camera e File System Access — pós-MVP
|
||||
- App Smartwatch para alertas Sandra — fora de escopo
|
||||
105
design-artifacts/A-Product-Brief/dialog/positioning.md
Normal file
105
design-artifacts/A-Product-Brief/dialog/positioning.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# Positioning — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 03 — Positioning
|
||||
**Synthesized by:** Saga (BA)
|
||||
|
||||
---
|
||||
|
||||
## Positioning Statement (framework Geoffrey Moore)
|
||||
|
||||
> **Para** distribuidoras, indústrias e escritórios de representação brasileiros com **5-50 representantes externos**,
|
||||
>
|
||||
> **que precisam** de visibilidade em tempo real do que está acontecendo na rua para decidir com dados em vez de no escuro,
|
||||
>
|
||||
> **o SAR é** uma plataforma SaaS de força de vendas que entrega **três experiências distintas no mesmo produto** — clareza operacional para o rep, instrumentos de decisão para o supervisor, IA estratégica para o dono — com WhatsApp como canal nativo e inteligência ativa de carteira.
|
||||
>
|
||||
> **Diferente de** apps verticais como Mercos e Promosoft (que tratam todos os usuários igual e não têm IA estratégica), módulos de força de vendas de ERPs como TOTVS e Sankhya (burocráticos, caros e desconectados do mobile), e do stack improvisado de planilha+WhatsApp+ERP (que não dá visibilidade nenhuma),
|
||||
>
|
||||
> **o SAR** é instalado em minutos como SaaS web, com camadas IA-first sobre cada papel — e coexiste com ERPs existentes em vez de exigir migração total.
|
||||
|
||||
---
|
||||
|
||||
## Componentes do positioning
|
||||
|
||||
### Target Customer (primário)
|
||||
|
||||
Empresas brasileiras B2B com força de vendas externa, dos seguintes perfis (todos válidos):
|
||||
|
||||
- **Distribuidoras / atacadistas** com equipe de representantes externos (perfil clássico)
|
||||
- **Indústrias** que vendem via representantes externos (fabricantes com canal próprio: food service, bebidas, química, materiais de construção)
|
||||
- **RCAs** — escritórios de representação que vendem para várias indústrias (multi-empresa nativo)
|
||||
- **PMEs com vendas externas** (imobiliárias, distribuição de serviços, etc. — extensão além do nicho clássico)
|
||||
|
||||
**Porte sweet spot:** **5-50 representantes na rua** — tem dor real de gestão, mas não tem TI interno suficiente para construir sob medida. SaaS chave-na-mão resolve.
|
||||
|
||||
### Need / Opportunity
|
||||
|
||||
**Donos e supervisores decidem no escuro.** Não sabem em tempo real:
|
||||
- Quem visitou quem hoje
|
||||
- Pedidos em aberto e status
|
||||
- Clientes esfriando / inativos
|
||||
- Metas atingidas e gap
|
||||
- Onde a equipe precisa de empurrão
|
||||
|
||||
Resultado: gestão reativa, perda de clientes silenciosa, esforço comercial desalinhado.
|
||||
|
||||
### Category
|
||||
|
||||
**Plataforma SaaS de Força de Vendas (SFA — Sales Force Automation)** com integração nativa de WhatsApp e camadas IA por papel.
|
||||
|
||||
### Key Benefit
|
||||
|
||||
Clareza em tempo real em **três camadas distintas** numa única plataforma:
|
||||
- **Rep:** clareza operacional (o que vender, pra quem, quanto, status)
|
||||
- **Supervisor:** instrumentos de decisão tática diária
|
||||
- **Dono:** análise estratégica com IA proativa
|
||||
|
||||
Atravessado por: WhatsApp nativo + inteligência ativa de carteira + facilidade de implantação SaaS.
|
||||
|
||||
### Alternatives (concorrência real)
|
||||
|
||||
1. **Apps verticais de força de vendas** — Mercos, Promosoft, MaxFV, Workforce, Mobits
|
||||
2. **Módulos de força de vendas de ERPs nacionais** — TOTVS, Sankhya, Senior
|
||||
3. **Stack improvisado** — planilha Excel + WhatsApp manual + ERP sem módulo
|
||||
4. **Apps caseiros** — sistemas próprios feitos por dev terceirizado
|
||||
|
||||
### Differentiators (7 itens — herdados de Vision + Step 3)
|
||||
|
||||
1. **Inteligência de carteira ativa** — inativos, ciclo de vendas, oportunidades (proativo, não relatório passivo)
|
||||
2. **WhatsApp como canal nativo** — não anexo, não webhook externo
|
||||
3. **Metas como gamificação operacional** — expostas, atingíveis, na cara do rep
|
||||
4. **3 experiências distintas por papel** — não "uma tela igual pra todos"
|
||||
5. **IA estratégica para o dono** — não decorativa, foco em insight de gestão
|
||||
6. **SaaS web distribuível** — instalação em minutos vs. apps Android/Desktop empacotados
|
||||
7. **Facilidade de implantação** — JCS-side: entregar sistema web ao cliente sem fricção (declarado pelo PO)
|
||||
|
||||
---
|
||||
|
||||
## Estratégia de aquisição por origem do cliente
|
||||
|
||||
| Origem | Mensagem-chave | Atrito principal | Vantagem técnica do SAR |
|
||||
|---|---|---|---|
|
||||
| **App vertical concorrente** (Mercos, Promosoft etc.) | "Ganha IA + 3 experiências por papel + WhatsApp nativo, sem perder o que já tinha" | Migração de dados, mudança de hábito | Importação de catálogo/clientes; UX moderna |
|
||||
| **Módulo de ERP** (TOTVS, Sankhya, Senior) | "Mantenha o ERP, troque só a força de vendas — integramos via API" | Convencer que pode "tirar uma peça" do ERP | Multi-tenant BD-por-workspace (ADR 0006) facilita integração heterogênea por cliente |
|
||||
| **Stack improvisado** (Excel + WhatsApp + ERP sem módulo) | "Primeira ferramenta de verdade — sai do escuro" | Educação de mercado, mudança comportamental | Onboarding rápido, UX que não exige treinamento longo |
|
||||
| **App caseiro** (dev terceirizado) | "Acabou com o pesadelo de manutenção — SaaS pronto + roadmap contínuo" | Custo afundado emocional do app antigo | Roadmap JCS contínuo, sem dependência de dev único |
|
||||
|
||||
---
|
||||
|
||||
## Implicações estratégicas
|
||||
|
||||
1. **Coexistência com ERPs é estratégia, não fallback.** Multi-tenancy BD-por-workspace é arquitetonicamente desenhada para integrar com ERPs distintos por cliente — vira diferencial competitivo vs. apps verticais que forçam migração total.
|
||||
2. **WhatsApp nativo e IA não são "futuro" — são MVP.** Estão no positioning statement, então não podem aparecer como Phase 2/3 de roadmap; precisam estar no produto desde o lançamento (ou pelo menos em beta declarado).
|
||||
3. **3 experiências distintas** virou pilar de marca, não detalhe. Influencia: design system, navegação, RBAC, telas iniciais por papel, e até pricing (talvez tier por papel?).
|
||||
4. **"Visibilidade em tempo real" é a promessa-mãe.** Implica websockets/SSE no produto (já previsto em STACK.md §13), e UX que mostra dados frescos (não relatórios datados de ontem).
|
||||
5. **Porte 5-50 reps define o pricing range.** Não pode mirar enterprise (compete com Salesforce), nem micro (não paga SaaS). Mid-SMB sweet spot.
|
||||
|
||||
---
|
||||
|
||||
## Origem (citações e escolhas do PO)
|
||||
|
||||
- Targets selecionados (todos os 4 perfis válidos)
|
||||
- Porte: 5-50 reps confirmado como sweet spot
|
||||
- Concorrência identificada nas 4 categorias
|
||||
- Dor central: **falta de visibilidade em tempo real**
|
||||
160
design-artifacts/A-Product-Brief/dialog/product-concept.md
Normal file
160
design-artifacts/A-Product-Brief/dialog/product-concept.md
Normal file
@@ -0,0 +1,160 @@
|
||||
# Product Concept — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 07a — Product Concept
|
||||
|
||||
> **Concept** ≠ feature list. É o **princípio organizador estrutural** que define como o produto funciona — não o que ele faz.
|
||||
|
||||
---
|
||||
|
||||
## A ideia em uma frase
|
||||
|
||||
> **SAR é uma plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.**
|
||||
|
||||
---
|
||||
|
||||
## Mental model (metáfora canônica)
|
||||
|
||||
> Como uma equipe de Fórmula 1: cada papel (piloto, engenheiro, estrategista, mecânico) tem **seu próprio dashboard, suas próprias decisões e seu próprio ritmo** — mas todos veem o mesmo carro em tempo real, com a mesma telemetria. WhatsApp e IA são o rádio que conecta todos.
|
||||
|
||||
---
|
||||
|
||||
## Por que ESTA estrutura (não outra)
|
||||
|
||||
| Alternativa considerada | Por que rejeitada |
|
||||
|---|---|
|
||||
| "Um produto único, RBAC esconde o que cada um não usa" | Modelo Mercos/Promosoft. Tela do rep cheia de coisa irrelevante e vice-versa. Não diferencia. |
|
||||
| "4 produtos separados (4 logins, 4 contas)" | Quebra o tempo real. Quando rep lança pedido, supervisor não vê na hora. Fragmenta a marca. |
|
||||
| "Web genérico responsivo igual pra todos" | Rafael precisa mobile-first (carro/posto/3G ruim). Daniel precisa desktop/iPad. Forçar igualdade penaliza ambos. |
|
||||
| **"4 cockpits especializados sobre dado único em tempo real"** ✅ | **Cada papel ganha o produto ideal para ele, sem fragmentar dado nem perder consistência.** |
|
||||
|
||||
---
|
||||
|
||||
## Princípios de implementação
|
||||
|
||||
### 1. Cada cockpit tem sua própria UX, navegação e device-target
|
||||
|
||||
| Cockpit | Device-target | Padrão UX |
|
||||
|---|---|---|
|
||||
| **Rafael (Rep)** | **Mobile-first** | Touch-friendly, offline-resiliente, latência percebida baixa, dark mode |
|
||||
| **Sandra (Supervisora)** | Desktop-dense + mobile-light | Dense information, ações 1-clique, push notifications |
|
||||
| **Daniel (Dono)** | Desktop/iPad | Visualização > tabela, tom executivo, claro/escuro elegante |
|
||||
| **Alice (Admin)** | Desktop-only | Dense forms com assistentes, bulk operations, auditoria visível |
|
||||
|
||||
### 2. Camada de dados única em tempo real
|
||||
|
||||
- **Socket.IO** + **SSE** (já previsto em STACK.md §13)
|
||||
- Mudança no Cockpit X aparece em Cockpit Y em <2 segundos
|
||||
- Sem batch noturno, sem refresh manual, sem polling
|
||||
|
||||
### 3. WhatsApp e IA atravessam os 4 cockpits
|
||||
|
||||
- Não são módulos isolados — são **fios condutores horizontais**
|
||||
- WhatsApp: mensagem do cliente vira notificação no Rep, alerta no Supervisor, log no Dono, configuração na Admin
|
||||
- IA: gera alertas para Supervisor (operacional), recomendações para Dono (estratégico), sugestões para Admin (campanhas)
|
||||
|
||||
### 4. Multi-tenancy BD-por-workspace (ADR 0006)
|
||||
|
||||
- Cada empresa-cliente tem **cluster Postgres dedicado**
|
||||
- Cockpits compartilham fonte de verdade **dentro de um workspace**
|
||||
- Isolamento físico entre clientes (LGPD, segurança)
|
||||
- Onboarding/trial: workspace sandbox provisionado automaticamente
|
||||
|
||||
---
|
||||
|
||||
## Exemplo concreto (fluxo que materializa o concept)
|
||||
|
||||
**Cenário:** Rafael lança um pedido com 15% de desconto (acima da alçada dele de 10%).
|
||||
|
||||
```
|
||||
[Cockpit Rafael — mobile, 14:32]
|
||||
│
|
||||
│ 1. Lança pedido R$ 12.000 c/ 15% desconto
|
||||
│ → toca "Enviar"
|
||||
│
|
||||
▼
|
||||
Backend: cria pedido status="aguardando_aprovacao"
|
||||
│ broadcast WebSocket → workspace
|
||||
│
|
||||
├─→ [Cockpit Sandra — desktop, 14:32]
|
||||
│ Fila de aprovações: +1 (animação suave)
|
||||
│ Push notification no celular dela
|
||||
│
|
||||
├─→ [WhatsApp do cliente — 14:32]
|
||||
│ "Olá! Seu pedido #1234 está em análise.
|
||||
│ Acompanhe: link..."
|
||||
│
|
||||
│
|
||||
[Sandra aprova com 1 clique, 14:34]
|
||||
│ broadcast WebSocket
|
||||
│
|
||||
├─→ [Cockpit Rafael — mobile, 14:34]
|
||||
│ Pedido muda de "aguardando" → "aprovado"
|
||||
│ Toast: "✅ Sandra aprovou seu desconto"
|
||||
│
|
||||
├─→ [WhatsApp do cliente — 14:34]
|
||||
│ "Pedido #1234 confirmado!"
|
||||
│
|
||||
│
|
||||
[Cockpit Daniel — desktop, 22:30 mesmo dia]
|
||||
IA: "Hoje você aprovou 3 descontos acima de 10%,
|
||||
todos para o cliente OPENFRIOS.
|
||||
Considere reavaliar a tabela base para eles."
|
||||
```
|
||||
|
||||
Esse fluxo único toca: **4 cockpits + tempo real + WhatsApp nativo + IA proativa**. É o produto-concept em ação — não é demo, é o dia-a-dia.
|
||||
|
||||
---
|
||||
|
||||
## Features que DECORREM (não definem) do concept
|
||||
|
||||
| Cockpit | Features pilares |
|
||||
|---|---|
|
||||
| **Rep** | Lançamento de pedido em <60s · Visão 360° cliente · Comissão tempo real · Funil pessoal · WhatsApp integrado · Agenda + GPS check-in |
|
||||
| **Supervisor** | Fila de aprovações com contexto · Mapa de calor da equipe · Alertas proativos · Comparativo entre reps · Dashboard "apertar parafusos" |
|
||||
| **Dono** | Faturamento vs meta · Top/bottom clientes e produtos · IA estratégica explicável · Análise de carteira/concentração de risco |
|
||||
| **Admin** | Cadastros (produto/cliente/rep) · Pautas versionadas · Editor de campanhas no-code · Assistente ICMS-ST · Auditoria · Bulk operations |
|
||||
| **Atravessando** | WhatsApp Business API nativo · IA contextual · Multi-tenancy BD-por-workspace · Real-time Socket.IO/SSE · Mobile+Desktop paradigmas distintos |
|
||||
|
||||
---
|
||||
|
||||
## Tensões deliberadas (decisões que custam, mas valem)
|
||||
|
||||
1. **Construir 4 UX paradigmas em vez de 1 responsivo**
|
||||
- **Custo:** mais código, mais design, mais teste, mais complexidade
|
||||
- **Ganho:** cada persona ganha experiência adequada; diferencial vs concorrentes
|
||||
- **Mitigação:** Design System compartilhado (Phase 6) garante tokens/componentes consistentes mesmo com paradigmas distintos
|
||||
2. **Tempo real over batch**
|
||||
- **Custo:** infraestrutura Socket.IO + SSE + Valkey adapter; complexidade de estado client-side
|
||||
- **Ganho:** promessa-mãe "visibilidade em tempo real" cumprida; demos brilham
|
||||
- **Mitigação:** STACK.md §13 já previu; multi-tenancy BD-por-workspace facilita escopo de broadcast (por workspace, não global)
|
||||
3. **WhatsApp e IA como pilares horizontais, não módulos**
|
||||
- **Custo:** acoplamento entre cockpits via filas e eventos; precisa pensar arquitetura desde o MVP
|
||||
- **Ganho:** diferenciais declarados não são afterthought; entram no produto coerentemente
|
||||
- **Mitigação:** event-driven via BullMQ (já no STACK.md §11); contrato de evento padronizado
|
||||
|
||||
---
|
||||
|
||||
## Implicações para Phase 2 / 3 / 4
|
||||
|
||||
- **Phase 2 (Trigger Map):** as 4 personas já são os Target Groups. Trigger Map vai aprofundar driving forces × feature impact por cockpit.
|
||||
- **Phase 3 (PRD):** cada cockpit pode virar um epic. Atravessadores (WhatsApp, IA, real-time, multi-tenancy) viram epics horizontais.
|
||||
- **Phase 4 (UX Specs):** cada cockpit gera scenarios separados. Páginas dentro de cada cockpit seguem o paradigma de device-target dele.
|
||||
- **Phase 6 (Design System):** tokens compartilhados, mas **variantes por cockpit** (mobile vs desktop dense vs visualização-first vs forms-first). Phase 6 não é opcional para o SAR.
|
||||
|
||||
---
|
||||
|
||||
## Relação com o concept e o positioning (sanity check)
|
||||
|
||||
O concept reforça o positioning:
|
||||
|
||||
| Positioning claim | Como o concept entrega |
|
||||
|---|---|
|
||||
| "3 (4) experiências distintas no mesmo produto" | Princípio estrutural #1: 4 cockpits especializados |
|
||||
| "Visibilidade em tempo real" | Princípio #2: dado único em tempo real entre cockpits |
|
||||
| "WhatsApp como canal nativo" | Princípio #3: WhatsApp como fio condutor horizontal |
|
||||
| "IA estratégica não decorativa" | Princípio #3: IA atravessando 4 cockpits, não cosmética |
|
||||
| "Coexistência com ERPs existentes" | Princípio #4: multi-tenancy BD-por-workspace facilita integração heterogênea |
|
||||
| "SaaS web distribuível" | Multi-tenancy + provisioning automatizado de workspace |
|
||||
|
||||
Positioning declara promessas. Concept estrutura a entrega.
|
||||
45
design-artifacts/A-Product-Brief/dialog/progress-tracker.md
Normal file
45
design-artifacts/A-Product-Brief/dialog/progress-tracker.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# Progress Tracker — Phase 1 (Project Brief)
|
||||
|
||||
> Status dos 36 steps da Phase 1 WDS-v6.
|
||||
|
||||
| # | Step | Status | Concluído em |
|
||||
|---|---|---|---|
|
||||
| 01 | Init | ✅ | 2026-05-26 |
|
||||
| 01a | Client Profile | ✅ | 2026-05-26 |
|
||||
| 02 | Vision | ✅ | 2026-05-26 |
|
||||
| 03 | Positioning | ✅ | 2026-05-26 |
|
||||
| 05 | Business Model | ✅ | 2026-05-26 |
|
||||
| 06 | Business Customers | ✅ | 2026-05-26 |
|
||||
| 07 | Target Users | ✅ | 2026-05-26 |
|
||||
| 07a | Product Concept | ✅ | 2026-05-26 |
|
||||
| 08 | Success Criteria | ✅ | 2026-05-26 |
|
||||
| 09 | Competitive Landscape | ✅ | 2026-05-26 |
|
||||
| 10 | Constraints | ✅ | 2026-05-26 |
|
||||
| 10a | Platform Strategy | ✅ | 2026-05-26 |
|
||||
| 11 | Tone of Voice | ✅ | 2026-05-26 |
|
||||
| 12 | Create Product Brief | ✅ **BLOCK A COMPLETO** | 2026-05-26 |
|
||||
| 13 | Content Init | ✅ | 2026-05-26 |
|
||||
| 14 | Personality | ✅ | 2026-05-26 |
|
||||
| 15 | Tone | ✅ | 2026-05-27 |
|
||||
| 16 | Languages | ✅ | 2026-05-27 |
|
||||
| 17 | SEO Keywords | ✅ | 2026-05-27 |
|
||||
| 17a | Content Structure | ✅ | 2026-05-27 |
|
||||
| 18 | Create Content Document | ✅ **BLOCK B COMPLETO** | 2026-05-27 |
|
||||
| 19 | Inspiration Workshop | ✅ | 2026-05-27 |
|
||||
| 20 | Visual Init | ✅ | 2026-05-27 |
|
||||
| 21 | Existing Brand | ✅ | 2026-05-27 |
|
||||
| 22 | References | ✅ | 2026-05-27 |
|
||||
| 23 | Design Style | ✅ | 2026-05-27 |
|
||||
| 24 | Layout & Effects | ✅ | 2026-05-27 |
|
||||
| 25 | Imagery | ✅ | 2026-05-27 |
|
||||
| 26 | Create Visual Document | ✅ **BLOCK C COMPLETO** | 2026-05-27 |
|
||||
| 27 | Platform Init | ✅ | 2026-05-27 |
|
||||
| 28 | Tech Stack | ✅ | 2026-05-27 |
|
||||
| 29 | Integrations | ✅ | 2026-05-27 |
|
||||
| 30 | Contact Strategy | ✅ | 2026-05-27 |
|
||||
| 31 | Multilingual | ✅ | 2026-05-27 |
|
||||
| 32 | Create Platform Document | ✅ **BLOCK D COMPLETO** | 2026-05-27 |
|
||||
| 33 | Analyze Brief | ✅ | 2026-05-27 |
|
||||
| 34 | Create Summary | ✅ | 2026-05-27 |
|
||||
| 35 | Update Design Log | ✅ | 2026-05-27 |
|
||||
| 36 | Provide Activation Phase 2 | ✅ **PHASE 1 COMPLETA** | 2026-05-27 |
|
||||
141
design-artifacts/A-Product-Brief/dialog/success-criteria.md
Normal file
141
design-artifacts/A-Product-Brief/dialog/success-criteria.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# Success Criteria — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 08 — Success Criteria
|
||||
|
||||
> Critérios SMART para guiar decisões. **North Star do MVP:** retenção do 1º cliente nos primeiros 3 meses.
|
||||
|
||||
---
|
||||
|
||||
## North Star
|
||||
|
||||
### MVP (primeiros 6 meses)
|
||||
> **1º cliente real paga e renova sem cancelar nos primeiros 3 meses após go-live.**
|
||||
|
||||
Critério primário: **retenção provada** > tração massiva. Prova que o produto entrega valor sustentado, não só "wow" da demo.
|
||||
|
||||
### Y1 comercial (12 meses pós-GA)
|
||||
> **10-20 clientes pagantes (perfil conservador) com NPS dos donos > 50 e ARR de R$ 200k-600k.**
|
||||
|
||||
Foco em referências sólidas que alimentem o canal #1 (boca-a-boca).
|
||||
|
||||
---
|
||||
|
||||
## A. Sucesso do negócio JCS (north star externa)
|
||||
|
||||
| Métrica | Target Y1 | Frequência de revisão | Por quê |
|
||||
|---|---|---|---|
|
||||
| **Clientes pagantes (logos)** | 10-20 | Mensal | Tração de mercado |
|
||||
| **MRR** | R$ 17k-50k (final de Y1) | Mensal | Saúde recorrente |
|
||||
| **ARR** | R$ 200k-600k | Trimestral | Valuation-relevant |
|
||||
| **Logo churn mensal** | < 3% | Mensal | Saúde da retenção SaaS B2B |
|
||||
| **NPS dos buyers (donos)** | > 50 | Trimestral | Probabilidade de indicação (canal #1) |
|
||||
| **CAC payback** | < 12 meses | Trimestral | Eficiência de aquisição |
|
||||
| **NRR (Net Revenue Retention)** | > 110% | Trimestral | Expansão dentro da base (clientes crescem reps) |
|
||||
|
||||
### Cálculo de ARR Y1 (sanity check)
|
||||
|
||||
Mix realista assumido: maioria clientes pequenos (5-10 reps) no início, alguns médios baixos.
|
||||
|
||||
- ARR médio/cliente Y1: ~R$ 15k-30k
|
||||
- 10 clientes: R$ 150k-300k (conservador-baixo)
|
||||
- 20 clientes: R$ 300k-600k (conservador-alto)
|
||||
|
||||
→ **Faixa target: R$ 200k-600k ARR ao final de Y1.**
|
||||
|
||||
---
|
||||
|
||||
## B. Sucesso do cliente (a empresa que comprou)
|
||||
|
||||
> A prova de que o SAR cumpre a promessa. Se o cliente cresce, ele recomenda — alimenta canal #1.
|
||||
|
||||
| Métrica | Como medir | Target | Quando |
|
||||
|---|---|---|---|
|
||||
| **Pedidos/rep/mês vs. baseline pré-SAR** | Cliente declara baseline; SAR mede pós | **+15-30%** | 6 meses pós-go-live |
|
||||
| **% clientes inativos recuperados via alerta IA** | Funil: inativo (>60d sem pedido) → pedido novo | **10-20%** | 3 meses pós-go-live |
|
||||
| **Tempo médio aprovação de desconto** | Telemetria: rep envia → supervisor decide | **< 30 min** | Imediato (vs horas no WhatsApp) |
|
||||
| **% reps ativos no produto** | DAU/MAU dos reps cadastrados | **> 80%** | 60 dias pós-go-live |
|
||||
| **NPS dos reps** | Survey trimestral | **> 30** | Trimestral (reps são duros) |
|
||||
|
||||
---
|
||||
|
||||
## C. Comportamento dos usuários (signal de adoção)
|
||||
|
||||
| Persona | Métrica | Target | Por quê |
|
||||
|---|---|---|---|
|
||||
| **🟢 Rafael (Rep)** | % pedidos lançados pelo SAR vs paralelo (WhatsApp/papel) | **> 95%** | Prova adoção real |
|
||||
| | Tempo médio de lançamento de pedido | **< 60s** | Cumpre cenário canônico |
|
||||
| | DAU/MAU | **> 70%** | Uso diário esperado |
|
||||
| **🟡 Sandra (Supervisora)** | Aprovações via SAR (não WhatsApp) | **> 90%** | Prova que abandona canal velho |
|
||||
| | Acessa "tela do dia" diariamente | **> 80% dias úteis** | Validação do "apertar parafusos" |
|
||||
| **🔵 Daniel (Dono)** | Acessa insights da IA | **> 2x/semana** | Diferencial declarado (IA estratégica) |
|
||||
| **🟣 Alice (Admin)** | Lança campanha sem suporte JCS | **> 80% das campanhas** | Validação do editor no-code |
|
||||
|
||||
---
|
||||
|
||||
## D. Qualidade de experiência (signal de saúde)
|
||||
|
||||
| Métrica | Target | Por quê |
|
||||
|---|---|---|
|
||||
| **p95 latência de tela** | < 800ms | Promessa "tempo real" |
|
||||
| **p95 lançamento de pedido (end-to-end)** | < 60s | Cumpre cenário Rafael |
|
||||
| **% tickets de suporte resolvidos < 4h** | > 80% | Padrão B2B SaaS |
|
||||
| **Disponibilidade (uptime mensal)** | 99.5% | SLA típico |
|
||||
| **Pedidos perdidos por bug/sync** | **0** | Crítico — Rafael não confia se perder pedido |
|
||||
| **Workspace provisionado em** | < 5 min (trial) | Onboarding "fácil" declarado |
|
||||
|
||||
---
|
||||
|
||||
## Timeline / Marcos
|
||||
|
||||
| Marco | Quando | Critério de aceite |
|
||||
|---|---|---|
|
||||
| **MVP em produção com 1º cliente real** | **3-4 meses** (a partir de 2026-05-26) | Cliente assinou contrato pago, está usando os 4 cockpits no dia-a-dia |
|
||||
| **MVP validado** | + 3 meses (≈mês 6-7) | 1º cliente renovou (não cancelou) → north star MVP atingida |
|
||||
| **Beta público / abertura para SDR** | + 1-2 meses (≈mês 8) | Funcionalidade core estável, processo comercial JCS operacional |
|
||||
| **10 clientes pagantes** | ≈ mês 12 | Marco conservador Y1 |
|
||||
| **20 clientes pagantes** | ≈ mês 16-18 | Marco esticado Y1+ |
|
||||
|
||||
**Premissa de timeline:** Julian acumulando PO + Tech + Champion com 1-2 devs adicionais. Stack canon + brand + concept prontos aceleram em ~30% vs. greenfield total.
|
||||
|
||||
---
|
||||
|
||||
## Decisões implícitas nessas métricas
|
||||
|
||||
1. **Métricas exigem instrumentação no produto desde MVP**
|
||||
- Telemetria de p95 latência, DAU/MAU, tempo de lançamento, funil de inativo→pedido
|
||||
- Implica setup de observabilidade (Pino + OTel + Grafana — STACK.md §09) **no MVP**, não em Phase 2 de roadmap
|
||||
- Implica também eventos de produto para analytics (PostHog, Amplitude, ou solução self-host)
|
||||
|
||||
2. **NPS exige operação contínua**
|
||||
- Survey trimestral via email/in-app
|
||||
- Implica módulo de feedback no produto (mesmo simples)
|
||||
|
||||
3. **Suporte com SLA de 4h exige time/processo JCS**
|
||||
- Define expectativa: SDR + 1 atendente mínimo
|
||||
- Pode ser Julian no início (não escalável, mas viável)
|
||||
|
||||
4. **CAC payback < 12 meses define o range comercial**
|
||||
- Para ticket médio R$ 1.500/mês (cliente médio), CAC < R$ 18k → limita custos de aquisição (eventos, ads, parceiros)
|
||||
- Implica que a aquisição começa **boca-a-boca + SEO** (custo baixo), não ads pagos pesados
|
||||
|
||||
---
|
||||
|
||||
## Riscos calibrados pelos critérios
|
||||
|
||||
| Risco | Métrica que detecta | Ação se falhar |
|
||||
|---|---|---|
|
||||
| **Rafael não adota** | DAU/MAU < 50% em 60 dias | Revisão UX mobile-first; possível pivot de interação |
|
||||
| **Sandra não confia** | Aprovações via WhatsApp > 30% | Investigação: SAR lenta? Falta contexto? Workflow ruim? |
|
||||
| **Daniel ignora IA** | < 1x/semana em IA insights | IA está irrelevante / pouco visível / black box demais |
|
||||
| **Cliente cancela em 3 meses** | Churn > 0 nos primeiros 3 meses | NORTH STAR FALHADA — review estrutural do MVP |
|
||||
| **Pedidos perdidos por bug** | > 0 incidentes em qualquer janela | P0 imediato — bloqueio de release até root cause |
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Preço exato/rep (validar com primeiras vendas)
|
||||
- Métrica de eficiência IA (qualidade de sugestão) — definir após primeiros insights gerados
|
||||
- NPS de Alice (Admin) — não prioritário no MVP
|
||||
- Métricas detalhadas de WhatsApp (engagement, response rate) — após integração funcionar
|
||||
257
design-artifacts/A-Product-Brief/dialog/target-users.md
Normal file
257
design-artifacts/A-Product-Brief/dialog/target-users.md
Normal file
@@ -0,0 +1,257 @@
|
||||
# Target Users — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 07 — Target Users
|
||||
**Primary persona:** Rafael (Representante)
|
||||
|
||||
> 4 user personas no produto. **Buyer persona** (dono empresário) já documentado em `business-customers.md` — overlap real com Daniel (User Dono+IA) em empresas pequenas.
|
||||
|
||||
---
|
||||
|
||||
## Hierarquia de prioridade no design
|
||||
|
||||
| Prioridade | Persona | Justificativa |
|
||||
|---|---|---|
|
||||
| **PRIMÁRIA (MVP focus)** | Rafael (Rep) | 70-90% do volume de uso; mobile-first; SAR ganha ou perde aqui |
|
||||
| Secundária — alto impacto | Sandra (Supervisora) | Influenciadora-chave da compra; demo vitrine |
|
||||
| Secundária — alto valor | Daniel (Dono) | Buyer overlap; IA é diferencial declarado |
|
||||
| Terciária — operacional | Alice (Admin) | Backoffice de pautas/promoções; baixo volume mas crítica para o produto rodar |
|
||||
|
||||
**Implicação de design:** **mobile-first para Rafael, desktop-first para Sandra/Daniel/Alice.** SAR não é "responsivo um-tamanho-só" — são duas paradigmas de UI no mesmo produto.
|
||||
|
||||
---
|
||||
|
||||
## 🟢 Rafael — Representante (PERSONA PRIMÁRIA)
|
||||
|
||||
### Quem é
|
||||
- 30-50 anos, vendedor B2B externo
|
||||
- Atende 50-200 clientes ativos numa região definida
|
||||
- Comissionado, meta mensal pesa muito na renda
|
||||
- Trabalha no carro, no posto, no escritório do cliente — **raramente na frente de um computador**
|
||||
|
||||
### Cenário típico (8h da manhã, segunda)
|
||||
> "No carro entre 2 clientes. Quer abrir o SAR no celular e ver: meta do mês, quem visitar hoje, status do último pedido da OPENFRIOS, se já chegou pedido novo, e se a Distribuidora Norte respondeu o orçamento."
|
||||
|
||||
### Frustrações (no legado)
|
||||
- Lança pedido pelo app e não sabe se entrou; precisa ligar pro escritório pra confirmar
|
||||
- Comissão é mistério até fechar o mês — calcula no Excel próprio "pra não confiar cego"
|
||||
- Cliente que parou de comprar passa despercebido até ele perceber sozinho
|
||||
- Atualizou número de WhatsApp do contato? Ninguém vai saber, vai esquecer
|
||||
- Não vê pipeline: tem 3 propostas em aberto e não lembra qual é mais quente
|
||||
- App lento, trava no 3G/4G ruim, perde formulário cheio
|
||||
|
||||
### Goals
|
||||
- **Bater meta** (sempre — define o salário)
|
||||
- Vender mais com menos esforço administrativo
|
||||
- Não levar bronca do supervisor por algo que ele já sabia
|
||||
- Ter resposta rápida quando cliente pede algo no campo
|
||||
|
||||
### Current solution (composição)
|
||||
- App Android JCS legado (lançamento de pedido)
|
||||
- WhatsApp pessoal (contato cliente)
|
||||
- Planilha Excel/Google Sheet própria (comissão, anotações)
|
||||
- Ligação pro escritório (confirmação)
|
||||
- Agenda física ou Google Agenda (visitas)
|
||||
|
||||
### O que ele precisa do SAR
|
||||
1. **Lançamento de pedido em < 60 segundos no celular**, mesmo com sinal ruim
|
||||
2. **Visão 360° do cliente** — histórico, pedidos, contatos, timeline
|
||||
3. **Comissão visível em tempo real** (não fechamento de mês)
|
||||
4. **Funil de propostas/oportunidades** (kanban simples)
|
||||
5. **Lista de clientes inativos** com alerta proativo
|
||||
6. **WhatsApp integrado** (não sair do app para conversar)
|
||||
7. **Agenda + check-in GPS** para roteiro do dia
|
||||
|
||||
### Implicações de design
|
||||
- **Mobile-first OBRIGATÓRIO** (Rafael abre o SAR no celular >80% do tempo)
|
||||
- **Offline-first parcial** ou ao menos resiliente — lançamento de pedido não pode perder por sinal ruim
|
||||
- **Touch-friendly:** botões grandes, gestos simples, sem dropdown aninhado
|
||||
- **Latência percebida baixa:** ack imediato do que ele faz, sync em background
|
||||
- **Dark mode** desejável (carro, posto à noite)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sandra — Supervisora de Vendas
|
||||
|
||||
### Quem é
|
||||
- 35-55 anos, gerente comercial ou gerente regional
|
||||
- Coordena 5-30 representantes
|
||||
- Reporta para dono/diretor comercial
|
||||
- **Trabalha em escritório** com desktop/notebook a maior parte do dia
|
||||
|
||||
### Cenário típico (segunda 9h, na sala)
|
||||
> "Café na mão, abre o SAR no notebook. Quer ver: quais reps já fizeram check-in essa manhã, pedidos aguardando aprovação de desconto, top 5 clientes da carteira que não compram há 30+ dias, e se tem alguma anomalia (queda brusca de faturamento, rep parado, cliente reclamando)."
|
||||
|
||||
### Frustrações (no legado)
|
||||
- Reps "somem" — não sabe quem está em campo, quem está enrolado em casa
|
||||
- Aprovação de desconto vira fila de WhatsApp ("preciso de R$ X de desconto pro cliente Y, libera?")
|
||||
- Não consegue ver pipeline real, só o que cada rep relata na reunião semanal
|
||||
- Quando algo dá errado em pedido (cliente bloqueado, crédito estourado), descobre tarde
|
||||
- Relatórios do legado são lentos, exigem export-Excel-pivottable
|
||||
- Não tem visão consolidada da meta da equipe em tempo real
|
||||
|
||||
### Goals
|
||||
- Garantir que **time bata meta**
|
||||
- Identificar reps performando mal **antes** que perca venda
|
||||
- Não negligenciar clientes-chave
|
||||
- Liberar descontos com critério (não no impulso)
|
||||
- **Dormir tranquila** sabendo que está tudo sob controle
|
||||
|
||||
### Current solution
|
||||
- Desktop JCS legado (relatórios + aprovações)
|
||||
- Planilhas (consolidação manual)
|
||||
- WhatsApp (aprovação de desconto, comunicação com reps)
|
||||
- Reunião semanal presencial/Zoom (90 min, suga tempo)
|
||||
|
||||
### O que ela precisa do SAR
|
||||
1. **Dashboard "apertar parafusos" diário** — top 5 ações que ela precisa tomar HOJE
|
||||
2. **Fila de aprovação de descontos** com contexto (cliente, histórico, margem)
|
||||
3. **Mapa de calor da equipe** — quem está produzindo, quem precisa empurrão
|
||||
4. **Alertas proativos** — rep sem check-in há 2 dias, cliente top sem pedido há 30+ dias
|
||||
5. **Comparativo entre reps** (sem expor publicamente, só pra ela)
|
||||
6. **Relatórios sob demanda** que carregam em <5 segundos
|
||||
|
||||
### Implicações de design
|
||||
- **Desktop-first**, mas com mobile útil (consulta rápida)
|
||||
- **Dense information design** — Sandra quer muita informação na mesma tela
|
||||
- **Ações decisórias com 1-2 cliques** (aprovar/negar desconto sem 5 telas)
|
||||
- **Notificações push** para itens que exigem decisão dela
|
||||
|
||||
---
|
||||
|
||||
## 🔵 Daniel — Dono / Diretor Comercial
|
||||
|
||||
### Quem é
|
||||
- 40-65 anos, sócio-fundador ou diretor sênior
|
||||
- Já passou pela operação, hoje dirige
|
||||
- Tem o caixa, decide investimentos
|
||||
- **Compra o SAR + usa o SAR** (buyer e user — overlap com business-customers.md)
|
||||
- Vê o SAR no notebook em casa, no escritório, no celular esporadicamente
|
||||
|
||||
### Cenário típico (terça à noite, em casa)
|
||||
> "Janta com a família, depois abre o SAR no iPad. Quer ver: faturamento do mês vs. meta, top 5 clientes do mês, top 5 produtos, **clientes que estão esfriando**, e principalmente **o que a IA está sugerindo** ('Atenção: cliente X reduziu pedidos 40% nos últimos 60 dias' / 'Oportunidade: produto Y cresceu 25%, considere campanha')."
|
||||
|
||||
### Frustrações (no legado)
|
||||
- Dashboards mostram passado, não próximo passo
|
||||
- Recebe planilhas mas não consegue extrair direção
|
||||
- Sabe que está perdendo cliente, mas não sabe quais nem por quê
|
||||
- Quer delegar pra Sandra mas não confia 100% que ela vai ver o que ele veria
|
||||
- Reuniões com supervisor são genéricas, sem dados acionáveis
|
||||
|
||||
### Goals
|
||||
- **Dirigir, não operar**
|
||||
- Ter painel que **avisa quando algo desvia** (não precisar procurar)
|
||||
- Confiar no time + ter visibilidade estratégica
|
||||
- Tomar decisões de investimento (contratar mais rep? trocar tabela de preço?) com dados
|
||||
|
||||
### Current solution
|
||||
- Desktop JCS legado para relatórios mensais
|
||||
- Excel (consolidação que financeiro/Sandra preparam)
|
||||
- Reuniões com supervisor (semanal/quinzenal)
|
||||
- Intuição + experiência
|
||||
|
||||
### O que ele precisa do SAR
|
||||
1. **Dashboard estratégico** (não operacional) — faturamento, top/bottom, tendências
|
||||
2. **IA estratégica proativa** — alertas + sugestões, não relatório passivo (DIFERENCIAL DECLARADO)
|
||||
3. **Comparativo período a período** (este mês vs. mês passado, vs. mesmo mês ano anterior)
|
||||
4. **Análise de carteira** — concentração de risco em 1-2 clientes, churn silencioso
|
||||
5. **Visão de meta por equipe / por rep**
|
||||
6. **Recomendações de IA** (campanhas, alocação de esforço, ajuste de tabela)
|
||||
|
||||
### Implicações de design
|
||||
- **Desktop/iPad-first** — Daniel quer telas amplas, gráficos grandes
|
||||
- **Visualização > tabela** — gráficos, indicadores, alertas; minimizar listas brutas
|
||||
- **Tom executivo** — sem ruído operacional ("3 pedidos aguardando aprovação" é da Sandra, não dele)
|
||||
- **IA precisa explicar:** "Por que está me dizendo isso?" — alertas com contexto, não black box
|
||||
- **Modo claro/escuro elegante** (uso noturno em casa)
|
||||
|
||||
---
|
||||
|
||||
## 🟣 Alice — Administradora / Backoffice
|
||||
|
||||
### Quem é
|
||||
- 25-45 anos, funcionária administrativa da empresa-cliente
|
||||
- Trabalha em escritório, **desktop o dia todo**
|
||||
- Reporta para Sandra ou Daniel
|
||||
- Domínio: catálogo, pautas, tributação, campanhas, cadastros
|
||||
|
||||
### Cenário típico (quarta 14h, no escritório)
|
||||
> "Está cadastrando nova linha de produtos que a empresa vai começar a vender em janeiro. Precisa importar planilha do fornecedor, ajustar pauta de preço por região, configurar grupo tributário (ICMS-ST), depois preparar a **campanha de lançamento com 15% de desconto na primeira compra**."
|
||||
|
||||
### Frustrações (no legado)
|
||||
- Cadastros lentos, telas confusas, muitos campos opcionais sem orientação
|
||||
- Pauta de preço é planilha avulsa importada manualmente — propensa a erro
|
||||
- Configurar promoção exige "pedir pro dev rodar SQL"
|
||||
- Tributação ICMS-ST por UF é um inferno — não tem assistente, tem que conhecer regra
|
||||
- Cadastrar rep com permissões/região é processo manual
|
||||
- Não tem trilha de auditoria — quem mexeu na tabela de preço ontem?
|
||||
|
||||
### Goals
|
||||
- Manter catálogo + tributação + promoções funcionando **sem incidente**
|
||||
- Não precisar do dono pra cada ajuste
|
||||
- **Lançar campanhas com agilidade** (promoções de fim de mês, sazonais, kit, brinde)
|
||||
- Ter confiança de que o sistema não vai "estourar" pedidos por erro de pauta
|
||||
|
||||
### Current solution
|
||||
- Desktop JCS legado (cadastros e pautas)
|
||||
- Excel (planilhas de import/conferência)
|
||||
- Pede pro dev (JCS ou interno) quando precisa de algo não-coberto pela tela
|
||||
- Documentos PDF da legislação ICMS-ST sempre abertos
|
||||
|
||||
### O que ela precisa do SAR
|
||||
1. **Cadastro de produto rápido** (form inteligente, validação por contexto)
|
||||
2. **Pauta de preço com versionamento** — saber o que mudou, quando, por quem
|
||||
3. **Editor de campanhas/promoções no-code** (não SQL): "Produto X com 15% off para clientes da região Y durante o mês Z"
|
||||
4. **Assistente de tributação** (ICMS-ST/IPI) — sugere grupo correto baseado em NCM + UF de destino
|
||||
5. **Gestão de representantes** — cadastro, região de atuação, hierarquia (rep → supervisor), comissão
|
||||
6. **Auditoria** — quem mexeu em quê, quando, conseguir reverter
|
||||
7. **Bulk operations** — import CSV, edição em lote
|
||||
|
||||
### Implicações de design
|
||||
- **Desktop-only** (sem investimento mobile prioritário)
|
||||
- **Dense forms** com assistentes — não wizards de 10 passos
|
||||
- **Confirmação para operações destrutivas** (alterar pauta de 500 produtos exige double-check)
|
||||
- **Trilha de auditoria visível** (histórico em cada entidade)
|
||||
- **Editor visual de campanhas** — possível diferencial sobre concorrentes que exigem SQL/script
|
||||
|
||||
---
|
||||
|
||||
## Comparativo executivo
|
||||
|
||||
| Persona | Device | Volume de uso | Frequência | Frustração #1 | Goal #1 |
|
||||
|---|---|---|---|---|---|
|
||||
| Rafael (Rep) | **Mobile-first** | 70-90% | Várias vezes ao dia | Cliente esfria sem ele saber | Bater meta |
|
||||
| Sandra (Supervisora) | Desktop-first + mobile | 5-15% | Várias vezes ao dia | Reps "somem" no campo | Time bate meta + dormir tranquila |
|
||||
| Daniel (Dono) | Desktop/iPad | 1-5% | Diário/semanal | Recebe passado, não próximo passo | Dirigir sem operar |
|
||||
| Alice (Admin) | Desktop-only | 1-5% | Diário (em ondas) | Promoção exige pedir pro dev | Lançar campanha sozinha |
|
||||
|
||||
---
|
||||
|
||||
## Buyer × User mapping (atualização do business-customers.md)
|
||||
|
||||
| Papel na compra | User persona overlap |
|
||||
|---|---|
|
||||
| **Decisor (Dono)** | Daniel (alto overlap — buyer = user em PME pequena) |
|
||||
| **Decisor (Diretor comercial)** | Sandra (em PME média, diretor comercial é a Sandra subindo na hierarquia) |
|
||||
| **Influenciador-chave** | Sandra (sempre) + Rafael (champion interno se já conheceu) |
|
||||
| **Ausente** | Alice (não pesa na decisão; só usa depois de comprado) |
|
||||
|
||||
**Insight de venda:** a **demo precisa brilhar para Sandra** (influenciadora), **vender para Daniel** (decisor), e **encantar Rafael** (champion). Alice é benefício mostrado, não argumento de venda.
|
||||
|
||||
---
|
||||
|
||||
## Implicações para Phase 2 (Trigger Map)
|
||||
|
||||
As 4 personas viram base para os "Target Groups" do Trigger Map. Cada uma terá:
|
||||
- Alliterative persona name confirmado: Rafael Representante / Sandra Supervisora / Daniel Dono / Alice Admin
|
||||
- Driving forces positivas + negativas
|
||||
- Frequency × Intensity × Fit scoring
|
||||
- Feature impact mapping
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Cena visceral / dia típico com dialogo real (Phase 2)
|
||||
- Sub-segmentação dentro de Rafael (rep de distribuidora vs rep de indústria — pode ter dores distintas)
|
||||
- Mapa empático completo (Phase 2 Trigger Map)
|
||||
131
design-artifacts/A-Product-Brief/dialog/tone-of-voice.md
Normal file
131
design-artifacts/A-Product-Brief/dialog/tone-of-voice.md
Normal file
@@ -0,0 +1,131 @@
|
||||
# Tone of Voice — SAR (Força de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 11 — Tone of Voice
|
||||
|
||||
> Tom de voz para **microcopy de UI** (botões, labels, erros, estados, notificações). Conteúdo estratégico (headlines, value propositions) será definido em Phase 1 Block B (Content & Language).
|
||||
|
||||
---
|
||||
|
||||
## 5 atributos canônicos
|
||||
|
||||
| # | Atributo | Por quê |
|
||||
|---|---|---|
|
||||
| **1** | **Direto** | Rafael precisa de info em 2 segundos no celular; Sandra decide num clique. Floreio mata fluxo. |
|
||||
| **2** | **Profissional sem ser frio** | B2B BR respeita formalidade, mas burocratês mata vendas. Sério mas humano. |
|
||||
| **3** | **Confiante** | SAR é ferramenta de trabalho, não conselheiro tímido. Afirmação > tentativa. |
|
||||
| **4** | **Específico** | "3 clientes pararam de comprar há 60+ dias" > "Há alertas". Números/dados criam confiança imediata. |
|
||||
| **5** | **Empático nos momentos difíceis** | Quando algo dá errado, explica o problema E o caminho, sem culpar o usuário. |
|
||||
|
||||
---
|
||||
|
||||
## Variações por cockpit (mesmos atributos, registros diferentes)
|
||||
|
||||
| Cockpit | Registro | Exemplo |
|
||||
|---|---|---|
|
||||
| **🟢 Rafael (Rep)** | Mais informal, frases curtas, foco em ação | "Sem sinal. Envio depois." · "Meta de junho: faltam R$ 12.400." |
|
||||
| **🟡 Sandra (Supervisora)** | Direto + decisivo, contexto rápido | "3 aprovações pendentes." · "Rep João sem visita há 2 dias." |
|
||||
| **🔵 Daniel (Dono)** | Executivo, focado em insight | "Faturamento em junho: +18% vs maio. Liderado por OPENFRIOS." |
|
||||
| **🟣 Alice (Admin)** | Técnico-preciso, mas humano | "Pauta atualizada. 1.247 produtos afetados." |
|
||||
|
||||
---
|
||||
|
||||
## Exemplos canônicos
|
||||
|
||||
### Botões
|
||||
|
||||
| Ação | ❌ Burocrata | ✅ SAR |
|
||||
|---|---|---|
|
||||
| Salvar | "Confirmar Operação" | **Salvar** |
|
||||
| Enviar pedido | "Submeter para Aprovação" | **Enviar pedido** |
|
||||
| Cancelar | "Desistir da Operação" | **Cancelar** |
|
||||
| Pedir desconto | "Solicitar Aprovação de Desconto" | **Pedir desconto** |
|
||||
|
||||
### Estados vazios
|
||||
|
||||
| Tela | ❌ Genérico | ❌ Forçado | ✅ SAR |
|
||||
|---|---|---|---|
|
||||
| Funil sem propostas | "Nenhum registro encontrado" | "Ops, vazio!" | "Sem propostas em andamento. Cadastre a primeira em **Nova proposta**." |
|
||||
| Inativos zerado | "Nenhum cliente com restrição" | "Tudo certo!" | "Nenhum cliente inativo nos últimos 60 dias." |
|
||||
| Sem pedidos hoje | "Não há registros" | "Hoje não rolou nada" | "Nenhum pedido lançado hoje. Bom dia para mudar isso." |
|
||||
|
||||
### Erros / problemas
|
||||
|
||||
| Situação | ❌ Burocrata | ✅ SAR |
|
||||
|---|---|---|
|
||||
| Sem sinal ao salvar | "ERRO: Falha de conexão" | "Sem sinal. Seu pedido fica salvo aqui e envia quando você se conectar." |
|
||||
| Cliente bloqueado | "O sistema identificou que o cliente apresenta restrição que impede a continuidade." | "Cliente **OPENFRIOS** está bloqueado: limite de crédito estourado. Peça liberação ao supervisor ou ajuste o valor." |
|
||||
| Senha errada | "Credenciais inválidas" | "Senha incorreta. Tente de novo ou **recupere sua senha**." |
|
||||
| Desconto além da alçada | "Operação não permitida" | "Esse desconto precisa de aprovação do supervisor. Quer enviar agora?" |
|
||||
|
||||
### Confirmações e notificações
|
||||
|
||||
| Evento | ❌ Vago | ✅ SAR |
|
||||
|---|---|---|
|
||||
| Pedido aprovado | "Operação concluída com sucesso" | "Pedido #1234 aprovado pela Sandra." |
|
||||
| Cliente esfriando | "Atenção necessária" | "**OPENFRIOS** não compra há 47 dias. Visite ou ligue." |
|
||||
| IA insight (Daniel) | "Análise disponível" | "Você aprovou 3 descontos acima de 10% essa semana, todos para OPENFRIOS. Reavaliar tabela?" |
|
||||
|
||||
### Loading states
|
||||
|
||||
| ❌ Genérico | ✅ SAR |
|
||||
|---|---|
|
||||
| "Carregando..." | "Carregando catálogo (8.234 produtos)..." |
|
||||
| "Aguarde" | "Sincronizando pedidos do dia..." |
|
||||
| "Processing..." | "Enviando pedido..." |
|
||||
|
||||
---
|
||||
|
||||
## Do's & Don'ts
|
||||
|
||||
### ✅ Do's
|
||||
- **Voz ativa:** "Sandra aprovou", não "Foi aprovado por Sandra"
|
||||
- **pt-BR coloquial profissional:** "Salvar", "Editar", "Excluir" (não "Salve", "Edite")
|
||||
- **Dados específicos** sempre que possível
|
||||
- **Problema E caminho** para resolver (não só o que deu errado)
|
||||
- **Nomes reais** quando aplicável (`OPENFRIOS`, `Rafael`, `Sandra`) — humaniza
|
||||
|
||||
### ❌ Don'ts
|
||||
- ❌ Emoji em texto de produção. Brand é clean Apple-inspired.
|
||||
- ❌ Caps lock para erros
|
||||
- ❌ Burocratês ("operação", "registro", "sistema", "movimentação", "documento")
|
||||
- ❌ "Por favor" e "obrigado" excessivos
|
||||
- ❌ Trocadilhos, gírias regionais, jokes (produto é multi-empresa/multi-região)
|
||||
- ❌ Anglicismos onde tem pt-BR claro (Submit → Enviar; Loading → Carregando)
|
||||
- ❌ Frases dúbias ou condicionais ("Talvez", "Possivelmente", "Acreditamos que...")
|
||||
|
||||
---
|
||||
|
||||
## Vocabulário canônico (entra no Design System)
|
||||
|
||||
Termos consistentes no produto inteiro. **Padrão único** — nunca sinônimos.
|
||||
|
||||
| Termo | Escolha canônica | Não usar |
|
||||
|---|---|---|
|
||||
| Pessoa que compra do cliente do SAR | **Cliente** | "Comprador", "consumidor", "shopper" |
|
||||
| Pessoa que vende (Rafael) | **Representante** ou **Rep** | "Vendedor", "promotor", "agente" |
|
||||
| Documento de venda em negociação | **Orçamento** | "Cotação", "proposta orçamentária" |
|
||||
| Documento de venda confirmado | **Pedido** | "Ordem de compra", "ordem de venda" |
|
||||
| Documento de venda concluído | **Faturado** | "Finalizado", "concluído", "fechado" |
|
||||
| Saída para visitar cliente | **Visita** | "Atendimento", "round" |
|
||||
| Carteira ativa do rep | **Carteira** | "Base de clientes", "lista" |
|
||||
| Cliente que parou de comprar | **Inativo** | "Frio", "perdido", "stand-by" |
|
||||
| Painel inicial | **Painel** | "Dashboard", "tela inicial" |
|
||||
| Aprovação de desconto | **Aprovação** | "Autorização", "validação", "endosso" |
|
||||
|
||||
---
|
||||
|
||||
## Implicações
|
||||
|
||||
1. **Vocabulário vira tokens i18n** — entrar no projeto como constantes em `libs/shared/api-interface` ou similar. Termos centralizados, não strings espalhadas.
|
||||
2. **Tom de voz vai no Design System (Phase 6)** como documento de referência para todos que escrevem microcopy.
|
||||
3. **PRs com microcopy** devem verificar contra este documento; eventual lint customizado pode detectar termos proibidos.
|
||||
4. **Atributos guiam decisões de IA generativa** quando IA escrever texto (alertas do Daniel, sugestões da Alice). Prompt da IA inclui esses 5 atributos + vocabulário canônico.
|
||||
|
||||
---
|
||||
|
||||
## Lacunas conscientemente adiadas
|
||||
|
||||
- Conteúdo estratégico (headlines, value propositions do site) — Steps 13-18 (Block B Content & Language)
|
||||
- Tom para emails transacionais (confirmação de pedido para cliente final) — Step 15
|
||||
- Tom para WhatsApp programático (mensagem ao cliente do cliente) — Step 15 ou 29
|
||||
67
design-artifacts/A-Product-Brief/dialog/vision.md
Normal file
67
design-artifacts/A-Product-Brief/dialog/vision.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# Vision — SAR (Force de Vendas)
|
||||
|
||||
**Confirmed:** 2026-05-26
|
||||
**Step:** 02 — Vision
|
||||
**Synthesized by:** Saga (BA) from Julian's exploratory answers
|
||||
|
||||
---
|
||||
|
||||
## Vision Statement
|
||||
|
||||
> **SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.**
|
||||
|
||||
---
|
||||
|
||||
## Três experiências distintas no mesmo produto
|
||||
|
||||
### Representante — "clareza total da minha carteira"
|
||||
- Sabe a cada momento: **quanto** vender, **pra quem**, **status** de cada pedido
|
||||
- **Metas expostas e atingíveis** (não escondidas em relatórios)
|
||||
- **WhatsApp nativo** integrado: conversa com cliente + aquecimento de leads sem sair do SAR
|
||||
- **Inteligência de carteira**: lista de inativos, ciclo de vendas por cliente, oportunidades
|
||||
|
||||
### Supervisor — "telas que apertam parafusos todos os dias"
|
||||
- Não é "dashboard contemplativo" — é **instrumento de ação diária**
|
||||
- Vê onde o time precisa de empurrão, libera/bloqueia, ajusta rotas
|
||||
- Decide rápido, com dados na frente
|
||||
|
||||
### Dono / Diretor — "gerencia só com análise e IA"
|
||||
- Sai da operação. Não acompanha pedido a pedido.
|
||||
- **IA dá dicas** — onde a empresa sangra, onde cresce, onde investir
|
||||
- Camada estratégica, não operacional
|
||||
|
||||
---
|
||||
|
||||
## Para a JCS Sistemas (perspectiva de negócio)
|
||||
|
||||
> **A primeira plataforma SaaS web da JCS** — produto distribuível, não software empacotado.
|
||||
|
||||
Salto qualitativo sobre Android+Desktop:
|
||||
- **Distribuição instantânea** (onboarding sem instalação)
|
||||
- **SaaS multi-tenant** (vende para N empresas com o mesmo produto)
|
||||
- **Vitrine de modernidade** (abre porta para próximos produtos JCS na nova stack)
|
||||
|
||||
---
|
||||
|
||||
## Diferenciais explícitos (entrada para Step 3 — Positioning)
|
||||
|
||||
1. **Inteligência de carteira ativa**: estatísticas de inativos, ciclo de vendas, radar de oportunidades
|
||||
2. **WhatsApp como canal nativo** (não anexo): conversa + aquecimento de lead
|
||||
3. **Metas como gamificação operacional**: expostas, atingíveis, ao alcance do rep
|
||||
4. **Camadas distintas por papel**: cada papel vê o que precisa, no formato que precisa decidir
|
||||
5. **IA estratégica para o dono** (não IA decorativa)
|
||||
6. **Web-first / SaaS distribuível** (vs. legado Android+Desktop instalável)
|
||||
|
||||
---
|
||||
|
||||
## Origem (citações do PO)
|
||||
|
||||
> "Quero que ele [cliente recomendando] fale que é a melhor plataforma de força de vendas, porque ela traz estatísticas de clientes inativos, ciclo de vendas dos cliente, API com WhatsApp para conversa e mensagem de aquecimento de lead. Cada representante sabe quanto, pra quem e status dos pedidos, tem suas metas expostas e prontas para atingir, supervisores com telas que tomam decisões apertam parafusos todos os dias e o dono que gerencia somente com análise e IA dando dicas."
|
||||
|
||||
> "Questão de entregar sistemas web para nossos clientes. E fácil instalação e distribuição do produto."
|
||||
|
||||
---
|
||||
|
||||
## Lacuna documentada
|
||||
|
||||
Pergunta 1 ("cena concreta de um dia típico vivido") ficou em aberto — substância suficiente emergiu das respostas de 2 e 3, mas o **dia-a-dia visceral** (clima, sentimento, tensões) será detalhado na Phase 2 (Trigger Map), quando aprofundarmos personas.
|
||||
217
design-artifacts/B-Trigger-Map/00-trigger-map.md
Normal file
217
design-artifacts/B-Trigger-Map/00-trigger-map.md
Normal file
@@ -0,0 +1,217 @@
|
||||
# Trigger Map: SAR — Força de Vendas
|
||||
|
||||
**Phase:** 2 — Trigger Mapping ✅ COMPLETO
|
||||
**Created:** 2026-05-27
|
||||
**Method:** Effect Mapping (Mijo Balic & Ingrid Domingues) adaptado por WDS
|
||||
**Agent:** Saga · Mode: Dream (autonomous + final review)
|
||||
|
||||
> Conecta **business goals → personas → driving forces → features**. Esta é a North Star estratégica que orienta toda decisão de design e priorização nas próximas fases (PRD, UX Specs, Dev).
|
||||
|
||||
---
|
||||
|
||||
## Documentos deste bloco
|
||||
|
||||
| Arquivo | Conteúdo |
|
||||
|---|---|
|
||||
| **`00-trigger-map.md`** (este) | Hub + mermaid diagram + síntese |
|
||||
| `01-business-goals.md` | 5 business goals refinados do Brief |
|
||||
| `personas/02-rafael-representante.md` | PRIMARY — mobile-first, 70-90% volume |
|
||||
| `personas/03-sandra-supervisora.md` | SECONDARY alto impacto — influenciadora compra |
|
||||
| `personas/04-daniel-dono.md` | SECONDARY alto valor — IA, buyer overlap |
|
||||
| `personas/05-alice-admin.md` | TERTIARY operacional — campanhas, pautas |
|
||||
| `06-feature-impact-analysis.md` | Matrix Features × Forças × Personas → priorização MVP |
|
||||
|
||||
---
|
||||
|
||||
## North Star
|
||||
|
||||
> **Tornar a JCS Sistemas referência em SaaS de força de vendas no mercado B2B brasileiro através do SAR — posicionando a empresa além da base atual de clientes, com produto moderno, multi-tenant e referenciável.**
|
||||
|
||||
---
|
||||
|
||||
## Mapa Goals → Personas → Forces (mermaid)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
NS[North Star<br/>JCS referência em SaaS<br/>força de vendas BR]
|
||||
|
||||
BG1[BG-1 PMF MVP<br/>1º cliente renova em 3m]
|
||||
BG2[BG-2 Base referenciável Y1<br/>10-20 clientes pagantes]
|
||||
BG3[BG-3 Modernidade visual<br/>setor medíocre, espaço aberto]
|
||||
BG4[BG-4 Coexistência ERPs<br/>não migração]
|
||||
BG5[BG-5 Fundação para escala<br/>débito técnico zero]
|
||||
|
||||
NS --> BG1
|
||||
NS --> BG2
|
||||
NS --> BG3
|
||||
NS --> BG4
|
||||
NS --> BG5
|
||||
|
||||
BG1 --> Rafael
|
||||
BG1 --> Sandra
|
||||
BG2 --> Daniel
|
||||
BG3 --> Mercado[Mercado externo<br/>concorrentes, observadores]
|
||||
BG4 --> Daniel
|
||||
BG5 --> Julian[Julian + futuros devs]
|
||||
|
||||
Rafael[🟢 Rafael Representante<br/>PRIMARY · 70-90% volume<br/>mobile-first PWA iOS]
|
||||
Sandra[🟡 Sandra Supervisora<br/>SECONDARY · influenciadora compra<br/>desktop + mobile-light]
|
||||
Daniel[🔵 Daniel Dono<br/>SECONDARY · IA + buyer<br/>desktop + iPad first-class]
|
||||
Alice[🟣 Alice Admin<br/>TERTIARY · operacional<br/>desktop-only]
|
||||
|
||||
Rafael --> RForces[Top forces:<br/>R+1 Bater meta · R+2 Clareza carteira<br/>R-4 Comissão mistério · R-5 Lentidão 3G<br/>R-3 Perder pedido P0]
|
||||
Sandra --> SForces[Top forces:<br/>S+2 Visibilidade tempo real<br/>S-1 Descobrir tarde · S-2 Aprovação WhatsApp<br/>S-3 Refém planilhas · S-4 Cliente top esfriando]
|
||||
Daniel --> DForces[Top forces:<br/>D+1 Insight estratégico · D+2 Dirigir sem operar<br/>D+4 IA segundo cérebro · D-1 Decidir no escuro<br/>D-6 IA black-box]
|
||||
Alice --> AForces[Top forces:<br/>A+1 Autonomia sem dev · A+3 Confiança produção<br/>A+4 Trilha auditoria · A-3 ICMS-ST labirinto]
|
||||
|
||||
RForces --> Features
|
||||
SForces --> Features
|
||||
DForces --> Features
|
||||
AForces --> Features
|
||||
|
||||
Features[Features pilares MVP<br/>Lançamento offline · Real-time · Visão 360°<br/>Comissão tempo real · Inativos · WhatsApp notif<br/>Fila aprovações · Watchlist · Pauta versionada]
|
||||
|
||||
classDef goal fill:#e6eff8,stroke:#004a99,stroke-width:2px,color:#004a99
|
||||
classDef persona fill:#fff,stroke:#004a99,stroke-width:2px
|
||||
classDef forces fill:#f4f7fa,stroke:#718096,stroke-width:1px
|
||||
classDef features fill:#e6eff8,stroke:#004a99,stroke-width:3px,color:#004a99,font-weight:bold
|
||||
|
||||
class NS,BG1,BG2,BG3,BG4,BG5 goal
|
||||
class Rafael,Sandra,Daniel,Alice,Mercado,Julian persona
|
||||
class RForces,SForces,DForces,AForces forces
|
||||
class Features features
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5 Business Goals (resumo)
|
||||
|
||||
| # | Goal | Outcome | Métrica north-star |
|
||||
|---|---|---|---|
|
||||
| **BG-1** | PMF do MVP | 1º cliente paga + renova em 3m | Renovação mês 3 = 100% |
|
||||
| **BG-2** | Base referenciável Y1 | 10-20 clientes + cases públicos | ARR R$ 200k-600k · NPS donos > 50 |
|
||||
| **BG-3** | Modernidade visual | SAR vira exemplo no setor | Menções orgânicas + top 5 SEO |
|
||||
| **BG-4** | Coexistência com ERPs | Não migração, integração | 30-40% clientes com integração ERP ativa |
|
||||
| **BG-5** | Fundação para escala | 0 débito técnico crítico | Coverage 70/25/5 · 0 pedidos perdidos |
|
||||
|
||||
---
|
||||
|
||||
## 4 Personas (resumo)
|
||||
|
||||
| Persona | Prioridade | Device | Top force positiva | Top force negativa |
|
||||
|---|---|---|---|---|
|
||||
| 🟢 **Rafael Representante** | PRIMARY (MVP) | Mobile-first PWA iOS | R+1 Bater meta (5/5/5) · R+2 Clareza carteira | R-3 Perder pedido (P0) · R-4 Comissão mistério |
|
||||
| 🟡 **Sandra Supervisora** | SECONDARY (alto impacto) | Desktop + mobile-light | S+2 Visibilidade tempo real (5/5/5) | S-1 Descobrir tarde demais · S-2 Aprovação WhatsApp |
|
||||
| 🔵 **Daniel Dono** | SECONDARY (alto valor) | Desktop + iPad first-class | D+1 Insight estratégico · D+4 IA segundo cérebro | D-1 Decidir no escuro · D-6 IA black-box |
|
||||
| 🟣 **Alice Admin** | TERTIARY (operacional) | Desktop-only | A+1 Autonomia sem dev (5/5/5) | A-3 ICMS-ST labirinto · A-2 Erro em produção |
|
||||
|
||||
---
|
||||
|
||||
## Forças cruzadas (alta prioridade — atendem 2+ personas)
|
||||
|
||||
| Force compartilhada | Personas | Feature pilar |
|
||||
|---|---|---|
|
||||
| "Cliente top esfria sem ver" | Rafael (R-1) · Sandra (S-4) · Daniel (D-4) | **Alerta IA de inativos + Watchlist** |
|
||||
| "Tempo real do que está na rua" | Rafael (R+2) · Sandra (S+2) · Daniel (D-1) | **Real-time entre cockpits (Socket.IO)** |
|
||||
| "Aprovação fora de WhatsApp informal" | Rafael (R-6) · Sandra (S-2) | **Fila de aprovações in-app + push** |
|
||||
| "Confiança em dados/auditoria" | Daniel (D-1) · Alice (A+4) · Sandra (S-5) | **Auditoria em cada entidade + versionamento de pautas** |
|
||||
| "Não depender de dev/escritório" | Rafael (R+4) · Alice (A+1) | **Autonomia operacional** (alçada local + editor no-code futuro) |
|
||||
| "Visibilidade decisória, não passiva" | Sandra (S+3) · Daniel (D+1) | **IA explicável com dado anexo** |
|
||||
|
||||
---
|
||||
|
||||
## Tensões críticas resolvidas no design
|
||||
|
||||
| Tensão | Resolução |
|
||||
|---|---|
|
||||
| R-7 (Rafael vigia) ↔ S+6 (Sandra ver talento) | SAR mostra **outputs**, não inputs punitivos. Sem geofencing contínuo, sem % tela ativa pública. |
|
||||
| D+4 (Daniel IA) ↔ D-6 (Daniel anti-black-box) | **IA explicável obrigatória** — cada insight tem "por que te digo isso" + dado anexo. |
|
||||
| Sandra ops do dia ↔ Daniel estratégico do período | Cockpits separados desde dia 1 (RBAC por papel) — mesma fonte, camadas qualitativamente diferentes. |
|
||||
| Concept ambicioso ↔ Solo founder MVP 3-4m | **MVP minimalista** — Rafael+Sandra completos, Daniel+Alice simplificados, **IA estratégica e editor no-code entram pós-MVP**. |
|
||||
|
||||
---
|
||||
|
||||
## Priorização final do MVP
|
||||
|
||||
### 🔴 P0 (absolutos — produto não roda sem)
|
||||
- Lançamento offline com sync (PWA + IndexedDB queue + Idempotency-Key)
|
||||
- Multi-tenancy BD-por-workspace
|
||||
- Auth + RBAC por cockpit
|
||||
- Real-time entre cockpits (Socket.IO)
|
||||
- **0 pedidos perdidos por bug**
|
||||
|
||||
### 🟢 MVP core
|
||||
- Visão 360° do cliente
|
||||
- Lançamento de pedido < 60s mobile
|
||||
- Comissão visível em tempo real
|
||||
- Funil de propostas
|
||||
- Alertas de inativos
|
||||
- Agenda + check-in GPS
|
||||
- WhatsApp notif outbound
|
||||
- Fila de aprovações com contexto
|
||||
- Dashboard "tela do dia" Sandra
|
||||
- Dashboard executivo Daniel **simplificado** (sem IA)
|
||||
- Watchlist clientes-chave
|
||||
- Cadastros completos (produto/cliente/rep)
|
||||
- Pauta com versionamento
|
||||
- ICMS-ST manual por UF
|
||||
- Auditoria em cada entidade
|
||||
- Limite de crédito + bloqueio automático
|
||||
|
||||
### 🟡 MVP-light (existe mas sem brilho — completar pós-MVP)
|
||||
- Dashboard Daniel **sem IA estratégica** (entra pós-MVP)
|
||||
- Tela direta de promoção 1 a 1 (editor visual no-code pós-MVP)
|
||||
- ICMS-ST manual (assistente IA pós-MVP)
|
||||
- WhatsApp apenas outbound (conversa bidirecional pós-MVP)
|
||||
- Bulk operations básico (edit em massa pós-MVP)
|
||||
|
||||
### ⚪ Pós-MVP / Y1+
|
||||
- IA estratégica explicável (DIFERENCIAL DECLARADO — fundamental para Daniel)
|
||||
- Editor de campanhas no-code (DIFERENCIAL DECLARADO — fundamental para Alice)
|
||||
- Conversa bidirecional WhatsApp + aquecimento de lead
|
||||
- Assistente ICMS-ST por NCM+UF
|
||||
- Comparativo período + análise de concentração
|
||||
- Programa de indicação
|
||||
- Adaptação app Android legado
|
||||
- Native iOS/Android sobre backend SAR
|
||||
|
||||
---
|
||||
|
||||
## Quality checklist (Self-review Layer 5 — Dream mode)
|
||||
|
||||
- [x] Personas com naming aliterativo (Rafael Representante, Sandra Supervisora, Daniel Dono, Alice Admin)
|
||||
- [x] Cada persona tem 5-7 driving forces (mix positivo+negativo)
|
||||
- [x] Forces scored Frequency × Intensity × Fit
|
||||
- [x] Top scores destacados por persona
|
||||
- [x] Feature Impact mapeia features → forças → personas
|
||||
- [x] Mermaid diagram conecta Goals → Personas → Forces → Features
|
||||
- [x] Tensões críticas explicitadas e resolvidas
|
||||
- [x] Priorização MVP clara (P0 / core / light / pós-MVP)
|
||||
- [x] Trace: cada decision tem origem em Phase 1 (Brief)
|
||||
- [x] Anti-padrões documentados por persona
|
||||
|
||||
---
|
||||
|
||||
## Como esse documento é consumido
|
||||
|
||||
| Fase | Como usa |
|
||||
|---|---|
|
||||
| **Phase 3 (PRD)** | Feature Impact Analysis vira backlog priorizado · driving forces viram acceptance criteria |
|
||||
| **Phase 4 (UX Specs)** | Personas + driving forces guiam cada page spec ("qual force essa tela resolve?") |
|
||||
| **Phase 5 (Dev)** | Tensões e anti-padrões viram code review checklist · P0 vira teste de regressão obrigatório |
|
||||
| **Phase 6 (Design System)** | Variantes por cockpit baseadas em personas |
|
||||
| **Sales & Marketing** | Buyer persona "Dono Empresário B2B" guia demo · tensões viram material de objection handling |
|
||||
|
||||
---
|
||||
|
||||
## Próximo passo
|
||||
|
||||
**Phase 3 — Scenarios / PRD** (escolher conforme stack metodológica)
|
||||
|
||||
Output esperado em `design-artifacts/C-UX-Scenarios/`: scenarios outline (jornadas dos usuários) + posteriormente page specifications detalhadas.
|
||||
|
||||
Tempo estimado: 2-4h.
|
||||
|
||||
---
|
||||
|
||||
_Trigger Map gerado em Dream mode (autonomous) em 2026-05-27. Self-review aprovado. Pronto para Phase 3._
|
||||
139
design-artifacts/B-Trigger-Map/01-business-goals.md
Normal file
139
design-artifacts/B-Trigger-Map/01-business-goals.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Business Goals — SAR (Phase 2: Trigger Mapping)
|
||||
|
||||
**Created:** 2026-05-27
|
||||
**Phase:** 2 — Trigger Mapping (Workshop 1: Business Goals)
|
||||
**Source:** refinado de `01-product-brief.md` Steps 1a (Internal Driver), 3 (Positioning), 8 (Success Criteria)
|
||||
|
||||
> Goals refinados do brief, traduzidos em **outcomes mensuráveis** que alimentam o mapa Goals → Personas → Forces → Features.
|
||||
|
||||
---
|
||||
|
||||
## North Star
|
||||
|
||||
> **Tornar a JCS Sistemas referência em SaaS de força de vendas no mercado B2B brasileiro através do SAR — posicionando a empresa além da base atual de clientes, com produto moderno, multi-tenant e referenciável.**
|
||||
|
||||
Esta é a North Star de **negócio JCS** (não do produto SAR). O sucesso do SAR alimenta a percepção da JCS como SaaS-maker moderno.
|
||||
|
||||
---
|
||||
|
||||
## 5 Business Goals canônicos
|
||||
|
||||
### 🎯 BG-1: Validar Product-Market Fit no MVP
|
||||
|
||||
**Outcome esperado:**
|
||||
> 1º cliente real paga e renova sem cancelar nos primeiros 3 meses pós go-live.
|
||||
|
||||
**Métricas:**
|
||||
- Conversão de trial → contrato pago: **≥ 80%** (vai ser parceiro próximo no MVP)
|
||||
- Renovação 3 meses: **100%** (1 cliente, não pode falhar)
|
||||
- NPS do dono do 1º cliente: **> 50**
|
||||
- DAU/MAU dos reps: **> 70%** após 30 dias de uso
|
||||
|
||||
**Por quê importa:** sem PMF provado, escalar é multiplicar dúvida. Renovação > tração.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 BG-2: Construir base referenciável Y1
|
||||
|
||||
**Outcome esperado:**
|
||||
> 10-20 clientes pagantes ao final de Y1 com permissão de uso público como case + NPS > 50.
|
||||
|
||||
**Métricas:**
|
||||
- Clientes pagantes: **10 (conservador) a 20 (esticado)** em 12 meses
|
||||
- ARR Y1: **R$ 200k-600k**
|
||||
- Logo churn mensal: **< 3%**
|
||||
- Cases publicados: **≥ 3** com permissão e mídia
|
||||
- Indicações geradas por cliente atual: **≥ 1 lead qualificado/cliente/trimestre**
|
||||
|
||||
**Por quê importa:** referenciabilidade alimenta canal #1 (boca-a-boca). Sem cases públicos, JCS depende de SEO/feiras sozinhos.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 BG-3: Estabelecer SAR como referência de modernidade no setor
|
||||
|
||||
**Outcome esperado:**
|
||||
> Quando alguém do setor (concorrente, parceiro, cliente potencial) pensar em "como deveria ser um SaaS de força de vendas hoje", o SAR é o exemplo.
|
||||
|
||||
**Métricas:**
|
||||
- Menções orgânicas em comunidades B2B BR (LinkedIn, fóruns de varejo, eventos)
|
||||
- Posicionamento SEO em top 5 para keywords primárias (`software de força de vendas`, `alternativa ao Mercos`)
|
||||
- Velocidade de iteração visível (changelog público, releases mensais pós-MVP)
|
||||
- NPS visual qualitativo (donos comentando "design moderno" nas conversas de venda)
|
||||
|
||||
**Por quê importa:** Step 19 revelou que estética moderna é diferencial **fundacional**, não cosmético. Mercado é visualmente medíocre.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 BG-4: Habilitar coexistência com ERPs existentes como porta de entrada
|
||||
|
||||
**Outcome esperado:**
|
||||
> Cliente que tem TOTVS/Sankhya/Senior compra o SAR sem precisar trocar o ERP. SAR é "camada de vendas" via API, não substituição.
|
||||
|
||||
**Métricas:**
|
||||
- % clientes Y1 vindos de "stack improvisado" (Excel+WhatsApp+ERP sem módulo): **40-50%** (segmento "primeira ferramenta de verdade")
|
||||
- % clientes Y1 com integração ERP ativa (TOTVS, Sankhya, Omie, etc.): **30-40%**
|
||||
- Tempo médio de setup de integração ERP por workspace: **< 5 dias úteis**
|
||||
|
||||
**Por quê importa:** dobra o TAM imediato — empresas com ERP entrincheirado eram leads frios; viram quentes. Multi-tenant BD-por-workspace facilita arquiteturalmente.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 BG-5: Construir fundação para escala pós-MVP
|
||||
|
||||
**Outcome esperado:**
|
||||
> Quando 1º cliente renovar (north star MVP atingida), JCS está pronta para contratar 1-2 devs e escalar sem refatorar tudo.
|
||||
|
||||
**Métricas:**
|
||||
- Coverage de testes (unit + integration + e2e): **≥ 70% / 25% / 5%** (pirâmide canon STACK.md §16)
|
||||
- Observabilidade completa (OTel + Pino + Grafana + Sentry + PostHog) no MVP
|
||||
- Documentação ADR atualizada (ADRs 0001-0006 + novas conforme RFC)
|
||||
- 0 pedidos perdidos por bug ou sync (P0 sempre)
|
||||
- Onboarding de novo dev < 5 dias até primeira PR mergeada
|
||||
|
||||
**Por quê importa:** evitar técnica debt fundacional. Solo founder mode é phase, não destino.
|
||||
|
||||
---
|
||||
|
||||
## Hierarquia e relações entre os 5 goals
|
||||
|
||||
```
|
||||
BG-1 PMF do MVP (3 meses)
|
||||
│
|
||||
▼
|
||||
BG-2 Base referenciável Y1
|
||||
┌─────┴─────┐
|
||||
▼ ▼
|
||||
BG-3 Marca BG-4 Coexistência ERPs
|
||||
↓ ↓
|
||||
└──── BG-5 Fundação para escala ────┘
|
||||
```
|
||||
|
||||
- **BG-1 é precondição** para BG-2 e tudo que vem depois
|
||||
- **BG-3 (marca) e BG-4 (ERPs) são paralelos** — alimentam BG-2
|
||||
- **BG-5 (fundação técnica) viabiliza** os 4 anteriores escalarem sem dívida
|
||||
|
||||
---
|
||||
|
||||
## Forças que vão atrás dos goals
|
||||
|
||||
Cada business goal precisa de **comportamento humano** que o realize. Phase 2 vai mapear isso:
|
||||
|
||||
| Business Goal | Pessoa que precisa agir | Comportamento esperado |
|
||||
|---|---|---|
|
||||
| BG-1 PMF | Rafael + Sandra do 1º cliente | Usar diariamente; preferir SAR sobre WhatsApp/Excel; valor percebido > preço |
|
||||
| BG-2 Referenciabilidade | Daniel (dono do cliente) | Recomendar publicamente; aceitar virar case |
|
||||
| BG-3 Marca | Mercado externo (concorrentes, observadores) | Notar diferencial visual + estrutural |
|
||||
| BG-4 Coexistência | Daniel + TI (eventual) | Aceitar integração ERP como modelo, não migração |
|
||||
| BG-5 Fundação | Julian + futuros devs JCS | Disciplina ADR/CODING-RULES; observabilidade desde dia 1 |
|
||||
|
||||
---
|
||||
|
||||
## Próximo (Workshop 2): Target Groups
|
||||
|
||||
Refinar as 4 personas em **archetypes acionáveis** com naming aliterativo:
|
||||
- **Rafael Representante** (PRIMARY)
|
||||
- **Sandra Supervisora**
|
||||
- **Daniel Dono**
|
||||
- **Alice Admin**
|
||||
|
||||
Cada persona ganha seu próprio arquivo em `personas/`.
|
||||
145
design-artifacts/B-Trigger-Map/06-feature-impact-analysis.md
Normal file
145
design-artifacts/B-Trigger-Map/06-feature-impact-analysis.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# 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
|
||||
@@ -0,0 +1,114 @@
|
||||
# Persona — Rafael Representante (PRIMARY)
|
||||
|
||||
**Phase 2 — Trigger Mapping · Workshop 2-4**
|
||||
**Status:** PRIMARY persona do MVP — 70-90% do volume de uso
|
||||
**Device-target:** Mobile-first PWA iOS (Android continua no app legado)
|
||||
|
||||
---
|
||||
|
||||
## Quem é Rafael
|
||||
|
||||
> Vendedor B2B externo, 30-50 anos, com 50-200 clientes ativos numa região definida. Comissionado — meta mensal pesa pesado na renda da família. Trabalha no carro, no posto, no escritório do cliente, no fundo da loja. **Raramente** na frente de um computador. Conhece o setor melhor que o supervisor, mas precisa de ferramenta que respeite essa expertise sem atrapalhar o fluxo.
|
||||
|
||||
### Dia típico (cenário canônico)
|
||||
|
||||
- **6h30** — café em casa, olha agenda do dia no celular ainda na cama
|
||||
- **7h30** — primeira visita; consulta histórico, comissão acumulada do mês, status de pedidos abertos
|
||||
- **9h-12h** — 3-4 visitas, alguns pedidos lançados na rua (sinal 3G/4G ruim)
|
||||
- **12h** — almoço; revisa funil de propostas, responde WhatsApp de clientes
|
||||
- **13h-17h** — mais visitas; aprovação de desconto sendo trocada no WhatsApp com Sandra
|
||||
- **17h** — para no posto, atualiza CRM, marca check-in da última visita
|
||||
- **20h** — antes de dormir, confere meta do mês e marca visitas de amanhã
|
||||
|
||||
### O que o motiva (em uma frase)
|
||||
|
||||
> **"Bater meta sem virar máquina."**
|
||||
|
||||
---
|
||||
|
||||
## Driving Forces
|
||||
|
||||
### ✅ Positive forces (motivações, aspirações)
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **R+1** | **Bater meta** | Comissão é metade do salário. Saber em tempo real quanto falta para meta é combustível diário. | 5/5 | 5/5 | 5/5 |
|
||||
| **R+2** | **Clareza absoluta da carteira** | Saber sem pensar: quanto, pra quem, status. Eliminar consulta "preciso ligar pro escritório pra confirmar". | 5/5 | 5/5 | 5/5 |
|
||||
| **R+3** | **Ser visto como profissional moderno** | Diferenciar-se de reps que ainda andam com talão de papel + WhatsApp. Trabalha com ferramenta de gente grande. | 3/5 | 4/5 | 4/5 |
|
||||
| **R+4** | **Autonomia em campo** | Não depender do escritório para decisões simples (preço dentro da alçada, agendar visita, registrar contato). | 5/5 | 4/5 | 5/5 |
|
||||
| **R+5** | **Reagir rápido ao cliente** | Cliente pediu algo no WhatsApp às 14h32, ter resposta antes de sair do estabelecimento. | 4/5 | 5/5 | 4/5 |
|
||||
|
||||
### ❌ Negative forces (medos, frustrações)
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **R-1** | **Cliente esfria e ele não vê** | Cliente top deixou de comprar há 47 dias e ele descobre tarde, perdeu o timing. | 3/5 | 5/5 | 5/5 |
|
||||
| **R-2** | **Levar bronca por algo que já sabia** | Supervisor cobra um cliente que ele "deveria ter visitado" — informação que ele dizia que estava no WhatsApp. | 4/5 | 4/5 | 4/5 |
|
||||
| **R-3** | **Perder pedido por bug ou sem sinal** | Lança pedido R$ 8 mil, sem sinal, app trava, pedido some. Crítico — esse é P0 absoluto do MVP. | 2/5 | 5/5 | 5/5 |
|
||||
| **R-4** | **Comissão é mistério até fim do mês** | Calcula em Excel próprio "pra não confiar cego". Estresse mensal evitável. | 5/5 | 4/5 | 5/5 |
|
||||
| **R-5** | **Ferramenta lenta no 3G/4G ruim** | Fica esperando tela carregar enquanto cliente espera resposta. Frustração diária. | 4/5 | 5/5 | 5/5 |
|
||||
| **R-6** | **WhatsApp informal pra tudo** | Cliente troca número de WhatsApp, anota no papel; supervisor não sabe; perde-se. | 4/5 | 3/5 | 4/5 |
|
||||
| **R-7** | **Ser substituível** | Receio existencial — se a ferramenta sabe tudo do cliente, qualquer um pode vender no lugar dele. (⚠️ tensão a respeitar — produto não pode parecer espião) | 2/5 | 4/5 | N/A (não-feature) |
|
||||
|
||||
---
|
||||
|
||||
## Score consolidado (Freq × Int × Fit)
|
||||
|
||||
Top 5 forces de Rafael (driving forces de alto impacto):
|
||||
|
||||
| Rank | Force | Score |
|
||||
|---|---|---|
|
||||
| 1 | **R+1 Bater meta** | 125 |
|
||||
| 1 | **R+2 Clareza da carteira** | 125 |
|
||||
| 3 | **R-5 Lentidão no 3G/4G ruim** | 100 |
|
||||
| 3 | **R+4 Autonomia em campo** | 100 |
|
||||
| 3 | **R-4 Comissão é mistério** | 100 |
|
||||
|
||||
---
|
||||
|
||||
## Features que respondem às forças de Rafael
|
||||
|
||||
| Force | Feature SAR que responde |
|
||||
|---|---|
|
||||
| R+1 Bater meta | **Gauge de meta em tempo real** no painel + indicador no header em qualquer tela |
|
||||
| R+2 Clareza da carteira | **Visão 360° do cliente** (timeline, histórico, contatos, pedidos, comissão por cliente) |
|
||||
| R+3 Profissional moderno | UX moderna PWA (diferencial vs concorrentes legados) |
|
||||
| R+4 Autonomia em campo | **Lançamento de pedido offline com sync** + alçada de desconto local |
|
||||
| R+5 Reagir rápido | **WhatsApp nativo no app** + Share API para encaminhar orçamento |
|
||||
| R-1 Cliente esfria | **Alerta proativo de inativos** (>60 dias) com IA ranking |
|
||||
| R-2 Levar bronca | **Timeline do cliente** mostra última visita; agenda+check-in GPS |
|
||||
| R-3 Perder pedido | **IndexedDB queue + Idempotency-Key** (offline robusto, P0 absoluto) |
|
||||
| R-4 Comissão mistério | **Comissão visível em tempo real** (calculada por pedido, FLEX rateado) |
|
||||
| R-5 Lentidão 3G | **PWA com Service Worker** + cache agressivo + lazy load |
|
||||
| R-6 WhatsApp informal | **Contatos centralizados** no cadastro de cliente + WhatsApp linkado |
|
||||
|
||||
---
|
||||
|
||||
## O que NÃO fazer (anti-padrões pra Rafael)
|
||||
|
||||
- ❌ Forçar Rafael a abrir desktop para consulta básica
|
||||
- ❌ Onboarding longo no primeiro login (carro/posto: tem 30s, não 30 min)
|
||||
- ❌ Notificações push para tudo (Rafael odeia ruído quando está com cliente)
|
||||
- ❌ Dashboards "executivos" no painel do rep — ele quer ação, não relatório
|
||||
- ❌ Gamificação ranking público (R-7 risco existencial — sem leaderboard "rep do mês")
|
||||
- ❌ Tela cheia de gráficos antes de chegar no que ele precisa fazer
|
||||
|
||||
---
|
||||
|
||||
## Métricas de adoção (entradas em Phase 3 — Success Criteria)
|
||||
|
||||
- **% pedidos lançados pelo SAR vs paralelo (WhatsApp/papel):** > 95% após 60 dias
|
||||
- **Tempo médio de lançamento de pedido:** < 60 segundos
|
||||
- **DAU/MAU:** > 70% (uso diário)
|
||||
- **NPS dos reps:** > 30 (reps são duros — 30 já é bom)
|
||||
- **Pedidos perdidos por bug/sync:** **0 (P0 absoluto)**
|
||||
|
||||
---
|
||||
|
||||
## Citações canônicas (servem de North Star em UX writing)
|
||||
|
||||
> "Sem sinal. Envio depois."
|
||||
|
||||
> "Meta de junho: faltam R$ 12.400."
|
||||
|
||||
> "OPENFRIOS não compra há 47 dias. Visite ou ligue."
|
||||
125
design-artifacts/B-Trigger-Map/personas/03-sandra-supervisora.md
Normal file
125
design-artifacts/B-Trigger-Map/personas/03-sandra-supervisora.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# Persona — Sandra Supervisora (SECONDARY — alto impacto)
|
||||
|
||||
**Phase 2 — Trigger Mapping · Workshop 2-4**
|
||||
**Status:** SECONDARY persona — 5-15% do volume de uso · INFLUENCIADORA-CHAVE da compra
|
||||
**Device-target:** Desktop-first + mobile-light (PWA para consultas/aprovações rápidas)
|
||||
|
||||
---
|
||||
|
||||
## Quem é Sandra
|
||||
|
||||
> Gerente comercial / supervisora regional, 35-55 anos. Coordena 5-30 representantes. Reporta direto para o dono ou diretor comercial. **Vive no escritório** com notebook aberto o dia todo, mas precisa de mobile-light para aprovar desconto durante reuniões/almoço. Conhece quase todos os clientes top da carteira. Foi rep antes — sabe o que é estar na rua.
|
||||
|
||||
### Dia típico
|
||||
|
||||
- **8h30** — chega ao escritório, café, abre SAR no notebook
|
||||
- **8h45-9h30** — "tela do dia": checa quem fez check-in, aprovações pendentes, alertas de inativos
|
||||
- **9h30-12h** — reuniões individuais com reps em campo (WhatsApp/áudio), libera descontos
|
||||
- **12h-13h** — almoço; ainda recebe push de aprovação no celular
|
||||
- **13h-17h** — análises, ajustes em pauta com Alice, fechamento do dia
|
||||
- **17h** — fechamento: revisa o dia, prepara plano de amanhã
|
||||
- **18h+** — eventual emergência (cliente top reclamando, pedido urgente)
|
||||
|
||||
### O que a motiva (em uma frase)
|
||||
|
||||
> **"Time bater meta sem que eu vire babá."**
|
||||
|
||||
---
|
||||
|
||||
## Driving Forces
|
||||
|
||||
### ✅ Positive forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **S+1** | **Time bate meta consistentemente** | Cobrança vem do Daniel; se time bate, ela respira. Reconhecimento profissional. | 5/5 | 5/5 | 4/5 |
|
||||
| **S+2** | **Visibilidade em tempo real do que acontece na rua** | Saber "quem visitou quem hoje" sem ligar pra ninguém. Eliminar consulta manual. | 5/5 | 5/5 | 5/5 |
|
||||
| **S+3** | **Tomar decisão tática com dados na frente** | Aprovar desconto vendo histórico, margem, comportamento do cliente. | 4/5 | 5/5 | 5/5 |
|
||||
| **S+4** | **Dormir tranquila** | Ter certeza que nada crítico passou despercebido — clientes top OK, reps OK, pedidos OK. | 4/5 | 5/5 | 4/5 |
|
||||
| **S+5** | **Ser vista como gestora moderna** | Subordinados percebem que ela usa tech de ponta — autoridade técnica. | 2/5 | 3/5 | 3/5 |
|
||||
| **S+6** | **Identificar talento e problema na equipe** | Ver quem está bombando e quem está enrolado, sem precisar perguntar. | 3/5 | 4/5 | 4/5 |
|
||||
|
||||
### ❌ Negative forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **S-1** | **Descobrir tarde demais que algo deu errado** | Cliente top bloqueado, pedido travado, rep parado há 3 dias — descobre na reunião semanal. | 4/5 | 5/5 | 5/5 |
|
||||
| **S-2** | **Aprovação de desconto vira fila no WhatsApp** | Reps mandando 10 áudios/dia pedindo R$ X de desconto, sem contexto, sem timeline. | 5/5 | 4/5 | 5/5 |
|
||||
| **S-3** | **Ficar refém de planilhas + WhatsApp** | Sair de uma ferramenta, abrir Excel, copy-paste número, voltar pro WhatsApp. Fluxo quebrado. | 5/5 | 4/5 | 5/5 |
|
||||
| **S-4** | **Perder cliente top sem saber** | Cliente importante começa a comprar menos, Sandra só percebe quando dono pergunta. Vergonha profissional. | 3/5 | 5/5 | 5/5 |
|
||||
| **S-5** | **Ser cobrada por algo que rep não relatou** | Daniel pergunta "por que perdemos OPENFRIOS?", Sandra não sabe porque rep não avisou. | 3/5 | 5/5 | 4/5 |
|
||||
| **S-6** | **Reunião semanal de 90 min que suga tempo** | Reunião viraliza porque ninguém tem dado em tempo real. Suga 1h30 produtiva. | 5/5 | 4/5 | 4/5 |
|
||||
| **S-7** | **Ser vista como Big Brother pelos reps** | Reps acharem que ela vigia demais (R-7 do Rafael, espelhada). Conflito de cultura. (⚠️ tensão a respeitar — UI dela não pode expor "rep está parado") | 3/5 | 3/5 | N/A |
|
||||
|
||||
---
|
||||
|
||||
## Score consolidado
|
||||
|
||||
Top 5 forces de Sandra:
|
||||
|
||||
| Rank | Force | Score |
|
||||
|---|---|---|
|
||||
| 1 | **S+2 Visibilidade tempo real** | 125 |
|
||||
| 2 | **S-1 Descobrir tarde demais** | 100 |
|
||||
| 2 | **S-2 Aprovação no WhatsApp** | 100 |
|
||||
| 2 | **S-3 Refém de planilhas** | 100 |
|
||||
| 2 | **S+3 Decisão tática com dados** | 100 |
|
||||
| 2 | **S-4 Perder cliente top sem saber** | 75 (3×5×5) — alto impact mesmo com freq menor |
|
||||
|
||||
---
|
||||
|
||||
## Features que respondem às forças de Sandra
|
||||
|
||||
| Force | Feature SAR que responde |
|
||||
|---|---|
|
||||
| S+1 Time bate meta | **Dashboard de meta da equipe** + comparativo entre reps |
|
||||
| S+2 Visibilidade tempo real | **Tela do dia** com check-ins, pedidos, alertas — atualização Socket.IO/SSE |
|
||||
| S+3 Decisão tática com dados | **Fila de aprovações com contexto** (cliente, margem, histórico, alçada) |
|
||||
| S+4 Dormir tranquila | **Resumo do dia / fim do expediente** com "tudo OK / N alertas" |
|
||||
| S+5 Gestora moderna | UX desktop dense + atalhos teclado (Linear-like) |
|
||||
| S+6 Identificar talento/problema | **Comparativo entre reps** (privado, só pra ela) — sem ranking público |
|
||||
| S-1 Descobrir tarde demais | **Alertas proativos** (push + in-app) — pedido travado, rep sem check-in, cliente top sem pedido |
|
||||
| S-2 Aprovação WhatsApp | **Aprovação 1-clique no SAR** com contexto completo · push notification para mobile |
|
||||
| S-3 Refém planilhas | **Tudo no SAR** + export CSV quando precisar (não importar) |
|
||||
| S-4 Cliente top esfriando | **Watchlist de clientes-chave** com alerta automático |
|
||||
| S-5 Cobrança sem dado | **Timeline de visitas + observações** (rep registra cada visita) |
|
||||
| S-6 Reunião 90 min | **Dashboard substitui parte da reunião** — menos discussão de "o que aconteceu" |
|
||||
| S-7 Big Brother | UI **não expõe rastreamento punitivo** — métricas como apoio, não controle (decisão de design importante) |
|
||||
|
||||
---
|
||||
|
||||
## O que NÃO fazer (anti-padrões pra Sandra)
|
||||
|
||||
- ❌ Tela com 30 KPIs sem hierarquia clara (Sandra precisa **decidir**, não navegar)
|
||||
- ❌ Linguagem punitiva sobre reps ("Rep X falhou", "Tempo ocioso") — fere R-7 e cria conflito interno
|
||||
- ❌ Modal de "Atenção!" para cada coisa (push fadiga)
|
||||
- ❌ Aprovação de desconto que exige sair pra outra tela
|
||||
- ❌ Relatórios em PDF — Sandra quer tela viva, não documento
|
||||
|
||||
---
|
||||
|
||||
## Tensão de design: Sandra ↔ Rafael
|
||||
|
||||
R-7 (Rafael teme ser substituível/vigiado) ↔ S+6 (Sandra quer identificar talento e problema)
|
||||
|
||||
**Resolução:** SAR mostra **dados de output** (pedidos, faturamento, % meta), não **dados de input punitivos** (tempo logado, % tela ativa, geofencing detalhado). Sandra vê quem está produzindo; não vê "rep X está parado há 47 minutos no posto de gasolina".
|
||||
|
||||
---
|
||||
|
||||
## Métricas de adoção
|
||||
|
||||
- **% aprovações via SAR (não WhatsApp):** > 90% em 60 dias
|
||||
- **% dias úteis com acesso à "tela do dia":** > 80%
|
||||
- **Tempo médio de aprovação de desconto:** < 30 min (vs horas no WhatsApp)
|
||||
- **NPS Sandra:** > 50 (gestores apreciam ferramenta boa)
|
||||
- **Push notifications ações decisivas:** taxa de leitura > 80%
|
||||
|
||||
---
|
||||
|
||||
## Citações canônicas
|
||||
|
||||
> "3 aprovações pendentes."
|
||||
|
||||
> "Rep João sem visita há 2 dias."
|
||||
|
||||
> "Tudo OK. Bom fim de semana."
|
||||
141
design-artifacts/B-Trigger-Map/personas/04-daniel-dono.md
Normal file
141
design-artifacts/B-Trigger-Map/personas/04-daniel-dono.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# Persona — Daniel Dono (SECONDARY — alto valor)
|
||||
|
||||
**Phase 2 — Trigger Mapping · Workshop 2-4**
|
||||
**Status:** SECONDARY persona — 1-5% volume · BUYER persona (overlap em PME pequena) · IA estratégica é diferencial declarado
|
||||
**Device-target:** Desktop + iPad first-class (uso noturno em casa)
|
||||
|
||||
---
|
||||
|
||||
## Quem é Daniel
|
||||
|
||||
> Sócio-fundador ou herdeiro de negócio familiar B2B, 40-65 anos. Já passou pela operação — foi rep, foi gerente — hoje dirige. Tem o caixa, decide investimentos. Gerencia "no peito" há anos; agora quer ferramenta que **substitua sua intuição parcialmente**, não que reforce essa dependência. Conhece o setor melhor que ninguém — mas reconhece que está cego em dados.
|
||||
|
||||
### Dia típico
|
||||
|
||||
- **8h** — escritório, café, abre relatórios do dia anterior (hoje no Desktop legado, futuro no SAR)
|
||||
- **8h30-10h** — reuniões com Sandra, financeiro, eventual operacional
|
||||
- **10h-12h** — agenda externa: cliente top, banco, fornecedor estratégico
|
||||
- **14h-17h** — análise + decisão estratégica + chamadas
|
||||
- **18h** — fim do expediente
|
||||
- **21h-22h** — em casa, no iPad, **abre SAR pra ver "o que tô esquecendo"** → momento crítico de uso
|
||||
|
||||
### O que o motiva (em uma frase)
|
||||
|
||||
> **"Dirigir sem operar — e nunca mais ser surpreendido pelo concorrente."**
|
||||
|
||||
---
|
||||
|
||||
## Driving Forces
|
||||
|
||||
### ✅ Positive forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **D+1** | **Insight estratégico, não relatório passivo** | Quer "olha aqui, isso aqui está sangrando" — não "veja o relatório anexo". | 4/5 | 5/5 | 5/5 |
|
||||
| **D+2** | **Dirigir sem micro-gerir** | Confiar no time + ter painel que avisa quando algo desvia. Liberdade de delegação. | 5/5 | 5/5 | 4/5 |
|
||||
| **D+3** | **Posicionamento estratégico de mercado** | Crescer market share, ganhar de concorrente, vencer feira do setor. Reconhecimento do mercado. | 3/5 | 5/5 | 3/5 |
|
||||
| **D+4** | **IA explicável que vira "segundo cérebro"** | Sentir que tem analista PhD trabalhando 24/7 olhando os dados dele — sem o custo de contratar. | 3/5 | 5/5 | 5/5 |
|
||||
| **D+5** | **Decisão de investimento com dados sólidos** | Contratar mais reps? Trocar tabela de preço? Decisão com base, não chute. | 3/5 | 5/5 | 4/5 |
|
||||
| **D+6** | **Histórico longo + tendência clara** | Comparar mês×mês, ano×ano, sazonalidade — narrativa de evolução. | 3/5 | 4/5 | 4/5 |
|
||||
|
||||
### ❌ Negative forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **D-1** | **Decidir no escuro com dado velho** | Recebe planilha de ontem, decide hoje, descobre amanhã que dado mudou. Cético com qualquer ferramenta lenta. | 4/5 | 5/5 | 5/5 |
|
||||
| **D-2** | **Ser surpreendido por concorrente** | Concorrente cresceu 20% no setor, ele não viu até ler na imprensa. Ferida narcísica. | 2/5 | 5/5 | 3/5 |
|
||||
| **D-3** | **Investir em ferramenta que não engata** | Já comprou software antes que ninguém usou. Resistência à compra de SaaS novo. (relevante na venda + retenção) | 2/5 | 5/5 | 4/5 |
|
||||
| **D-4** | **Perder cliente top em silêncio** | Top 10% da carteira responde por 50%+ do faturamento. Perder 1 cliente top = trimestre arranhado. | 3/5 | 5/5 | 5/5 |
|
||||
| **D-5** | **Reuniões longas com supervisor sem dado** | Sandra reporta "está OK", mas o dado bruto está no Excel da Sandra, não no sistema do Daniel. Frustração crônica. | 4/5 | 4/5 | 4/5 |
|
||||
| **D-6** | **IA black-box que não consegue explicar** | Receia "isso aí é só hype" se a IA não diz **por que** está alertando. Conhece o setor — quer ver lógica. | 3/5 | 5/5 | 5/5 |
|
||||
| **D-7** | **Pagar caro por algo que entrega pouco** | Como dono, sente custo recorrente diretamente. Quer ROI visível. | 5/5 | 4/5 | 4/5 |
|
||||
|
||||
---
|
||||
|
||||
## Score consolidado
|
||||
|
||||
Top 5 forces de Daniel:
|
||||
|
||||
| Rank | Force | Score |
|
||||
|---|---|---|
|
||||
| 1 | **D+1 Insight estratégico** | 100 |
|
||||
| 1 | **D+2 Dirigir sem operar** | 100 |
|
||||
| 1 | **D+4 IA explicável "segundo cérebro"** | 75 (3×5×5) |
|
||||
| 1 | **D-1 Decidir no escuro** | 100 |
|
||||
| 1 | **D-6 IA black-box** | 75 |
|
||||
|
||||
---
|
||||
|
||||
## Features que respondem às forças de Daniel
|
||||
|
||||
| Force | Feature SAR que responde |
|
||||
|---|---|
|
||||
| D+1 Insight estratégico | **Card "IA disse hoje"** no topo do painel — 1-3 insights/dia priorizados |
|
||||
| D+2 Dirigir sem operar | **Painel executivo** focado em outcomes (faturamento, top/bottom, alertas), não em operação |
|
||||
| D+3 Posicionamento mercado | Pós-MVP: benchmarking setorial (anonimizado, cross-tenant — futuro) |
|
||||
| D+4 IA segundo cérebro | **Análises proativas:** carteira esfriando, oportunidades, anomalia de margem |
|
||||
| D+5 Decisão de investimento | Comparativo mês×mês, análise de concentração, alertas de tendência |
|
||||
| D+6 Histórico/tendência | **Gráficos longitudinais** (Chart.js) com tendência + sazonalidade |
|
||||
| D-1 Decidir no escuro | **Real-time entre cockpits** — Daniel sempre vê o "agora", não o "ontem" |
|
||||
| D-2 Surpreendido por concorrente | Pós-MVP: mercado/benchmark |
|
||||
| D-3 Investir e não engatar | Onboarding white-glove no MVP + acompanhamento das primeiras semanas |
|
||||
| D-4 Perder cliente top em silêncio | **Watchlist clientes-chave** com alerta IA proativo |
|
||||
| D-5 Reunião com Sandra sem dado | **Dashboard que Sandra e ele veem JUNTOS** (mesmo tempo real) |
|
||||
| D-6 IA black-box | **IA explicável obrigatória:** cada alerta tem "por que te digo isso" |
|
||||
| D-7 Pagar caro sem ROI | **Card de "valor entregue"** (clientes recuperados, descontos racionalizados, etc.) — pós-MVP |
|
||||
|
||||
---
|
||||
|
||||
## O que NÃO fazer (anti-padrões pra Daniel)
|
||||
|
||||
- ❌ Tela operacional ("aqui tem 3 pedidos para aprovar") — isso é da Sandra
|
||||
- ❌ Relatório PDF em vez de tela viva
|
||||
- ❌ IA que aparece como "magia" sem explicar premissa
|
||||
- ❌ Métricas vaidade sem ação ("você teve 234 logins esse mês")
|
||||
- ❌ Notificações constantes (Daniel não é operacional — fica chateado com push frequente)
|
||||
- ❌ Decoração/gamificação (Daniel é veterano, não nativo digital — clean executive)
|
||||
|
||||
---
|
||||
|
||||
## Tensão de design: Daniel ↔ Sandra
|
||||
|
||||
D+2 (Daniel quer delegar) ↔ S+1 (Sandra quer entregar resultado) — **alinhados**, mas exigem que o painel do Daniel **não duplique o da Sandra**:
|
||||
|
||||
- Sandra vê **operacional do dia** (aprovações, alertas, equipe)
|
||||
- Daniel vê **estratégico do período** (tendência, concentração, IA insight, ROI)
|
||||
|
||||
Mesma fonte de dado, **camadas qualitativamente diferentes**.
|
||||
|
||||
---
|
||||
|
||||
## Tensão crítica: IA explicável vs autonomia
|
||||
|
||||
D+4 quer IA proativa MAS D-6 odeia black-box.
|
||||
|
||||
**Resolução de design:**
|
||||
- Cada insight da IA tem **3 partes obrigatórias:**
|
||||
1. **O que aconteceu:** "Você aprovou 3 descontos > 10% essa semana"
|
||||
2. **Para quem/onde:** "Todos para OPENFRIOS"
|
||||
3. **Sugestão (não ordem):** "Considere reavaliar a tabela base para esse cliente"
|
||||
- Cada insight tem um link/expansão "**Por que te digo isso**" mostrando os dados que levaram à conclusão
|
||||
- Insight nunca aparece sem dado anexo
|
||||
|
||||
---
|
||||
|
||||
## Métricas de adoção
|
||||
|
||||
- **% dias úteis com acesso ao painel:** > 60% (Daniel não usa todo dia)
|
||||
- **% IA insights interagidos (lido + clicado em "por que"):** > 50%
|
||||
- **Acessa IA pelo menos 2x/semana:** **métrica north-star** (Step 8)
|
||||
- **NPS Daniel:** > 50 (donos B2B são duros, > 50 é bom)
|
||||
- **Retenção pós-mês 3:** 100% (essa é a north star do MVP)
|
||||
|
||||
---
|
||||
|
||||
## Citações canônicas
|
||||
|
||||
> "Faturamento em junho: R$ 1.2M (+18% vs maio). Liderado por OPENFRIOS."
|
||||
|
||||
> "Hoje você aprovou 3 descontos acima de 10%, todos para OPENFRIOS. Considere reavaliar a tabela base para esse cliente."
|
||||
|
||||
> "Top 12% da carteira responde por 58% do faturamento. Risco de concentração elevado."
|
||||
134
design-artifacts/B-Trigger-Map/personas/05-alice-admin.md
Normal file
134
design-artifacts/B-Trigger-Map/personas/05-alice-admin.md
Normal file
@@ -0,0 +1,134 @@
|
||||
# Persona — Alice Admin (TERTIARY — operacional crítico)
|
||||
|
||||
**Phase 2 — Trigger Mapping · Workshop 2-4**
|
||||
**Status:** TERTIARY persona — 1-5% volume (em ondas) · NÃO pesa na decisão de compra, mas o produto não roda sem ela
|
||||
**Device-target:** Desktop-only
|
||||
|
||||
---
|
||||
|
||||
## Quem é Alice
|
||||
|
||||
> Funcionária administrativa da empresa-cliente, 25-45 anos. Trabalha em escritório, desktop o dia todo. Reporta para Sandra ou Daniel. **É quem mantém o produto rodando** — cadastra produtos, atualiza pautas de preço, configura grupos tributários, lança campanhas/promoções, gerencia reps. Não tem treino de dev, mas domina Excel a níveis avançados.
|
||||
|
||||
### Dia típico
|
||||
|
||||
- **8h** — chega ao escritório, café, abre SAR no desktop
|
||||
- **8h30-10h** — atualiza pauta de preço da semana, configura promoções de fim de mês
|
||||
- **10h-12h** — cadastra novos produtos da linha de janeiro (do fornecedor que mandou planilha)
|
||||
- **12h** — almoço
|
||||
- **13h-15h** — ajustes tributários (ICMS-ST por UF), revisa cadastros de novos clientes inseridos pelos reps
|
||||
- **15h-17h** — cadastros de reps novos, ajustes de comissão, suporte a casos pontuais
|
||||
- **17h** — fechamento
|
||||
|
||||
### O que a motiva (em uma frase)
|
||||
|
||||
> **"Manter tudo rodando sem incidente, sem depender do dev para ajuste pequeno."**
|
||||
|
||||
---
|
||||
|
||||
## Driving Forces
|
||||
|
||||
### ✅ Positive forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **A+1** | **Autonomia operacional (sem precisar do dev)** | Lançar promoção, ajustar pauta, mexer em tributação sem abrir chamado de TI. | 5/5 | 5/5 | 5/5 |
|
||||
| **A+2** | **Eficiência em bulk operations** | Importar 500 produtos do fornecedor, atualizar pauta de 1000 itens — sem clicar 1000 vezes. | 4/5 | 5/5 | 4/5 |
|
||||
| **A+3** | **Confiança no que está em produção** | Não ter receio de "estourei o sistema com uma pauta errada". | 5/5 | 5/5 | 4/5 |
|
||||
| **A+4** | **Trilha de auditoria visível** | Saber quem mexeu em quê, quando. Proteção pessoal e organizacional. | 4/5 | 4/5 | 5/5 |
|
||||
| **A+5** | **Lançar campanha rapidamente** | Promoção sazonal, kit de produtos, brinde — em < 30 min, não semana. | 3/5 | 5/5 | 3/5 (pós-MVP) |
|
||||
| **A+6** | **Ser reconhecida como mais que "backoffice"** | Ter ferramenta que respeita seu domínio técnico (tributação, pauta, processo). | 3/5 | 4/5 | 3/5 |
|
||||
|
||||
### ❌ Negative forces
|
||||
|
||||
| ID | Force | Descrição | Freq | Int | Fit MVP |
|
||||
|---|---|---|---|---|---|
|
||||
| **A-1** | **Depender do dev para ajuste pequeno** | "Preciso de uma promoção de 15% no produto X, dev tá ocupado, leva 1 semana." | 4/5 | 5/5 | 3/5 (pós-MVP completo) |
|
||||
| **A-2** | **Ser culpada por erro em produção** | Pauta com vírgula errada, 1.000 pedidos saem com preço errado. Pesadelo. | 2/5 | 5/5 | 5/5 |
|
||||
| **A-3** | **ICMS-ST como labirinto sem mapa** | Cada UF tem regra, NCM específico, alíquota... sem assistente, precisa de PDF da legislação. | 3/5 | 5/5 | 4/5 |
|
||||
| **A-4** | **Perder histórico de mudança** | Editou pauta, alguém depois questiona "por que estava em R$ X mês passado?". Sem evidência. | 3/5 | 4/5 | 5/5 |
|
||||
| **A-5** | **Telas lentas em bulk** | Editar 200 produtos um por um, tela carrega cada vez. Hora de trabalho perdida. | 4/5 | 4/5 | 4/5 |
|
||||
| **A-6** | **Ser vista só como "backoffice"** | Esforço técnico invisível — quando dá tudo certo, ninguém percebe; quando dá errado, é culpada. | 3/5 | 4/5 | 3/5 |
|
||||
|
||||
---
|
||||
|
||||
## Score consolidado
|
||||
|
||||
Top 5 forces de Alice:
|
||||
|
||||
| Rank | Force | Score |
|
||||
|---|---|---|
|
||||
| 1 | **A+1 Autonomia (sem dev)** | 125 |
|
||||
| 1 | **A+3 Confiança em produção** | 100 |
|
||||
| 1 | **A-3 ICMS-ST labirinto** | 75 (3×5×5) |
|
||||
| 1 | **A+4 Trilha auditoria** | 80 |
|
||||
| 1 | **A-4 Perder histórico** | 60 (3×4×5) |
|
||||
|
||||
---
|
||||
|
||||
## Features que respondem às forças de Alice
|
||||
|
||||
| Force | Feature SAR que responde |
|
||||
|---|---|
|
||||
| A+1 Autonomia sem dev | **Editor de campanhas no-code** (pós-MVP) + cadastros completos no MVP |
|
||||
| A+2 Bulk operations | **Import CSV/Excel** com preview · seleção múltipla com bulk edit · sem refresh entre operações |
|
||||
| A+3 Confiança em produção | **Preview obrigatório** antes de salvar mudanças em massa · double-confirm para operações destrutivas |
|
||||
| A+4 Trilha auditoria | **Histórico em cada entidade** (quem, quando, valor anterior) · revertível |
|
||||
| A+5 Campanhas no-code | **Editor visual de campanha** pós-MVP: "Produto X com 15% off para clientes região Y no mês Z" — sem SQL |
|
||||
| A+6 Reconhecida | UX que respeita expertise técnica (forms densos, atalhos, profissionalidade) |
|
||||
| A-1 Depender do dev | Cobertura ampla do editor no-code (pós-MVP) — MVP entrega cadastros e pautas com versionamento |
|
||||
| A-2 Erro em produção | Preview · validação Zod · "X produtos serão afetados — confirma?" · rollback de pauta versionada |
|
||||
| A-3 ICMS-ST | **Assistente de tributação:** sugere grupo correto baseado em NCM + UF de destino |
|
||||
| A-4 Perder histórico | Versionamento de pautas · auditoria em produtos/clientes |
|
||||
| A-5 Telas lentas | **Bulk edit otimizado** (server-side, queries batch via Prisma) |
|
||||
| A-6 Backoffice invisible | UI elegante para Alice (não tela "tabelão preto e cinza") — Notion-inspired |
|
||||
|
||||
---
|
||||
|
||||
## O que NÃO fazer (anti-padrões pra Alice)
|
||||
|
||||
- ❌ Wizard de 10 passos para criar promoção (Alice quer form denso, não condução infantil)
|
||||
- ❌ Pedido constante de confirmação para tudo (Alice é técnica, sabe o que faz)
|
||||
- ❌ Esconder funcionalidade avançada atrás de "modo avançado" (Alice é avançada)
|
||||
- ❌ Sem atalho de teclado em telas de cadastro (Alice digita rápido, mouse é freio)
|
||||
- ❌ Form sem auto-save (Alice perde 30 min de cadastro por refresh acidental)
|
||||
- ❌ Bulk operations sem preview (Alice é cuidadosa — quer ver antes de aplicar)
|
||||
|
||||
---
|
||||
|
||||
## Restrições MVP (refinamento da tensão Step 10)
|
||||
|
||||
Como solo founder + 3-4 meses não comporta tudo, **o cockpit Alice no MVP** tem:
|
||||
|
||||
| Feature | MVP | Pós-MVP |
|
||||
|---|---|---|
|
||||
| Cadastro de produto | ✅ Form denso completo | Bulk import refinado |
|
||||
| Cadastro de cliente | ✅ Completo (com integração ERP eventual) | — |
|
||||
| Cadastro de rep | ✅ Permissões + região + comissão | Hierarquia rep → supervisor |
|
||||
| Pauta de preço | ✅ Edição + versionamento | Diff visual entre versões |
|
||||
| ICMS-ST por UF | ✅ Configuração manual | **Assistente automático por NCM** |
|
||||
| Campanhas/Promoções | 🟡 Tela direta (editar 1 a 1) | **Editor visual no-code** |
|
||||
| Auditoria | ✅ Histórico em cada entidade | UI dedicada de auditoria/relatório |
|
||||
| Bulk operations | 🟡 Import básico | Edit múltipla, scripts |
|
||||
|
||||
Alice no MVP é **suficiente para o produto rodar**, mas não brilha como diferencial. O **editor no-code** é onde ela passa a ser argumento de marketing — entra pós-MVP.
|
||||
|
||||
---
|
||||
|
||||
## Métricas de adoção
|
||||
|
||||
- **% campanhas lançadas sem suporte (no-code editor):** > 80% (pós-MVP feature do editor)
|
||||
- **Tempo médio de cadastro de produto:** < 90 segundos
|
||||
- **Erros de pauta em produção (mensais):** 0 (P0)
|
||||
- **NPS Alice:** > 40 (admins têm vida dura — > 40 é bom)
|
||||
- **Adoção do assistente ICMS-ST:** > 70% dos novos cadastros (pós-MVP)
|
||||
|
||||
---
|
||||
|
||||
## Citações canônicas
|
||||
|
||||
> "Pauta atualizada. 1.247 produtos afetados."
|
||||
|
||||
> "Promoção lançada. 234 itens em desconto até 30/06."
|
||||
|
||||
> "Grupo tributário sugerido pela IA para NCM 22030000 + UF SP. Aplicar?"
|
||||
85
design-artifacts/C-UX-Scenarios/00-ux-scenarios.md
Normal file
85
design-artifacts/C-UX-Scenarios/00-ux-scenarios.md
Normal file
@@ -0,0 +1,85 @@
|
||||
# UX Scenarios: SAR
|
||||
|
||||
> Design experiences, not screens — every page serves a user with a goal and an emotion.
|
||||
|
||||
**Created:** 2026-05-26
|
||||
**Phase:** 3 (Scenario Outline) + Phase 4 (UX Design)
|
||||
**Agents:** Saga (Scenario Outline), Freya (Page Specifications)
|
||||
|
||||
---
|
||||
|
||||
## What Belongs Here
|
||||
|
||||
Scenarios organize the product into meaningful user journeys. Each scenario groups related pages. Each page gets a full specification that a developer can build from.
|
||||
|
||||
**Folder structure per scenario:**
|
||||
```
|
||||
C-UX-Scenarios/
|
||||
├── 00-ux-scenarios.md ← This file (scenario guide + page index)
|
||||
├── 01-scenario-name/
|
||||
│ ├── 1.1-page-name/
|
||||
│ │ ├── 1.1-page-name.md ← Page specification
|
||||
│ │ └── Sketches/ ← Wireframes and concepts
|
||||
│ ├── 1.2-page-name/
|
||||
│ │ ├── 1.2-page-name.md
|
||||
│ │ └── Sketches/
|
||||
│ └── ...
|
||||
├── 02-scenario-name/
|
||||
│ └── ...
|
||||
├── Components/ ← Shared component specs
|
||||
└── Features/
|
||||
└── Storyboards/ ← Multi-step interaction flows
|
||||
```
|
||||
|
||||
**Learn more:**
|
||||
- WDS Course Module 08: Outline Scenarios — Design Experiences Not Screens
|
||||
- WDS Course Module 09: Conceptual Sketching
|
||||
- WDS Course Module 10: Storyboarding
|
||||
- WDS Course Module 11: Conceptual Specifications
|
||||
- WDS Course Tutorial 08: From Trigger Map to Scenarios
|
||||
|
||||
---
|
||||
|
||||
## For Agents
|
||||
|
||||
### Scenario Outline (Saga)
|
||||
**Workflow:** `skill:wds-3-scenarios`
|
||||
**Agent trigger:** `SC` (Saga)
|
||||
|
||||
### Page Specifications (Freya)
|
||||
**Workflow:** `skill:wds-4-ux-design`
|
||||
**Agent trigger:** `UX` (Freya)
|
||||
**Page template:** `./resources/wds-4-ux-design/templates/page-specification.template.md`
|
||||
**Scenario template:** `./resources/wds-4-ux-design/templates/scenario-overview.template.md`
|
||||
**Quality guide:** `./resources/agent-guides/freya/specification-quality.md`
|
||||
**Object types:** `./resources/wds-4-ux-design/object-types/`
|
||||
|
||||
### Specification Audit (Freya)
|
||||
**Workflow:** `skill:wds-4-ux-design`
|
||||
**Agent trigger:** `SA` (Freya)
|
||||
|
||||
**Before writing any page specification:**
|
||||
1. Read `B-Trigger-Map/` — know the personas and their driving forces
|
||||
2. Read the page specification template — use it as your scaffold, not memory
|
||||
3. Discuss the page purpose with the user before filling in details
|
||||
4. Each page folder needs a `Sketches/` subfolder for wireframes
|
||||
|
||||
**Harm:** Producing page specs from memory of what the template "roughly" contains. Plausible-looking specs that use wrong structure break the pipeline — developers can't trust them, audits can't validate them, and the user must correct what should have been right.
|
||||
|
||||
**Help:** Reading the actual template into context, discussing page purpose with the user, then filling the template with specific content. Specs that follow the template work across projects, pass audits, and give developers confidence.
|
||||
|
||||
---
|
||||
|
||||
## Scenarios
|
||||
|
||||
_This section will be updated as scenarios are outlined during Phase 3._
|
||||
|
||||
---
|
||||
|
||||
## Page Index
|
||||
|
||||
_This section will be updated as page specifications are created during Phase 4._
|
||||
|
||||
---
|
||||
|
||||
_Created using Whiteport Design Studio (WDS) methodology_
|
||||
156
design-artifacts/D-Design-System/00-design-system.md
Normal file
156
design-artifacts/D-Design-System/00-design-system.md
Normal file
@@ -0,0 +1,156 @@
|
||||
# Design System: SAR
|
||||
|
||||
> Components, tokens, and patterns that grow from actual usage — not upfront planning.
|
||||
|
||||
**Created:** 2026-05-26
|
||||
**Phase:** 7 — Design System (mantida porque AntD 6.4 não cobre tokens/variações JCS)
|
||||
**Agent:** Freya (Designer)
|
||||
|
||||
---
|
||||
|
||||
## What Belongs Here
|
||||
|
||||
O Design System captura padrões reutilizáveis que emergem durante o UX Design (Fase 4). Para o SAR, ele camada **sobre Ant Design 6.4**, não substitui:
|
||||
|
||||
- **Design Tokens** — paleta JCS (`#004a99`, `#f4f7fa`, etc.), Plus Jakarta Sans, radius 12/20px, sombra `0 4px 25px rgba(0,0,0,0.05)` (já em `brand.md`)
|
||||
- **AntD theming** — variações via `ConfigProvider` do AntD para refletir a marca JCS
|
||||
- **Componentes JCS** — padrões além do AntD: sidebar 260px fixa, topbar 80px, gradientes de login `#f0f4f8 → #d9e2ec`, cards 360°, kanban CRM
|
||||
- **Patterns** — layouts (sidebar+topbar), formulários, blocos de conteúdo
|
||||
- **Visual Design** — mood boards, color exploration (validação de paleta), typography tests
|
||||
- **Assets** — logos (já em `frontend/img/`), ícones (Font Awesome 6.4), gráficos (Chart.js)
|
||||
|
||||
**What does NOT go here:**
|
||||
- Page-specific content (lives in `C-UX-Scenarios/`)
|
||||
- Business logic or API specs (BMM territory)
|
||||
- Aspirational components nobody uses yet
|
||||
|
||||
**Learn more:**
|
||||
- WDS Course Module 12: Functional Components — Patterns Emerge
|
||||
- WDS Course Module 13: Design System
|
||||
|
||||
---
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
D-Design-System/
|
||||
├── 00-design-system.md ← This file (hub + guide)
|
||||
├── 01-Visual-Design/ [Early design exploration]
|
||||
│ ├── mood-boards/
|
||||
│ ├── design-concepts/
|
||||
│ ├── color-exploration/
|
||||
│ └── typography-tests/
|
||||
├── 02-Assets/ [Final production assets]
|
||||
│ ├── logos/ [Copiar de frontend/img/ quando consolidado]
|
||||
│ ├── icons/ [Subset de FA6 efetivamente usado]
|
||||
│ ├── images/
|
||||
│ └── graphics/
|
||||
└── components/ [Emerges during Phase 4]
|
||||
├── interactive/
|
||||
├── form/
|
||||
├── layout/
|
||||
├── content/
|
||||
├── feedback/
|
||||
└── navigation/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## For Agents
|
||||
|
||||
**Workflow:** `skill:wds-7-design-system`
|
||||
**Agent trigger:** `DS` (Freya)
|
||||
**Router:** `./resources/wds-7-design-system/design-system-router.md`
|
||||
**Templates:** `./resources/wds-7-design-system/templates/`
|
||||
**Guide:** `./resources/agent-guides/freya/design-system.md`
|
||||
|
||||
**Before creating any component:**
|
||||
1. Verificar se já existe no Ant Design 6.4 — usar AntD nativo sempre que possível
|
||||
2. Olhar uso real em `C-UX-Scenarios/` page specs — extrair, não inventar
|
||||
3. Documentar overrides/extensões sobre AntD em vez de recriar do zero
|
||||
|
||||
**Harm:** Recriar componentes que o AntD já oferece. Inventar tokens que conflitam com `brand.md`.
|
||||
|
||||
**Help:** Extrair padrões reais de page specs. Documentar o tema AntD JCS (cores, radius, fonte). Quando 3 páginas usam mesmo layout → vira componente JCS.
|
||||
|
||||
---
|
||||
|
||||
## Spacing Scale (preliminar — refinar em Phase 4)
|
||||
|
||||
> Base 8px (compatível com AntD). `space-md = 16px` é o baseline.
|
||||
|
||||
| Token | Value | Use |
|
||||
|-------|-------|-----|
|
||||
| space-3xs | 2px | Hairline gaps |
|
||||
| space-2xs | 4px | Minimal spacing |
|
||||
| space-xs | 8px | Tight spacing |
|
||||
| space-sm | 12px | Small gaps |
|
||||
| **space-md** | 16px | **Default element spacing** |
|
||||
| space-lg | 24px | Card padding, form fields |
|
||||
| space-xl | 32px | Section padding |
|
||||
| space-2xl | 48px | Section gaps |
|
||||
| space-3xl | 64px | Page-level breathing room |
|
||||
|
||||
---
|
||||
|
||||
## Type Scale (preliminar — refinar em Phase 4)
|
||||
|
||||
> Tipografia: **Plus Jakarta Sans** (pesos 400, 500, 600, 700, 800).
|
||||
|
||||
| Token | Value | Use |
|
||||
|-------|-------|-----|
|
||||
| text-3xs | 10px | Fine print |
|
||||
| text-2xs | 11px | Metadata |
|
||||
| text-xs | 12px | Captions |
|
||||
| text-sm | 13px | Labels |
|
||||
| text-md | 14px | Body text (baseline AntD) |
|
||||
| text-lg | 16px | Emphasis |
|
||||
| text-xl | 18px | Subheadings |
|
||||
| text-2xl | 24px | Section titles |
|
||||
| text-3xl | 32px | Hero headings |
|
||||
|
||||
---
|
||||
|
||||
## Tokens
|
||||
|
||||
**Cores canônicas** (de `brand.md`):
|
||||
|
||||
| Papel | Token | Hex |
|
||||
|---|---|---|
|
||||
| Primária | `--jcs-blue` | `#004a99` |
|
||||
| Primária hover | `--jcs-blue-hover` | `#003a7a` |
|
||||
| Fundo ativo menu | `--jcs-blue-light` | `#e6eff8` |
|
||||
| Background app | `--bg-body` | `#f4f7fa` |
|
||||
| Texto principal | `--text-main` | `#2d3748` |
|
||||
| Texto secundário | `--text-muted` | `#718096` |
|
||||
| Sucesso/Faturado | `--green` | `#38a169` |
|
||||
| Alerta/Em aberto | `--orange` | `#ed8936` |
|
||||
| Erro/Bloqueado | `--red` | `#e53e3e` |
|
||||
| WhatsApp | `--whatsapp-green` | `#25d366` |
|
||||
|
||||
**Bordas e sombras**: `--radius-md: 12px`, `--radius-lg: 20px`, `--shadow: 0 4px 25px rgba(0,0,0,0.05)`.
|
||||
|
||||
---
|
||||
|
||||
## Patterns
|
||||
|
||||
_Padrões serão documentados aqui conforme objetos de spacing recorrerem entre páginas._
|
||||
|
||||
---
|
||||
|
||||
## Components
|
||||
|
||||
_Componentes serão documentados aqui conforme padrões emergirem nos cenários._
|
||||
|
||||
Lista preliminar esperada (a confirmar em Phase 4):
|
||||
- Sidebar 260px fixa com itens hierárquicos
|
||||
- Topbar 80px com busca + perfil
|
||||
- Card 360° (visão do cliente)
|
||||
- Kanban CRM (funil de vendas)
|
||||
- Tabela de pedidos (Orçamento → Faturado)
|
||||
- Modal de lançamento de pedido
|
||||
- Gráfico de comissão/FLEX (Chart.js)
|
||||
|
||||
---
|
||||
|
||||
_Created using Whiteport Design Studio (WDS) methodology_
|
||||
245
design-artifacts/_progress/00-design-log.md
Normal file
245
design-artifacts/_progress/00-design-log.md
Normal file
@@ -0,0 +1,245 @@
|
||||
# Design Log
|
||||
|
||||
**Project:** SAR — Força de Vendas
|
||||
**Started:** 2026-05-26
|
||||
**Method:** Whiteport Design Studio (WDS)
|
||||
|
||||
---
|
||||
|
||||
## Backlog
|
||||
|
||||
> Business-value items. Add links to detail files if needed.
|
||||
|
||||
- [ ] Complete product brief — Phase 1 (`A-Product-Brief/`)
|
||||
- [ ] Define trigger map — Phase 2 (`B-Trigger-Map/`) — 3 personas hipotéticas: rep externo, supervisor, admin
|
||||
- [ ] Create user scenarios — Phase 3 (`C-UX-Scenarios/`)
|
||||
- [ ] Page specifications — Phase 4 (`C-UX-Scenarios/<scenario>/<page>/`)
|
||||
- [ ] Design System overlay sobre AntD 6.4 — Phase 6 (`D-Design-System/`)
|
||||
- [ ] Agentic development — Phase 5 (`E-Development/`)
|
||||
|
||||
---
|
||||
|
||||
## Current
|
||||
|
||||
| Task | Started | Agent |
|
||||
|------|---------|-------|
|
||||
| Phase 0 setup | 2026-05-26 | wds-0-project-setup |
|
||||
|
||||
**Rules:** Mark what you start. Complete it when done (move to Log). One task at a time per agent.
|
||||
|
||||
---
|
||||
|
||||
## Design Loop Status
|
||||
|
||||
> Per-page design progress. Updated by agents at every design transition.
|
||||
|
||||
| Scenario | Step | Page | Status | Updated |
|
||||
|----------|------|------|--------|---------|
|
||||
|
||||
**Status values:** `discussed` → `wireframed` → `specified` → `explored` → `building` → `built` → `approved` | `removed`
|
||||
|
||||
---
|
||||
|
||||
## Log
|
||||
|
||||
### 2026-05-26 — Project initialized (Phase 0)
|
||||
- Type: greenfield
|
||||
- Complexity: complex (Web Application, SaaS B2B multi-tenant)
|
||||
- Tech stack: STACK.md JCS v2.2 — React 19.2 + Vite 8 + Ant Design 6.4 / NestJS 11.1 + Prisma 7 + PostgreSQL 18 / Proxmox on-prem
|
||||
- Existing materials: `brand.md`, `STACK.md`, `CODING-RULES.md`, logos em `frontend/img/`
|
||||
- Strategic analysis: full (Phase 2 habilitada)
|
||||
- Brief level: complete
|
||||
- Stakes: small-business (JCS Sistemas)
|
||||
- Active agents: Saga (estratégia), Freya (design)
|
||||
- **Next:** `skill:wds-1-project-brief` com Saga
|
||||
|
||||
### 2026-05-26 — Phase 1 Steps 1, 1a, 2 concluídos
|
||||
- **Step 1 (Init):** materiais adicionais identificados — mockup SPA legado (`index.html` 2251 linhas, 9 telas, login excluído).
|
||||
- **Step 1a (Client Profile):** JCS = PME software house 11-50p, tech maturity alta + design iniciante. Julian acumula PO + Tech Lead + único Champion, autonomia total. Cultura fast-individual. SAR é upgrade-de-tier para SaaS web vendável (não conserto de legado).
|
||||
- **Step 2 (Vision):** SAR oferece 3 experiências distintas (rep operacional / supervisor tático / dono estratégico+IA). 6 diferenciais explícitos: inteligência de carteira, WhatsApp nativo, metas gamificadas, camadas por papel, IA estratégica, SaaS web distribuível.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 3 (Positioning) concluído
|
||||
- **Target:** Distribuidoras / indústrias / RCAs / PMEs com 5-50 reps externos (sweet spot mid-SMB).
|
||||
- **Dor central:** Donos e supervisores decidem no escuro — falta visibilidade em tempo real do que acontece na rua.
|
||||
- **Concorrência:** Apps verticais (Mercos/Promosoft/MaxFV/Workforce/Mobits), módulos de ERP (TOTVS/Sankhya/Senior), stack improvisado (Excel+WhatsApp+ERP), apps caseiros.
|
||||
- **Estratégia:** Coexistência com ERPs (não migração total) — multi-tenancy BD-por-workspace facilita integração heterogênea. WhatsApp+IA no MVP, não em roadmap.
|
||||
- **Próximo:** Step 5 — Business Model.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 5 (Business Model) concluído
|
||||
- **Modelo:** B2B SaaS per-seat, sales-led, trial 14-30 dias, contrato híbrido mensal/anual.
|
||||
- **Ticket médio:** R$ 750-7.500/mês (porte pequeno a médio alto).
|
||||
- **Implicações técnicas:** active rep counter no produto; provisioning automatizado de workspace para trial; billing suporta cobrança mensal recorrente + anual única; reusa BD-por-workspace (ADR 0006) para sandbox.
|
||||
- **Implicações marketing:** CTA "Agende demo", trial gated por SDR, pricing page no site.
|
||||
- **Próximo:** Step 6 — Business Customers.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 6 (Business Customers) concluído
|
||||
- **Buyer persona:** "Dono Empresário B2B" — 35-60 anos, sócio-fundador, decide na fé+demo+boca-a-boca.
|
||||
- **Decisão:** dono OU diretor comercial. Influenciadores chave: supervisor + reps. **Ausentes: financeiro, TI, jurídico** (venda operacional-emocional).
|
||||
- **Canais:** indicação + SEO + feiras + parceiros (todos os 4 ativos).
|
||||
- **Ciclo:** 2-4 semanas (pequeno) → 2-4 meses (médio alto).
|
||||
- **Implicações chave:** site precisa 3 páginas por papel, comparativos diretos com concorrentes, demo-friendliness obrigatória, JCS precisa de CRM próprio (possível dogfood).
|
||||
- **Próximo:** Step 7 — Target Users (3 user personas: rep / supervisor / dono).
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 7 (Target Users) concluído
|
||||
- **4 personas confirmados:** Rafael (Rep — PRIMÁRIA, mobile-first), Sandra (Supervisora), Daniel (Dono+IA), **Alice (Admin — nova)** com responsabilidade por campanhas/promoções, pautas e tributação.
|
||||
- **Decisão crítica de design:** mobile-first para Rafael, desktop-first para os outros 3. SAR são 2 paradigmas de UI no mesmo produto.
|
||||
- **Diferenciais reforçados:** editor de campanhas no-code (Alice), assistente ICMS-ST (Alice), auditoria de pautas (Alice+regulatório), comissão em tempo real (Rafael), IA explicável (Daniel).
|
||||
- **Insight de venda:** demo precisa brilhar para Sandra, vender para Daniel, encantar Rafael. Alice é benefício, não argumento.
|
||||
- **Próximo:** Step 7a — Product Concept.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 7a (Product Concept) concluído
|
||||
- **Concept canônico:** "SAR é uma plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual."
|
||||
- **Metáfora:** equipe de Fórmula 1 — cada papel tem seu próprio dashboard sobre o mesmo carro em telemetria real.
|
||||
- **4 princípios:** cada cockpit com UX/device próprios; tempo real (Socket.IO/SSE); WhatsApp+IA como fios horizontais; multi-tenancy BD-por-workspace.
|
||||
- **Tensões aceitas:** 4 paradigmas UX vs 1 responsivo; tempo real obrigatório; WhatsApp/IA pilares desde MVP.
|
||||
- **Implicação:** Phase 6 (Design System) deixa de ser opcional — tokens compartilhados + variantes por cockpit.
|
||||
- **Próximo:** Step 8 — Success Criteria.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 8 (Success Criteria) concluído
|
||||
- **North star MVP:** 1º cliente paga e renova nos primeiros 3 meses após go-live.
|
||||
- **Y1:** 10-20 clientes (conservador) · NPS donos > 50 · ARR R$ 200k-600k.
|
||||
- **Timeline:** MVP em 3-4 meses → cliente renova em mês 6-7 → 10 clientes pagantes em mês 12.
|
||||
- **Métricas em 4 camadas:** negócio JCS · cliente · comportamento usuário · qualidade técnica.
|
||||
- **Implicação:** instrumentação de produto (OTel/Grafana/analytics/NPS) no MVP, não em roadmap.
|
||||
- **Próximo:** Step 9 — Competitive Landscape.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 9 (Competitive Landscape) concluído
|
||||
- **5 grupos analisados:** apps verticais (Mercos+), ERPs com módulo (TOTVS+), stack improvisado, apps caseiros, **do-nothing** (50%+ dos prospects).
|
||||
- **5 unfair advantages estruturais:** 4 cockpits + multi-tenancy BD-por-workspace + stack moderna + IA estrutural + velocidade JCS.
|
||||
- **Posição alvo:** vendas-first + baixo atrito de implantação.
|
||||
- **Estratégia de venda:** demo ataca do-nothing primeiro (urgência), coexistência com ERPs para Grupo 2.
|
||||
- **Janela de mercado:** 2-3 anos para entrincheirar; velocidade MVP é decisão estratégica.
|
||||
- **Próximo:** Step 10 — Constraints.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 10 (Constraints) concluído
|
||||
- **Tensão estratégica flagueada:** concept ambicioso + 3-4 meses + **solo founder mode** não comportam concept completo no MVP.
|
||||
- **Resolução proposta:** MVP mínimo defensível = Rafael + Sandra completos + Daniel/Alice simplificados + WhatsApp básico (sem IA). IA + editor no-code entram pós-MVP.
|
||||
- **Premissa:** 1º cliente é referência/parceiro, aceita limitações; quando renova, Julian contrata 1-2 devs e completa.
|
||||
- **Constraints fixos:** STACK.md v2.2, brand.md, LGPD by design, Proxmox on-prem BR, multi-tenancy BD-por-workspace.
|
||||
- **Flexível:** providers (pagamento, IA, WhatsApp), analytics, dark mode.
|
||||
- **Próximo:** Step 10a — Platform Strategy.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 10a (Platform Strategy) concluído
|
||||
- **Plataforma primária:** Web SaaS (React SPA + Cloudflare + Nginx).
|
||||
- **Rafael:** **PWA mobile-first com foco iOS** (Android continua com app legado por enquanto).
|
||||
- **Sandra:** Desktop + PWA mobile-light.
|
||||
- **Daniel:** Desktop + iPad first-class.
|
||||
- **Alice:** Desktop-only.
|
||||
- **Coexistência:** Android legado intocado no MVP; pós-MVP adapta para consumir backend SAR; futuro avalia native iOS+Android sobre SAR.
|
||||
- **Offline:** Read + Write com sync (IndexedDB + Service Worker) para Rafael.
|
||||
- **Native features MVP:** Geolocation, Web Push, Share API, Notification API. Camera/File API pós-MVP.
|
||||
- **Acessibilidade:** WCAG AA desde MVP.
|
||||
- **Próximo:** Step 11 — Tone of Voice.
|
||||
|
||||
### 2026-05-26 — Phase 1 Step 11 (Tone of Voice) concluído
|
||||
- **5 atributos canônicos:** Direto · Profissional sem ser frio · Confiante · Específico · Empático nos momentos difíceis.
|
||||
- **Variações por cockpit:** Rafael (informal/curto), Sandra (decisivo), Daniel (executivo), Alice (técnico-preciso).
|
||||
- **Vocabulário canônico:** Cliente · Rep · Orçamento · Pedido · Faturado · Visita · Carteira · Inativo · Painel · Aprovação.
|
||||
- **Don'ts:** emoji em produção, caps lock erros, burocratês, anglicismos desnecessários, frases dúbias.
|
||||
- **Implicação:** vocabulário vira tokens i18n; Phase 6 inclui guia microcopy; prompt de IA generativa precisa carregar atributos + vocabulário.
|
||||
- **Próximo:** Step 12 — Create Product Brief (consolidação dos Steps 1-11 num documento canônico).
|
||||
|
||||
### 2026-05-26 — Phase 1 BLOCK A (Product Brief) CONCLUÍDO ✅
|
||||
- **Brief canônico gerado:** `design-artifacts/A-Product-Brief/01-product-brief.md`
|
||||
- **14 steps concluídos** (1, 1a, 2, 3, 5, 6, 7, 7a, 8, 9, 10, 10a, 11, 12)
|
||||
- **Tempo decorrido:** ~2-3h em uma sessão
|
||||
- **Confirmação:** narrativa estratégica apresentada e confirmada sem ajustes
|
||||
- **Próximo:** Block B (Content & Language) — Steps 13-18.
|
||||
|
||||
### 2026-05-27 — Phase 1 BLOCK B (Content & Language) CONCLUÍDO ✅
|
||||
- **Documento canônico gerado:** `design-artifacts/A-Product-Brief/02-content-language.md`
|
||||
- **7 steps concluídos** (13, 14, 15, 16, 17, 17a, 18)
|
||||
- **Personality:** "Consultor sênior brasileiro de vendas B2B" (5 atributos)
|
||||
- **Tone spectrums:** Formality 3 · Mood 2 · Complexity 3 · Energy 2
|
||||
- **Languages:** pt-BR only no MVP, i18n-ready
|
||||
- **SEO:** 6 intents de keywords · sitemap robusto · structured data plan · page-keyword map top 10
|
||||
- **Content Structure:** 10 princípios site + 11 princípios produto + 8 exclusões explícitas
|
||||
- **Content guidelines:** UI/Marketing/Info/Email/WhatsApp/IA + ownership + checklist 13 itens
|
||||
- **Próximo:** Block C (Visual Direction) — fast-track via brand.md.
|
||||
|
||||
### 2026-05-27 — Phase 1 Step 19 (Inspiration Workshop) concluído
|
||||
- **🌟 Insight estratégico:** "Não acho nada no mercado de identidade como inspirador — uma das coisas que nos trouxe para esse projeto" → **estética moderna é parte do diferencial fundacional do SAR**, adicionar como 6º unfair advantage no Brief.
|
||||
- **4 referências externas:** Apple iCloud · Linear · Stripe Dashboard · Notion (todas fora do setor B2B força de vendas BR, propositalmente).
|
||||
- **7 padrões destilados:** sidebar fixa + tipografia hierarquia + único accent JCS + densidade respirável + animações sutis + dark mode + empty states informativos.
|
||||
- **Referências por cockpit** mapeadas para alimentar Phase 4.
|
||||
- **Próximo:** Step 20 — Visual Init.
|
||||
|
||||
### 2026-05-27 — Phase 1 BLOCK C (Visual Direction) CONCLUÍDO ✅
|
||||
- **Documento canônico:** `design-artifacts/A-Product-Brief/03-visual-direction.md`
|
||||
- **8 steps concluídos** (19, 20, 21, 22, 23, 24, 25, 26)
|
||||
- **Insight estratégico:** estética moderna é parte do diferencial fundacional do SAR (6º unfair advantage)
|
||||
- **Visual DNA:** Modern Flat + Minimal · JCS Blue mono + accents · Plus Jakarta Geometric Humanist · Clean/Confident/Specific/Serene/Modern · split hero + cockpits diferenciados · effects sutis · screenshots-only Apple-style
|
||||
- **Próximo:** Block D (Platform Requirements) — fast-track via STACK.md.
|
||||
|
||||
### 2026-05-27 — Phase 1 BLOCK D (Platform Requirements) CONCLUÍDO ✅
|
||||
- **Documento canônico:** `design-artifacts/A-Product-Brief/04-platform-requirements.md`
|
||||
- **6 steps concluídos** (27, 28, 29, 30, 31, 32) — batched após Step 27
|
||||
- **Tech Stack:** espelho de STACK.md v2.2 (Node 24 + Nest 11 + Prisma 7 + React 19 + AntD 6.4 + multi-tenant BD-por-workspace ADR 0006 + Proxmox on-prem ADR 0004)
|
||||
- **Integrações fechadas:** Iugu (pagamento) · Meta Cloud API oficial (WhatsApp) · PostHog self-host (analytics)
|
||||
- **Integração ABERTA:** IA generativa — abstração multi-provider (Vercel AI SDK/LiteLLM) com default temporário Anthropic Claude
|
||||
- **Contact strategy:** Form de demo como único CTA; sem chat ao vivo no MVP
|
||||
- **Multilingual:** pt-BR only, i18n-ready · Lighthouse > 90 como CI gate
|
||||
- **Maintenance:** solo founder mode até 1º cliente
|
||||
- **Próximo:** Block E (Wrap-up) — Steps 33-36.
|
||||
|
||||
### 2026-05-27 — Phase 1 BLOCK E (Wrap-up) CONCLUÍDO ✅ — PHASE 1 INTEIRA COMPLETA 🎉
|
||||
|
||||
**Steps concluídos:** 33 (Analyze), 34 (Summary), 35 (Update Design Log), 36 (Provide Activation Phase 2).
|
||||
|
||||
**Handover document:** `design-artifacts/A-Product-Brief/00-handover-summary.md`
|
||||
|
||||
**Artefatos canônicos finais (todos em `design-artifacts/A-Product-Brief/`):**
|
||||
- `00-handover-summary.md` ⭐ entrada para Phase 2
|
||||
- `01-product-brief.md` ⭐ brief estratégico (Block A)
|
||||
- `02-content-language.md` (Block B)
|
||||
- `03-visual-direction.md` (Block C)
|
||||
- `04-platform-requirements.md` (Block D)
|
||||
- `dialog/` (16 documentos de histórico detalhado)
|
||||
|
||||
**Tempo total Phase 1:** ~6-8 horas em 2 dias (2026-05-26 + 2026-05-27).
|
||||
|
||||
**Steps completados:** 36/36 ✅
|
||||
|
||||
**Decisões abertas conscientemente:**
|
||||
- Provider de IA generativa (resolver pré-feature IA)
|
||||
- Preço per-seat exato (validar com primeiras vendas)
|
||||
- Setup fee, add-ons premium, contratações futuras, JCS team photos
|
||||
|
||||
**Tensão estratégica documentada:**
|
||||
- Solo founder + 3-4 meses + concept ambicioso → MVP minimalista (Rafael+Sandra completos; Daniel+Alice simplificados; IA+editor no-code pós-MVP).
|
||||
|
||||
**Próximo:** Phase 2 — Trigger Mapping (skill `wds-2-trigger-mapping` com Saga). 5 workshops sequenciais. Output em `design-artifacts/B-Trigger-Map/`.
|
||||
|
||||
### 2026-05-27 — Phase 2 (Trigger Mapping) CONCLUÍDA ✅ (Dream mode)
|
||||
- **7 documentos gerados** em `design-artifacts/B-Trigger-Map/`:
|
||||
- `00-trigger-map.md` (hub + mermaid diagram + síntese + priorização MVP)
|
||||
- `01-business-goals.md` (5 BGs refinados do Brief)
|
||||
- `personas/02-rafael-representante.md` (PRIMARY MVP)
|
||||
- `personas/03-sandra-supervisora.md` (influenciadora compra)
|
||||
- `personas/04-daniel-dono.md` (IA + buyer overlap)
|
||||
- `personas/05-alice-admin.md` (operacional)
|
||||
- `06-feature-impact-analysis.md` (matrix Features × Forças × Personas)
|
||||
- **Session log:** `_progress/agent-experiences/2026-05-27-trigger-map-D.md`
|
||||
- **Modo:** Dream (autonomous) com self-review
|
||||
- **Tempo total:** ~15-20 min de geração
|
||||
- **5 business goals canônicos:** BG-1 PMF · BG-2 Referenciabilidade · BG-3 Modernidade · BG-4 Coexistência ERPs · BG-5 Fundação técnica
|
||||
- **Driving forces por persona:** 5-7 por persona, mix positivo+negativo, scored Freq×Int×Fit
|
||||
- **Tensões críticas resolvidas:** R-7↔S+6 (vigia↔talento) · D+4↔D-6 (IA↔black-box) · Sandra ops↔Daniel estratégico · concept↔solo founder
|
||||
- **Priorização MVP fechada:** P0 (lançamento offline, multi-tenant, real-time, 0 pedidos perdidos) → MVP core → MVP-light → pós-MVP
|
||||
- **Próximo:** Phase 3 — UX Scenarios (skill `wds-3-scenarios`).
|
||||
|
||||
### 2026-05-27 — Phase 3 pausada em Step 2 (decisão estratégica de paralelizar com setup)
|
||||
- **Step 1+2 concluídos:** site type = Mixed, 65 páginas inventariadas, **7 scenarios MVP aprovados** (Marketing→Demo · Trial Onboarding · 4 cockpits · Cross-cockpit Real-Time Flow)
|
||||
- **Decisão pragmática (escolha Julian):** pausar detalhamento dos outlines em Phase 3 e **começar setup do monorepo HOJE em paralelo**. Phase 4 page specs serão feitas just-in-time por feature, junto com o PR de implementação.
|
||||
- **Outlines Phase 3 detalhados (Steps 5+):** retomar quando primeiro cockpit precisar ser implementado.
|
||||
- **Próximo:** **Setup do monorepo SAR** — pnpm + Nx + Nest + Prisma + Vite + React + Docker Compose + git Gitea.
|
||||
|
||||
---
|
||||
|
||||
## About This Folder
|
||||
|
||||
- **This file** — Single source of truth for project progress
|
||||
- **agent-experiences/** — Compressed insights from design discussions (dated files)
|
||||
- **wds-project-outline.yaml** — Project configuration from Phase 0 setup
|
||||
|
||||
**Do not modify `wds-project-outline.yaml`** — it is the source of truth for project configuration.
|
||||
@@ -0,0 +1,91 @@
|
||||
# Session Log — Trigger Mapping (Dream Mode)
|
||||
|
||||
**Date:** 2026-05-27
|
||||
**Agent:** Saga (BA / Strategic Analyst)
|
||||
**Mode:** Dream (D) — autonomous generation + final review
|
||||
**Duration target:** 15-25 min
|
||||
|
||||
---
|
||||
|
||||
## Layer 1: WDS Form (internalizado)
|
||||
|
||||
Effect Mapping by Mijo Balic & Ingrid Domingues, adapted by WDS:
|
||||
- **WHY:** Business goals (refined from brief)
|
||||
- **WHO:** Target groups (alliterative persona names)
|
||||
- **WHAT:** Driving forces (positive motivations + negative fears/frustrations)
|
||||
- **HOW:** Feature impact (mapping features to forces)
|
||||
|
||||
**Quality criteria:**
|
||||
- Personas alliterative, behavioral (não demográficas)
|
||||
- Driving forces specific, not vague (não "user wants efficiency")
|
||||
- Forces scored Frequency × Intensity × Fit
|
||||
- Feature impact direct mapping
|
||||
- Diagram mermaid Goals → Personas → Forces
|
||||
|
||||
**Common mistakes:**
|
||||
- Personas demográficos sem comportamento
|
||||
- Forces genéricas ("quer mais produtividade")
|
||||
- Pular forças negativas (medos, frustrações)
|
||||
- Não escorar forças
|
||||
- Inventar sem ancorar em discovery
|
||||
|
||||
---
|
||||
|
||||
## Layer 2: Project Context (Phase 1 destilada)
|
||||
|
||||
Disponível em contexto:
|
||||
- `01-product-brief.md` — Vision, Positioning, Personas, Business Model, Success, Competitive, Constraints
|
||||
- `02-content-language.md` — Tom, vocabulário canônico
|
||||
- `03-visual-direction.md` — Visual DNA
|
||||
- `04-platform-requirements.md` — Stack, integrações
|
||||
- `dialog/*` — 16 docs de histórico detalhado
|
||||
|
||||
**4 personas confirmadas:**
|
||||
- Rafael Representante (PRIMARY) — mobile-first, 70-90% volume
|
||||
- Sandra Supervisora — desktop+mobile, influenciadora-chave da compra
|
||||
- Daniel Dono — desktop/iPad, IA estratégica, overlap buyer persona
|
||||
- Alice Admin — desktop-only, campanhas no-code
|
||||
|
||||
**Concept canônico:** "4 cockpits especializados sobre dado único em tempo real, atravessado por WhatsApp nativo e IA contextual"
|
||||
|
||||
**Positioning:** target 5-50 reps · dor "decide no escuro" · coexistência com ERPs.
|
||||
|
||||
---
|
||||
|
||||
## Layer 3: Domain Research (skipped — Phase 1 já cobre extensivamente)
|
||||
|
||||
Domain conhecido:
|
||||
- Mercado B2B força de vendas BR (concorrentes Mercos/Promosoft/MaxFV/Workforce/Mobits)
|
||||
- ERPs com módulo (TOTVS/Sankhya/Senior/Bling/Tiny/Omie)
|
||||
- Realidade do rep externo BR (carro, 3G, comissão pesa no salário)
|
||||
- Estrutura típica PME 5-50 reps (dono decide, supervisor influencia, financeiro/TI ausentes)
|
||||
- Dor "decide no escuro" validada com Julian
|
||||
- LGPD constraints
|
||||
- Setor visual medíocre (insight Step 19)
|
||||
|
||||
Web search seria redundante — basear em context destilado.
|
||||
|
||||
---
|
||||
|
||||
## Layer 4: Generate (executando)
|
||||
|
||||
Outputs em `design-artifacts/B-Trigger-Map/`:
|
||||
- `01-business-goals.md`
|
||||
- `personas/02-rafael-representante.md`
|
||||
- `personas/03-sandra-supervisora.md`
|
||||
- `personas/04-daniel-dono.md`
|
||||
- `personas/05-alice-admin.md`
|
||||
- `06-feature-impact-analysis.md`
|
||||
- `00-trigger-map.md` (hub + mermaid)
|
||||
|
||||
---
|
||||
|
||||
## Layer 5: Self-Review (pós-generation)
|
||||
|
||||
A executar após assembly completo. Verificar:
|
||||
- [ ] Goals refinados, não copiados do brief
|
||||
- [ ] Personas com 5-7 driving forces cada (mix positivo+negativo)
|
||||
- [ ] Forces scored Freq×Int×Fit
|
||||
- [ ] Feature impact matrix completa
|
||||
- [ ] Diagram mermaid coerente
|
||||
- [ ] Trace: cada decision desta Phase 2 tem origem em Phase 1
|
||||
121
design-artifacts/_progress/wds-project-outline.yaml
Normal file
121
design-artifacts/_progress/wds-project-outline.yaml
Normal file
@@ -0,0 +1,121 @@
|
||||
# WDS Project Outline — SAR
|
||||
# Generated by skill:wds-0-project-setup on 2026-05-26
|
||||
# DO NOT MODIFY — source of truth for project configuration
|
||||
|
||||
project:
|
||||
name: SAR
|
||||
full_name: "SAR — Força de Vendas"
|
||||
company: JCS Sistemas
|
||||
type: greenfield
|
||||
product_complexity: complex
|
||||
product_kind: web-application
|
||||
created: 2026-05-26
|
||||
language: pt-BR
|
||||
|
||||
tech:
|
||||
stack: react
|
||||
stack_reference: STACK.md # canon JCS v2.2 (2026-05-24)
|
||||
details:
|
||||
runtime: Node 24 LTS · pnpm 11.1 · TypeScript 5.9
|
||||
monorepo: Nx 22.7
|
||||
backend: NestJS 11.1 (Express 5) · Prisma 7 · PostgreSQL 18
|
||||
frontend: React 19.2 + Compiler · Vite 8 (Rolldown) · TanStack Query/Router · Zustand
|
||||
api: REST + OpenAPI 3.1 + Zod 4 + nestjs-zod + react-hook-form
|
||||
auth: master-login (IdP OAuth2/OIDC próprio) · jose · argon2id
|
||||
multi_tenancy: BD-por-workspace (ADR 0006) — cluster PG por workspace
|
||||
infra: Proxmox on-prem BR · Docker Compose · MinIO · Vault · Valkey
|
||||
component_library: ant-design
|
||||
component_library_version: "6.4"
|
||||
skip_design_system: false # AntD não cobre tokens/variações JCS — Phase 7 mantida
|
||||
|
||||
phases:
|
||||
enabled:
|
||||
- phase-1-project-brief
|
||||
- phase-2-trigger-mapping # strategic_analysis: full
|
||||
- phase-3-prd
|
||||
- phase-4-ux-design
|
||||
- phase-5-agentic-development
|
||||
- phase-6-design-system # mantida apesar de AntD — overrides JCS
|
||||
- phase-7-go-live
|
||||
brief_level: complete
|
||||
strategic_analysis: full
|
||||
|
||||
structure:
|
||||
root_folder: design-artifacts
|
||||
folders:
|
||||
- design-artifacts/A-Product-Brief/
|
||||
- design-artifacts/B-Trigger-Map/
|
||||
- design-artifacts/C-UX-Scenarios/
|
||||
- design-artifacts/D-Design-System/
|
||||
- design-artifacts/E-Development/
|
||||
- design-artifacts/_progress/
|
||||
- design-artifacts/_progress/agent-experiences/
|
||||
|
||||
existing_materials:
|
||||
has_materials: true
|
||||
items:
|
||||
- path: brand.md
|
||||
type: brand-identity
|
||||
summary: "Paleta JCS (#004a99 primária), Plus Jakarta Sans, Font Awesome 6.4, Chart.js, layout topbar 80px + sidebar 260px, radius 12/20px, sombra suave. Tom Apple-inspired."
|
||||
- path: STACK.md
|
||||
type: tech-canon
|
||||
version: "2.2"
|
||||
summary: "Stack canônica JCS — Node 24 + Nest 11 + Prisma 7 + Postgres 18 + React 19.2 + AntD 6.4. Multi-tenancy BD-por-workspace. Self-host Proxmox sa-east-1 → on-prem BR."
|
||||
- path: CODING-RULES.md
|
||||
type: invariants
|
||||
version: "2.0"
|
||||
summary: "Invariantes (Zod contrato, RFC 9457 422, Vault, BullMQ, Idempotency-Key, argon2id) + pegadinhas 🔥 PGD-SEC/PGD-DB."
|
||||
- path: frontend/img/SAR_logo_fundo_transparente.png
|
||||
type: asset-logo
|
||||
- path: frontend/img/SAR_icone_fundo_transparente.png
|
||||
type: asset-icon
|
||||
- path: design-artifacts/_references/legacy-screens-html/index.html
|
||||
type: legacy-mockup
|
||||
summary: |
|
||||
SPA mockup do SAR (2251 linhas) com 9 telas: indicadores, pedidos,
|
||||
funil, agenda, novo-pedido, analise-cliente, clientes, cadastro-cliente,
|
||||
produtos. Login excluído. Usa variáveis CSS de brand.md.
|
||||
Revela 7ª tela "Painel de Desempenho" (BI) não listada nos módulos do brand.md.
|
||||
|
||||
product_context:
|
||||
description: |
|
||||
SAR é um sistema web de força de vendas SaaS B2B para representantes comerciais
|
||||
e empresas. Substitui app Android/Desktop legado. Centraliza pedidos, clientes,
|
||||
financeiro, comissões/FLEX e CRM, sincronizado com ERP.
|
||||
modules:
|
||||
- vendas # Pedidos (Orçamento→Faturado), catálogo, pautas
|
||||
- fiscal # ICMS-ST, IPI, grupos tributários por UF
|
||||
- financeiro # Títulos, recebimentos, limite de crédito
|
||||
- comissao-flex # Cálculo por rep e produto, rateio supervisor, saldo FLEX
|
||||
- crm # Funil Kanban, agenda, check-in GPS, timeline 360°
|
||||
- administrativo # Multi-empresa, configs, gestão de reps
|
||||
initial_personas_hypothesis:
|
||||
- representante-externo # Pedidos, CRM, agenda, comissão
|
||||
- supervisor-vendas # Acompanha equipe, libera descontos
|
||||
- administrador # Configurações, pautas, relatórios
|
||||
|
||||
project_context:
|
||||
stakes: small-business
|
||||
domain: b2b-saas / sales-force-automation
|
||||
market: representantes comerciais e empresas B2B (Brasil)
|
||||
competing_with: app Android/Desktop legado proprietário + planilhas + ferramentas fragmentadas
|
||||
|
||||
working_relationship:
|
||||
involvement: balanced
|
||||
role: product-owner
|
||||
presentation: recommend-with-rationale
|
||||
communication_language: pt-BR
|
||||
|
||||
agents:
|
||||
active:
|
||||
- saga # Strategy: Brief, Trigger Map, Scenarios outline
|
||||
- freya # Design: UX, Page Specs, Design System
|
||||
triggers:
|
||||
PB: saga # Project Brief
|
||||
TM: saga # Trigger Map
|
||||
SC: saga # Scenarios outline
|
||||
UX: freya # Page specs
|
||||
SA: freya # Spec audit
|
||||
DS: freya # Design System
|
||||
|
||||
next_phase: wds-1-project-brief
|
||||
BIN
design-artifacts/_references/jcs-logo/LOGO - PRETO.png
Normal file
BIN
design-artifacts/_references/jcs-logo/LOGO - PRETO.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
design-artifacts/_references/jcs-logo/LOGO-BRANCO.png
Normal file
BIN
design-artifacts/_references/jcs-logo/LOGO-BRANCO.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
design-artifacts/_references/jcs-logo/logo_azul.png
Normal file
BIN
design-artifacts/_references/jcs-logo/logo_azul.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
BIN
design-artifacts/_references/jcs-logo/logo_branco_trans.png
Normal file
BIN
design-artifacts/_references/jcs-logo/logo_branco_trans.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
2252
design-artifacts/_references/legacy-screens-html/index.html
Normal file
2252
design-artifacts/_references/legacy-screens-html/index.html
Normal file
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user