Come un sistema di pagamento è passato dalla crisi al 99% di uptime
99.19%
success rate globale
-25%
incidenti post-release
Ruolo
Senior Product Manager, Payments
Periodo
2025
Settore
B2B SaaS · Payments · Enterprise
99.19%
success rate globale
-25%
incidenti post-release
99.19%
success rate globale. 100% uptime contro un target del 99%
I clienti perdevano soldi a ogni transazione. Ho trovato i 4 problemi che contavano davvero su 44, li ho risolti in 6 settimane, e ho portato il sistema al 99%+ di affidabilità.
Addebiti doppi. Rimborsi che non arrivavano. Il sistema che si piantava nelle ore di punta. C'erano 44 problemi aperti e tutti volevano tutto risolto subito. Ho capito quali 4 stavano facendo perdere soldi per davvero, li ho risolti in 6 settimane, e il sistema è diventato affidabile al 99%+.
L'istinto in una crisi è risolvere e crescere allo stesso tempo. Non funziona. La prima vera decisione di prodotto è smettere di scavare il buco più in profondità.
Il contesto
Un prodotto che gestiva soldi veri per centinaia di attività in cinque paesi. Era la linea di ricavi che cresceva più veloce in azienda — 42% del volume totale delle transazioni, 25% di crescita anno su anno, l'unico che andava verso l'alto.
Finché la crescita non ha superato quello che il prodotto era in grado di fare. La versione originale era nata per pochi clienti fidati. Adesso girava su una scala molto più grande, e la distanza tra 'tecnicamente funziona' e 'ci puoi contare' era diventata impossibile da ignorare.
La sfida
Oltre il 60% dei clienti arrivati da poco era scontento o aveva smesso di usare il prodotto. Le lamentele si accumulavano. Le attività che già lo usavano si ritrovavano addebiti doppi, rimborsi che non andavano a buon fine, e il sistema che si bloccava nelle ore di punta. Ogni problema costava soldi veri.
Il problema di fondo: si continuavano ad aggiungere clienti nuovi a pieno ritmo mentre quelli esistenti erano in difficoltà. Ogni nuovo cliente scontento significava più lamentele, più danno alla reputazione, più pressione sul team di supporto. Il prodotto non reggeva più il passo, e la crescita peggiorava tutto.
Nessuno aveva una visione chiara di cosa fosse rotto davvero, quanto fosse grave ogni problema, o chi se ne stesse occupando.
L'approccio
La prima decisione è stata smettere di scalare il problema. Le feature di crescita sono state messe in pausa. L'acquisizione clienti è rallentata. L'intero team si è spostato su una singola priorità: far funzionare in modo affidabile i centri già in produzione. Questo ha richiesto allineare la leadership commerciale, l'engineering e gli stakeholder executive sugli stessi dati. I numeri sulla soddisfazione clienti hanno fatto il caso.
La prima decisione è smettere di scavare. Tutto il resto viene dopo.
Poi è arrivato il triage. 44 problemi aperti nel backlog, segnalati da engineering, sales e supporto senza un ordine di priorità. Il criterio di ordinamento era semplice: questo sta costando soldi a un centro adesso? Questo ha diviso il backlog in tre livelli. 12 problemi erano critici per le operazioni di pagamento. Di questi, 4 avevano impatto finanziario immediato sui centri live: addebiti doppi, timeout dei pagamenti, split payment non funzionanti, rimborsi mancanti. I restanti 32 erano problemi reali, ma potevano aspettare.
I 4 problemi a più alto impatto hanno ottenuto un responsabile ciascuno, una scadenza e un impegno pubblico. Tutti e quattro sono stati rilasciati in sei settimane. Zero lamentele su nessuno di essi dopo il rilascio.
Un unico criterio di priorità chiaro ha dato al team più direzione di qualsiasi discussione.
Mentre il team stabilizzava, ho scavato in un problema che altri avevano classificato come irrisolvibile. Un centro importante stava per cancellare l'integrazione perché non riusciva a riconciliare i conti. Ogni transazione appariva come "entrata non categorizzata" nella dashboard Square. Nessun dettaglio per terminale, nessuna attribuzione della fonte, nessun modo di chiudere i conti.
La causa radice era nell'API di Square. Il campo dove venivano salvati i metadati delle transazioni non preservava informazioni sufficienti. Ho tracciato il data model fino a trovare `external_payment_type`, un parametro esistente che poteva trasportare l'attribuzione della fonte senza modifiche architetturali su nessuno dei due lati. Ho scritto le specifiche di implementazione e le ho passate al team. Il centro è rimasto ed è diventato un account di riferimento.
La disciplina di scope contava quanto la velocità. Nell'arco dell'intero anno, 23 dei 44 item sono stati rilasciati. Gli altri 21 erano decisioni deliberate di "non ora", ciascuna con una motivazione documentata. I 12 item critici di pagamento sono stati ridotti a 5 rimanenti, con ogni problema risolto validato in produzione. Quando la feature di rimborso non era abbastanza solida prima del picco natalizio, l'ho ritirata e ho organizzato una giornata completa di test piuttosto che rilasciare logica rotta a centinaia di centri durante la settimana più intensa.
In parallelo alla stabilizzazione, sono corsi due filoni di compliance. Ho proposto una riduzione di scope per la certificazione PCI DSS presentando ai certificatori un'architettura di pagamento a tre canali, eliminando un rischio significativo di penale ricorrente. Ho anche completato end-to-end la certificazione tecnica FreedomPay, che ha sbloccato un nuovo segmento di centri enterprise.
La comunicazione è stata deliberata. Riepiloghi settimanali strutturati, memo operative per decisioni urgenti, verbali delle riunioni pubblicati entro poche ore. Quando il team di supporto doveva aiutare clienti con problemi non ancora risolti, ho creato video tutorial sulle soluzioni temporanee. Soluzioni ponte mentre le correzioni vere erano in coda.
I risultati
-12%
tempi di elaborazione su tutti i flussi di pagamento
99.19%
success rate globale. 100% uptime contro un target del 99%
-25%
incidenti post-release
25%
crescita anno su anno per l'integrazione Square, l'unico fornitore ancora in crescita
116
centri integrati. 5 nuovi centri a settimana come ritmo di onboarding
23/44
item del backlog rilasciati. Problemi critici di pagamento ridotti da 12 a 5 rimanenti
Cosa ho imparato
L'istinto in una crisi è risolvere tutto e crescere allo stesso tempo. Non funziona. La prima vera decisione di prodotto è smettere di scavare il buco più in profondità. Tutto il resto segue da lì.
La seconda cosa: 44 problemi, 12 critici, 4 urgenti. La maggior parte di quello che sembrava urgente poteva aspettare. Sapere quali no è la vera competenza. Un singolo criterio di ordinamento chiaro ha dato al team più chiarezza di qualsiasi discussione.
La terza: quando un problema viene etichettato come "irrisolvibile" o "in attesa del partner", vale la pena verificare se qualcuno ha effettivamente letto la documentazione dell'API. La correzione per l'attribuzione della fonte era già lì. Serviva solo qualcuno disposto a cercare.
Approcci trasferibili
Crisi → Blocco → Triage → Correzione → Ripresa
Quando un sistema è in fiamme, l'istinto è risolvere tutto contemporaneamente. Lo schema che funziona: congela l'ambito, fai il triage senza pietà (siamo passati da 44 problemi a 4 priorità), aggiusta quello che conta, poi riprendi la crescita.
Le metriche come strumento di triage, non decorazione di dashboard
Il numero 99.19% di uptime contava solo perché veniva dal misurare ogni modalità di fallimento. La dashboard non era per i dirigenti — era per l'ingegnere di turno alle 2 di mattina.
Disciplina di ambito sotto pressione
Ogni persona coinvolta aveva la sua correzione preferita. La regola: se non riduce direttamente il tasso di errore, aspetta. Dire no a 40 problemi ha reso possibile risolvere i 4 che contavano.
L'architettura post-crisi > architettura pre-crisi
Il sistema di pagamento dopo il rescue era migliore di quello prima della crisi. Le crisi espongono il debito tecnico che le operazioni normali nascondono.