IOSOR Guide
Finanza e prodotto condividono un solo export
Le dashboard di prodotto e la chiusura finanziaria devono leggere lo stesso export DLR. Un secondo foglio con stati più accomodanti è un errore di riconciliazione preannunciato.
Sia il team di prodotto sia la finanza necessitano della verità unica sui messaggi a fine mese. La modalità di errore classica consiste nell'avere due file: una dashboard di prodotto che conta i 'successi' e un foglio finanziario che conta le ricevute di consegna. Quando questi valori divergono, il saldo del wallet appare errato anche se gli addebiti prepagati erano corretti.
IOSOR richiede uno schema di export unico condiviso da entrambe le postazioni. Stessi stati DLR, stessi limiti temporali e stesse chiavi di corridoio. Il prodotto può creare grafici dal file e la finanza può elaborare tabelle pivot — nessuno dei due inventa un dizionario di stati privato.
Un solo export, due postazioni, le stesse colonne DLR
Pubblica un unico export di report che sia il prodotto sia la finanza possono scaricare. Le colonne indicano messaggi consegnati, falliti, sconosciuti, rifiutati e la spesa in un linguaggio di stato condiviso. Il prodotto può generare grafici e la finanza può aggiungere note di fatturazione, ma nessuno rinominerà 'unknown' in 'delivered' per rendere più gradevole una presentazione.
Il linguaggio di stato condiviso è il contratto
Il linguaggio di stato condiviso tra prodotto e finanza è il contratto che rende utilizzabile un unico export. Delivered indica una ricevuta di consegna effettiva. Submitted indica l'accettazione per l'invio, non la prova di arrivo in casella di posta. Unknown indica che si è ancora in attesa. Se il prodotto scrive 'OK' e la finanza scrive 'DLR delivered', hai già due verità all'interno dello stesso CSV.
La revisione del volume legge sempre lo stesso file
La revisione del volume del wallet e la governance della spesa si basano sullo stesso export. La revisione periodica in presenza di volumi di spesa mensili elevati utilizza i dati reali di consegna e addebito del pacchetto condiviso, non il conteggio di un funnel di marketing. Se la governance richiede i 'messaggi inviati con successo', traducili in ricevute consegnate nell'export, mai in totali inviati.
Rifiuta il secondo foglio di calcolo
Un foglio ombra che 'pulisce' gli stati per il consiglio di amministrazione è un anti-pattern: eliminalo o contrasseagnalo come non ufficiale. Se la direzione necessita di una vista più semplice, crea dei grafici dall'export canonico; non modificare manualmente gli stati. I partner white-label applicano la stessa regola: un solo contratto di export, senza alias di successo privati.
Percorsi operativi correlati
- Linguaggio di stato condiviso per prodotto e finanza
- guida operativa alla deliverability SMS
- governance di wallet e volume review
Inizia con IOSOR
Apri la scheda di report della console IOSOR e pianifica un export canonico contenente gli stati DLR standardizzati e le colonne di addebito per il tuo team. Invia sia i flussi di analisi di prodotto sia l'acquisizione del registro finanziario a questo singolo file pianificato o feed webhook. Elimina le macro di foglio di calcolo esistenti che riclassificano gli stati sconosciuti o inviati prima delle presentazioni al consiglio.
Sintesi IOSOR
La salute delle funzioni di prodotto e la governance della spesa finanziaria richiedono una verità di consegna identica. Riconciliare export separati per dashboard di prodotto e registri contabili crea discrepanze artificiali e nasconde i problemi di recapito dietro definizioni di stato personalizzate.
Fai in modo di acquisire un export automatizzato con termini di ricezione DLR rigorosi sia negli strumenti di prodotto sia in quelli finanziari. Non generare fogli di calcolo secondari o rimappare manualmente le colonne di stato per presentare curve di consegna più morbide.
Questa guida ti è stata utile?
Guide correlate
- Viste report rispetto alle righe del libro mastro del wallet
Le viste report raggruppano DLR e spesa. Le singole righe del libro mastro rimangono nell'export del wallet — non trattare il CSV del report come libro mastro.
- I report devono corrispondere ai DLR, non ai conteggi di invio
L'invio non equivale alla consegna. Le esportazioni dei report finanziari e di prodotto devono seguire le ricevute DLR: mai fatturare una settimana basandosi solo sui totali di accettazione.