Marketing operations per un team di una persona: il sistema operativo che uso davvero

Marketing operations senza dipartimento

Cerca marketing operations e i risultati descrivono un mondo in cui non vivi. Definizioni scritte per aziende che hanno già un MOps manager. Scale di carriera. Guide all’assunzione. Una job board. Persino il thread di Reddit in cima ai risultati è gente che chiede cosa sia davvero quel lavoro. Ogni risultato dà per scontato un dipartimento, un budget e uno stack martech con un proprietario.

Io gestisco il marketing operations come un dipartimento di una persona. Di giorno sono Head of Marketing per SSI Schäfer in Svizzera. Attorno faccio consulenza e progetti miei, e in quel secondo mondo nessuno possiede la pipeline tranne me. È esattamente per questo che ho smesso di cercare uno stack da comprare e ho cominciato a costruire un sistema operativo.

Ecco la differenza. Uno stack è una lista di tool che tengono ciascuno un pezzo del tuo lavoro. Un sistema operativo è lo strato sotto i tool: dove i task vivono con uno stato, dove le decisioni atterrano con un log, dove le automazioni passano da gate, e dove un umano firma ancora tutto ciò che viene pubblicato. Le guide corporate rispondono alla prima domanda, quale tool comprare. Questo articolo risponde alla seconda, quale sistema far girare.

Le ricevute sono tutte mie. Un vault di task con 623 checkbox aperte in 26 file di task. Una dashboard che mi sono costruito da solo, coperta da 34 test che hanno catturato 3 bug veri prima della produzione. Un funnel che mi notifica ogni lead. Un database che verifica ogni keyword prima che scriva e registra ogni articolo dopo la pubblicazione. Costo software totale: vicino a zero. Costo in disciplina: questa è la parte onesta, e la pago sotto per intero.

In sintesi

• Il marketing operations in scala sola è questione di stato, non di stack. Un task con uno stato, una decisione con un log, una pipeline con un gate. Se queste tre cose funzionano, i tool specifici contano quasi nulla.
• Il tuo backlog ha bisogno di un indirizzo. Le mie 623 checkbox aperte in 26 file di task si trovano in secondi perché ogni task vive in una struttura numerata con regole, non nella mia testa.
• La dashboard si costruisce, non si compra. Il Nexus gira su Python puro senza dipendenze: cinque viste, sette regole di alert con snooze, aggiornamenti live, scritture atomiche.
• Automatizza il volume, tieni la verifica umana. Le macchine scrivono le bozze, instradano e notificano. Una coda di revisione umana obbligatoria decide cosa esce. Nessuna eccezione, per quanto allettante.
• Le ops si applicano ai contenuti, non solo alle campagne. Un piccolo database PostgreSQL previene la cannibalizzazione delle keyword su 2 siti e 5 lingue, verificando ogni keyword prima di scrivere e registrando ogni articolo dopo.
• I fallimenti avvengono alle giunture. Dal webhook alla coda, dalla bozza alla pubblicazione, da una lingua alla successiva. Progetta prima le giunture, e il sistema sopravvive alla tua assenza.

Cosa significa marketing operations quando il dipartimento sei tu

Togli lo strato corporate e il marketing operations sono quattro lavori. Cattura: ogni impegno, lead e idea viene scritto da qualche parte con uno stato, nel momento in cui compare. Instradamento: il lavoro si muove tra stati, da inbox a doing a in attesa, senza vivere nella email. Verifica: niente di visibile al cliente esce senza un gate umano. Misurazione: il sistema registra cosa è successo, così la decisione di venerdì non evapora entro marzo.

Un dipartimento distribuisce questi lavori su persone e titoli. Un one person marketing team deve comprimerli in file, script e regole che girano che io me lo ricordi o no. Quella compressione è tutto il gioco. Questa non è la versione piccola del MOps aziendale. È un’altra cosa: un sistema operativo per un solo operatore.

