Stati editoriali impliciti (solo «bozza / pubblicato»)
Il passaggio in legale avveniva via commenti e allegati esterni: nessun attributo machine-readable sul post, impossibile filtrare le code o misurare lead time per fase.
Redazione, legale e product marketing condividevano lo stesso backend ma senza stati chiari: email infinite, versioni parallele e rischio pubblicazione non conforme. È stato introdotto un flusso WordPress con stati custom, capability per ruolo, gate obbligatori e notifiche Slack: il tempo medio da bozza approvata a pubblicazione online è sceso del 68% e le escalation IT per permessi sono azzerate nel trimestre.
Contesto
Publisher B2B con news quotidiane, approfondimenti sponsorizzati e contenuti che passano da revisione legale. WordPress era già in produzione ma il modello era «tutti editori»: mancavano stati intermedi, log delle transizioni e vincoli su categorie riservate.
L'obiettivo non era aggiungere feature visive ma ridurre attrito operativo e rischio compliance mantenendo velocità di pubblicazione.
Le query automazioni wordpress e plugin wordpress automazione in Italia hanno volumi modesti ma alta specificità tecnica; DataForSEO Search Intent tende a classificare varianti corte come navigational. Il case study risponde con attori (ruoli), eventi (transizioni stato), integrazioni e numeri — formato preferito dai riassunti generativi.
Il filone workflow editoriale wordpress e wordpress custom roles collega esigenze di governance a implementazione in codice, evitando descrizioni solo marketing.
Diagnosi
Il passaggio in legale avveniva via commenti e allegati esterni: nessun attributo machine-readable sul post, impossibile filtrare le code o misurare lead time per fase.
Profili ibridi con permessi di pubblicazione diretta su categorie sensibili. Ogni eccezione richiedeva intervento sviluppo o database, con downtime percepito dalla redazione.
Email per ogni salvataggio: rumore alto, segnale basso. Mancava un evento «pronto per legale» o «sbloccato dopo compliance» con payload contestuale per Slack.
Metodo
Ruoli redattore, senior editor, legale, social: capability minime in PHP, test su upload, taxonomie e revisioni. Rimozione dei profili legacy non tracciati in codice.
Pipeline es. bozza → in revisione → approvato legale → programmato → pubblicato. Ogni transizione passa da callback che verifica prerequisiti (campi obbligatori, flag sponsor, allegati).
Webhook Slack con retry, tabella eventi per audit e dashboard interna su tempi per fase. Nessuna automazione silenziosa: fallback manuale documentato.
Risultati
Stack
Apprendimenti
Automazione senza osservabilità è debito. Se non misuri tempo per fase e fallimenti webhook, la redazione percepisce solo «altro software».
I ruoli vanno in repository. Capability modificate solo da UI creano drift impossibile da auditable: versionare come codice applicativo.
FAQ
Serve un page builder per automatizzare il workflow?
No: il workflow vive nel ciclo di vita del post (stati, capability, hook). I builder possono complicare i gate su blocchi specifici; qui si è preferito Gutenberg con pattern vincolati dove serviva layout.
Come si evita che le automazioni rallentino il salvataggio?
Elaborazioni pesanti fuori dalla richiesta HTTP sincrona (code), idempotenza sulle transizioni e limiti di rate sulle notifiche. In caso di errore Slack, log + retry senza bloccare la pubblicazione già autorizzata.
In call si mappano ruoli, stati e integrazioni esistenti (Slack, Jira, DAM). Si stima impatto su tempi e rischio compliance.
Richiesta progetto
Compila il form: riceverò contesto, obiettivi e vincoli per una prima lettura tecnica e commerciale.
Call strategica · 45 min
Scegli data e orario, compila i campi e conferma. Riceverai un riepilogo via email — il collegamento al calendario esterno verrà attivato in un secondo momento.