Come creare con l'AI la matrice delle responsabilità di un evento

Lunedì, 10:06. La grafica del palco aspetta il via libera. Il producer pensa che decida il cliente. L'account pensa che decida il producer. Il cliente non ha ricevuto il file.

Scenario fittizio. Tre persone coinvolte. Nessun owner della decisione.

Per creare con l'AI una matrice delle responsabilità di un evento devi partire dai work package e dalle decisioni, non dall'elenco dei reparti. Ogni riga dice cosa va prodotto, chi fa il lavoro, chi prende la decisione, chi viene consultato, chi riceve l'esito, entro quando e con quale prova. L'AI trova buchi e conflitti. Non assegna autorità alle persone.

L'organigramma non descrive la delivery

Produzione, creatività, cliente, venue e fornitore tecnico sono etichette. Non dicono chi approva la grafica, chi conferma il numero di tavoli o chi blocca una versione sbagliata.

Una matrice utile usa oggetti e verbi:

• validare la planimetria v4,
• confermare la scaletta speaker,
• approvare il master della grafica palco,
• comunicare un cambio sala,
• accettare il piano di carico.

L'AI per agenzie eventi e DMC può raccogliere attività e documenti. La matrice fa un lavoro diverso. Attribuisce il diritto e il dovere di muovere ogni oggetto al prossimo stato.

Parti dai work package

Dividi l'evento in blocchi che producono un risultato verificabile. Non serve una struttura universale. Un congresso, un viaggio incentive e una cena aziendale hanno lavori diversi.

Un set iniziale può includere venue, contenuti, speaker, registration, travel, hospitality, allestimento, tecnica, catering, comunicazioni e produzione on-site. Dentro ogni blocco elenca i deliverable e le decisioni.

work_package: stage-content
deliverable_id: STAGE-GFX-014
deliverable: stage-screen-master
decision: approve-master-for-production
cutoff: 2026-10-06T12:00:00+02:00
evidence: approved-preview-and-source-version

Nomi e data sono fittizi. La riga evita grafica palco senza stato. Specifica quale master e quale decisione.

Separa lavoro e decisione

Chi prepara un output non deve diventare automaticamente chi lo approva.

Usa 4 ruoli operativi:

Ruolo nella riga	Domanda
responsabile operativo	chi prepara o coordina il lavoro?
decision owner	chi ha autorità per cambiare lo stato?
consultato	chi deve dare un input prima della decisione?
informato	chi deve ricevere l'esito dopo la decisione?

Questo schema ricorda una RACI, ma qui aggiunge decisione, cutoff, evidenza e sostituto. Non lo attribuiamo a GovS 002 o a The Teal Book. È un metodo locale per rendere la delivery leggibile.

GovS 002 versione 2.1 ha reso obbligatori i ruoli di governance nel proprio perimetro governativo. The Teal Book distingue responsabilità del project manager, ownership specialistica delle prove e accountability del senior responsible owner. Il principio utile è la separazione dei ruoli. I titoli e le deleghe del tuo evento restano da decidere.

Scrivi una riga per decisione

Un deliverable può richiedere più decisioni. La planimetria, per esempio, può avere verifica tecnica, validazione operativa e approvazione del cliente. Se le comprimi in una cella, non sai quale passaggio manca.

Decision ID	Oggetto	Decision owner	Prova	Stato
DEC-041	conformità tecnica planimetria	technical lead	checklist firmata	pending
DEC-042	usabilità per operations	event producer	walk-through registrato	pending
DEC-043	approvazione versione cliente	account owner	preview e conferma	pending

La stessa persona può coprire 2 righe. La matrice deve mostrarlo. Non creare 3 persone immaginarie solo per riempire il modello.

Se la decisione riguarda safety, security, aspetti legali o altri ambiti specialistici, usa il ruolo competente previsto dall'organizzazione. L'AI non decide chi ha quella delega.

Aggiungi cutoff e tempo di risposta

Entro venerdì è ambiguo per un team che lavora tra città e fusi diversi. Usa data, ora e timezone quando il ritardo coinvolge altri work package.

Il cutoff supera la semplice scadenza del file: indica l'ultimo momento in cui la decisione può arrivare senza cambiare piano, costo o rischio.

Registra anche il tempo concesso a chi viene consultato. Se il parere non arriva, il fallback può essere escalation, mantenimento della versione precedente oppure stop. Mai approvazione per silenzio, salvo una regola esplicita e autorizzata.

Nel run of show di un evento trovi tempi, cue e responsabilità operative. La matrice non copia tutte le righe. Collega il decision ID ai cue che dipendono da quella decisione.

Prepara sostituto ed escalation

Un owner senza sostituto crea un single point of failure umano. Scrivi chi può assumere la decisione, in quali condizioni e con quale autorità.

decision_owner: client-content-owner
delegate: client-project-lead
delegate_condition: owner_unavailable_after_4_business_hours
escalation: account-director
fallback: keep-last-approved-version

Anche qui i ruoli sono fittizi. 4 business hours è un esempio, non una soglia consigliata.

Qui tocca fare la domanda antipatica: il sostituto può davvero decidere oppure riceve soltanto le mail? Se non ha delega, non è un sostituto.