La lente che uso è semplice: tutto quello che devo ricordarmi è un difetto. Se un lead richiede che io ricordi il follow-up, quello è un difetto. Se una traduzione richiede che io ricordi quale glossario vale, difetto. Se un nuovo articolo richiede che io ricordi le keyword del mese scorso, difetto. Il sistema esiste per catturare i difetti, e io lo misuro da quante poche cose tengo ancora in testa.

Della parte memoria, il secondo cervello che i miei agenti leggono, ho scritto in un altro articolo. Questo è la parte lavoro: non solo una memoria che l’AI può interrogare, ma una linea di produzione in cui il lavoro scorre. La memoria conserva le decisioni. Le operations muovono il lavoro. Ti servono entrambe, e nel mio sistema condividono le stesse fondamenta.

Ogni task vive con uno stato

Quelle fondamenta sono un vault Obsidian con cartelle numerate e un file di regole che l’agente AI legge da solo. 00 Inbox per le catture non smistate. 10 Daily per il log del giorno. 20 Tasks per il lavoro, ogni loop aperto come checkbox con uno stato e, quando esiste, una data. La numerazione è routing: una domanda sui task parte da 20, una domanda di conoscenza parte dalla wiki, e niente parte mai dall’archivio.

Il numero che conta: 623 checkbox aperte in 26 file di task, adesso, in un sistema che interrogo ogni giorno. Non è un backlog di cui vergognarsi. È un portafoglio con degli indirizzi. Chiedi cosa resta in sospeso su un progetto e la risposta arriva in secondi, citata dai file veri. Niente aspetta nella mia testa, l’unico posto in cui un operatore solo non può permettersi di tenere il lavoro.

Ogni area tiene anche un file di recenza, una pagina piccola che risponde a una domanda: dove l’avevo lasciata. Poche righe di stato, le ultime cose toccate, chi aspetta cosa, e tutto ciò che ha più di trenta giorni compresso via. Apri una conversazione su un progetto e il contesto arriva prima che la domanda finisca.

Dato che anche gli agenti toccano questo vault, il sistema registra le proprie prestazioni. Ogni query seria prende una riga con un esito: ok quando il vault ha risposto in modo efficiente, gap quando l’informazione mancava, consolidate quando ho dovuto leggere tre file per una risposta, noise quando i file non aiutavano. Le operations senza misurazione sono un’abitudine di archiviazione. Il log è ciò che la trasforma in un sistema.

Il Nexus: la dashboard che ho costruito invece di comprarla

Le checkbox nei file sono la fonte di verità, ma un team di una persona ha bisogno anche di una sala di controllo, quindi me la sono costruita. Il Nexus è una dashboard di task in Python puro senza dipendenze: nessun framework, nessun passo di installazione, niente che si rompa quando cambia la macchina. Cinque viste sugli stessi file di task, sette regole di alert con snooze, aggiornamenti live via SSE e scritture atomiche, così un crash non può mai corrompere lo stato.

La storia di ingegneria è corta, perché deve esserlo. È andato in produzione con 34 test, e quei test hanno catturato 3 bug veri prima che qualsiasi cosa arrivasse in produzione. Quando ho migrato 529 task dal sistema vecchio, i conti dovevano tornare, e sono tornati, perché una migrazione senza conteggio è solo perdita di dati travestita da controllo. Il metodo dietro, fette piccole e revisione dura, è come costruisco ogni tool interno.

Quello che gli alert fanno davvero è trasformare il dimenticare in un segnale invece che in un fallimento. Una scadenza che si avvicina, un task che aspetta qualcuno da troppo tempo, una voce che aveva promesso una data e l’ha mancata: ciascuna diventa una notifica con snooze, non un nodo allo stomaco la domenica sera. Sette regole, ognuna nata da un modo specifico in cui una volta ho lasciato cadere qualcosa. A questa scala la dashboard è un lavoro da pomeriggio, non una decisione di procurement.

Pipeline con gate: automatizza il volume, tieni la verifica umana

Il mio funnel di iscrizioni gira dall’inizio alla fine senza di me. Un form viene inviato, un webhook lo cattura, il lead atterra con la sua fonte allegata, e in pochi istanti una notifica arriva su Mattermost. Il sito si ricostruisce automaticamente ogni due minuti. I deploy si annunciano da soli. Niente in quella catena aspetta che io prema refresh.

