Flussi di lavoro di esempio

Cinque flussi di lavoro che il team di VM0 esegue ogni settimana. Ognuno mostra la configurazione, il prompt, l'artefatto che Zero produce e il tempo che fa risparmiare.

Il punto non è copiarli alla lettera — è vedere la forma di un flusso di lavoro Zero completo e adattarlo al tuo lavoro.

1. Brief mattutino

Il problema. Ogni mattina inizia con un recupero: aprire Slack, scorrere le @menzioni, controllare il calendario, dare un'occhiata alle PR aperte. Venti minuti prima del primo vero compito.

Configurazione. Una pianificazione, nei giorni feriali alle 8. Connettori: Slack, GitHub, Google Calendar.

Prompt.

"Ogni giorno feriale alle 8 ora di Pechino, mandami un DM con quattro sezioni:

1. Le @menzioni Slack non lette delle ultime 24 ore, con riepiloghi di una riga
2. Le issue GitHub assegnate a me, ordinate per anzianità, con stato e ultimo commento
3. Il calendario di oggi — titoli delle riunioni, orari, e il documento Notion pertinente se collegato
4. Un focus suggerito per la giornata, in base a ciò che è in ritardo o blocca gli altri"

Cosa ottieni. Un DM su Slack alle 8, di solito 200–350 parole. Ogni sezione è breve; i numeri sono concreti; i link sono inline. Il "focus suggerito" varia — a volte è una PR ovvia; a volte è la preparazione di una riunione che richiede più attenzione di quanto la giornata suggerisca.

Fa risparmiare. Circa 20 minuti al giorno, più il costo cognitivo del cambio di contesto tra quattro strumenti come prima cosa.

Varianti. Aggiungi una quinta sezione per i nuovi iscritti clienti, o per gli errori di produzione da Sentry. Sostituisci il DM Slack con un'email se preferisci mattine senza notifiche.

2. Concorrenti settimanale

Il problema. Sapere cosa hanno rilasciato i concorrenti la settimana scorsa è utile. Controllare manualmente tre account X, tre changelog, tre pagine di pricing e una rassegna di blog è una scocciatura che silenziosamente slitta.

Configurazione. Una skill (competitor-scan) più una pianificazione del lunedì mattina. Connettori: X, ricerca web, Notion.

Prompt.

"Scansiona @competitor1, @competitor2, @competitor3 su X e i loro changelog da lunedì scorso. Incrocia con le loro pagine di pricing e qualsiasi post di blog. Confronta con la baseline della settimana scorsa (pagina Notion 'Competitor State'). Pubblica un digest su #competitor-intel evidenziando: nuove feature, cambi di pricing, segnali di assunzione, e qualsiasi cosa notevole nel tono o nel messaggio."

Cosa ottieni. Un thread Slack il lunedì mattina. Messaggio principale: un riepilogo in 5 punti. Risposte: sezioni per concorrente con aggiornamenti citati e link. La pagina baseline di Notion viene aggiornata automaticamente così il confronto della settimana prossima ha una base di verità fresca.

Fa risparmiare. Circa 90 minuti a settimana, più il carico mentale fuori campo del "dovrei controllare Acme".

Varianti. Aggiungi Reddit e Hacker News per il sentiment della community. Aggiungi una retrospettiva trimestrale che riassume i confronti dell'anno in una slide pronta per la board.

3. Triage dei bug

Il problema. Qualcuno lascia uno screenshot o una descrizione vaga in #bug-report. Deve diventare una vera issue GitHub con passi di riproduzione, una gravità, un'etichetta e un team. Quel passaggio di formalizzazione è piccolo ma costante.

Configurazione. Una skill (triage-bug-report), invocata manualmente da @Zero in #bug-report. Connettori: Slack, GitHub.

Prompt (nel canale):

"@Zero fai il triage di questo — estrai i passi di riproduzione dagli screenshot e dal thread, cerca issue GitHub correlate, classifica la gravità (P0–P3), assegna al team più probabile in base ai percorsi dei file o ai sintomi, e apri una nuova issue se non è un duplicato. Rispondi in questo thread con il link."

Cosa ottieni. Una risposta nel thread entro ~60 secondi: un link a una issue GitHub, la gravità scelta con una giustificazione di una riga, un elenco di 2–3 issue correlate per contesto, e il team assegnato. Se Zero ritiene che sia un duplicato, pubblica il link della issue originale invece di aprirne una nuova.

