- 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>
5.6 KiB
Business Goals — SAR (Phase 2: Trigger Mapping)
Created: 2026-05-27
Phase: 2 — Trigger Mapping (Workshop 1: Business Goals)
Source: refinado de 01-product-brief.md Steps 1a (Internal Driver), 3 (Positioning), 8 (Success Criteria)
Goals refinados do brief, traduzidos em outcomes mensuráveis que alimentam o mapa Goals → Personas → Forces → Features.
North Star
Tornar a JCS Sistemas referência em SaaS de força de vendas no mercado B2B brasileiro através do SAR — posicionando a empresa além da base atual de clientes, com produto moderno, multi-tenant e referenciável.
Esta é a North Star de negócio JCS (não do produto SAR). O sucesso do SAR alimenta a percepção da JCS como SaaS-maker moderno.
5 Business Goals canônicos
🎯 BG-1: Validar Product-Market Fit no MVP
Outcome esperado:
1º cliente real paga e renova sem cancelar nos primeiros 3 meses pós go-live.
Métricas:
- Conversão de trial → contrato pago: ≥ 80% (vai ser parceiro próximo no MVP)
- Renovação 3 meses: 100% (1 cliente, não pode falhar)
- NPS do dono do 1º cliente: > 50
- DAU/MAU dos reps: > 70% após 30 dias de uso
Por quê importa: sem PMF provado, escalar é multiplicar dúvida. Renovação > tração.
🎯 BG-2: Construir base referenciável Y1
Outcome esperado:
10-20 clientes pagantes ao final de Y1 com permissão de uso público como case + NPS > 50.
Métricas:
- Clientes pagantes: 10 (conservador) a 20 (esticado) em 12 meses
- ARR Y1: R$ 200k-600k
- Logo churn mensal: < 3%
- Cases publicados: ≥ 3 com permissão e mídia
- Indicações geradas por cliente atual: ≥ 1 lead qualificado/cliente/trimestre
Por quê importa: referenciabilidade alimenta canal #1 (boca-a-boca). Sem cases públicos, JCS depende de SEO/feiras sozinhos.
🎯 BG-3: Estabelecer SAR como referência de modernidade no setor
Outcome esperado:
Quando alguém do setor (concorrente, parceiro, cliente potencial) pensar em "como deveria ser um SaaS de força de vendas hoje", o SAR é o exemplo.
Métricas:
- Menções orgânicas em comunidades B2B BR (LinkedIn, fóruns de varejo, eventos)
- Posicionamento SEO em top 5 para keywords primárias (
software de força de vendas,alternativa ao Mercos) - Velocidade de iteração visível (changelog público, releases mensais pós-MVP)
- NPS visual qualitativo (donos comentando "design moderno" nas conversas de venda)
Por quê importa: Step 19 revelou que estética moderna é diferencial fundacional, não cosmético. Mercado é visualmente medíocre.
🎯 BG-4: Habilitar coexistência com ERPs existentes como porta de entrada
Outcome esperado:
Cliente que tem TOTVS/Sankhya/Senior compra o SAR sem precisar trocar o ERP. SAR é "camada de vendas" via API, não substituição.
Métricas:
- % clientes Y1 vindos de "stack improvisado" (Excel+WhatsApp+ERP sem módulo): 40-50% (segmento "primeira ferramenta de verdade")
- % clientes Y1 com integração ERP ativa (TOTVS, Sankhya, Omie, etc.): 30-40%
- Tempo médio de setup de integração ERP por workspace: < 5 dias úteis
Por quê importa: dobra o TAM imediato — empresas com ERP entrincheirado eram leads frios; viram quentes. Multi-tenant BD-por-workspace facilita arquiteturalmente.
🎯 BG-5: Construir fundação para escala pós-MVP
Outcome esperado:
Quando 1º cliente renovar (north star MVP atingida), JCS está pronta para contratar 1-2 devs e escalar sem refatorar tudo.
Métricas:
- Coverage de testes (unit + integration + e2e): ≥ 70% / 25% / 5% (pirâmide canon STACK.md §16)
- Observabilidade completa (OTel + Pino + Grafana + Sentry + PostHog) no MVP
- Documentação ADR atualizada (ADRs 0001-0006 + novas conforme RFC)
- 0 pedidos perdidos por bug ou sync (P0 sempre)
- Onboarding de novo dev < 5 dias até primeira PR mergeada
Por quê importa: evitar técnica debt fundacional. Solo founder mode é phase, não destino.
Hierarquia e relações entre os 5 goals
BG-1 PMF do MVP (3 meses)
│
▼
BG-2 Base referenciável Y1
┌─────┴─────┐
▼ ▼
BG-3 Marca BG-4 Coexistência ERPs
↓ ↓
└──── BG-5 Fundação para escala ────┘
- BG-1 é precondição para BG-2 e tudo que vem depois
- BG-3 (marca) e BG-4 (ERPs) são paralelos — alimentam BG-2
- BG-5 (fundação técnica) viabiliza os 4 anteriores escalarem sem dívida
Forças que vão atrás dos goals
Cada business goal precisa de comportamento humano que o realize. Phase 2 vai mapear isso:
| Business Goal | Pessoa que precisa agir | Comportamento esperado |
|---|---|---|
| BG-1 PMF | Rafael + Sandra do 1º cliente | Usar diariamente; preferir SAR sobre WhatsApp/Excel; valor percebido > preço |
| BG-2 Referenciabilidade | Daniel (dono do cliente) | Recomendar publicamente; aceitar virar case |
| BG-3 Marca | Mercado externo (concorrentes, observadores) | Notar diferencial visual + estrutural |
| BG-4 Coexistência | Daniel + TI (eventual) | Aceitar integração ERP como modelo, não migração |
| BG-5 Fundação | Julian + futuros devs JCS | Disciplina ADR/CODING-RULES; observabilidade desde dia 1 |
Próximo (Workshop 2): Target Groups
Refinar as 4 personas em archetypes acionáveis com naming aliterativo:
- Rafael Representante (PRIMARY)
- Sandra Supervisora
- Daniel Dono
- Alice Admin
Cada persona ganha seu próprio arquivo em personas/.