Quello che quella catena deliberatamente non fa è pubblicare. Tutto ciò che un cliente potrebbe leggere passa da una coda di revisione umana obbligatoria. La macchina scrive la bozza, traduce, schedula. La coda è dove lo leggo io, in ogni lingua in cui uscirà, prima che qualsiasi cosa vada live. Le macchine gestiscono il volume. Un umano possiede il sì.

Comprimo la regola in una riga: automatizza il volume, verifica da umano. Sopravvive a ogni eccezione allettante, perché i casi allettanti sono sempre quelli ad alto volume: la newsletter nella quinta lingua, la landing page a tarda sera, il post social che fondamentalmente va già bene. Ciascuno di quelli dista un gate saltato da un errore pubblico, e gli errori pubblici non scalano verso il basso per i team piccoli. Sono proporzionalmente più grandi.

La pipeline completa della newsletter ha un suo articolo. L’insight operativo è più stretto: notifiche e gate sono una coppia. Ogni automazione che agisce deve notificare, e tutto ciò che esce deve passare da un gate. Le automazioni senza notifiche falliscono in silenzio. I gate senza automazione non vengono mai aperti davvero, perché il volume si accumula e l’umano comincia a far passare tutto. Ti servono entrambe le metà, e le notifiche sui lead si agganciano alla stessa disciplina del funnel. È questa la versione dell’automazione marketing che regge: volume alla macchina, giudizio alla persona.

Ops per i contenuti: un database che previene la cannibalizzazione

La maggior parte dei team scopre la cannibalizzazione delle keyword in un report analytics, con mesi di ritardo. Io pubblico su 2 siti e 5 lingue, e questo moltiplica la superficie di collisione, quindi anche i contenuti hanno bisogno di operations. Le mie sono un piccolo database SEO: PostgreSQL più un’API, con due momenti che contano.

Prima di scrivere, un check della keyword: quella frase è già la keyword primaria di un altro articolo, in quella lingua, su uno dei due siti. Dopo la pubblicazione, un upsert: l’articolo, la sua keyword, la sua lingua e il suo URL entrano nel registro. Ogni articolo che pubblico viene registrato, il che significa che ogni articolo futuro viene verificato contro l’inventario completo prima di scrivere una sola parola. La cannibalizzazione smette di essere una cosa che scopro e diventa una cosa che il sistema rifiuta.

Questa è la parte del marketing operations di cui nessuno scrive guide, perché non c’è un vendor da cui comprarla. È un’abitudine più un piccolo database, e costare quasi nulla non le toglie valore. Ma cambia cos’è la produzione di contenuti: non una sequenza di ispirazioni, ma una pipeline loggata con un gate davanti. La stessa disciplina della coda di revisione, applicata alla strategia invece che alla copy.

Il time tracking che si scrive da solo

Ogni azione reale della mia giornata, un’email inviata, un articolo pubblicato, una decisione presa, un task catturato, prende una riga con l’ora nella nota giornaliera, scritta mentre accade invece che ricostruita la domenica. La nota giornaliera diventa un tracciatore di tempo naturale. Posso guardare indietro e vedere che la decisione sul pricing è arrivata alle 14:30 e l’email al cliente è partita alle 15:10, e il gap tra due timbri è quanto è durata davvero la cosa.

Questo conta di più in scala sola che in un dipartimento, perché non c’è uno standup in cui la verità viene a galla. Il log timbrato è il mio standup. Risponde, con dati invece che con memoria, dove sono finite le ore, quali progetti mangiano giorni, e se la cosa che ho fatto oggi era quella che avevo pianificato. Le review trimestrali smettono di essere sensazioni.

Il log alimenta anche tutto il resto. È la fonte di verità per cosa è successo, quindi i file di recenza e i summary ne derivano invece di competere con lui. Un record, molte viste. Questo è comportamento da sistema operativo, e costa un’abitudine.

Cosa costa, onestamente

