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.
|
||||
Reference in New Issue
Block a user