Boundary white-label & customização controlada (Fase 8.4)
Use o Sign como capability embutida com branding honesto — não white-label total como pacote fechado. Matriz e limites no repositório.
A — Standard B•Code Sign
Branding e fluxo padrão
Portal, assinante em /sign/:token e API com identidade B•Code Sign. Personalização de contrato e operação (planos Commerce OS), não de casca white-label da plataforma.
B — Customização controlada
Integração + narrativa honesta
API, webhooks, deep links; no seu produto a UX pode envolver o Sign como capability. Comunicação externa pode usar “powered by” / co-marca na sua camada — o fluxo hospedado permanece em grande parte B•Code Sign.
C — White-label forte (aspiracional)
Não como pacote fechado hoje
Eliminar marca B•Code em todas as superfícies, domínio dedicado por tenant na UI do assinante ou portal OEM isolado exige evolução técnica/comercial — avaliação sales-led, não self-serve.
Checklist rápida (OEM / WL)
- ?Basta API e webhooks (e portal para operação)?
- ?Precisa só de branding parcial na comunicação do parceiro (ex.: “powered by”)?
- ?Exige domínio próprio na experiência do assinante?
- ?Exige fluxo do assinante sem marca B•Code?
- ?Exige portal isolado por parceiro/OEM?
Controlled branding (Fase 8.6)
O que é concreto hoje: identidade da empresa (nome/documento) e título do contrato no fluxo do assinante; integração e “powered by” na sua camada. Logo, cores e domínio próprio na UI do assinante não são pacote self-serve fechado.
- → Assinante ainda vê produto B•Code Sign na experiência hospedada — não é white-label total.
Três níveis de oferta
A — Produto direto
SaaS e portal
Cliente usa o B•Code Sign como produto: portal em /dashboard/sign/*, planos no Commerce OS, operação manual ou semi-automatizada. Ideal para validar valor antes de embutir.
B — Infraestrutura / integrador
API, webhooks, evidence
Software de terceiros integra via API keys test/live, webhooks HMAC, documentação pública e proof pack quando o fluxo permite. Mesmos planos; integrador conduz implementação — ver também /bcode-sign/partners.
C — OEM / embedded readiness
Capability no seu software
Uso embutido: fluxos disparados do seu produto, assinatura em /sign/:token, jurídico e evidências no motor B•Code. Branding do assinante e URLs ainda são em grande parte B•Code Sign — não prometemos white-label total nesta fase; casos fortes → alinhamento comercial/técnico.
Pacote OEM operacional (Fase 8.8)
Estrutura comercial-operacional sobre o mesmo produto e planos (Commerce OS): como o caso é conduzido — sem SKU “OEM” separado no catálogo.
Embedded Ready
Self-serve ou integrador-led
Conta ativa, plano no Commerce OS, API keys test/live, webhooks, fluxo /sign/:token e validação em homologação. Ideal para quem integra sem projeto comercial dedicado.
Embedded Assisted
Onboarding alinhado (processo, não SKU)
Mesmos planos e produto; time comercial/técnico ajuda sequência de go-live, limites de branding e critérios de aceite. Use quando o parceiro precisa de ritmo guiado.
Enterprise / OEM avaliado
Volume, SLA, branding agressivo → conversa
Avaliação explícita do que é possível hoje (readiness + boundary 8.4–8.7) vs roadmap. Não promete white-label forte nem domínio próprio como padrão.
Checklist operacional de go-live
Técnico
- API keys sk_test_* e sk_live_* criadas e rotacionadas conforme política
- Webhooks com HMAC validado (eventos de envelope e assinatura)
- Fluxo test → live com contadores separados
- Chamadas idempotentes e tratamento de 402/limites
Superfície e suporte
- Surface settings revisados: suporte, textos de ajuda ao signatário (8.7)
- Limites de branding e white-label compreendidos (8.4–8.6)
- Links de docs técnicas compartilhados com integradores
Validação
- Assinatura de ponta a ponta em test e dry-run em live
- Proof pack / evidência conferidos no fluxo real
- Responsável operacional interno definido (owner)
Comercial
- Plano e entitlement Sign ativos (Commerce OS)
- Caminho definido: self-serve vs assisted vs avaliação enterprise
Superfícies e embedded
1) Operator surface
Portal do cliente
Billing, API keys, webhooks, contratos, evidências, onboarding — /dashboard/sign/*.
Templates e operação
O que o tenant configura no portal; limites via Commerce OS.
2) Signer surface
/sign/:token
Experiência do assinante final: fluxo jurídico estável (não alterado nesta fase). Personalização forte de marca do parceiro na UI do assinante não é oferta fechada — pode haver evolução futura.
3) Integrator surface
API e webhooks
Integração produtiva com idempotência, ambientes separados, docs públicas e OpenAPI subset.
Proof pack e evidence
Export verificável quando o plano e o fluxo permitem; mesma cadeira de custódia do produto.
4) OEM readiness layer (hoje)
O que já pode ser embutido
Chamar API a partir do seu software, receber eventos, abrir links de assinatura, usar portal para operação. “Powered by” / positioning honesto na sua comunicação.
O que ainda depende de evolução
White-label completo, domínio dedicado do parceiro na UI do assinante, portal isolado por OEM — fora do pacote fechado atual.
Casos de uso embutidos
SaaS vertical
Contratos e aditivos dentro do seu produto: criação via API, assinatura no fluxo /sign/:token, status por webhook.
ERP / CRM
Disparo a partir do sistema de registro; acompanhamento de envelope até conclusão; arquivo com proof pack quando aplicável.
Produto no ecossistema B•Code
Outro produto B•Code consome o Sign como capability — alinhamento técnico e comercial.
Software house para clientes finais
Revenda de valor com integração: mesma base que integradores (Fase 8.1), com ênfase em UX embutida no software do cliente.
Enterprise — Sign nos bastidores
Operação quer motor jurídico e evidências sem expor marca B•Code ao usuário final: possível parcialmente via UX do seu app; eliminar toda marca B•Code nas superfícies não é prometido aqui.
O que não prometemos (nesta fase)
- ×White-label total da experiência do assinante ou do portal
- ×Portal 100% isolado por parceiro/OEM nesta fase
- ×Substituir a marca B•Code Sign em todas as superfícies apenas por configuração
- ×Programa de canal com revenda formal (ver Fase 8.1)
- ×SKU separado “OEM” no catálogo — o pacote é operacional, não produto distinto
Readiness checklist
Já pronto (self-serve)
- API keys test e live
- Webhooks configuráveis com HMAC
- Ambientes test/live separados
- Fluxo público do assinante /sign/:token
- Proof pack e evidence bundle conforme plano e fluxo
- Documentação pública e hub /bcode-sign/docs
- Portal do tenant para operação e billing (Commerce OS)
- Surface settings (8.7): suporte e textos de ajuda quando aplicável
Sales-led / avaliação
- →Embedded Assisted: onboarding técnico/comercial alinhado (não é SKU; é processo)
- →OEM com requisitos de marca/domínio agressivos
- →Enterprise / OEM avaliado: SLA, volume, governança — mesmo núcleo Commerce OS
- →Qualquer promessa de white-label total antes de validação técnica/comercial
Validação do motion (Fase 8.8.1)
Ciclo curto para testar se o pacote atual é compreendido antes de abrir roadmap pesado (ex. white-label forte). Use em discovery: qual postura faz sentido?
- Embedded Ready — self-serve / integração sem projeto comercial dedicado.
- Embedded Assisted — go-live alinhado com o time (processo, não SKU novo).
- Enterprise / OEM avaliado — volume, SLA ou marca agressiva → conversa explícita sobre o que existe hoje vs roadmap.
Documentação: PHASE82_OEM_EMBEDDED_READINESS.md · PHASE88_OEM_OPERATIONAL_READINESS_AND_COMMERCIAL_PACKAGING.md · PHASE881_OEM_MOTION_VALIDATION_CYCLE.md
Qualificação comercial: guia de descoberta (GitHub) · Sales enablement (8.3)