Un workflow di pubblicazione social per le agenzie

Gli hashtag si controllano su ogni rete indicata dal piano, e un piano ha un solo insieme di hashtag. Instagram è l’unica rete con un tetto rigido: un post con più di 30 hashtag non può essere lanciato. Gli altri limiti sono consigli. Le verifiche segnalano un avviso quando un insieme supera 5 hashtag su Facebook, 10 su Instagram, 5 su LinkedIn o 3 su X, perché oltre quella soglia un post sembra spam: un insieme pensato per Instagram genera quindi un avviso non appena si aggiunge anche X. L’avviso lascia la scelta a una persona: ridurre l’insieme per adattarlo alla rete più restrittiva, oppure pianificare le reti separatamente.

Gli hashtag consumano anche lo spazio della didascalia. Un post si misura come didascalia, riga vuota e poi i tag: tre tag da dodici caratteri, gli spazi tra uno e l’altro e la riga vuota che li precede occupano quindi 40 dei 280 caratteri che X consente. Un tag deve anche diventare un link: è un segno # seguito da lettere, numeri o trattini bassi, perciò #Spring-Blend genera un avviso e #SpringBlend no. Prima di contare, il lancio mette in ordine ciò che può: aggiunge il segno # mancante, toglie gli spazi dentro un tag e conta una sola volta i tag che differiscono solo per le maiuscole.

Due permessi tengono separati i ruoli. L’accesso in modifica alla libreria del cliente permette di eseguire le verifiche e di inoltrare una richiesta, e il pulsante di chi lo ha dice «Request launch approval» (richiedi l’approvazione del lancio). Il permesso «Publish» (pubblicare), aggiunto all’accesso in modifica, avvia direttamente un lancio. Da solo permette di approvare o rifiutare una richiesta, annullarne una e segnare un post come pubblicato. Chi ha richiesto il lancio può ritirare la richiesta finché è in attesa, e un rifiuto porta sempre un motivo scritto.

Questa separazione permette a chi modifica di preparare l’intero lancio mentre un responsabile della pubblicazione ne risponde, e in un team piccolo una sola persona può avere entrambi i ruoli. Una richiesta fa suonare la campanella dei responsabili della pubblicazione del cliente e, in base alle loro impostazioni di notifica, raggiunge via email fino a cinque di loro. Compare in «Launches» in Team > Approvazioni e apre in Progetti un’attività «Approve launch» (approva il lancio). Nulla si muove finché un responsabile della pubblicazione non approva, e per il social non c’è nemmeno un posto in cui possa muoversi: a pubblicare sono le persone, non l’app. Un membro del team dell’agenzia ha bisogno sia del permesso sia dell’assegnazione al cliente, mentre un amministratore dell’agenzia ha ogni permesso: verifica quindi chi può pubblicare per un cliente prima di promettere un post per venerdì.

Un lancio manuale apre un’attività in Progetti, nel progetto «Marketing Plans» del cliente, riservato all’agenzia. Il titolo indica il post e le sue reti, come in «Launch Spring Blend post on Facebook, Instagram». L’attività va al responsabile della pubblicazione che ha avviato il lancio o approvato la richiesta, chi ha richiesto il lancio viene aggiunto come osservatore, e l’attività è segnata con priorità alta, in scadenza tra sette giorni e collegata al lancio. Poiché si trova in Progetti, compare nella board e nell’elenco attività di chi la riceve, accanto al resto del suo lavoro, ed è lì che una scadenza si nota.

L’attività dice cosa fare e cosa fare per ultimo: pubblicare su ogni rete a partire dalla specifica esportata, poi registrare il lancio nella pagina di lancio, aggiungendo il link live se c’è. Completare l’attività non segna il post come pubblicato, quindi una casella spuntata non può sostituire un post online. Finché è in attesa, la riga del lancio mostra il chip «Waiting for manual launch» (in attesa del lancio manuale) e la riga «Waiting to be published by hand» (in attesa di pubblicazione a mano).

Quando il post è online, un responsabile della pubblicazione apre il suo lancio e sceglie «Mark as published» (segna come pubblicato). Il link è facoltativo, ma se c’è deve essere un indirizzo https completo, e la nota può arrivare a 2.000 caratteri. La riga indica «Published» (pubblicato), l’attività si chiude con un commento che riporta il link e il piano risulta «Published» nel planner. Chi ha chiesto il lancio e il responsabile della pubblicazione che lo ha approvato vengono avvisati con la campanella e, in base alle loro impostazioni di notifica, anche via email, a meno che uno dei due non l’abbia registrato lui stesso. Il registro rimanda all’indirizzo con le parole «Open the live link» (apri il link live).

Un lancio contiene un solo link. Un post uscito su quattro reti ha comunque un solo registro: metti il primo indirizzo nel campo del link e gli altri nella nota, insieme all’ora di uscita e al nome di chi ha pubblicato. Se una rete ha cambiato qualcosa, per esempio ha ritagliato un’immagine o accorciato una didascalia, scrivilo lì. La specifica mostra cosa è stato approvato, la nota cosa è successo. Quando un post è segnato come pubblicato, il suo piano viene bloccato: una nuova versione parte quindi da un duplicato.

La pagina di lancio si legge un cliente alla volta, quindi le sue liste sono lo storico di pubblicazione di quel cliente: i post in attesa di approvazione, quelli in attesa di essere pubblicati a mano e infine quelli conclusi, mostrando i cento più recenti. Ogni riga indica il post e chi lo ha richiesto, con un chip di stato e da quanto tempo. Sopra le liste, quattro conteggi mostrano ciò che è in sospeso prima ancora di scorrere: i piani pronti, i lanci in attesa di approvazione, i lanci in corso e i lanci conclusi. Cambiando cliente nell’intestazione cambia anche la pagina, e con «Tutti i clienti» la pagina chiede di sceglierne prima uno.

Aprire un lancio mostra, per ogni rete, la didascalia, il numero di caratteri rispetto al limite e quante creatività la accompagnano, poi le verifiche superate e una cronologia di ogni passaggio. «Export spec (JSON)» (esporta la specifica) scarica l’intero post congelato. Risponde alle domande che emergono in una chiamata con il cliente: quale versione è stata approvata, chi l’ha registrata come pubblicata e dove si trova. Il registro appartiene all’agenzia. Non fa parte del portale cliente e le sue attività restano riservate all’agenzia.

In AI Marketing Dashboard non esiste alcun collegamento di pubblicazione con nessuna rete social. Il workflow non accede a Facebook, Instagram, LinkedIn o X, non pubblica e non mette in coda né programma nulla per dopo. Non verifica se un post sia andato online, quindi «Published» è la dichiarazione di un responsabile della pubblicazione e non la conferma di una rete, e il rendimento dei post è una questione di reporting che questo workflow non tocca. Una verifica presente in ogni lancio social lo dice con parole proprie: «Posting isn’t connected yet» (la pubblicazione non è ancora collegata). L’esportazione riporta il nome di ogni immagine e, quando ha un link a un file web, quel link; anche caricare l’immagine è un passaggio manuale.

Ciò che automatizza è tutto quello che sta attorno al post: l’approvazione che vincola la didascalia, le verifiche di rete, l’attività, le notifiche e il registro. Che il tuo team pubblichi dalla rete stessa o da uno strumento di programmazione che usa già, il lancio è identico, e didascalia e hashtag esportati vanno bene per entrambi. I lanci social sono inclusi dal piano Agency in su.