REDE · PORTAL DO CLIENTE
Seu cliente faz pedidos com quinze fornecedores por ano. A maioria envia faturas em PDF e espera ser acionada para saber o status. As aprovações acontecem por e-mail e travam no momento em que alguém se esquece de responder. ”Onde está o meu pedido?” chega cinquenta vezes por semana na caixa de entrada do seu time de CS. Reclamações e disputas vivem em threads de e-mail de três dias e depois somem em pastas compartilhadas. O cliente sai achando que sua empresa funciona com PDFs.
O TradeOS Portal do cliente é exatamente esse portal — totalmente com a marca do seu operador. Nove seções reais: pedidos, produção, embarques, faturas, reclamações, amostras, aprovações, mensagens, conta. Três máquinas de estado (reclamações · amostras · aprovações). Trilhos Stripe Connect. Redação na camada de serviço — fornecedor e margem nunca cruzam a fronteira.
Agendar demonstraçãoVer preços →
Seções do portal
9 · pedidos, embarques, finanças, reclamações e mais 4
Máquinas de estado
Reclamações, amostras, aprovações
Identidade multi-operador
Um único acesso, todos os seus operadores, visão unificada
Custo para o cliente
$0 · vagas ilimitadas
O operador propõe aumentar a quantidade do lote 4 de 150K para 200K unidades. Mesma especificação, mesma data de embarque. Variação líquida: +$140,000 · dentro do limite director-tier de $200K. Solicitado há 11 min.
O Painel home real — chrome com identidade visual do operador, navegação em 9 seções, faixa de status hero, prompt de ação para aprovações pendentes, grade de duas colunas com embarque ativo e central de faturas, feed de atividade recente. Uma única chamada de backend (GET /api/portal/client/dashboard) retorna tudo. O Painel se adapta por 4 ClientDashboardMode estados conforme a primeira sessão do cliente avança (novo → em produção → em trânsito → ativo).
A CAIXA DE ENTRADA QUE NUNCA ESVAZIA
O trabalho é real: os Clientes querem saber onde estão seus Pedidos, querem aprovações rápidas e querem sentir que estão lidando com uma empresa séria. A solução padrão — PDF + e-mail + pastas compartilhadas — custa dias por semana à sua equipe de CS e custa ainda mais à sua taxa de renovação.
01 · ”ONDE ESTÁ MEU PEDIDO?” VIVE EM 50 E-MAILS POR SEMANA
O Cliente quer saber se RD-2026-018 foi embarcado. Ele envia um e-mail ao Procurement, que envia às operações, que abre quatro seções e redigita a resposta manualmente. Quando o e-mail chega, o lote já avançou duas etapas. Multiplicado por vinte clientes, são dois dias por semana de tempo de CS gastos com atualizações que o sistema já possui.
02 · APROVAÇÕES TRAVAM EM CADEIAS DE PDF
Você envia uma cotação, um pedido, uma contraproposta. O Cliente diz que precisa escalar. Três dias depois você faz um follow-up. Ele havia esquecido. Dois dias depois a aprovação chega por e-mail — mas as condições que você havia atualizado nesse intervalo não estão refletidas. O negócio avança na velocidade da caixa de entrada mais lenta.
03 · VOCÊ PARECE UMA FÁBRICA DE PDFs
Seu Cliente compra de quinze fornecedores por ano. O que tem um portal com identidade própria — Pedidos, Embarques, reclamações, aprovações em uma única interface — é percebido como uma categoria diferente de empresa. Ele é renovado. Você volta para a shortlist de RFP.
9 SEÇÕES · UM PORTAL
Dados CLIENT_NAV.flatLinks em tempo real de client/src/lib/navConfig.ts. A navegação inferior mobile usa quatro itens: Home · Pedidos · Pagamentos (a rota /invoices renomeada, porque os clientes pensam ”estou pagando coisas”) · Mensagens.
Painel adaptativo de 1.710 linhas. Status hero + prompt de ação + grade de 2 colunas com embarque ativo (mapa D3) e central de faturas. Quatro ClientDashboardMode estados para renderização em primeira sessão vs. relacionamento em curso.
Aceite de PO, aditivos, itens de linha, lotes, vínculo com embarques. Lista de 608 linhas + detalhe de 964 linhas. Roteamento de aprovações via mecanismo de tarefas.
Acompanhe a fabricação das mercadorias — fases de produção, progresso por unidade fabril, rastreamento de lotes. Identidade da fonte sempre anonimizada (suprimida na camada de serviço).
Mapa D3 + topojson, marcos em tempo real (reservado → carregamento → partido → chegado), anexo de documentos. O mesmo renderizador utilizado na página inicial.
Lista de faturas + detalhe de 764 linhas. Pagamento via Stripe Connect (4 modalidades). No mobile, esta seção é renomeada para Pagamentos na barra de navegação inferior.
Acesso controlado por tags de visibilidade. CO, BL, lista de embalagem, CI, COA, seguro, fitossanitário, QC. Exportação assíncrona (pedidos/faturas/documentos/mensagens/auditoria).
Tarefas com escopo restrito ao cliente. Geradas automaticamente pelas ações do portal do cliente no lado do operador via auto-tasks.service.ts. Aprovações também residem aqui (task_category='approval').
Mensagens em threads com o operador. Associadas por entidade (pedido, fatura, embarque, reclamação, amostra). Preferências de notificação em 5 categorias.
Análises no nível de relacionamento. Agregadas entre operadores no nível Business+ ou superior (funcionalidade cross_operator_analytics real).
RECLAMAÇÕES & AMOSTRAS · FLUXOS COMERCIAIS
Todo relacionamento B2B gera eventos comerciais que não são Pedidos nem faturas — problemas de qualidade, embarques incompletos, solicitações de amostras, aprovação de amostra de referência. A maioria dos softwares operadores trata esses eventos como trocas de e-mail fora do sistema. O TradeOS os trata como entidades de primeira classe com máquinas de estado impostas.
RECLAMAÇÕES · MIGRAÇÃO 165 · 6 ESTADOS
Tabela real client_claims. Seis tipos de reclamação cobrindo todo o universo de ”temos um problema com a mercadoria” — distintos de disputas de fatura (que tratam do conteúdo da fatura, gerenciadas separadamente na mig 166).
Ramificações: escalated · cancelled. Seis modalidades de resolução (replacement_shipment · credit · refund · price_concession · no_action · dispute). Fotos e evidências em JSONB. Três níveis de gravidade (minor / major / critical). O cliente abre e aceita propostas; o operador investiga e propõe resoluções — caminhos de escrita distintos em serviços separados.
AMOSTRAS · MIGRAÇÃO 163 · 8 ESTADOS
Tabela real sample_requests. Cinco tipos de amostra cobrindo o ciclo de validação do ”primeiro envio da fábrica” ao ”padrão de referência retido por ambas as partes”.
Ramos de decisão: approved_with_conditions · rejected · cancelled. Fotos e anotações de ambas as partes. Amostras de referência têm datas retain_until (tipicamente 2 anos). O portal gerencia todo o fluxo — solicitação, upload de fotos, anotação, decisão, retenção — sem recorrer ao e-mail.
ESCALA COM SEUS CLIENTES
O mesmo portal atende o comprador de bairro e a organização de Procurement de uma Fortune 500. Os cinco reais client.*_approvals recursos de tier (migração 161) liberam progressivamente um roteamento mais rico conforme o tier do operador avança. O processo de Procurement do cliente é respeitado, não imposto.
TIER · STARTER (PADRÃO PME)
1 aprovador · sem roteamento
Proprietário / Comprador
AUTORIZAÇÃO TOTAL · QUALQUER VALOR
aprovar
CHAVE DE RECURSO REAL
client.single_approver_workflow
CLIENTE EXEMPLO
Rede independente de farmácias · 4 unidades · $80K/mo em gastos
NÍVEL · SOLO+ / EQUIPE+
3 aprovadores · escalonamento por valor
Líder de equipe
EQUIPE DE COMPRAS
< $50K
Diretor
DIRETOR · COMPRAS
$50K — $200K
VP · Cadeia de Suprimentos
VP · CADEIA DE SUPRIMENTOS
> $200K
CHAVES DE RECURSOS REAIS
client.amount_based_approvals(Solo+) ·client.sequential_multi_step(Business+)
CLIENTE EXEMPLO
Distribuidor médico regional · 14 unidades · $4M/mês em compras
NÍVEL · BUSINESS+ / ENTERPRISE
Configurável · n-of-m · políticas de delegação · log de auditoria
Solicitante
LÍDER DE UNIDADE
enviar
Responsável pelo centro de custo
APROVAÇÃO FINANCEIRA
qualquer
Qualidade / Compliance
REGULADO · MÉDICO
QA
Segurança / Risco de fornecedor
SAML · ENTERPRISE
risco
VP · Cadeia de Suprimentos
RESPONSÁVEL FUNCIONAL · DELEGAÇÃO OK
< $5M
Aprovação do CFO
EXEC · COM DELEGAÇÃO
> $5M
CHAVES DE RECURSOS REAIS
client.parallel_approvals · client.delegation_policies · client.category_based_approvals(Business+) ·client.custom_approval_builder(Enterprise)
CLIENTE EXEMPLO
Rede hospitalar Fortune 500 · 200 unidades · $40M/mo em gastos
ISOLAMENTO DE DADOS · ARQUITETURAL
Um portal de clientes que expõe seus fornecedores ou suas margens é um portal que você não coloca em produção. Transparência total no status; opacidade total na origem. Cada campo visível foi deliberadamente exposto; todo o restante é invisível antes que a linha saia do banco de dados.
Apenas os próprios Pedidos, os próprios dados
Um cliente nunca vê outro dos seus clientes na plataforma. Escopo por conexão na camada de serviço; a visão consolidada entre operadores (Starter+) agrega apenas os dados desse cliente nos operadores aos quais ele está conectado.
Nunca seus fornecedores ou Fabricantes
”Produção em andamento” — sem nome de Factory, sem país, sem localização do lote. O verdadeiro redactFor() em server/src/modules/portal-shell/redaction.ts reescreve a linha antes que ela saia do serviço.
Nunca seus custos, margens ou estrutura de preços
O cliente vê seu preço comercial. Ele nunca vê o que você pagou à fábrica, sua base de custo de frete, nem o que outros clientes no mesmo SKU são cobrados.
Redação de Documentos na camada de serviço
Mesmo que um documento contenha uma referência de fornecedor nos metadados — um bloco XMP de PDF, um cabeçalho de Excel, uma marca d'água — ele é reescrito antes da entrega. Nenhum vazamento por arquivo compartilhado acidentalmente.
Nenhuma configuração para definir incorretamente
Não existe interface de administração onde um operador possa ativar por engano a exposição de custos. O limite está codificado; a única forma de contorná-lo é uma revisão de código submetida à validação de deploy.
OPERATOR-BRANDED · ELES VÊM VOCÊ, NÃO O TRADEOS
Seus clientes não escolhem fornecedores com base no software de back-office que você utiliza — escolhem com base em como o fornecedor se apresenta. O Portal do cliente é a principal interface do operador para essa apresentação. Cada byte visível é exibido sob a sua marca.
LAYER 01 · SEU LOGO, SUAS CORES
DISPONÍVEL A PARTIR DO · Solo TIERFaça upload de um logo, escolha uma cor principal de marca, e cada artefato que o cliente acessa a herda — interface do portal, faturas em PDF, contratos assinados, notificações por e-mail, manifestos para download. A marca verbal TradeOS fica restrita a um pequeno rodapé no portal; nos Documentos, ela não aparece.
CAMADA 02 · DOMÍNIO PERSONALIZADO
DISPONÍVEL A PARTIR DE · ENTERPRISE TIERSeus clientes nunca digitam ”edma” ou ”tradeos” em um navegador. Um client.custom_domain recurso-chave do Enterprise Tier — white-label completo conforme a migração 161. O portal é servido a partir do seu próprio DNS, com um certificado provisionado para o seu domínio. A barra de endereços faz parte da sua marca — e permanece limpa desde o login até a fatura paga.
O envio de e-mail pelo operador (saída assinada com DKIM a partir do seu domínio) está no roadmap — registrado com transparência no §13 abaixo.
UM CLIENTE · VÁRIOS OPERADORES · VISÃO UNIFICADA
Uma entidade jurídica cliente conectada a múltiplos operadores no TradeOS obtém uma visão de leitura unificada por meio da verdadeira client.cross_operator_account feature key (nível Starter+, migração 161) e o endpoint /cross-operator/dashboard em portal-client/services/cross-operator.service.ts.
Um usuário, um login, todos os seus operadores em uma única tela — com isolamento por conexão preservado. Os dados de cada operador permanecem restritos à respectiva conexão; a agregação ocorre apenas no nível seguro de resumos (contagens, totais, sem vazamento de PII entre operadores). Análises entre operadores a partir do nível Business+.
Esta é uma desvio deliberado em relação à FAQ que muitos produtos SaaS de portal de clientes apresentam — "a identidade do cliente é limitada ao operador, sem visões entre operadores." O TradeOS expõe a visão unificada porque os clientes realmente precisam dela e o isolamento por conexão na camada de agregação é a salvaguarda arquitetural, não a ausência da superfície.
PAGAMENTOS · STRIPE CONNECT
Real client.direct_payment_rails feature key (Starter+, migração 161). Quatro trilhos Stripe Connect — cartão · ACH · SEPA · BACS. O histórico de pagamentos em leitura é disponibilizado no lançamento; a superfície INITIATE é entregue com o receptor de webhook Stripe, atualmente pendente do marco v1.1. Ambas as superfícies estão sinalizadas abaixo para que você saiba exatamente o que está integrado vs. pronto na interface.
CARTÃO
Visa, MC, Amex via Stripe. Liquidação imediata. Ideal para Clientes PME que priorizam velocidade; não recomendado para faturas de alto valor onde a taxa é relevante.
ACH
Transferência bancária nos EUA. Liquidação em 2 dias. Padrão para faturas de alto valor. Menor taxa por dólar movimentado.
SEPA
Transferência bancária na UE. Liquidação em 2 dias em toda a zona SEPA. Padrão para Clientes europeus que pagam operadores europeus.
BACS
Transferência bancária no Reino Unido. Liquidação em 3 dias. Padrão para Clientes britânicos. Substitui o débito direto em fluxos de pagamento avulsos.
ESTADO
Superfície READ ativa · Superfície INITIATE entregue com o receptor de webhook Stripe (v1.1)
Pagamentos agendados e recorrentes a partir do tier Business+ (client.scheduled_payments)
AI · EM EVENTOS DO PORTAL DE CLIENTES
Cada interação do cliente no portal é um evento sobre o qual a stack de AI pode agir. As mesmas regras de isolamento de dados se aplicam — o Atlas raciocina sobre o escopo do próprio cliente, nunca sobre o de seus outros Clientes.
AATLAS · REDAÇÃO DE RESPOSTAS AO CLIENTE
O cliente pergunta ”podemos antecipar em 3 dias?” O Atlas consulta o progresso atual da Produção, as opções de frete, o impacto nos preços e redige uma resposta no seu tom. Você clica em enviar. O registro é atualizado automaticamente.
▶ FWD ATLAS · A. Kohl @ Brevin"Can we accelerate PO 0418 by 3d?"▶ ATLAS · draft reply"Yes — air-freight lot 3 for +$14K (currently 78% production, ETA Jul 18 instead of Jul 21). Confirm by EOD Tuesday and we'll book."→ context · production · freight · margin (private)
BBOT STUDIO · EM APROVAÇÕES DE CLIENTES
Você configura o bot uma única vez. Ele monitora eventos de aprovação do cliente: atualiza automaticamente o plano de produção do fornecedor, redige a nota ao agente de cargas, recalcula o cronograma de faturas e só escala para um humano quando a alteração ultrapassa um limite definido.
▶ BOT client-approval-cascade · v2.4→event ·approve · +50K units→supplier plan ·lot 4 updated→forwarder ·capacity check requested→invoice schedule ·+$140K · INV-019→human ·none required
$ACCOUNTING AI · EM PAGAMENTOS DE CLIENTES
O cliente paga $560K via ACH. A Accounting AI associa o canal de pagamento à fatura, lança no seu livro-razão, sinaliza qualquer pagamento a menor com base em uma política de retenção conhecida, e exibe apenas os casos que precisam de análise humana.
▶ ACCOUNTING AI rail match · v1.8→ ACH · $560,000 · ref MERIDIAN-018→matched ·INV-2026-018 · 100%→ledger ·posted · AR cleared→next ·INV-019 holdback 2.3% · review
COMPARATIVO
E-mail e PDF são a solução dominante — ganham na familiaridade, perdem em tudo o mais. Customer Communities e Ariba ganham no Procurement enterprise, perdem no branding do operador e na proteção de margem. Portais internos ganham em flexibilidade, perdem seis meses depois.
| Funcionalidade | TradeOS Portal do Cliente | E-mail + PDF | Salesforce Customer Communities | Ariba Buyer (imposto a você) | Portal custom interno |
|---|---|---|---|---|---|
| Portal com marca do operador (seu domínio, suas cores) | ✓ portal.yours.com · nível Enterprise | ✓ sua assinatura | suas cores, Salesforce URL | — marca SAP | ✓ |
| Visibilidade de status em tempo real · mesmo registro | ✓ chamada única ao backend | — manual | via Integrações | sync assíncrona | DIY |
| Aprovações inline · um toque até o construtor personalizado | ✓ 5 níveis vinculados ao tier | — PDF + e-mail | ✓ construtor de fluxo | ✓ somente Enterprise | DIY |
| Trilhos de pagamento Stripe Connect (cartão · ACH · SEPA · BACS) | ✓ todos os 4 · taxas transparentes | — somente transferência | via terceiros | ACH · transferência | — raro |
| Visão unificada entre operadores (um login, todos os seus operadores) | ✓ funcionalidade Starter+ | — N/A | — silo por organização | — silo por organização | — Faça você mesmo |
| Isolamento de dados entre tenants imposto pela arquitetura | ✓ redactFor() na API | — vazamentos acidentais | nível de organização | nível de tenant | — Faça você mesmo |
| Workflows de reclamações + amostras (máquinas de estado) | ✓ 6 + 8 estados · live | — e-mail ad hoc | módulo de cases | — fora do sistema | — Faça você mesmo |
| SAML SSO no tier Enterprise | ✓ client.saml_sso | — | ✓ SF Identity | ✓ | DIY |
| Acessos gratuitos para Clientes (operador paga pelo TradeOS) | ✓ ilimitado no tier | ✓ e-mail é gratuito | — por usuário community | — por assento | ✓ interno |
| Integração de IA nativa (Atlas · Bots · Contabilidade) | ✓ configurado por cliente | — solução própria necessária | add-on Einstein | add-on Joule | — |
O e-mail é o verdadeiro incumbente — e vence pela familiaridade por uma boa razão. Os clientes dominam o PDF. O Portal do cliente não tenta substituir o e-mail sendo mais impressionante; tenta substituí-lo sendo mais simples que o e-mail nas áreas em que o e-mail falha: visibilidade de status, roteamento de aprovações, pagamento, reclamações, amostras, anexação de documentos ao PO correto e evitar que o operador pareça um fornecedor rodando em Excel.
CONTROLE POR NÍVEL · 19 FUNCIONALIDADES
O registro tier_features real (migração 161) define dezenove gates de funcionalidades do portal do cliente. Os clientes nunca veem um paywall; o tier do operador conectado define o que está disponível no seu workspace para aquele operador. Roteiro identifica funcionalidades cujo tier_feature key está registrado, mas cuja implementação de UI/motor é pós-lançamento.
NO ROADMAP
A v1 entrega nove seções, três máquinas de estado, quatro rails de pagamento Stripe Connect (lado READ em produção), identidade multi-tenant com visão unificada entre operadores, redação na camada de serviço, instalação PWA, overlay de onboarding + checklist por nível, tarefas automáticas, exportação de dados e gating por nível em dezenove chaves de funcionalidades. As capacidades abaixo estão sinalizadas com transparência — suas chaves tier_feature existem, mas a UI, o motor e a integração chegam após o lançamento.
01
A superfície READ (histórico de pagamentos) está em produção. O lado INITIATE — POST /invoices/:id/pay — está em stub aguardando o receptor de webhook Stripe que registra as linhas de pagamento. Conforme payments.service.ts: ”Em stub exatamente como createSetupIntent. Lança ValidationError com os próximos passos documentados.”
02
Confirmações de pedidos, solicitações de aprovação, alertas de embarque, avisos de fatura — entregues a partir de [email protected], não da infraestrutura TradeOS. SPF, DKIM, DMARC configurados no seu DNS. Ainda não implementado; nível Enterprise quando disponível.
03
O SSO SAML está ativo no nível Enterprise (client.saml_sso). OIDC e o provisionamento automático SCIM chegam a seguir — mesmo gate Enterprise. O SCIM remove o acesso quando o sistema de RH do cliente desativa um usuário, mantendo o acesso ao portal alinhado à fonte de dados do cliente.
04
Chave de funcionalidade real client.order_templates a partir de Business+ (mig 161, sinalizada como «UI pós-lançamento»). O schema está pronto; o seletor de modelos salvos e o fluxo de recompra com um clique chegam após o lançamento.
05
client.custom_approval_builder no nível Enterprise. O motor de runtime está em funcionamento (paralelo, sequencial, n-of-m, delegação, roteamento por categoria — tudo operacional); a UI do builder visual para operadores não técnicos chega após o lançamento. Operadores no nível Enterprise podem solicitar workflows construídos manualmente até lá.
06
client.edi_integration no nível Enterprise (mig 161). Para clientes enterprise que utilizam EDI, o fluxo de pedidos/embarques/faturas chega diretamente via X12 / EDIFACT em vez da UI do portal. Schema reservado; os adaptadores de integração são entregues por cliente conforme os contratos Enterprise são fechados.
07
Os quatro rails Stripe Connect (cartão / ACH / SEPA / BACS) cobrem o universo de rails digitais. Wire e LC são rails fora de banda que o operador ainda pode registrar manualmente em uma fatura hoje. Os fluxos nativos do portal para confirmações de transferência e rastreamento de apresentação de LC chegam à medida que os casos de uso se concentrarem.
08
A PWA é a superfície mobile do cliente v1 (manifest + service worker + InstallNudge — já em produção). Os aplicativos nativos com autenticação biométrica, APIs de câmera nativas e notificações push chegam após o lançamento.
FAQ
Respostas diretas às perguntas que distribuidores, importadores e proprietários de trading companies nos fazem durante a chamada de demonstração.
Sim — mas ele é apresentado como o seu sistema. Eles veem o seu logotipo, as suas cores e, no nível Enterprise, um domínio personalizado (portal.yourcompany.com com o seu próprio certificado SSL). A maioria dos clientes prefere isso a perseguir PDFs por e-mail; os operadores que fizeram a migração relatam que as equipes de procurement pedem o portal primeiro, e não o contrário.
Agendar demonstração de 30 minutos. Configuramos um Portal do cliente em sandbox com o seu logotipo, a sua cor de marca, o seu domínio personalizado em um subdomínio de staging, um pedido fictício e um VP de procurement fictício. Você navega por ele em um desktop real e em um telefone real. Se eles não prefeririam isso a uma cadeia de PDFs, não pediremos que você compre.