Fai controllare la matrice all'AI

Il workflow può leggere work breakdown, calendario, run of show, deliverable register e briefing. Poi segnala difetti strutturali.

Controlli utili:

• decisioni senza owner,
• 2 owner sulla stessa decisione,
• responsabile operativo assente,
• consultato che compare dopo il cutoff,
• informato non collegato al canale giusto,
• owner indisponibile senza sostituto,
• deliverable approvato senza evidenza,
• dipendenza tra 2 righe con scadenze invertite,
• ruolo presente in un documento e assente negli altri.

L'AI deve citare il record da cui ricava ogni ruolo. Probabilmente approva l'account non entra nella matrice. Diventa una domanda aperta.

Un output corretto su una riga può essere:

finding_id: OWN-019
decision_id: DEC-043
finding: missing-decision-owner
source_refs:
  - WBS@7:stage-content
  - RUN@12:cue-088
proposed_action: request-owner-assignment
status: open

Niente assegnazione automatica. Il workflow prepara il punto da chiudere.

Collega la prova

La matrice diventa utile quando lo stato ha un'evidenza.

Per una decisione editoriale può bastare la preview approvata con versione e timestamp. Per un deliverable tecnico serve la prova indicata dal processo competente. Per una comunicazione, la prova può essere il copy approvato e il canale autorizzato, non l'invio automatico.

The Teal Book assegna al project manager la responsabilità di predisporre e gestire metodi di verifica e validazione, con specialisti che possiedono le prove relative ai singoli output. Il decision owner deve vedere il risultato e capirne l'effetto.

Nel briefing e nelle prove speaker puoi avere owner distinti per contenuto, tecnica e disponibilità. La matrice collega le decisioni senza fingere che una sola approvazione copra tutto.

Non duplicare la matrice in 7 file

Scegli una fonte canonica. Run of show, brief, registro deliverable e comunicazioni conservano il decision ID oppure il work package ID.

Quando cambia un owner, aggiorni la matrice e propaghi il riferimento. Non sostituisci nomi a mano in ogni PDF.

Il passaggio in uso descritto da The Teal Book richiede chiarezza su accountabilities e responsabilità, anche nel momento in cui cambiano. In un evento il cambio può avvenire al passaggio da progettazione a on-site, oppure dal team agency al referente venue. Segna punto e ora.

Esempio:

Fase	Decisione	Owner prima	Owner dopo	Handover
pre-produzione	approvare master	client content owner	invariato	nessuno
montaggio	accettare set-up tecnico	technical producer	show caller	walk-through 17:30
live	attivare cue	show caller	invariato	run of show v8

I ruoli sono esempi. La tabella mostra che la responsabilità può cambiare senza cambiare l'oggetto.

Un esempio completo

Scenario fittizio. Un evento ha 9 work package, 47 deliverable e 63 decisioni. L'AI legge work breakdown, run of show e 6 briefing.

Il primo controllo trova 8 decisioni senza owner e 5 con 2 owner. Tre conflitti dipendono da un errore di naming: event lead e producer sono la stessa persona. Il team unifica il ruolo.

Restano 2 decisioni vere in conflitto. Sulla grafica palco, account e producer credono entrambi di approvare. Il cliente conferma un content owner e un sostituto. Sull'apertura porte, venue manager e show caller hanno responsabilità diverse: il primo conferma disponibilità dello spazio, il secondo dà il cue operativo. La decisione viene divisa in 2 righe.

Il controllo finale trova 0 decisioni senza owner, 0 doppi owner e 4 consultazioni con scadenza successiva al cutoff. Le scadenze vengono corrette. Nessuna persona viene aggiunta dal modello.

Misura dove si ferma la decisione

Conta decisioni senza owner, doppi owner, pareri arrivati dopo il cutoff, escalation, fallback attivati e cambi di owner non propagati.

Misura anche il tempo tra ready_for_decision e decided. Se il collo di bottiglia si concentra su un ruolo, non allargare automaticamente la delega. Guarda quali prove mancano e quali decisioni sono state assegnate alla persona sbagliata.

Non premiare chi approva più in fretta se poi cresce il rework. Velocità e qualità vanno lette insieme.

Errori che svuotano la matrice

• partire dall'elenco reparti invece che dai work package,
• scrivere 1 riga per deliverable quando servono più decisioni,
• usare team come decision owner,
• assegnare 2 owner per evitare un conflitto,
• lasciare consultati senza tempo di risposta,
• chiamare sostituto una persona senza delega,
• copiare nomi in più documenti senza ID,
• approvare per silenzio senza regola autorizzata,
• lasciare che l'AI deduca ruoli da titolo o anzianità.

La grafica ferma alle 10:06

Prendi il deliverable che oggi aspetta un via libera. Scrivi la decisione esatta, l'owner e la prova che deve vedere.

Se una cella resta vuota, hai trovato il blocco. Non un problema di email.

Porta a MAIKER HUB work breakdown, run of show e lista team. Nel percorso Think -> Build -> Enable costruiamo la matrice e il controllo dei conflitti senza lasciare che l'AI distribuisca autorità.