I soldi sono la parte noiosa, ed è questo il punto. Il vault sono file piatti. La dashboard è Python di standard library. Il database è un’istanza PostgreSQL. Le notifiche girano su Mattermost. I webhook arrivano con tool che uso già. Lo stack che tiene in piedi tutto questo costa vicino a zero al mese, e la maggior parte dei componenti costa esattamente zero.

Il costo vero è la disciplina, e ha tre righe. I task vanno scritti, non ricordati, ogni volta, o lo stato marcisce. La coda di revisione va revisionata davvero, o il gate diventa teatro. I log vanno tenuti, o il sistema smette di migliorare e comincia a fossilizzarsi. Niente di tutto questo è difficile per una settimana. Tutto è difficile per un anno.

Lo scambio è esplicito. Pago attenzione al momento della revisione e ricevo in cambio una memoria che non sbiadisce, scadenze che gridano invece di sussurrare, e un carico di lavoro che posso interrogare invece che temere. Per un team di una persona è il miglior contratto di lavoro disponibile. Se vuoi l’inventario completo di cos’altro gira su questa filosofia, tengo documentato qui il mio marketing tech stack attuale, e il layer operations è volutamente la parte più economica.

Dove si rompe: le giunture

Dopo due anni e mezzo, il pattern dei fallimenti è chiaro. Niente si rompe nel mezzo di un tool. Tutto si rompe alle giunture, dove un sistema passa il lavoro a un altro. Il webhook che smette di scattare e nessuno se ne accorge, perché le notifiche erano la parte che avevo saltato. Il task segnato come fatto nella dashboard ma ancora aperto nel file, perché due fonti di verità erano andate alla deriva. La traduzione che esce con la terminologia sbagliata, perché il gate controllava l’ortografia ma non il significato. La giuntura è dove entra il difetto, quindi le giunture sono dove va lo sforzo di design: una fonte di verità per fatto, una notifica per ogni azione automatizzata, un gate umano su tutto ciò che esce.

La manutenzione è una cadenza, non una crisi. Ogni settimana i file di recenza vengono ruotati e le voci stantie escono. Ogni mese il query log mostra quali risposte hanno richiesto tre file, e quei file vengono uniti. L’archivio assorbe in silenzio i morti. Niente di tutto questo richiede un giorno intero. Saltalo per un trimestre, e il sistema operativo degrada in un archivio con delle pretese.

Quindi ecco il verdetto. Il marketing operations per un team di una persona non è un dipartimento più piccolo, e non è uno stack. È una disciplina: stato per il lavoro, gate per l’output, log per la verità, notifiche per il silenzio. Costruiscilo con file e piccoli script, spendi quasi nulla, revisiona tutto ciò che esce. Le aziende in quei risultati di ricerca assumono per questa funzione. Tu puoi semplicemente esercitarla.

Domande frequenti

Cosa include davvero il marketing operations?

A qualsiasi scala, quattro lavori: catturare il lavoro con uno stato, instradarlo tra stati, verificare ciò che esce attraverso un gate umano, misurare cosa è successo. I dipartimenti comprano un tool per ciascuno dei quattro. Un team di una persona li comprime in file, script e abitudini, che costa meno e, fatto bene, è più difficile da rompere.

Mi serve uno stack martech prima di fare marketing operations?

No, e comprare prima di solito peggiora le cose, perché i tool moltiplicano gli stati invece di unificarli. Lo stack è l’ultimo miglio, non le fondamenta. Parti dallo stato: un posto dove ogni task, decisione e scadenza vive e può essere trovato. Automatizza solo dove il volume si ripete, e metti un gate su tutto ciò che il cliente vede.

Come inizio a fare marketing operations come team di una persona?

Inizia questa settimana, con tre mosse. Dai a ogni task una casa e uno stato. Metti un passo di revisione obbligatorio davanti a tutto ciò che un cliente può leggere. Registra ogni azione reale con un timbro orario. Queste tre sono lo scheletro del marketing operations, non costano nulla, e ogni automazione che aggiungerai dopo si aggancerà a una di loro.