Team · Approvazioni
Ogni via libera, in un’unica coda
Revisioni della libreria, piani di campagna, richieste di lancio e ferie aspettano in un unico posto, e ciascuno si decide con le regole dello strumento a cui appartiene. Crea il tuo spazio di lavoro, oppure scopri come funziona.
Hai già uno spazio di lavoro? Accedi
- Piani da 99 $ al mese
- Pensato per le agenzie con più clienti
- Il tuo brand in tutta la console
Team · Approvazioni
Workflow di approvazione per agenzie, con una sola coda per ogni decisione
In molte agenzie un via libera è un messaggio in chat che dice «ok, mandalo». Non è legato a nessuna versione, nessuno lo ritrova un mese dopo, e il collega che ha modificato il file in seguito non l’ha mai visto. Approvazioni di AI Marketing Dashboard lo sostituisce con un workflow di approvazione costruito attorno a un’unica coda. Gli asset della libreria inviati in revisione, i piani di campagna inviati per l’approvazione, i lanci che qualcuno ha richiesto e le richieste di ferie aspettano tutti lì, ciascuno deciso da una persona autorizzata a deciderlo, con le regole dello strumento a cui appartiene. Un piano modificato dopo l’approvazione lo dice, e un lancio non può partire in forza di un vecchio sì.
Chat o coda
Dove si conserva un sì decide se ci si può fidare
Un via libera vale quanto il registro che lascia. Metti un pollice in su in una conversazione accanto a una decisione presa dove le regole possono vederla.
Via libera a messaggio
- Un sì in una conversazione in chat, legato a nessuna versione
- Un’approvazione via email che la persona successiva non vede mai
- Un piano modificato dopo l’ok, senza che nessuno lo sappia
- Un lancio chiesto con un colpetto sulla spalla
- Ferie decise nel primo messaggio arrivato
Ogni sì era sincero, e nessuno di essi si può verificare dopo.
Via libera in un’unica coda
- Fino a cinque schede raccolgono ciò che aspetta una persona
- L’approvazione di un piano copre il piano com’è stato approvato
- Un piano rimandato indietro, o una richiesta di lancio o di ferie rifiutata, porta un motivo scritto
- Le richieste di lancio aspettano qualcuno con il permesso «Publish»
- Le righe di piani, lanci e libreria aprono il record di cui parlano
Ogni decisione mantiene le regole dello strumento a cui appartiene, quindi la coda non aggiunge scorciatoie.
La coda
Svuota le decisioni del mattino in un solo giro
Tutto ciò che aspetta una persona è elencato per ciò che è e per chi deve muoversi per primo, così i primi dieci minuti della giornata sono un giro su una sola pagina.
Decisioni su libreria, lanci e ferie senza saltare da una scheda all’altra
- Schede «All», «Library», «Plans», «Launches» e «Time off», con «Time off» riservata agli amministratori
- I piani approvati restano elencati per 14 giorni
- Un filtro per cliente che parte dal cliente scelto nel selettore dell’intestazione
Il percorso di un piano
Da un piano inviato a un lancio autorizzato a partire
Quattro passaggi portano un piano da chi lo ha costruito a chi lo pubblica, e ciascuno lascia un registro.
Invia con un revisore
Chi costruisce il piano lo invia in approvazione e può indicare un revisore. Un’attività di revisione compare nel progetto «Marketing Plans» del cliente, in scadenza tra tre giorni e assegnata al revisore se ne è indicato uno, e la campanella e un’email avvisano chi deve decidere.Decidi sul piano così com’è
Chi approva lo approva, oppure lo rimanda con una nota. Chi ha inviato un piano non può approvare il proprio. Un amministratore dell’agenzia può, e la cronologia registra che lo ha fatto.Aprilo in Lancia
Un piano approvato compare in «Ready to launch» (pronti al lancio) nella pagina di lancio del suo canale. Modifica prima il piano e viene segnalato come cambiato, e il lancio è rifiutato finché non viene approvato di nuovo.Se non puoi, chiedi a un responsabile della pubblicazione
Un collega senza il permesso «Publish» presenta invece una richiesta di lancio. Un responsabile della pubblicazione legge le verifiche, approva o rifiuta con un motivo, e le verifiche si ripetono mentre approva.
Guarda il video guida
Guarda decidere un asset della libreria, un piano e una richiesta di lancio
Il video guida parte da ciò che è in attesa, apre un asset come lo vedrà il cliente, lo rimanda indietro con un motivo, approva un piano e finisce spiegando perché una richiesta di lancio è una decisione separata.
- 0:00Guarda tutto ciò che aspetta te
- 0:06Apri l’asset come lo vedrà il cliente
- 0:11Rimandalo indietro con un motivo chiaro
- 0:20Approva un piano così com’è
- 0:29Le richieste di lancio sono separate
42 secondi
Leggi la trascrizione
0:00 Guarda tutto ciò che aspetta te. Asset della libreria, piani, lanci e ferie arrivano in un’unica coda. Filtrala per cliente.
0:06 Apri l’asset come lo vedrà il cliente. Le revisioni della libreria si aprono a schermo intero e mostrano l’asset esattamente come lo vede il cliente.
0:11 Rimandalo indietro con un motivo chiaro. «Request changes» richiede una nota. Di’ cosa correggere, così l’autore può agire.
0:20 Approva un piano così com’è. Alex Morgan, amministratore dell’agenzia, approva il piano di Jordan Lee esattamente com’è scritto.
0:29 Le richieste di lancio sono separate. Un lancio aspetta qualcuno con «Publish». Approvarne uno manuale crea soltanto un’attività.
Metti ogni decisione dove le regole possono vederla
Aggiungi il tuo team e i tuoi clienti a un nuovo spazio di lavoro, poi invia un primo piano in approvazione e guardalo arrivare nella coda.
I piani partono da 99 $ al mese.
In questa pagina
Un workflow di approvazione con un’unica coda per revisioni della libreria, piani, lanci e ferie
Fino a cinque schede, un conteggio su ciascuna e un filtro per cliente che segue il selettore
Team, poi Approvazioni, apre un’unica pagina con fino a cinque schede: «All», «Library», «Plans», «Launches» e «Time off» (ferie e permessi). La scheda «Time off» compare solo per gli amministratori dell’agenzia. Ogni scheda riporta il numero di elementi in attesa di una persona, «All» mostra i primi cinque elementi in attesa di ciascuna fonte con un link «View all» (vedi tutto), e un filtro per cliente restringe il lavoro dei clienti a un solo account. Il filtro parte dal cliente su cui è impostato il selettore nell’intestazione, quando quel cliente ha qualcosa nella coda, e un clic lo allarga a tutti i clienti. Le ferie non sono lavoro per i clienti, quindi la scheda «Time off» ignora il filtro e lo dice con l’etichetta «Workspace-wide» (valida per tutto lo spazio di lavoro).
Nulla viene copiato in un secondo sistema. Una revisione della libreria si decide ancora nella sua schermata di revisione, un piano attraverso la sua approvazione, un lancio attraverso il suo registro e le ferie attraverso la richiesta di ferie, quindi la coda non aggiunge regole proprie né scappatoie. Si aggiorna quando torni sulla scheda e ogni minuto finché resta aperta, e un link da una notifica di piano o di lancio, o da un avviso della libreria in attesa di te, apre la scheda giusta su quell’elemento, così chi approva arriva a ciò per cui è stato interpellato invece che a un elenco in cui cercare.
Un’approvazione copre il piano esattamente com’è stato approvato
Se cambi il piano dopo, indica «Changed since approval»
Un via libera vale qualcosa solo se descrive ancora ciò che esce. Quando un piano di campagna viene approvato, il server registra un’impronta del suo contenuto: il nome, il canale, il tema, le piattaforme, il pubblico e le impostazioni, i modelli della libreria che un piano email invia e il pubblico salvato a cui punta un piano email, SMS o paid, cioè la sua definizione e, per una lista fissa, i suoi membri. Non ne fa parte chi, quel giorno, corrisponde a un segmento basato su regole. Se cambi una qualsiasi di queste cose in seguito, l’impronta non corrisponde più. Il piano indica allora «Changed since approval» (modificato dopo l’approvazione) ovunque venga mostrata la sua approvazione, e non può essere lanciato finché non viene inviato e approvato di nuovo.
Il confronto lo fa il server rispetto al piano così com’è adesso, mai la schermata, e si ripete dove conta: quando si crea un lancio, quando si approva una richiesta di lancio e un attimo prima che un lancio programmato parta. Nemmeno un piano modificato mentre aspetta nella coda può essere approvato: la coda dice che va inviato di nuovo. Gli asset della libreria si revisionano diversamente: portano uno stato, e modificare un asset approvato non lo azzera, quindi un revisore riapre la revisione quando il lavoro cambia.
Rimanda indietro il lavoro con un motivo su cui l’autore possa agire
Rimandare indietro un piano, o rifiutare un lancio o delle ferie, richiede un motivo scritto
Approvare un piano, un lancio o una richiesta di ferie richiede un clic e una conferma, con una nota facoltativa. Richiedere modifiche richiede un clic e una frase, e la frase è obbligatoria: un piano non può essere rimandato indietro senza una nota che dica cosa cambiare, un lancio non può essere rifiutato senza un motivo e nemmeno una richiesta di ferie. Anche la schermata di revisione della libreria richiede una nota quando chiedi modifiche. Il piano torna a chi lo ha inviato come «Changes requested», l’attività di revisione torna nel suo elenco con la nota allegata e l’elemento esce dal conteggio in attesa di chi approva.
Così le correzioni restano fuori dalla chat. L’autore legge il motivo dove ha inviato il lavoro, modifica e invia di nuovo, e chi approva lo ritrova come un nuovo invio con una nuova impronta da verificare. Nella libreria, la schermata di revisione mostra l’asset come lo vedrà il cliente, e i commenti possono essere fissati con un pin su un punto dell’anteprima e restare interni, oppure essere condivisi con il cliente da chi ha il permesso «Publish», così il feedback indica la cosa invece di descriverla a memoria.
L’approvazione del cliente avviene nel portale, sull’asset stesso
Una richiesta di approvazione, una richiesta di modifica fissata su un punto e una striscia di versioni per le creatività
Una revisione del cliente comincia solo dopo che il tuo team ha approvato l’asset o registrato di averne saltato l’approvazione. Chi ha il permesso «Publish» lo condivide nel portale del cliente e chiede una risposta, aggiungendo una nota facoltativa che il cliente legge. Nel pannello di revisione un titolo nomina la tua agenzia e dice che sta chiedendo un’approvazione. Solo un amministratore del portale vede «Approve». Qualsiasi membro del portale può scegliere «Request changes», che chiede una nota scritta e può portare un pin sul punto esatto. Quando la grafica di una creatività è stata sostituita durante la revisione, le versioni precedenti compaiono in una striscia, e ogni pin ricorda la versione su cui è stato lasciato.
Il tuo team vede la risposta come «Client approved» o «Client requested changes», e chi ha chiesto la revisione e chi ha inviato l’asset vengono avvisati subito, nei limiti delle loro impostazioni di notifica. Un amministratore del portale può ritirare un’approvazione entro un’ora, il che riporta l’asset a «Awaiting client review». Quando tornano delle modifiche, modifichi l’asset e chiedi di nuovo. I commenti interni e la cronologia della revisione restano dalla tua parte: il portale riceve la nota della richiesta, la decisione del cliente e i commenti marcati come condivisi. I portali cliente fanno parte dei piani Scale ed Enterprise, mentre l’approvazione interna funziona in ogni piano.
Nessuno approva il proprio piano, e l’unica eccezione viene registrata
Un amministratore dell’agenzia può approvare il proprio lavoro, e il registro lo dice
Un piano inviato da una persona lo approva un’altra. Se chi l’ha inviato ci prova, il server rifiuta con un messaggio chiaro, e la coda mostra un suggerimento al posto del pulsante «Approve» invece di offrirlo. Il revisore indicato su un invio è un’indicazione, non un vincolo: qualsiasi collega con il permesso di approvare per quel cliente può decidere, quindi l’assenza di una persona non deve bloccare una campagna finché c’è un’altra persona che può approvare, e un invio che non nomina nessuno può essere preso in carico da chiunque possa approvare.
Esiste un’eccezione, e lascia una traccia. Un amministratore dell’agenzia può approvare il proprio invio, o un piano che nessuno ha inviato, e l’approvazione viene registrata come auto-approvata ed etichettata così nella coda; quando il piano è stato inviato, lo registra anche la sua attività di revisione. Per una piccola agenzia in cui il titolare è anche lo strategist, è una contabilità onesta e non un ripiego: la cronologia mostra chi ha deciso e che nessuna seconda persona l’ha fatto.
Le richieste di lancio aspettano qualcuno che possa pubblicare
I controlli preliminari del server si ripetono al momento dell’approvazione
Non tutti quelli che costruiscono una campagna possono metterla online. Lanciare richiede il permesso «Publish» per il cliente, e un lancio email o SMS richiede anche l’accesso al CRM del cliente, che tu lo lanci, lo approvi o lo chieda. Un collega senza «Publish» può comunque chiedere. La richiesta compare in «Launches» come «Waiting for launch approval». La riga mostra chi ha chiesto, la sua nota e le verifiche com’erano quando la richiesta è stata fatta, avvisi compresi: un modello della libreria non ancora approvato, per esempio. Una richiesta che non supera una verifica viene rifiutata già quando viene presentata, quindi una richiesta in attesa ha superato le verifiche bloccanti. Un responsabile della pubblicazione approva o rifiuta, e un rifiuto richiede un motivo che chi ha richiesto il lancio può leggere.
Prima di approvare, il responsabile della pubblicazione legge una breve riga sulle conseguenze: chi riceverà l’email e se parte subito o a una data programmata, oppure che un lancio manuale crea soltanto un’attività per chi pubblica a mano. Le verifiche si ripetono poi, perché tra una richiesta e la sua approvazione le cose cambiano, e una verifica che fallisce viene elencata nella finestra invece di essere lasciata passare. I lanci email vengono inviati; i lanci paid, social e SMS si registrano come fatti a mano, e la coda è chiara su quale sia quale.
Le decisioni sulle ferie stanno accanto al lavoro per i clienti ma separate da esso
Approva o rifiuta, e un rifiuto si spiega sempre
Le richieste di ferie non sono lavoro per i clienti, quindi hanno una scheda tutta loro, mostrata solo agli amministratori dell’agenzia ed etichettata «Workspace-wide». Ogni riga indica la persona, il tipo di assenza, le date, i giorni lavorativi conteggiati e l’eventuale nota lasciata, e «Approve» o «Decline» apre la stessa finestra usata dalle altre schede. Rifiutare richiede un motivo che chi ha richiesto le ferie leggerà, così un rifiuto non arriva mai come silenzio.
Le regole sono quelle che pretenderebbero le risorse umane. Le tue richieste non compaiono mai nella tua coda, e nessuno decide le proprie ferie finché esiste un altro amministratore dell’agenzia attivo. Solo in uno spazio di lavoro con un unico amministratore una persona può decidere la propria richiesta, e il registro mostra allora che è stata un’autodecisione. Chi ha richiesto le ferie viene a sapere l’esito via email, il conteggio dei giorni è stato calcolato una volta sola dal server, così la cifra approvata coincide con quella che ha visto, e il profilo del membro è a un clic per avere il contesto. Il permesso non può essere delegato a un responsabile di team: resta agli amministratori.
«Also waiting»: i conteggi del lavoro che si decide altrove
Timesheet e script di prenotazione si contano qui e si revisionano nei loro strumenti
Alcune approvazioni hanno bisogno di più spazio di una riga. Le voci del timesheet si revisionano nel Timesheet con un’intera settimana in vista, e le revisioni degli script di prenotazione si revisionano accanto allo script. La coda le lascia dove lavorano meglio e aggiunge un riquadro, «Also waiting», con un conteggio e un link «Open» (apri) per ciascuna, così un amministratore che comincia la giornata qui scopre comunque quante voci sono in attesa senza aprire un secondo strumento per saperlo.
I conteggi sono onesti o assenti. Ogni fonte riporta il proprio stato, e una che non si carica mostra un riquadro di errore con un nuovo tentativo invece di uno zero; un conteggio che non si è potuto leggere viene omesso, mai mostrato come nessuno. La stessa regola vale per l’intera pagina: una lettura della libreria andata male non può svuotare la scheda «Plans», e una coda lunga dice quando è stata tagliata agli elementi più recenti invece di far credere che sia tutto.
Una matrice di approvazione: chi decide cosa, e con quale permesso
Stabiliscilo una volta, prima del primo lancio, e ogni discussione successiva su chi avrebbe dovuto approvare qualcosa si accorcia. La tabella indica cosa applica oggi la console, riga per riga.
| Cosa è in attesa | Chi lo invia | Chi lo decide | Una seconda persona? | Cosa fa la decisione |
|---|---|---|---|---|
| Un asset della libreria: tema, lista di parole chiave, testo, creatività, landing page, pagina di prenotazione, modulo o email | Chiunque possa modificare la libreria | Chiunque abbia il permesso «Approve» per quel cliente | Non richiesta: chi approva può approvare ciò che ha inviato | Un asset approvato, o con l’approvazione saltata, può essere condiviso con il cliente |
| La revisione di un cliente su un asset condiviso | L’agenzia chiede, con il permesso «Publish» | Il cliente: un amministratore del portale approva, qualsiasi membro del portale può richiedere modifiche | L’altra parte è il cliente | La risposta viene registrata sulla revisione, e un’approvazione può essere annullata entro un’ora |
| Un piano di campagna | Chiunque possa modificare la libreria | Chiunque abbia il permesso «Approve» per quel cliente | Sì, tranne un amministratore dell’agenzia, e l’eccezione viene registrata | Il piano può essere lanciato, purché nessuno lo modifichi dopo |
| Una richiesta di lancio | Chiunque possa modificare la libreria, con accesso al CRM per email e SMS | Chiunque abbia il permesso «Publish» per quel cliente, con accesso al CRM per email e SMS | Sempre: senza «Publish» non si può lanciare, quindi decide un responsabile della pubblicazione | Un lancio email parte o viene programmato, e un lancio manuale crea un’attività |
| Una richiesta di ferie | Qualsiasi membro del team, per le proprie ferie | Solo un amministratore dell’agenzia | Sì, finché esiste un altro amministratore dell’agenzia attivo | Registra approvato o rifiutato con il motivo, e invia un’email a chi ha richiesto le ferie |
Per impostazione predefinita un membro del team dell’agenzia può vedere, creare e modificare asset della libreria e piani, il che significa che può inviare piani per l’approvazione ma non approvare né pubblicare. Una richiesta di lancio di una campagna email o SMS richiede inoltre che chi la presenta abbia l’accesso al CRM, che i membri del team non hanno per impostazione predefinita. Gli amministratori dell’agenzia hanno ogni permesso. Un amministratore può concedere «Approve» o «Publish» a un responsabile di team, una persona alla volta o tramite un modello di permessi, e un collega agisce solo sui clienti a cui è assegnato. Le decisioni sulle ferie non si possono delegare affatto.
Suggerimento
Metti la matrice per iscritto prima del primo lancio
Per ogni cliente, indica chi approva i piani e chi pubblica, e fai in modo che siano persone diverse dove puoi. Dove una persona deve fare entrambe le cose, la console lo registra, ed è l’alternativa onesta al fingere che un secondo paio d’occhi abbia guardato.
Chi invia, revisore, chi approva, responsabile della pubblicazione e richiedente, in parole semplici
Le stesse cinque parole ricorrono in ogni scheda. Ciascuna significa una cosa sola.
- Chi invia
- La persona che manda un piano in approvazione. Modifica e invia, e non può approvare il proprio piano a meno che non sia un amministratore dell’agenzia.
- Revisore
- La persona che chi invia indica su un piano. Il nome è indicativo: sceglie chi viene avvisato e a chi spetta l’attività di revisione, e chiunque possa approvare può comunque decidere.
- Chi approva
- Chiunque abbia il permesso «Approve» per il cliente. Chi approva decide le revisioni della libreria e le approvazioni dei piani.
- Responsabile della pubblicazione
- Chiunque abbia il permesso «Publish» per il cliente. I responsabili della pubblicazione lanciano i piani approvati, decidono le richieste di lancio e chiedono ai clienti di rivedere gli asset della libreria.
- Richiedente
- La persona che ha chiesto un lancio senza il permesso «Publish». Può annullare la propria richiesta finché è in attesa.
Portare i via libera fuori da chat ed email in quattro passaggi
Le persone continuano ad approvare dove già parlano. Un avvio funziona quando la coda è più facile del messaggio, quindi parti da un cliente e da un tipo di decisione.
Elenca i sì che dai oggi
Per una settimana, annota ogni via libera che avviene in chat o per email: una creatività, una landing page, una campagna, un lancio, un giorno di ferie. Dividili tra le quattro cose che la coda contiene e lascia il resto dove sta.
Indica chi approva per ogni cliente
Scegli chi approva i piani e chi pubblica per ogni cliente, concedi quei permessi e assegna quelle persone al cliente. Un collega non assegnato a un cliente non vedrà il suo lavoro nella coda.
Prova con un cliente per due settimane
Chiedi a chi invia di indicare un revisore e di mettere il motivo nella nota. Quando qualcuno chiede un sì in chat, rispondi che è nella coda e decidilo lì. L’attività di revisione, la campanella e un’email avvisano già il revisore, quindi la maggior parte dei revisori ne viene a conoscenza senza bisogno di un sollecito.
Fai della coda l’unico sì
Dopo due settimane, passa al cliente successivo. Di’ al team che un lancio senza un piano approvato viene comunque rifiutato dalla console, e inizia ogni giornata dalla scheda «All», trattando un conteggio sopra zero come il primo lavoro da fare.
Da cosa ti protegge «Changed since approval»
L’avviso non è una seccatura. Segna il momento in cui un piano ha smesso di essere quello su cui qualcuno aveva dato il via libera.
| Stato | Cosa significa | Cosa succede dopo |
|---|---|---|
| «Pending» | In sospeso: inviato e in attesa di chi approva | Un revisore decide: lo approva, oppure lo rimanda con una nota |
| «Changes requested» | Modifiche richieste: rimandato a chi lo ha inviato | Questa persona modifica il piano e lo invia di nuovo |
| «Approved» | Approvato: chi approva ha accettato il piano così com’era | Si può lanciare dalla pagina di lancio del suo canale |
| «Changed since approval» | Modificato dopo l’approvazione: il piano è stato modificato dopo essere stato approvato | Serve una nuova approvazione prima che possa essere lanciato |
Il confronto legge tre cose: il piano stesso, i modelli email della libreria che un piano email invia e qualsiasi pubblico salvato dietro un piano email, SMS o paid: la definizione del pubblico e, per una lista fissa, chi ne fa parte. Conta una modifica a una qualsiasi di queste cose, compresa quella a un modello condiviso da altre campagne. Un segmento definito da regole può comunque raggiungere persone diverse il giorno dell’invio senza rendere obsoleta l’approvazione. Un invio in attesa che è stato modificato mentre aspettava non può essere approvato, e la sua riga dice che va inviato di nuovo.
Vale la pena conoscere due limiti. Se un piano viene modificato dopo che un lancio è stato programmato, il sistema di invio confronta di nuovo un attimo prima di agire, e il lancio fallisce allora con una spiegazione chiara e non viene inviato nulla. E gli asset della libreria funzionano diversamente: un asset porta uno stato di revisione invece di un’impronta del contenuto, quindi una modifica a un asset approvato lascia la sua revisione com’era. Riapri la revisione quando il lavoro cambia.
Un giro di dieci minuti nella coda per chi approva
La coda è fatta per essere svuotata dall’alto. Questo ordine mette per prime le decisioni che bloccano altre persone.
Parti da «All»
Leggi i conteggi sulle schede. Se il selettore nell’intestazione ha ristretto il filtro per cliente a un solo account, allargalo prima, così nulla aspetta dietro un filtro che avevi dimenticato di avere.
Prendi per prime le richieste di lancio
Qualcuno è in attesa di pubblicare. Leggi le verifiche e la riga sulle conseguenze, poi approva o rifiuta con un motivo. Una verifica che fallisce compare nella finestra e trattiene l’approvazione.
Poi i piani
Apri ogni piano dalla sua riga. Una riga segnalata come modificata dopo l’invio non può essere approvata, quindi chiedi un nuovo invio invece di aspettare. Richiedi modifiche con una nota che dica cosa cambiare.
Poi la libreria
Apri ogni revisione come la vedrà il cliente. Approva, richiedi modifiche oppure salta l’approvazione, il che registra che nessuno ha revisionato l’asset e non viene mostrato come approvato. Fissa un commento con un pin sul punto che intendi.
Chiudi con le ferie e «Also waiting»
Gli amministratori decidono le ferie per ultime, con un motivo per ogni rifiuto. Se il riquadro «Also waiting» mostra voci del timesheet o revisioni degli script di prenotazione, apri il Timesheet o Script di prenotazione dai suoi link.
Tre abitudini tengono breve il giro: invia con una nota, indica un revisore e decidi nella coda invece che in chat. La coda si rilegge ogni volta che torni sulla scheda e una volta al minuto finché resta aperta, quindi puoi lasciarla aperta e ritrovare un conteggio aggiornato.
Cosa non fa la coda, perché nessuno lo dia per scontato
Una coda di decisioni è affidabile solo quando i suoi confini sono chiari.
- La coda non invia promemoria e non fa escalation. L’invio di un piano fa suonare la campanella e manda un’email al revisore, o a tutte le persone che possono approvare per il cliente quando non ne è indicato nessuno, e crea un’attività di revisione in scadenza tra tre giorni, quindi la data di quell’attività in Progetti è il sollecito. Il riepilogo del mattino, inviato nei giorni feriali per impostazione predefinita, elenca anche le revisioni della libreria, le voci del timesheet e le ferie in attesa di te, ma non i piani né le richieste di lancio. L’invio di un asset della libreria avvisa chi approva e non crea alcuna attività. Un elemento aspetta finché una persona non lo decide.
- A parte l’email, oggi non pubblica né invia al posto tuo. Un lancio paid, social o SMS si registra come fatto a mano: l’approvazione crea un’attività e un’esportazione della specifica congelata, e qualcuno lo segna come lanciato, pubblicato o inviato. Un lancio email è l’eccezione, e invia.
- Non decide timesheet né script di prenotazione. Quelli si contano sotto «Also waiting» e si decidono nei loro strumenti.
- Non mostra piani, lanci né la coda ai clienti. Un cliente vede gli asset della libreria che condividi con lui, nel portale, e rivede quelli che gli chiedi di rivedere.
- Mostra a ciascuno i clienti che può vedere. «Approve» e «Decline» compaiono solo dove si ha il permesso, una riga di piano o lancio in attesa che non si può decidere dice chi può, e la scheda «Time off» compare solo per gli amministratori.
- Non rilancia un piano il cui lancio è concluso. Per inviarlo di nuovo, duplica il piano e approva la copia. Un lancio fallito, annullato o rifiutato si può riprovare.
Dove si colloca l’approvazione del cliente
Piani e lanci sono decisioni interne. Il via libera del cliente riguarda gli asset della libreria che condividi con lui.
Prima approva internamente
Un asset si può condividere con un cliente quando chi approva per l’agenzia lo ha approvato o ha saltato l’approvazione. Gli asset già condivisi prima che esistessero le approvazioni sono etichettati come condivisi e non vengono mai bloccati.
Condividi, poi richiedi la revisione
Chi ha il permesso «Publish» condivide l’asset e chiede la revisione del cliente, con una nota facoltativa che il cliente vede insieme alla richiesta. Anche i commenti marcati come condivisi sono visibili al cliente.
Il cliente risponde nel portale
Un amministratore del portale approva, e qualsiasi membro del portale può richiedere modifiche. Entrambe le cose avvengono sull’asset come lo vede il cliente, con commenti che può fissare con un pin sul punto che intende.
Annulla, riapri o chiedi di nuovo
Il cliente può annullare un’approvazione entro un’ora. Dopo una richiesta di modifiche modifichi e chiedi di nuovo. Puoi ritirare la richiesta mentre è dal cliente, e riaprire la revisione una volta che è stata approvata o saltata.
Nella coda questi asset stanno sotto «With the client» (dal cliente) nella scheda «Library» finché il cliente non li approva, poi sotto «Decided» (decisi). Se il cliente chiede modifiche, restano sotto «With the client» finché non chiedi di nuovo o ritiri la richiesta. La revisione del cliente richiede il portale cliente, incluso nei piani Scale ed Enterprise. La grafica è un caso comune, e la pagina sulla gestione delle creatività mostra come versioni e revisione stiano sulla creatività stessa.
Domande frequenti
Che cosa dovrebbe coprire un workflow di approvazione in un’agenzia?
Quattro cose richiedono di solito una decisione attribuita a una persona precisa: creatività e testi prima che arrivino a un cliente, piani di campagna prima che si impegni denaro, lanci prima che qualcosa vada online e ferie prima che vengano promesse. Questa coda le contiene tutte e quattro, con le regole di ciascuno strumento intatte, quindi il workflow è un insieme di permessi e registri e non un documento che nessuno apre.
Quali piani includono la coda delle approvazioni?
La coda è in ogni piano. Ciò che vi confluisce dipende dal piano: i planner e i lanci paid e social richiedono il piano Agency o superiore, i planner email e SMS sono inclusi in ogni piano, e la revisione di un asset della libreria da parte del cliente richiede il portale cliente nei piani Scale o Enterprise. Le decisioni sulle ferie sono disponibili agli amministratori dell’agenzia in qualsiasi piano.
Chi può approvare un piano o un asset della libreria?
Chiunque abbia il permesso «Approve» per quel cliente. Gli amministratori dell’agenzia ce l’hanno in automatico, e un amministratore può concederlo a un responsabile di team. Per impostazione predefinita un membro del team può modificare e inviare ma non approvare né pubblicare. I membri del team agiscono inoltre solo sui clienti a cui sono assegnati, quindi chi approva vede la coda filtrata sui propri account.
Posso approvare il mio stesso lavoro nella coda delle approvazioni?
Dipende dal tipo di elemento. Un piano non può essere approvato da chi lo ha inviato, a meno che non sia un amministratore dell’agenzia, e in quel caso l’approvazione viene registrata come auto-approvata. Le revisioni della libreria non richiedono una seconda persona, quindi chi approva può approvare ciò che ha inviato. Nessuno decide le proprie ferie finché può farlo un altro amministratore.
Che cosa succede se un piano viene modificato dopo essere stato approvato?
Indica «Changed since approval», nella coda per le approvazioni degli ultimi 14 giorni e nelle pagine del piano e di lancio, e non può essere lanciato finché non viene inviato e approvato di nuovo. Il server confronta il contenuto approvato con il piano così com’è quando un lancio viene creato o approvato, e di nuovo un attimo prima che un lancio programmato parta, quindi il contenuto approvato non può uscire come un altro contenuto.
Approvare un lancio lo pubblica o lo invia in automatico?
I lanci email vengono inviati. Oggi, approvare un lancio paid, social o SMS crea un’attività e una specifica esportata da eseguire da parte di una persona, e un responsabile della pubblicazione segna poi il lancio come lanciato, pubblicato o inviato, con un link facoltativo. La console non pubblica sui social network né invia SMS.
I clienti vedono la coda delle approvazioni o i loro piani?
No. La coda è interna, e piani e lanci non vengono mai mostrati nel portale. Un cliente vede gli asset della libreria che condividi con lui, nel proprio portale con il suo brand, e rivede quelli che gli chiedi di rivedere: un amministratore del portale può approvare, e qualsiasi membro del portale può richiedere modifiche. Il portale è incluso nei piani Scale ed Enterprise.
La coda sollecita chi approva o fa escalation sugli elementi fermi?
La coda non invia email di promemoria e non fa escalation. L’invio di un piano fa suonare la campanella e manda un’email al revisore, o a tutte le persone che possono approvare per il cliente quando non ne è indicato nessuno, e crea un’attività di revisione in scadenza tra tre giorni. L’invio di un asset della libreria avvisa chi approva e non crea alcuna attività. Il riepilogo del mattino nei giorni feriali elenca le revisioni della libreria, le voci del timesheet e le ferie in attesa di te. Un elemento aspetta finché qualcuno non lo decide, quindi usa i conteggi e le date delle attività per sollecitare.
E se una parte della coda non si carica?
Ogni fonte riporta il proprio stato. Una lettura fallita mostra un riquadro di errore con un nuovo tentativo solo su quella scheda, e le altre schede continuano a funzionare. Un conteggio che il server non ha potuto leggere viene omesso invece di essere mostrato come zero, e una lista tagliata al suo limite lo dice, così una scheda vuota non nasconde mai lavoro non letto.
In che cosa la coda è diversa dal Centro attività?
Il Centro attività è un feed di ciò che è successo in tutta la console, con filtri e stato di lettura. La coda delle approvazioni è dove si prendono le decisioni, con le loro regole: chi può approvare, che cosa copre l’approvazione e che cosa succede dopo. Molti elementi compaiono in entrambi, e una notifica su un’approvazione apre qui la sua riga.