RETE · PORTALE CLIENTI
Il vostro cliente ordina da quindici fornitori all'anno. La maggior parte invia fatture in PDF e si aspetta di essere sollecitata per ogni aggiornamento di stato. Le approvazioni avvengono via e-mail e si bloccano non appena qualcuno dimentica di rispondere. «Dov'è il mio ordine?» arriva cinquanta volte a settimana nella casella del vostro team CS. Reclami e contestazioni si perdono in thread e-mail da tre giorni, per poi scomparire in cartelle condivise. Il cliente se ne va convinto che la vostra azienda giri sui PDF.
Il TradeOS Portale cliente è esattamente quel portale — completamente brandizzato con il vostro operatore. Nove sezioni reali: ordini, produzione, spedizioni, fatture, reclami, campioni, approvazioni, messaggi, account. Tre macchine a stati (reclami · campioni · approvazioni). Circuiti Stripe Connect. Oscuramento a livello di servizio — fornitore e margine non attraversano mai il confine.
Prenota una demoVedi i prezzi →
Sezioni del portale
9 · ordini, spedizioni, finanza, reclami e altri 4
Macchine a stati
Reclami, campioni, approvazioni
Identità multi-operatore
Un solo accesso, tutti i vostri operatori, vista unificata
Costo per il cliente
$0 · postazioni illimitate
L'operatore propone di aumentare la quantità del lotto 4 da 150K a 200K unità. Stessa specifica, stessa data di spedizione. Variazione netta: +$140,000 · entro il limite director-tier di $200K. Richiesta inviata 11 min fa.
Il vero Dashboard home — chrome brandizzato dall'operatore, navigazione a 9 sezioni, striscia di stato hero, prompt di azione per le approvazioni in sospeso, griglia a due colonne con spedizione attiva e centro fatture, feed delle attività recenti. Un'unica chiamata backend (GET /api/portal/client/dashboard) restituisce tutto. Il Dashboard si adatta attraverso 4 ClientDashboardMode stati nel corso della prima sessione del cliente (nuovo → in produzione → in spedizione → attivo).
LA CASELLA DI POSTA CHE NON SI SVUOTA MAI
Il lavoro è reale: i Clienti vogliono sapere dove si trovano i loro Ordini, vogliono approvazioni rapide e vogliono avere la sensazione di trattare con un'azienda seria. Gli strumenti predefiniti — PDF + e-mail + cartelle condivise — costano al vostro team CS giorni interi ogni settimana e al vostro tasso di rinnovo qualcosa di ancora più significativo.
01 · «DOV'È IL MIO ORDINE?» VIVE IN 50 E-MAIL A SETTIMANA
Il Cliente vuole sapere se RD-2026-018 è stato spedito. Scrive al Procurement, che scrive alle operations, che apre quattro sezioni e ridigita manualmente la risposta. Quando l'e-mail arriva, il lotto ha già avanzato di due fasi. Moltiplicato per venti clienti, sono due giorni a settimana di tempo CS spesi per aggiornamenti che il sistema già contiene.
02 · LE APPROVAZIONI SI BLOCCANO IN CATENE DI PDF
Inviate un preventivo, un ordine, una controproposta. Il Cliente dice che deve escalare. Tre giorni dopo lo sollecitate. Aveva dimenticato. Due giorni dopo ancora arriva l'approvazione via e-mail — ma le condizioni che avevate aggiornato nel frattempo non vi sono riflesse. La trattativa avanza alla velocità della casella di posta più lenta.
03 · SEMBRATE UNA FABBRICA DI PDF
Il vostro Cliente acquista da quindici fornitori all'anno. Quello con un portale brandizzato — Ordini, Spedizioni, reclami, approvazioni su un'unica interfaccia — si percepisce come una categoria diversa di azienda. Viene rinnovato. Voi finite di nuovo nella shortlist RFP.
9 SEZIONI · UN PORTALE
Dati CLIENT_NAV.flatLinks in tempo reale da client/src/lib/navConfig.ts. La barra di navigazione mobile inferiore utilizza quattro voci: Home · Ordini · Pagamenti (la route /invoices rinominata, perché i clienti pensano «sto pagando le cose») · Messaggi.
Dashboard adattivo di 1.710 righe. Stato hero + prompt di azione + griglia a 2 colonne con spedizione attiva (mappa D3) e centro fatturazione. Quattro ClientDashboardMode stati per il rendering alla prima sessione rispetto a una relazione consolidata.
Accettazione PO, modifiche, voci di riga, lotti, collegamento alle spedizioni. Lista di 608 righe + dettaglio di 964 righe. Instradamento delle approvazioni tramite il motore delle attività.
Monitoraggio della produzione delle merci — fasi produttive, avanzamento per stabilimento, tracciamento dei lotti. L'identità della fonte è sempre anonimizzata (oscurata a livello di servizio).
Mappa D3 + topojson, milestone in tempo reale (prenotato → in carico → partito → arrivato), allegati documentali. Lo stesso renderer utilizzato nella homepage.
Lista fatture + dettaglio di 764 righe. Pagamento tramite Stripe Connect (4 circuiti). Su mobile, questa sezione viene rinominata Pagamenti nella barra di navigazione inferiore.
Accesso gestito tramite tag di visibilità. CO, BL, Packing list, CI, COA, assicurazione, fitosanitario, QC. Export asincrono (ordini/fatture/documenti/messaggi/audit).
Attività con scope limitato al cliente. Generate automaticamente dalle azioni del portale cliente sul lato operatore tramite auto-tasks.service.ts. Le approvazioni risiedono qui (task_category='approval').
Messaggistica in thread con l'operatore. Associata per entità (ordine, fattura, spedizione, reclamo, campione). Preferenze di notifica su 5 categorie.
Analisi a livello di relazione. Aggregate su più operatori dal livello Business+ in su (vera funzionalità cross_operator_analytics).
RECLAMI & CAMPIONI · FLUSSI COMMERCIALI
Ogni relazione B2B genera eventi commerciali che non sono Ordini né fatture — problemi di qualità, spedizioni incomplete, richieste di campioni, approvazione del campione di riferimento. La maggior parte dei software operativi li tratta come scambi e-mail fuori sistema. TradeOS li tratta come entità di primo livello con macchine a stati imposte.
RECLAMI · MIGRAZIONE 165 · 6 STATI
Vera tabella client_claims. Sei tipologie di reclamo che coprono l'intero universo di «abbiamo un problema con la merce» — distinte dalle controversie su fattura (riguardanti il contenuto della fattura, gestite separatamente in mig 166).
Rami: escalated · cancelled. Sei modalità di risoluzione (replacement_shipment · credit · refund · price_concession · no_action · dispute). Foto e prove in JSONB. Tre livelli di gravità (minor / major / critical). Il cliente presenta e accetta le proposte; l'operatore istruisce e propone le risoluzioni — percorsi di scrittura distinti in servizi separati.
CAMPIONI · MIGRAZIONE 163 · 8 STATI
Vera tabella sample_requests. Cinque tipologie di campione che coprono il ciclo di validazione dal «primo invio dello stabilimento» allo «standard di riferimento conservato da entrambe le parti».
Rami di decisione: approved_with_conditions · rejected · cancelled. Foto e annotazioni da entrambe le parti. I campioni di riferimento hanno date retain_until (tipicamente 2 anni). Il portale gestisce l'intero flusso — richiesta, caricamento foto, annotazione, decisione, conservazione — senza ricorrere all'e-mail.
SI SCALA CON I VOSTRI CLIENTI
Lo stesso portale serve l'acquirente sotto casa e l'organizzazione Procurement di una Fortune 500. Le cinque vere client.*_approvals funzionalità di tier (migrazione 161) abilitano progressivamente un instradamento più ricco man mano che il tier dell'operatore avanza. Il processo Procurement del cliente viene rispettato, non imposto.
TIER · STARTER (PREDEFINITO PMI)
1 approvatore · nessun instradamento
Titolare / Acquirente
AUTORIZZAZIONE TOTALE · QUALSIASI IMPORTO
approvare
CHIAVE FUNZIONALITÀ REALE
client.single_approver_workflow
CLIENTE ESEMPIO
Catena farmaceutica indipendente · 4 sedi · $80K/mo di spesa
LIVELLO · SOLO+ / TEAM+
3 approvatori · escalation per valore
Team lead
TEAM ACQUISTI
< $50K
Direttore
DIRETTORE · ACQUISTI
$50K — $200K
VP · Supply Chain
VP · SUPPLY CHAIN
> $200K
CHIAVI FUNZIONALITÀ REALI
client.amount_based_approvals(Solo+) ·client.sequential_multi_step(Business+)
CLIENTE ESEMPIO
Distributore medicale regionale · 14 sedi · $4M/mese di spesa
LIVELLO · BUSINESS+ / ENTERPRISE
Configurabile · n-of-m · politiche di delega · registro di audit
Richiedente
RESPONSABILE DI SEDE
invia
Responsabile del centro di costo
CONTROLLO FINANZIARIO
qualsiasi
Qualità / Compliance
REGOLAMENTATO · MEDICALE
QA
Sicurezza / Rischio fornitore
SAML · ENTERPRISE
rischio
VP · Supply Chain
RESPONSABILE DI FUNZIONE · DELEGA OK
< $5M
Firma CFO
EXEC · CON DELEGA
> $5M
CHIAVI FUNZIONALITÀ REALI
client.parallel_approvals · client.delegation_policies · client.category_based_approvals(Business+) ·client.custom_approval_builder(Enterprise)
CLIENTE ESEMPIO
Rete ospedaliera Fortune 500 · 200 sedi · $40M/mo di spesa
ISOLAMENTO DEI DATI · ARCHITETTURALE
Un portale clienti che espone i vostri fornitori o i vostri margini è un portale che non mettete in produzione. Trasparenza totale sullo stato; opacità totale sull'origine. Ogni campo visibile è stato deliberatamente esposto; tutto il resto è invisibile prima che la riga lasci il database.
Solo i propri Ordini, solo i propri dati
Un cliente non vede mai nessun altro dei vostri clienti sulla piattaforma. Perimetro per connessione a livello di servizio; la vista consolidata multi-operatore (Starter+) aggrega esclusivamente i dati di quel cliente relativi agli operatori a cui è connesso.
Mai i vostri fornitori o Produttori
«Produzione in corso» — nessun nome di Factory, nessun paese, nessuna ubicazione del lotto. Il vero redactFor() in server/src/modules/portal-shell/redaction.ts riscrive la riga prima che lasci il servizio.
Mai i vostri costi, margini o struttura dei prezzi
Il cliente vede il proprio prezzo commerciale. Non vede mai quanto avete pagato alla fabbrica, la vostra base di costo del nolo, né quanto vengono addebitati altri clienti sullo stesso SKU.
Oscuramento dei Documenti a livello di servizio
Anche se un documento contiene un riferimento fornitore nei metadati — un blocco XMP di un PDF, un'intestazione Excel, una filigrana — viene riscritto prima della trasmissione. Nessuna fuga di dati attraverso file condivisi accidentalmente.
Nessuna impostazione da configurare erroneamente
Non esiste alcuna interfaccia di amministrazione in cui un operatore possa attivare per errore l'esposizione dei costi. Il confine è codificato; l'unico modo per aggirarlo è una revisione del codice soggetta a validazione del deploy.
OPERATOR-BRANDED · VEDONO VOI, NON TRADEOS
I vostri clienti non scelgono i fornitori in base al software back-office che utilizzate — li scelgono in base a come il fornitore si presenta. Il Portale cliente è la superficie principale dell'operatore per questa presentazione. Ogni byte visibile viene trasmesso sotto il vostro marchio.
LAYER 01 · IL VOSTRO LOGO, I VOSTRI COLORI
DISPONIBILE DAL · Solo TIERCaricate un logo, scegliete un colore principale del brand, e ogni artefatto che il cliente consulta lo eredita — interfaccia del portale, fatture in PDF, contratti firmati, notifiche via e-mail, manifesti scaricabili. Il nome TradeOS è limitato a un piccolo footer sul portale; sui Documenti non è presente.
STRATO 02 · DOMINIO PERSONALIZZATO
DISPONIBILE A PARTIRE DA · ENTERPRISE TIERI vostri clienti non digitano mai «edma» né «tradeos» in un browser. Una vera client.custom_domain funzionalità chiave dell'Enterprise Tier — white-label completo ai sensi della migrazione 161. Il portale viene servito dal vostro DNS, con un certificato emesso per il vostro dominio. La barra degli indirizzi è parte del vostro brand — e rimane pulita dall'accesso fino alla fattura saldata.
L'invio di e-mail tramite l'operatore (messaggi in uscita firmati DKIM dal vostro dominio) è previsto nella roadmap — segnalato esplicitamente al §13 di seguito.
UN CLIENTE · MOLTI OPERATORI · VISTA UNIFICATA
Un'entità legale cliente connessa a più operatori su TradeOS ottiene una vista in lettura unificata tramite la vera client.cross_operator_account feature key (livello Starter+, migrazione 161) e l'endpoint /cross-operator/dashboard in portal-client/services/cross-operator.service.ts.
Un utente, un accesso, tutti i propri operatori in un'unica schermata — con isolamento per connessione preservato. I dati di ciascun operatore rimangono circoscritti alla rispettiva connessione; l'aggregazione avviene esclusivamente al livello sicuro dei riepiloghi (conteggi, totali, nessuna perdita di PII tra operatori). Analisi cross-operatore a partire dal livello Business+.
Si tratta di una deviazione deliberata rispetto alla FAQ che molti prodotti SaaS di portale clienti propongono — «l'identità del cliente è limitata all'operatore, nessuna vista cross-operatore.» TradeOS espone la vista unificata perché i clienti ne hanno effettivamente bisogno e l'isolamento per connessione nel livello di aggregazione è la salvaguardia architetturale, non l'assenza della superficie.
PAGAMENTI · STRIPE CONNECT
Vero client.direct_payment_rails feature key (Starter+, migrazione 161). Quattro canali Stripe Connect — carta · ACH · SEPA · BACS. La cronologia pagamenti in lettura è disponibile al lancio; la superficie INITIATE viene rilasciata con il ricevitore webhook Stripe, attualmente dietro la milestone v1.1. Entrambe le superfici sono segnalate di seguito affinché sappiate esattamente cosa è operativo rispetto a cosa è pronto lato interfaccia.
CARTA
Visa, MC, Amex tramite Stripe. Regolamento istantaneo. Ideale per i Clienti PMI che privilegiano la rapidità; sconsigliato per fatture di importo elevato in cui la commissione è rilevante.
ACH
Bonifico bancario negli USA. Regolamento in 2 giorni. Soluzione predefinita per fatture di importo elevato. Commissione più bassa per dollaro trasferito.
SEPA
Bonifico bancario nell'UE. Regolamento in 2 giorni nell'intera zona SEPA. Soluzione predefinita per i Clienti europei che pagano operatori europei.
BACS
Bonifico bancario nel Regno Unito. Regolamento in 3 giorni. Soluzione predefinita per i Clienti britannici. Sostituisce l'addebito diretto per i flussi di pagamento una tantum.
STATO
Superficie READ attiva · Superficie INITIATE rilasciata con il ricevitore webhook Stripe (v1.1)
Pagamenti programmati e ricorrenti a partire dal tier Business+ (client.scheduled_payments)
AI · SU EVENTI DEL PORTALE CLIENTI
Ogni interazione del cliente nel portale è un evento su cui lo stack AI può intervenire. Si applicano le stesse regole di isolamento dei dati — Atlas ragiona sul perimetro del singolo cliente, mai su quello degli altri vostri Clienti.
AATLAS · REDAZIONE RISPOSTE AI CLIENTI
Il cliente chiede «possiamo anticipare di 3 giorni?» Atlas recupera l'avanzamento della Produzione, le opzioni di trasporto, l'impatto sui prezzi e redige una risposta nel tuo tono. Premi invia. Il record si aggiorna 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 · SULLE APPROVAZIONI DEI CLIENTI
Il bot si configura una volta sola. Monitora gli eventi di approvazione del cliente: aggiorna automaticamente il piano di produzione del fornitore, redige la nota allo spedizioniere, ricalcola il piano di fatturazione e scala verso un operatore umano solo se la modifica supera una soglia definita.
▶ 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 · SUI PAGAMENTI DEI CLIENTI
Il cliente versa $560K tramite ACH. Accounting AI abbina il canale di pagamento alla fattura, la registra nel libro contabile, segnala qualsiasi pagamento parziale rispetto a una politica di trattenuta nota, e porta all'attenzione solo i casi che richiedono una verifica umana.
▶ 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
CONFRONTO
E-mail e PDF sono la soluzione consolidata — vincono sulla familiarità, perdono su tutto il resto. Le Customer Communities e Ariba vincono nel Procurement enterprise, perdono sul branding dell'operatore e sulla protezione dei margini. I portali interni vincono in flessibilità, poi perdono sei mesi dopo.
| Funzionalità | TradeOS Portale Clienti | Email + PDF | Salesforce Customer Communities | Ariba Buyer (imposto) | Portale custom interno |
|---|---|---|---|---|---|
| Portale a marchio dell'operatore (dominio e colori personalizzati) | ✓ portal.yours.com · livello Enterprise | ✓ firma personalizzata | colori personalizzati, Salesforce URL | — brand SAP | ✓ |
| Visibilità dello stato in tempo reale · stesso record | ✓ singola chiamata backend | — manuale | tramite Integrazioni | sync asincrono | DIY |
| Approvazioni inline · da un tap al generatore personalizzato | ✓ 5 livelli vincolati al tier | — PDF + e-mail | ✓ builder di flusso | ✓ solo Enterprise | DIY |
| Circuiti di pagamento Stripe Connect (carta · ACH · SEPA · BACS) | ✓ tutti e 4 · commissioni trasparenti | — solo bonifico | tramite terze parti | ACH · bonifico | — raro |
| Vista unificata multi-operatore (un unico login, tutti i vostri operatori) | ✓ funzionalità Starter+ | — N/D | — silo per organizzazione | — silo per organizzazione | — Fai-da-te |
| Isolamento dei dati tra tenant imposto a livello architetturale | ✓ redactFor() nell'API | — fughe di dati accidentali | livello organizzazione | livello tenant | — Fai-da-te |
| Workflow reclami + campioni (macchine a stati) | ✓ 6 + 8 stati · live | — e-mail ad hoc | modulo cases | — fuori banda | — Fai-da-te |
| SAML SSO nel tier Enterprise | ✓ client.saml_sso | — | ✓ SF Identity | ✓ | DIY |
| Accessi gratuiti per i Clienti (l'operatore paga TradeOS) | ✓ illimitati nel tier | ✓ l'e-mail è gratuita | — per utente community | — per postazione | ✓ interno |
| Integrazione AI nativa (Atlas · Bots · Contabilità) | ✓ configurato per cliente | — soluzione propria richiesta | add-on Einstein | add-on Joule | — |
L'e-mail è il vero incumbent — e vince sulla familiarità per una ragione precisa. I clienti padroneggiano il PDF. Il Portale cliente non punta a sostituire l'e-mail essendo più sofisticato; punta a sostituirla essendo più semplice dell'e-mail nelle aree in cui l'e-mail è carente: visibilità degli stati, routing delle approvazioni, pagamenti, reclami, campioni, allegare i documenti al PO corretto e non far sembrare l'operatore un fornitore che lavora su Excel.
ACCESSO PER LIVELLO · 19 FUNZIONALITÀ
Il registro tier_features reale (migrazione 161) definisce diciannove gate di funzionalità del portale clienti. I clienti non vedono mai un paywall; il tier dell'operatore collegato determina ciò che è disponibile nel vostro workspace per quell'operatore. Roadmap contrassegna le funzionalità la cui chiave tier_feature è registrata ma la cui implementazione UI/motore è successiva al lancio.
SULLA ROADMAP
La v1 include nove sezioni, tre state machine, quattro rails di pagamento Stripe Connect (lato READ attivo), identità multi-tenant con vista unificata tra operatori, redazione a livello di service layer, installazione PWA, overlay di onboarding + checklist per livello, attività automatiche, esportazione dati e gating per livello su diciannove chiavi di funzionalità. Le funzionalità elencate di seguito sono segnalate con trasparenza — le loro chiavi tier_feature esistono, ma la UI, il motore e il collegamento arrivano dopo il lancio.
01
La superficie READ (storico pagamenti) è attiva. Il lato INITIATE — POST /invoices/:id/pay — è in stub in attesa del webhook receiver Stripe che scrive le righe di pagamento. Secondo payments.service.ts: «In stub esattamente come createSetupIntent. Genera ValidationError con i passi successivi documentati.»
02
Conferme d'ordine, richieste di approvazione, avvisi di spedizione, notifiche di fattura — recapitati da [email protected], non dall'infrastruttura TradeOS. SPF, DKIM, DMARC configurati sul vostro DNS. Non ancora implementato; livello Enterprise una volta realizzato.
03
Il SSO SAML è attivo al livello Enterprise (client.saml_sso). OIDC e il provisioning automatico SCIM arriveranno in seguito — stesso gate Enterprise. SCIM rimuove l'accesso quando il sistema HR del cliente disattiva un utente, in modo che l'accesso al portale segua la fonte dati del cliente.
04
Vera chiave di funzionalità client.order_templates a Business+ (mig 161, contrassegnata come «UI post-lancio»). Lo schema è pronto; il selettore di modelli salvati e il flusso di riordino con un clic arriveranno dopo il lancio.
05
client.custom_approval_builder al livello Enterprise. Il motore di runtime è in funzione (parallelo, sequenziale, n-of-m, delega, routing per categoria — tutto operativo); la UI del builder visivo per operatori non tecnici arriverà dopo il lancio. Gli operatori Enterprise possono nel frattempo richiedere workflow costruiti manualmente.
06
client.edi_integration al livello Enterprise (mig 161). Per i clienti enterprise che utilizzano EDI, il flusso ordini/spedizioni/fatture arriva direttamente tramite X12 / EDIFACT invece che dall'UI del portale. Schema riservato; gli adapter di integrazione vengono rilasciati per ogni cliente alla chiusura dei contratti Enterprise.
07
I quattro rails Stripe Connect (carta / ACH / SEPA / BACS) coprono l'intero universo dei rails digitali. Wire e LC sono rails fuori banda che l'operatore può comunque registrare manualmente su una fattura oggi stesso. I flussi nativi del portale per le conferme di bonifico e il tracking della presentazione LC arriveranno man mano che i casi d'uso si concentreranno.
08
La PWA è la superficie mobile client v1 (manifest + service worker + InstallNudge — già in produzione). Le app native con autenticazione biometrica, API fotocamera native e notifiche push arriveranno dopo il lancio.
FAQ
Risposte dirette alle domande che distributori, importatori e titolari di società commerciali ci rivolgono durante la chiamata di demo.
Sì — ma è brandizzato come il vostro sistema. Vedono il vostro logo, i vostri colori, e al livello Enterprise un dominio personalizzato (portal.yourcompany.com con il proprio certificato SSL). La maggior parte dei clienti preferisce questo all'inseguimento di PDF via e-mail; gli operatori che hanno effettuato la transizione riferiscono che i team procurement richiedono il portale per primi, non il contrario.
Prenota una demo di 30 minuti. Configuriamo un Portale cliente sandbox con il vostro logo, il colore del vostro brand, il vostro dominio personalizzato su un sottodominio di staging, un ordine fittizio e un VP procurement fittizio. Lo percorrete su un vero desktop e un vero telefono. Se non lo preferirebbero a una catena di PDF, non vi chiederemo di acquistarlo.