Fa risparmiare. Nell'arco di una settimana intensa, è la differenza tra un issue tracker pulito e un backlog di screenshot Slack non triagiati.

Varianti. Aggiungi un tag "customer-facing" in base al fatto che il segnalante provenga dall'esterno dell'azienda. Chiamata automatica del reperibile per i P0.

4. Bozza di risposta al cliente

Il problema. Un'email di un cliente richiede una risposta che sia utile, in linea con il brand e fondata sulla documentazione. Cinque minuti a email × 30 email a settimana è un costo reale.

Configurazione. Una skill (customer-reply-draft), invocata manualmente inoltrando un'email a Zero o incollandola in chat. Connettori: Gmail, Notion (o il tuo help center), Stripe (per il billing), Linear (per le issue note).

Prompt.

"Il cliente ha scritto questa email [incolla]. Leggi i suoi ultimi tre ticket, controlla la nostra documentazione per la sezione pertinente, controlla Linear per eventuali issue note che corrispondono alla sua segnalazione, e controlla Stripe per eventuale contesto di billing. Redigi una risposta nella sua lingua. Cita la sezione della documentazione. Mantienila sotto le 150 parole. Rispecchia il tono della nostra ultima risposta di supporto a lui."

Cosa ottieni. Una bozza di risposta con le citazioni collegate in fondo — di solito due o tre link alla documentazione, più un avviso come "Linear ENG-4422 è una issue nota con questo; ETA la prossima settimana." Tu scorri, aggiusti una riga, invii.

Fa risparmiare. Circa 3–4 minuti a email. Nell'arco di una settimana di supporto, sono ore.

Varianti. Rileva automaticamente il livello del cliente da Stripe; instrada i clienti VIP verso un flusso di sola bozza (nessun invio automatico) e i clienti di livello inferiore verso una coda di invio automatico ad alta affidabilità.

5. Produzione settimanale di contenuti

Il problema. Il marketing vuole un post di blog, tre post LinkedIn e un set di social card ogni settimana. Ogni pezzo ha bisogno di contesto dalla ricerca e dai contenuti esistenti. Coordinarlo tra gli strumenti è più lavoro della scrittura.

Configurazione. Una skill multi-step (weekly-content) su una pianificazione del venerdì pomeriggio. Connettori: Notion (ricerca), Plausible (analytics), Fal (generazione di immagini), Loops (email).

Prompt.

"Ogni venerdì alle 14, fai quanto segue:

1. Leggi i nuovi documenti Notion di questa settimana nel database 'Marketing Inputs'
2. Incrocia con gli argomenti di blog della settimana scorsa per evitare ripetizioni
3. Redigi un post di blog di 800 parole sull'argomento più attuale; salvalo in Notion in 'Blog Drafts'
4. Redigi tre varianti LinkedIn della stessa idea — un saggio, un listicle, una storia personale
5. Genera tre social card quadrate nel nostro stile di brand
6. Pubblica il pacchetto su #marketing per la revisione"

Cosa ottieni. Un unico messaggio Slack il venerdì pomeriggio contenente tutti e sei gli artefatti inline. La bozza del blog rimanda a una pagina Notion già formattata. Le bozze LinkedIn sono pronte da copiare e incollare. Le social card sono scaricate e pronte da allegare.

Fa risparmiare. Circa mezza giornata di coordinamento settimanale. Gli editor revisionano e pubblicano; non redigono.

Varianti. Aggiungi un test A/B in cui Zero genera due titoli e li testa su un piccolo pubblico via Loops. Aggiungi un controllo Plausible sugli argomenti più performanti della settimana scorsa per orientare la scelta degli argomenti.

Ognuno di questi flussi di lavoro ha richiesto 10–30 minuti per essere configurato. Dopodiché fanno risparmiare ogni giorno o ogni settimana. Il costo è all'incirca i crediti che ogni esecuzione consuma — visibile per ogni chat nella pagina Usage. Consulta Crediti e fatturazione per i conti.

Per costruire la tua versione, copia uno di questi prompt, sostituisci i nomi dei tuoi strumenti e canali, e provalo. Itera a partire dal risultato.