Files
sar/design-artifacts/B-Trigger-Map/01-business-goals.md
julian 17c08e6392 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>
2026-05-27 14:34:20 +00:00

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/.