01Hele driften på én skjerm
Oversikten åpner dagen. Systemhelse for vedlikehold, API-broen, databasen og cachen. Signaler for breakers, leverandører og uløste feil. Arbeidet som tellede køer — 12 KYC-vurderinger venter, den eldste på 5h 02m, 8 avstemmingsavvik med €18,240 klare til å krediteres, 2 godkjenninger i vente. Nylige privilegerte handlinger og helse per leverandør ligger under. Ingenting på denne skjermen krever et ekstra verktøy.
- System, signaler og køer i én vertikal lesning
- Hvert kort lenker til køen det teller
- Leverandørhelse per rail — degradert, oppe, under gjenoppretting
02Operatørens copilot
Et copilot-panel åpnes ved siden av enhver visning, med kontekstbevisste startforslag — hvorfor feiler påfyll, oppsummer åpne hendelser. Den er skrivebeskyttet og utfører ikke handlinger. Og den svikter ærlig: til modellendepunktet er koblet til, sier panelet det rett ut i stedet for å dikte opp svar.
03Innsikt
Driften på én skjerm: 42,180 brukere, 12,408 aktive, 61.8% aktiveringsrate, 96.4% suksessrate og pengestrøm på +€1.84M inn og −€1.52M ut over 30 dager. KYC- og onboarding-traktene ligger ved siden av, så et fall i aktivering er synlig samme uke det begynner. Pengemetrikker ligger bak den økonomiske rollen.
04Feiltriage
Varselstrømmen kommer deduplisert. 142 forekomster av én WebhookSignatureError — som rammer 38 brukere — slås sammen til én kritisk rad med handlingene bekreft og løs, og visningen oppdateres hvert 10. sekund. Operatører løser signaturer, ikke sider med støy.
- Én rad per feilsignatur, med antall
- Berørte brukere knyttet til hver signatur
- Bekreft og løs som reviderbare handlinger
05Brukere, søkbare på alt
12,408 kontoer som kan søkes opp på navn, e-post, telefon eller ID, med KYC- og kontostatus på hver rad og faner for ventende KYC, verifisert, avvist, sperret og arkivert. Hver rad åpner en User 360 — saldoer, kort, enheter, KYC-nivå og full historikk for én kunde på én skjerm.
06KYC-vurderingskø
Ventende vurderinger kommer som en tellet kø med klokken synlig — 12 i demoen, hver rad med leverandør, status, siste årsak og hvor lenge søkeren har ventet. Et liveness-forsøk som har stått fast i 5h 02m vises i rødt. Godkjenn, avvis eller nullstill i konsollen; hver avgjørelse krever begrunnelse, revideres og endrer kontoens status overalt på én gang.
- Ventende, forhåndsfullførte, avviste og alle som faner
- Årsak på raden — adressevurdering, liveness-forsøk, dokumentvurdering
- Ventetid synlig, den eldste flagget
07Drill-down i hovedboken
Hver pengerad åpner seg helt ned. Overføring TR-90211 — en fullført peer-to-peer-betaling på €120.00 — viser avsender, mottaker og begge bokførte hovedbokposter: et debet på −€120.00 og et kredit på +€120.00, dobbelt bokholderi og i balanse. Ingen oppsummeringsvisning står mellom en operatør og hovedboken.
08Krypto-påfyll
Onchain-innskudd er førsteklasses rader, ikke en eksport fra et annet sted. Et vellykket påfyll på Base-nettverket viser 250.00 USDC som krediterer EUR-hovedboken, med vekslingskurs, gebyr, lommebokadresse og transaksjonshash i sidepanelet. Begge rails, én konsoll, sporbart helt ned til kjeden.
09Avstemming
Innkommende SEPA-innskudd matches automatisk mot brukere; unntakene havner i en tellet arbeidskø — matchede rader klare til kreditering, en ukjent betaler med to mulige treff, og faner for klar, trenger vurdering, umatchet og historikk. Kreditering er ett klikk når matchen er ren, og en begrunnet avgjørelse når den ikke er det — og hver manuelle kreditering krever begrunnelse, med beløpsgrenser hentet fra konfigurasjonen.
- Match en betaling mot en bruker, krediter og avstem
- Tvetydige betalere holdes tilbake for vurdering sammen med kandidatene
- Bankrapporter importeres rett inn i køen
10Tracer
Lim inn en referanse og få hele historien. Trace 9F21-0716 åpnes som et hopp-spor — forespørsel sendt, hovedbok validert mot policy, leverandørkurs registrert, onchain-bekreftelse på Base ved 12 av 12, oppgjør levert — hvert hopp tidsmålt, fra +42ms til +22s. Skrivebeskyttet av design: Tracer forklarer, den endrer aldri noe.
- Én referanse, hvert hopp fra forespørsel til oppgjør
- Policyen og kursen hvert hopp brukte, registrert
- Idempotensnøkkel synlig i sporet
11Godkjenningsinnboks
Krediteringer over grensen venter på en annen operatør. Innboksen deles i det som venter på din godkjenning og det du selv har bedt om — en goodwill-kreditering på €500.00 og en refusjon av mislykket påfyll på €120.00 på den ene siden, din egen gebyrtilbakeføring på €40.00 som venter på en medsignatør på den andre. Du kan ikke godkjenne saker du selv har opprettet; du kan trekke dem tilbake.
12Revisjonsloggen
18,942 operatørhandlinger i en append-only-tabell: tid, operatør, handling, mål, den skriftlige begrunnelsen og den underliggende forespørselen med responskode. Systemhandlinger havner i samme logg som menneskelige. Filtrer på operatør, handling eller dato; eksporter til CSV når noen utenfor konsollen spør.
- Kun tillegg — oppføringer endres eller fjernes aldri
- Begrunnelse og forespørsel knyttet til hver rad
- Filtrerbar, paginert, eksporterbar
13Webhook-inspeksjon og replay
18,204 innkommende leverandørhendelser, hver med signaturverifisering på raden. En mislykket hendelse kan spilles av på nytt for å bruke en tapt avgjørelse — krever begrunnelse, ingen doble varsler — men bare hvis signaturen er gyldig; ugyldige signaturer stoles ikke på, og replay er blokkert. Å vise rå payload sender umaskerte personopplysninger til nettleseren din, så det skriver en revisjonshendelse.
14Feature flags og remote config
38 typede nøkler fordelt på 8 områder — brytere, beløp, enumer — for kort, påfyll, KYC og resten av kjøretidsflaten. Hver nøkkel viser hvem som endret den sist og når; hver endring vises som diff, begrunnes og revideres. En utgiftsgrense eller en leverandørbryter er en endring i konsollen, ikke en app-release.
- Typede kontroller — ingen konfigstrenger i fritekst
- Historikk per nøkkel: hvem, hva, når, hvorfor
- Endringer trer i kraft uten app-release
15Kill switches
Når noe må stoppe, stopper det herfra. En global frysing viser vedlikeholdsskjermen ved appstart; kill switches per funksjon kutter kort, påfyll, overføringer eller KYC hver for seg — 4 aktive, 0 deaktivert i demoen. En OTP-bypass for QA ligger bak sin egen bryter, av som standard. Hver endring logges og dobbeltbekreftes.
16Operatører og roller
Teamet administreres der arbeidet skjer. Seks operatørkontoer har roller fra superadmin til auditor, og hver post viser nylig revidert aktivitet. Rolleendringer går gjennom en begrunnelsesdialog, og ingen kan endre sin egen rolle eller deaktivere seg selv — det må en annen superadmin gjøre.
- Seks roller — superadmin, ops, compliance, engineer, support, auditor
- Hver operatørs nylige handlinger på posten
- Ingen selvopphøyelse, ingen selvdeaktivering
17Handlinger med påkrevd årsak
En privilegert handling forklarer seg selv før den kjøres. Å fryse kort 4417 åpner en dialog som angir konsekvensomfanget, krever en skriftlig begrunnelse og — fordi dette er produksjon — får operatøren til å skrive PROD før bekreft-knappen aktiveres. Begrunnelsen havner i den uforanderlige revisjonsloggen ved siden av selve handlingen.
18Breakers og leverandørstatus
Utviklersiden følger breakers og leverandørstatus live. Når en leverandør svekkes, er breaker-tilstanden synlig i konsollen før supportsakene kommer inn — og det samme gjelder gjenopprettingen.
19Backoffice for betalingslenker
Lenkene kundene oppretter har en operatørvisning: i demoen 214 lenker fordelt på betalt, aktiv og utløpt, hver med tilhørende oppgjørsoverføring og en åpne-i-Tracer-lenke til hele sporingen. Å tilbakekalle en lenke er ikke en refusjon — det sier konsollen fra om før du gjør det.
20Innloggings-whitelists og maskert PII
Tilgang til konsollen er begrenset av en whitelist, og det operatørene ser er minimert som standard: e-post og telefon forblir maskert til de avsløres med vilje, og pengemetrikker ligger bak den økonomiske rollen. Å se mer er en bevisst, logget handling.
21Manuelle krediteringer og påfylling
Å fylle på en brukers konto er en fullverdig flyt i konsollen, ikke en skriving til databasen. Hver kreditering har en skriftlig begrunnelse, og krediteringer over terskelen går via godkjenningsinnboksen for godkjenning av en annen operatør.
22Kortoperasjoner
Kort på tvers av hele kundebasen: frys og tin med konsekvensomfanget oppgitt, kortvarianter administrert per program, og hvert kort nås fra User 360 det tilhører. Destruktive handlinger får den samme dialogen med påkrevd begrunnelse som alt annet.
23Bankkontoer
Plattformens bankkontoer har sin egen visning, og importerte bankrapporter mates rett inn i avstemmingskøen. Skinnegangen pengene faktisk beveger seg på er synlig i samme konsoll som hovedboken de lander i.
24Kommandopalett og søk
⌘K åpner paletten fra hvor som helst; søk på navn, e-post, telefon eller ID og kom rett til riktig post. Konsollen er bygget for å kunne styres fra tastaturet på en dårlig dag.
25Kampanjer, vervekampanjer og invitasjonskoder
Vekstverktøyene ligger i samme konsoll: kampanjer settes opp og følges opp, vervekampanjer overvåkes, invitasjonskoder utstedes og tilbakekalles. Ops kjører kampanjer uten et ekstra adminverktøy.
26Appversjoner og mobilfaner
Se hvilke appversjoner som er i bruk, og konfigurer fanelayouten i mobilappen eksternt. Appskallet styres fra konsollen — en fanendring er konfigurasjon, ikke en release.
27Innhold, FAQ og chat
Innhold i appen, FAQ-oppføringer og kundechatten styres i konsollen. Den som besvarer en supporttråd har User 360 ett klikk unna, ikke i en annen fane i et annet system.
28Kryptooperasjoner
Krypto har sin egen seksjon: en kryptooversikt, wallets, et aktivaregister og kryptohandlinger — ved siden av køen for påfyll. Operatørene ser on-chain-flaten like grundig som fiat-hovedboken.
29Eksport
Dataene forlater systemet rent når det trengs: CSV-eksport fra revisjonsloggen og driftstabellene, filtrert nøyaktig slik de vises. Det en revisor ber om er en nedlasting, ikke en utviklingssak.
30Whitelabel og miljøer
Konsollen kjører under ditt merke — demoinstallasjonen heter YourBrand, ikke vårt navn. Et fast banner viser miljøet, produksjonsvisninger har et prod-merke, og produksjonshandlinger krever at operatøren skriver PROD. Ingen tar feil av hvilket miljø de er i.
