RED · PORTAL DE CLIENTE
Su cliente compra a quince proveedores al año. La mayoría envía facturas en PDF y espera que se les persiga por el estado. Las aprobaciones ocurren por correo y se atascan el día que alguien se olvida. «¿Dónde está mi pedido?» llega a la bandeja de su equipo de CS cincuenta veces por semana. Las reclamaciones y disputas viven en hilos de correo de tres días, y luego desaparecen en carpetas compartidas. El cliente se queda con la idea de que su negocio funciona con PDFs.
El Portal de Cliente de TradeOS es ese portal, totalmente de marca del operador. Nueve secciones de superficie real: pedidos, producción, envíos, facturas, reclamaciones, muestras, aprobaciones, mensajes, cuenta. Tres máquinas de estado (reclamaciones · muestras · aprobaciones). Rieles de Stripe Connect. Redacción en la capa de servicio: su proveedor y su margen nunca cruzan el límite.
Solicitar una demoVer precios →
Secciones del portal
9 · pedidos, envíos, finanzas, reclamaciones, y 4 más
Máquinas de estado
Reclamaciones, muestras, aprobaciones
Identidad multioperador
Un login, todos sus operadores, vista unificada
Coste para el cliente
$0 · asientos ilimitados
El operador propone que la cantidad del lote 4 pase de 150K a 200K unidades. Misma especificación, misma fecha de envío. Cambio neto: +$140,000 · dentro de su techo de nivel director de $200K. Planteada hace 11 min.
El panel real de Inicio: chrome de marca del operador, navegación de 9 secciones, franja de estado, indicador de acción para aprobaciones pendientes, cuadrícula de dos columnas con envío activo + centro de facturas, feed de actividad reciente. Una sola llamada al backend (GET /api/portal/client/dashboard) lo devuelve todo. El panel se adapta a través de 4 estados ClientDashboardMode a medida que se desarrolla la primera sesión del cliente (nueva → en producción → enviada → activa).
LA BANDEJA QUE NUNCA SE VACÍA
El trabajo es real: los clientes quieren saber dónde están sus pedidos, quieren que las aprobaciones sean rápidas, quieren sentir que tratan con un negocio serio. Las herramientas por defecto —PDF + correo + carpetas compartidas— le cuestan a su equipo de CS días a la semana y le cuestan a su tasa de renovación algo aún mayor.
01 · «¿DÓNDE ESTÁ MI PEDIDO?» VIVE EN 50 CORREOS POR SEMANA
El cliente quiere saber si RD-2026-018 ha sido enviado. Le escribe a compras, que escribe a ops, que abre cuatro secciones, y vuelve a teclear la respuesta. Para cuando llega el correo el lote ha avanzado dos etapas. Multiplique por veinte clientes y eso son dos días a la semana de tiempo de CS gastado en actualizaciones de estado que el registro ya tiene.
02 · LAS APROBACIONES SE ATASCAN EN CADENAS DE PDF
Envía una cotización, un pedido, una contrapropuesta. El cliente dice que necesita escalarlo. Tres días después le hace ping. Lo olvidó. Dos días después la aprobación llega por correo, pero los términos que había actualizado mientras tanto no se reflejan. La operación avanza a la velocidad de la bandeja más lenta.
03 · PARECE UN MOLINO DE PDFs
Su cliente compra a quince proveedores al año. El que tiene un portal de marca —pedidos, envíos, reclamaciones, aprobaciones todo en una superficie— parece de otra categoría de negocio. A ese se le renueva. A usted se le vuelve a sacar a RFP.
9 SECCIONES · UN PORTAL
El CLIENT_NAV.flatLinks real de client/src/lib/navConfig.ts. La navegación inferior móvil usa cuatro: Inicio · Pedidos · Pagos (la ruta /invoices renombrada, porque los clientes piensan «estoy pagando cosas») · Mensajes.
Panel adaptativo de 1,710 líneas. Estado destacado + indicador de acción + cuadrícula de 2 columnas con envío activo (mapa D3) y centro de facturas. Cuatro estados ClientDashboardMode para el renderizado de primera-sesión vs relación-en-curso.
Aceptación de OC, enmiendas, líneas, lotes, vinculación de envíos. Lista de 608 líneas + detalle de 964 líneas. Enrutamiento de aprobación vía el motor de tareas.
Vea cómo se fabrican los bienes: fases de producción, progreso de fábrica, seguimiento de lotes. La identidad del origen siempre anonimizada (redactada en la capa de servicio).
Mapa D3 + topojson, hitos en tiempo real (reservado → cargando → salido → llegado), adjunto de documentos. El mismo renderizador que usa la página de inicio.
Lista de facturas + detalle de 764 líneas. Pague vía Stripe Connect (4 rieles). En móvil esto se renombra a Pagos en la navegación inferior.
Acceso guiado por etiqueta de visibilidad. CO, BL, lista de empaque, CI, COA, seguro, fitosanitario, CC. Exportación asíncrona (pedidos/facturas/docs/mensajes/auditoría).
Tareas acotadas al cliente. Auto-generadas por las acciones del portal de cliente del lado del operador vía auto-tasks.service.ts. Las aprobaciones también viven aquí (task_category='approval').
Mensajería en hilos con el operador. Adjunta por entidad (pedido, factura, envío, reclamación, muestra). Preferencias de notificación de 5 categorías.
Analítica a nivel de relación. Agregada entre operadores en el nivel Business+ (función cross_operator_analytics real).
RECLAMACIONES Y MUESTRAS · FLUJOS COMERCIALES
Toda relación B2B tiene eventos comerciales que no son pedidos ni facturas: problemas de calidad, envíos faltantes, solicitudes de muestra, aprobación de muestra patrón. La mayoría del software de operador trata esto como intercambios de correo fuera de banda. TradeOS los trata como entidades de primera clase con máquinas de estado aplicadas.
RECLAMACIONES · MIGRACIÓN 165 · 6 ESTADOS
Tabla client_claims real. Seis tipos de reclamación que cubren todo el universo de «tenemos un problema con los bienes», distintos de las disputas de factura (que son sobre el contenido de la factura, gestionadas por separado en la mig 166).
Ramas: escalated · cancelled. Seis tipos de resolución (replacement_shipment · credit · refund · price_concession · no_action · dispute). Fotos y pruebas en JSONB. Tres niveles de gravedad (minor / major / critical). El cliente plantea y acepta propuestas; el operador investiga y propone resoluciones: rutas de escritura distintas en servicios distintos.
MUESTRAS · MIGRACIÓN 163 · 8 ESTADOS
Tabla sample_requests real. Cinco tipos de muestra que cubren el ciclo de validación desde «lo primero que envía la fábrica» hasta «el estándar de referencia que ambas partes conservan».
Ramas de decisión: approved_with_conditions · rejected · cancelled. Fotos y anotaciones de ambos lados. Las muestras patrón tienen fechas retain_until (típico 2 años). El portal lleva todo el flujo de trabajo —solicitud, subida de fotos, anotación, decisión, retención— sin recurrir al correo.
ESCALA CON SUS CLIENTES
El mismo portal sirve al comprador de la tienda de la esquina y a la organización de compras de una Fortune 500. Las cinco funciones de nivel client.*_approvals reales (migración 161) restringen un enrutamiento progresivamente más rico a medida que sube el nivel del operador. El proceso de compras del cliente se respeta, no se impone.
NIVEL · STARTER (PREDET. PYME)
1 aprobador · sin enrutamiento
Propietario / Comprador
AUTORIZACIÓN TOTAL · CUALQUIER IMPORTE
aprobar
CLAVE DE FUNCIÓN REAL
client.single_approver_workflow
CLIENTE DE EJEMPLO
Cadena de farmacias independiente · 4 ubicaciones · $80K/mes de gasto
NIVEL · SOLO+ / TEAM+
3 aprobadores · escala por valor en dólares
Líder de equipo
EQUIPO DE COMPRAS
< $50K
Director
DIRECTOR · COMPRAS
$50K — $200K
VP · Cadena de Suministro
VP · CADENA DE SUMINISTRO
> $200K
CLAVES DE FUNCIÓN REALES
client.amount_based_approvals(Solo+) ·client.sequential_multi_step(Business+)
CLIENTE DE EJEMPLO
Distribuidor médico regional · 14 sitios · $4M/mes de gasto
NIVEL · BUSINESS+ / ENTERPRISE
Configurable · n-de-m · políticas de delegación · registro de auditoría
Solicitante
RESPONSABLE DE SITIO
enviar
Dueño de centro de coste
FILTRO DE FINANZAS
cualquiera
Calidad / Cumplimiento
REGULADO · MÉDICO
QA
Seguridad / Riesgo de Proveedor
SAML · ENTERPRISE
riesgo
VP · Cadena de Suministro
JEFE DE FUNCIÓN · DELEGACIÓN OK
< $5M
Visto bueno del CFO
EJEC. · CON DELEGACIÓN
> $5M
CLAVES DE FUNCIÓN REALES
client.parallel_approvals · client.delegation_policies · client.category_based_approvals(Business+) ·client.custom_approval_builder(Enterprise)
CLIENTE DE EJEMPLO
Red hospitalaria Fortune 500 · 200 sitios · $40M/mes de gasto
AISLAMIENTO DE DATOS · ARQUITECTÓNICO
Un portal de cliente que filtra su proveedor o su margen es un portal que no lanza. Transparencia radical sobre el estado; opaco sobre el origen. Cada campo visible se expuso deliberadamente; todo lo demás es invisible antes de que la fila salga de la base de datos.
Solo sus propios pedidos, sus propios datos
Un cliente nunca ve a otro de sus clientes en la plataforma. Alcance por conexión en la capa de servicio; la vista unificada entre operadores (Starter+) agrega solo los propios datos de este cliente entre los operadores a los que está conectado.
Nunca sus proveedores ni fabricantes
«Producción en curso»: no el nombre de la fábrica, ni el país, ni la ubicación del lote. El redactFor() real en server/src/modules/portal-shell/redaction.ts reescribe la fila antes de que salga del servicio.
Nunca su coste, margen, o estructura de precios
Ven su precio comercial. Nunca ven lo que usted pagó a la fábrica, su base de coste de flete, ni lo que se cobra a otros clientes por el mismo SKU.
Redacción de documentos en la capa de servicio
Incluso si un documento tiene una referencia de proveedor en los metadatos —un bloque XMP de un PDF, una cabecera de Excel, una marca de agua—, se reescribe antes de servirlo. Sin ruta de «fuga vía archivo compartido por accidente».
Sin interruptor en Ajustes que mal configurar
No hay UI de administración donde un operador pueda activar el interruptor equivocado y exponer el coste. El límite está codificado; la única forma de pasarlo es una revisión de código con despliegue restringido.
DE MARCA DEL OPERADOR · LE VEN A USTED, NO A TRADEOS
Sus clientes no eligen proveedores según el software de back-office que usa: eligen según cómo se presenta el proveedor. El Portal de Cliente es la superficie principal del operador para esa presentación. Cada byte visible sale bajo su marca.
CAPA 01 · SU LOGO, SUS COLORES
DISPONIBLE DESDE · NIVEL SOLOSuba un logo, elija un color de marca primario, y cada artefacto que el cliente toca lo hereda: la UI del portal, las facturas en PDF, los contratos firmados, las notificaciones por correo, los manifiestos descargables. El logotipo de TradeOS se restringe a un pequeño pie en el portal; en los documentos, no está presente en absoluto.
CAPA 02 · DOMINIO PERSONALIZADO
DISPONIBLE DESDE · NIVEL ENTERPRISESus clientes nunca teclean «edma» ni «tradeos» en un navegador. Clave de función client.custom_domain real en el nivel Enterprise: marca blanca completa según la migración 161. El portal se sirve desde su propio DNS, con un certificado aprovisionado para su dominio. La barra de URL es parte de su marca, y se mantiene limpia desde el inicio de sesión hasta una factura pagada.
El remitente de correo del operador (saliente con firma DKIM desde su dominio) está en la hoja de ruta, marcado honestamente en el §13 abajo.
UN CLIENTE · MUCHOS OPERADORES · VISTA UNIFICADA
Una entidad legal de cliente conectada a múltiples operadores en TradeOS obtiene una vista de lectura unificada vía la clave de función client.cross_operator_account real (nivel Starter+, migración 161) y el endpoint /cross-operator/dashboard en portal-client/services/cross-operator.service.ts.
Un usuario, un login, todos sus operadores en una pantalla: aislamiento por conexión preservado. Los datos de cada operador permanecen acotados a esa conexión; la agregación solo ocurre a nivel de resumen seguro (recuentos, totales, sin fuga de PII entre operadores). Analítica entre operadores en el nivel Business+.
Esto es una desviación deliberada de la respuesta que dan muchos productos SaaS de portal de cliente: «la identidad del cliente está acotada al operador, sin vistas entre operadores». TradeOS expone la vista unificada porque los clientes realmente la necesitan y el aislamiento por conexión en la capa de agregación es la salvaguarda arquitectónica, no la ausencia de la superficie.
PAGOS · STRIPE CONNECT
Clave de función client.direct_payment_rails real (Starter+, migración 161). Cuatro rieles de Stripe Connect: tarjeta · ACH · SEPA · BACS. El lado de LECTURA del historial de pagos se lanza al inicio; el lado de INICIO se lanza con el receptor de webhooks de Stripe, actualmente detrás del hito v1.1. Ambas superficies están marcadas abajo para que sepa exactamente qué está conectado vs listo en la UI.
CARD
Visa, MC, Amex vía Stripe. Liquidación instantánea. Mejor para clientes PYME que quieren velocidad; no para facturas de alto valor donde la comisión importa.
ACH
Banco a banco en EE. UU. Liquidación en 2 días. El predeterminado para facturas grandes. La comisión más barata por dólar movido.
SEPA
Banco a banco en la UE. Liquidación en 2 días en toda la zona SEPA. El predeterminado para clientes europeos que pagan a operadores europeos.
BACS
Banco a banco en el RU. Liquidación en 3 días. El predeterminado para clientes del RU. Reemplaza el Direct Debit para flujos de pago único.
ESTADO
Superficie de LECTURA en vivo · la superficie de INICIO se lanza con el receptor de webhooks de Stripe (v1.1)
Pagos programados y recurrentes en el nivel Business+ (client.scheduled_payments)
IA · EN LOS EVENTOS DEL CLIENTE
Cada interacción del cliente en el portal es un evento sobre el que la pila de IA puede actuar. Se aplican las mismas reglas de aislamiento de datos: Atlas razona sobre el propio alcance del cliente, nunca entre otros clientes suyos.
AATLAS · REDACTANDO RESPUESTAS AL CLIENTE
El cliente pregunta «¿podemos acelerar 3 días?» Atlas extrae el % de producción actual, las opciones de flete, el impacto en el precio, y redacta una respuesta con su voz. Usted le da a enviar. El registro se actualiza automáticamente.
▶ REENV ATLAS · A. Kohl @ Brevin«¿Podemos acelerar la OC 0418 en 3d?»▶ ATLAS · borrador de respuesta«Sí: flete aéreo del lote 3 por +$14K (actualmente 78% de producción, ETA 18 jul. en vez del 21 jul.). Confirme antes del cierre del martes y lo reservamos.»→ contexto · producción · flete · margen (privado)
BBOT STUDIO · EN LAS APROBACIONES DEL CLIENTE
Construye el bot una vez. Vigila los eventos de aprobación del cliente: auto-actualiza el plan de producción del proveedor, redacta la nota del transitario, recalcula el calendario de facturas, y solo escala a un humano cuando el cambio cruza un umbral.
▶ BOT client-approval-cascade · v2.4→evento ·aprobar · +50K unidades→plan del proveedor ·lote 4 actualizado→transitario ·comprobación de capacidad solicitada→calendario de factura ·+$140K · INV-019→humano ·ninguno requerido
$IA DE CONTABILIDAD · EN LOS PAGOS DEL CLIENTE
El cliente paga $560K vía ACH. La IA de Contabilidad empareja el riel con la factura, lo asienta en su libro mayor, marca cualquier pago corto contra una política de retención conocida, y muestra solo los casos que necesitan ojo humano.
▶ ACCOUNTING AI rail match · v1.8→ ACH · $560,000 · ref MERIDIAN-018→emparejado ·INV-2026-018 · 100%→libro mayor ·asentado · CxC saldada→siguiente ·INV-019 retención 2.3% · revisar
COMPARAR
El correo y el PDF son el incumbente, y ganan en familiaridad, pierden en todo lo demás. Las Customer Communities y Ariba ganan en compras empresariales, pierden en marca del operador y protección del margen. Los portales internos ganan en flexibilidad, pierden seis meses después.
| Capacidad | Portal de Cliente TradeOS | Correo + PDF | Salesforce Customer Communities | Ariba Buyer (impuesto) | Portal personalizado interno |
|---|---|---|---|---|---|
| De marca del operador (su dominio, sus colores) | ✓ portal.yours.com · nivel Enterprise | ✓ su firma | sus colores, URL de Salesforce | — marca SAP | ✓ |
| Visibilidad de estado en tiempo real · mismo registro | ✓ una llamada al backend | — manual | vía integraciones | sincronización asíncrona | DIY |
| Aprobaciones en línea · de un toque a constructor personalizado | ✓ 5 niveles restringidos por nivel | — PDF + correo | ✓ constructor de flujos | ✓ solo enterprise | DIY |
| Rieles de pago de Stripe Connect (tarjeta · ACH · SEPA · BACS) | ✓ los 4 · comisiones transparentes | — solo transferencia | vía terceros | ACH · transferencia | — raramente |
| Vista unificada entre operadores (un login, todos sus operadores) | ✓ función Starter+ | — N/D | — silo por organización | — silo por organización | — DIY |
| Aislamiento de datos entre inquilinos aplicado arquitectónicamente | ✓ redactFor() en la API | — filtra por accidente | a nivel de organización | a nivel de inquilino | — DIY |
| Flujos de Reclamaciones + Muestras (máquinas de estado) | ✓ 6 + 8 estados · en vivo | — correo ad-hoc | módulo de casos | — fuera de banda | — DIY |
| SAML SSO en Enterprise | ✓ client.saml_sso | — | ✓ SF Identity | ✓ | DIY |
| Asientos gratis para clientes (el operador paga por TradeOS) | ✓ ilimitados en el nivel | ✓ el correo es gratis | — por usuario de comunidad | — por asiento | ✓ interno |
| Integración nativa de IA (Atlas · Bots · Contabilidad) | ✓ acotado por cliente | — trae el tuyo | complemento Einstein | complemento Joule | — |
El correo es el verdadero incumbente, y gana en familiaridad por una razón. Los clientes dominan el PDF. El Portal de Cliente no intenta reemplazar el correo siendo más impresionante; intenta reemplazarlo siendo más fácil que el correo para las cosas en las que el correo es malo: visibilidad de estado, enrutamiento de aprobaciones, pago, reclamaciones, muestras, adjuntar documentos a la OC correcta, y no hacer que el operador parezca un proveedor que funciona con Excel.
RESTRICCIÓN POR NIVEL · 19 CLAVES DE FUNCIÓN
El registro tier_features real (migración 161) define diecinueve restricciones de función del portal de cliente. Los clientes nunca ven un muro de pago; el nivel del operador conectado decide qué está disponible en su espacio de trabajo para ese operador. Hoja de ruta las etiquetas marcan las funciones cuya clave tier_feature está registrada pero cuya implementación de UI/motor es posterior al lanzamiento.
EN LA HOJA DE RUTA
La v1 lanza nueve secciones, tres máquinas de estado, cuatro rieles de pago de Stripe Connect (lado de LECTURA en vivo), identidad multiinquilino con vista unificada entre operadores, redacción en la capa de servicio, instalación PWA, superposición de incorporación + lista de verificación según el nivel, auto-tareas, exportación de datos, y restricción por nivel en diecinueve claves de función. Las capacidades de abajo están marcadas honestamente: sus claves tier_feature existen pero su UI / motor / conexión aterriza tras el lanzamiento.
01
La superficie de LECTURA (historial de pagos) está en vivo. El lado de INICIO —POST /invoices/:id/pay— está esbozado a la espera del receptor de webhooks de Stripe que escribe las filas de pago. Según payments.service.ts: «Esbozado exactamente como createSetupIntent. Lanza ValidationError con los siguientes pasos documentados.»
02
Confirmaciones de pedido, solicitudes de aprobación, alertas de envío, avisos de factura: entregados desde [email protected], no desde la infraestructura de TradeOS. SPF, DKIM, DMARC configurados en su DNS. Aún no implementado; nivel Enterprise cuando se construya.
03
SAML SSO está en vivo en el nivel Enterprise (client.saml_sso). El auto-aprovisionamiento OIDC y SCIM aterriza después: la misma restricción Enterprise. SCIM desaprovisiona cuando el sistema de RR. HH. del cliente da de baja a un usuario, de modo que el acceso al portal sigue la fuente de verdad del cliente.
04
Clave de función client.order_templates real en Business+ (mig 161, marcada «UI posterior al lanzamiento»). El esquema está listo; el selector de plantillas guardadas + el flujo de reorden de un clic se lanza tras el lanzamiento.
05
client.custom_approval_builder en el nivel Enterprise. El motor de ejecución está en su lugar (paralelo, secuencial, n-de-m, delegación, enrutamiento por categoría: todo funciona); la UI del constructor visual para operadores no técnicos se lanza tras el lanzamiento. Los operadores en Enterprise pueden solicitarnos flujos construidos a mano mientras tanto.
06
client.edi_integration en el nivel Enterprise (mig 161). Para clientes empresariales en EDI, el flujo de pedido/envío/factura aterriza directamente vía X12 / EDIFACT en lugar de la UI del portal. Esquema reservado; los adaptadores de integración se lanzan por cliente a medida que se cierran los contratos Enterprise.
07
Los cuatro rieles de Stripe Connect (tarjeta / ACH / SEPA / BACS) cubren el universo de rieles digitales. La transferencia y la LC son rieles fuera de banda que el operador aún puede registrar manualmente contra una factura hoy. Los flujos nativos del portal para confirmaciones de transferencia y seguimiento de presentación de LC se lanzan a medida que se concentran los casos de uso.
08
La PWA es la superficie móvil de cliente v1 (manifest + service worker + InstallNudge: ya en producción). Las apps nativas con autenticación biométrica, API de cámara nativas, y notificaciones push aterrizan tras el lanzamiento.
FAQ
Respuestas honestas a las preguntas con las que distribuidores, importadores y dueños de compañías de trading nos abordan en la llamada de demo.
Sí, pero con la marca de su sistema. Ven su logo, sus colores, y en el nivel Enterprise un dominio personalizado (portal.yourcompany.com con su propio certificado SSL). La mayoría de los clientes prefieren esto a perseguir PDFs por correo; los operadores que cambiaron reportan que los equipos de compras piden el portal primero, no al revés.
Reserve una demo de 30 minutos. Pondremos en marcha un Portal de Cliente en entorno de pruebas con su logo, su color de marca, su dominio personalizado en un subdominio de staging, un pedido ficticio, y un VP de compras ficticio. Lo recorre en un escritorio real y un teléfono real. Si no lo prefiriera a una cadena de PDF, no le pediremos que lo compre.