01Il deployment su una schermata
La panoramica apre la giornata. Stato di salute del sistema tra manutenzione, API bridge, database e cache. Segnali su breaker, provider ed errori irrisolti. Il lavoro come code conteggiate: 12 revisioni KYC in attesa, la più vecchia da 5h 02m, 8 differenze di riconciliazione con €18,240 pronti da accreditare, 2 approvazioni in attesa. Più sotto, le azioni privilegiate recenti e lo stato di ogni provider. Nulla in questa schermata richiede un secondo strumento.
- Sistema, segnali e code in un'unica lettura verticale
- Ogni card rimanda alla coda che conteggia
- Stato dei provider per rail: degradato, attivo, in ripristino
02Il copilot per gli operatori
Un dock copilot si apre accanto a qualsiasi vista con suggerimenti sensibili al contesto, come perché le ricariche falliscono o riepiloga gli incidenti aperti. È di sola lettura e non esegue azioni. E degrada con onestà: finché l'endpoint del modello non è collegato, il dock lo dice chiaramente invece di inventare risposte.
03Insights
L'operatività su una schermata: 42,180 utenti, 12,408 attivi, un tasso di attivazione del 61.8%, un tasso di successo del 96.4% e un flusso di denaro di +€1.84M in entrata e −€1.52M in uscita in 30 giorni. Accanto ci sono i funnel di KYC e onboarding, così un calo di attivazione si vede nella settimana in cui inizia. Le metriche sul denaro restano riservate al ruolo finanziario.
04Triage degli errori
Il flusso di alert arriva deduplicato. 142 occorrenze di un unico WebhookSignatureError, che coinvolgono 38 utenti, si riducono a una sola riga critica con azioni di presa in carico e risoluzione, e la vista si aggiorna ogni 10 secondi. Gli operatori risolvono firme, non pagine di rumore.
- Una riga per ogni firma di errore, conteggiata
- Utenti coinvolti associati a ciascuna firma
- Presa in carico e risoluzione come azioni tracciate
05Utenti, ricercabili per qualsiasi dato
12,408 account ricercabili per nome, email, telefono o ID, con stato KYC e stato dell'account su ogni riga e schede per KYC in attesa, verificati, rifiutati, bloccati e archiviati. Ogni riga si apre in uno User 360: saldi, carte, dispositivi, livello KYC e storico completo di un cliente su una sola schermata.
06Coda di revisione KYC
Le revisioni in attesa arrivano come coda conteggiata, con il cronometro in vista: 12 nella demo, ogni riga con provider, stato, ultimo motivo e da quanto tempo attende il richiedente. Un nuovo tentativo di liveness bloccato a 5h 02m compare in rosso. Approva, rifiuta o reimposta direttamente in console; ogni decisione richiede una motivazione, viene tracciata e aggiorna lo stato dell'account ovunque in un colpo solo.
- In attesa, precompletate, rifiutate e tutte, in schede
- Motivi sulla riga: revisione indirizzo, nuovo tentativo liveness, revisione documento
- Tempo di attesa visibile, il più vecchio segnalato
07Drill-down sul libro mastro
Ogni riga di denaro si apre fino in fondo. Il trasferimento TR-90211, un pagamento peer-to-peer completato da €120.00, mostra mittente, destinatario e le due registrazioni a libro mastro: un addebito di −€120.00 e un accredito di +€120.00, in partita doppia e bilanciate. Nessuna vista di sintesi si frappone tra l'operatore e il libro mastro.
08Ricariche crypto
I depositi on-chain sono righe a pieno titolo, non l'esportazione di qualcos'altro. Una ricarica riuscita sulla rete Base mostra 250.00 USDC che accreditano il ledger in EUR, con tasso di cambio, commissione, indirizzo del wallet e hash della transazione nel pannello laterale. Entrambi i rail, una sola console, tracciabili fino alla chain.
09Riconciliazione
I bonifici SEPA in entrata vengono abbinati automaticamente agli utenti; le eccezioni finiscono in una coda di lavoro conteggiata: righe abbinate pronte da accreditare, un ordinante sconosciuto con due possibili corrispondenze e schede per pronte, da verificare, non abbinate e storico. L'accredito è un clic quando l'abbinamento è chiaro, una decisione motivata quando non lo è, e ogni accredito manuale richiede una motivazione, con limiti di importo letti dalla configurazione.
- Abbina un pagamento a un utente, poi accredita e riconcilia
- Ordinanti ambigui trattenuti per revisione, con i loro candidati
- Report bancari importati direttamente nella coda
10Tracer
Incolla un riferimento e ottieni tutta la storia. La traccia 9F21-0716 si apre come sequenza di passaggi: richiesta inviata, ledger validato rispetto alla policy, quotazione del provider registrata, conferma on-chain su Base a 12 di 12, regolamento consegnato, ognuno con il suo tempo, da +42ms a +22s. Di sola lettura per progetto: Tracer spiega, non modifica mai.
- Un riferimento, ogni passaggio dalla richiesta al regolamento
- Policy e quotazione applicate a ogni passaggio, registrate
- Chiave di idempotenza visibile nella traccia
11Inbox delle approvazioni
I crediti sopra soglia attendono un secondo operatore. L'inbox si divide tra ciò che attende la tua approvazione e ciò che hai richiesto: da un lato un credito di cortesia da €500.00 e un rimborso di ricarica fallita da €120.00, dall'altro la tua inversione di commissione da €40.00 in attesa di un cofirmatario. Non puoi approvare ciò che hai richiesto; puoi ritirarlo.
12Il log di audit
18,942 azioni degli operatori in una tabella append-only: ora, operatore, azione, destinazione, motivazione scritta e richiesta sottostante con il relativo codice di risposta. Le azioni di sistema finiscono nella stessa dorsale di quelle umane. Filtra per operatore, azione o data; esporta in CSV quando qualcuno fuori dalla console lo chiede.
- Append-only: le voci non vengono mai modificate né rimosse
- Motivazione e richiesta allegate a ogni riga
- Filtrabile, paginato, esportabile
13Ispezione e replay dei webhook
18,204 eventi in ingresso dai provider, ciascuno con la verifica della firma sulla riga. Un evento fallito può essere rieseguito per applicare di nuovo un esito perso, con motivazione obbligatoria e senza notifiche duplicate, ma solo se la firma è valida; le firme non valide non sono attendibili e il replay è bloccato. Mostrare un payload grezzo invia PII non mascherate al tuo browser, quindi l'operazione genera un evento di audit.
14Feature flag e configurazione remota
38 chiavi tipizzate in 8 aree (interruttori, importi, enum) per carte, ricariche, KYC e il resto della superficie runtime. Ogni chiave indica chi l'ha modificata per ultimo e quando; ogni modifica ha il suo diff, la sua motivazione e viene tracciata. Un limite di spesa o il cambio di un provider è una modifica in console, non un rilascio sugli store.
- Controlli tipizzati: niente stringhe di configurazione a testo libero
- Storico per chiave: chi, cosa, quando, perché
- Le modifiche hanno effetto senza rilasciare una nuova versione dell'app
15Kill switch
Quando qualcosa deve fermarsi, si ferma da qui. Un blocco globale mostra la schermata di manutenzione all'avvio dell'app; i kill switch per singola funzione spengono carte, ricariche, trasferimenti o KYC separatamente: nella demo 4 attivi, 0 disattivati. Un bypass OTP per il QA ha un proprio interruttore, spento di default. Ogni modifica è registrata e richiede doppia conferma.
16Operatori e ruoli
Il team si gestisce dove si lavora. Sei account operatore coprono i ruoli da superadmin ad auditor, e ogni scheda mostra l'attività recente tracciata. Le modifiche di ruolo passano da una finestra di motivazione e nessuno può cambiare il proprio ruolo o disattivarsi da solo: serve un secondo superadmin.
- Sei ruoli: superadmin, ops, compliance, engineer, support, auditor
- Le azioni recenti di ogni operatore sulla sua scheda
- Niente autopromozione, niente autodisattivazione
17Azioni con motivo obbligatorio
Un'azione privilegiata si spiega prima di essere eseguita. Bloccare la carta 4417 apre una finestra che indica l'impatto potenziale, richiede una motivazione scritta e, trattandosi di produzione, fa digitare PROD all'operatore prima di abilitare il pulsante di conferma. La motivazione finisce nel log di audit immutabile accanto all'azione stessa.
18Circuit breaker e stato dei provider
Il lato engineering monitora in tempo reale i circuit breaker e lo stato dei provider. Quando un provider degrada, lo stato del breaker è visibile in console prima che arrivino i ticket di supporto — e lo stesso vale per il recupero.
19Back office dei payment link
I link creati dai clienti hanno una vista operatore: 214 link tra pagati, attivi e scaduti nella demo, ciascuno con il trasferimento di regolamento associato e un link per aprire la traccia completa in Tracer. Revocare un link non equivale a un rimborso — la console lo dice prima che tu proceda.
20Whitelist di accesso e PII mascherati
L'accesso alla console è in whitelist e ciò che gli operatori vedono è ridotto al minimo per impostazione predefinita: email e telefono restano mascherati finché non vengono rivelati di proposito, e le metriche economiche stanno dietro il ruolo finanziario. Vedere di più è un atto deliberato e registrato.
21Accrediti manuali e ricariche
Accreditare fondi a un utente è un flusso di console a pieno titolo, non una scrittura sul database. Ogni accredito riporta un motivo scritto, e quelli oltre la soglia passano dalla casella delle approvazioni per il via libera di un secondo operatore.
22Operatività carte
Le carte dell'intera base: blocco e sblocco con l'impatto dichiarato, varianti di carta gestite per programma, ogni carta raggiungibile dallo User 360 a cui appartiene. Le azioni distruttive hanno la stessa finestra con motivo obbligatorio di tutto il resto.
23Conti bancari
I conti bancari della piattaforma hanno una vista dedicata, e i report bancari importati alimentano direttamente la coda di riconciliazione. Il circuito su cui il denaro si muove davvero è visibile nella stessa console del ledger in cui arriva.
24Command palette e ricerca
⌘K apre la palette da qualsiasi punto; la ricerca accetta nome, email, telefono o ID e arriva al record giusto. La console è pensata per essere usata da tastiera nei giorni peggiori.
25Campagne, referral e codici invito
Gli strumenti di crescita vivono nella stessa console: campagne configurate e monitorate, programmi referral sotto controllo, codici invito emessi e revocati. L'Ops gestisce le promozioni senza un secondo strumento di amministrazione.
26Versioni dell'app e tab mobile
Scopri quali versioni dell'app sono in circolazione e configura da remoto il layout dei tab. La shell dell'app si gestisce dalla console — cambiare un tab è configurazione, non una release.
27Contenuti, FAQ e chat
Contenuti in-app, FAQ e chat con i clienti si gestiscono in console. Chi risponde a una richiesta di supporto ha lo User 360 a un clic, non in un'altra scheda di un altro sistema.
28Operatività crypto
La parte crypto ha una sezione dedicata: panoramica crypto, wallet, registro degli asset e azioni crypto — accanto alla coda delle ricariche. Gli operatori vedono la superficie on-chain con la stessa profondità del ledger fiat.
29Esportazioni
I dati escono in modo pulito quando serve: export CSV su audit log e tabelle operative, filtrati esattamente come visualizzati. Ciò che chiede un auditor è un download, non un ticket per l'engineering.
30Whitelabel e ambienti
La console gira con il tuo brand — il deployment demo è YourBrand, non il nostro. Un banner persistente indica l'ambiente, le viste di produzione portano un badge prod e le azioni in produzione richiedono di digitare PROD. Nessuno confonde il deployment in cui si trova.
