Commercial layer
Home, pagine informative, contatti e policy restano pubblici per clienti e partner.
VECTOR combina pagine commerciali, workspace applicativi, runtime containerizzato, database dedicato e storage oggetti in un ecosistema unico per operazioni logistiche e aziendali.
Home, pagine informative, contatti e policy restano pubblici per clienti e partner.
Workspace, shipping flows, mail, office, records, dashboard, intelligence e finance restano in aree autenticate con ruoli e permessi specifici.
Audit, billing, policy, controllo accessi e riferimenti di compliance fanno parte dello stesso ecosistema, ma non vengono esposti come contenuto pubblico indistinto.
VECTOR può accogliere corrieri diretti, aggregatori e partner locali, ma la superficie utente deve rimanere onesta: un carrier viene mostrato solo se esiste copertura reale per la tratta e se il relativo modulo operativo è abilitato. Questo principio protegge la UX e impedisce pagine vuote o promesse non verificabili.
Ogni integrazione segue un contratto comune: capacità di tariffazione, validazione indirizzo, creazione label, opzioni di ritiro o consegna in filiale, tracking e gestione delle eccezioni.
Il routing considera paese del mittente, paese del destinatario, peso, dimensioni, servizio richiesto e disponibilità del carrier. Se l’origine non è coperta, il sistema informa l’utente invece di inventare un risultato.
La piattaforma è pronta ad accogliere Europa, DACH e tratte globali tramite moduli successivi, ma ogni mercato viene aperto solo dopo verifiche funzionali e conferma operativa.
Anche quando dietro una spedizione lavorano API diverse, VECTOR normalizza campi come servizio, prezzo, valuta, tracking, label, pickup, drop-off, riferimento esterno e stato carrier. Questo rende il record leggibile all’utente e agli operatori.
L’infrastruttura può contenere moduli sperimentali o futuri, ma la UX pubblica deve restare pulita: niente provider non abilitati, niente schermate vuote e niente contenuti tecnici che non aiutano a completare una decisione.
Le pagine pubbliche devono rimanere accessibili anche quando il prodotto evolve. Per questo la parte editoriale viene separata dagli endpoint API e dai workspace, riducendo il rischio che un errore operativo produca una pagina vuota indicizzata.