Come usare l'AI nel passaggio di consegne di eventi e DMC

Venerdì, 18:06. La proposta è accettata. Lunedì operations apre 4 file e trova 3 versioni della capienza, 2 formule sul catering e una riga che dice supporto completo.

Completo per chi?

Il passaggio di consegne di un evento trasferisce da commerciale a operations ciò che è stato accettato, con fonti, assunzioni, esclusioni, prove, owner e scadenze. L'AI può estrarre e confrontare. Non può decidere quale promessa valga quando i documenti non concordano.

Noi usiamo un oggetto semplice: il foglio delle promesse operative. Ogni riga deve arrivare a una persona che può confermarla, rifiutarla o trasformarla in lavoro.

Il progetto si rompe nel passaggio

Una proposta racconta una soluzione. Un piano operativo deve assegnare oggetti, date e responsabilità.

Nel mezzo si perdono spesso 4 cose: il punto esatto da cui nasce una promessa, l'assunzione su cui si regge, l'esclusione che la limita e la persona che deve accettarla.

La pagina su AI per agenzie eventi e DMC descrive il workflow complessivo. Qui guardiamo un solo momento: dopo l'accettazione commerciale e prima che il team costruisca il piano di delivery.

Il Teal Book di Government Project Delivery tratta la transizione come passaggio formale di accountability verso chi possiederà o gestirà un output. La guida non parla di eventi privati e non prescrive il nostro foglio. Offre però un criterio utile: punti di passaggio chiari, informazioni pronte e accettazione da parte di chi riceve.

Congela prima le fonti

Non chiedere all'AI di riassumere la cartella del progetto. Crea un set chiuso.

Per un evento, il set può includere RFP, chiarimenti ricevuti, proposta accettata, allegati approvati, revisioni economiche confermate e note che hanno valore secondo il vostro processo. Il contratto resta la fonte autorevole quando esiste.

Ogni file riceve ID, versione, data e stato:

source_set_id: HANDOVER-EVT-024
frozen_at: 2026-08-16T18:06:00+02:00
sources:
  - id: RFP-001
    version: 1
    status: received
  - id: PROPOSAL-004
    version: 4
    status: accepted
  - id: CLARIFICATIONS-002
    version: 2
    status: confirmed

La data è parte della prova. Un file arrivato dopo non entra di nascosto nella fotografia precedente. Apre una modifica.

Se manca la versione accettata, il workflow si ferma. Riassumere fonti ambigue rende l'ambiguità più ordinata, non meno pericolosa.

Estrai 4 tipi di riga

Un modello tende a fondere frasi simili. Tu vuoi l'opposto. Vuoi separare ciò che ha effetti diversi.

Classifica ogni passaggio come:

Tipo	Domanda	Esempio fittizio
promessa	cosa è stato dichiarato come incluso?	regia tecnica per 2 sale
assunzione	quale condizione è data per vera?	accesso venue dalle 7:00
esclusione	cosa resta fuori?	traduzione simultanea non inclusa
domanda	cosa non è ancora deciso?	formato del file speaker

Non trasformare una domanda in un'attività confermata. Non trasformare un'assunzione in una promessa.

Per ogni riga conserva una citazione breve o un riferimento puntuale. Il testo completo resta nella fonte. Il foglio deve permettere a operations di tornare al documento senza cercare 20 minuti.

item_id: H-017
type: assumption
statement: accesso venue dalle 07:00
source_id: CLARIFICATIONS-002
source_ref: Q12
confidence: exact
status: needs_confirmation

Confidence: exact descrive la corrispondenza testuale, non la verità dell'assunzione.

Trasforma la frase in lavoro

Una riga diventa operativa quando ha oggetto, owner, prova, scadenza e condizione di accettazione.

Prendi regia tecnica per 2 sale. Mancano ancora mixer, microfoni, schermi, streaming, operatori, orari, prove e confini con il fornitore venue.

Il passaggio non deve progettare tutto. Deve assegnare chi chiude il dettaglio e quale fonte userà.

Campo	Domanda
owner	chi risponde della chiusura?
due date	entro quando serve una decisione?
evidence	quale documento o prova chiude la riga?
acceptance	chi conferma che basta?
dependency	cosa non può partire prima?
fallback	cosa succede se resta aperta?

Il due date in un campo interno può chiamarsi scadenza. Nel copy e nel lavoro quotidiano usiamo italiano. Gli ID tecnici restano brevi perché devono viaggiare tra sistemi.

Qui tocca essere pignoli. Owner: produzione non assegna nulla. Owner: project manager evento, accettazione: responsabile operations permette di passare la riga.

Usa l'AI per confrontare, non per arbitrare

L'AI può fare 4 lavori utili sul set congelato:

• estrarre frasi candidate con riferimento,
• raggruppare formulazioni che parlano dello stesso oggetto,
• segnalare valori diversi tra fonti,
• proporre campi mancanti per la review.

Non dovrebbe scegliere da sola tra 200 persone e 220 persone. Può mostrare che il conflitto esiste, quali fonti lo contengono e quale data hanno.

Un output possibile:

conflict_id: C-009
field: expected_attendance
values:
  - value: 200
    source: RFP-001#2.3
  - value: 220
    source: PROPOSAL-004#scope
decision_owner: account-lead
operations_blocked: room-layout

La decisione torna a chi ha autorità sul rapporto commerciale. Se il punto riguarda il contratto, entra la funzione competente.

Fai 2 review diverse

Commerciale e operations non devono controllare la stessa cosa.

Commerciale verifica fedeltà alle fonti: cosa è incluso, escluso, assunto o ancora aperto. Operations verifica eseguibilità: owner, scadenza, prova, dipendenza e capacità.

Usa 2 esiti separati:

commercial_review: accepted|rejected|clarify
operations_review: accepted|capacity_gap|dependency_gap

Una riga può essere commercialmente corretta e operativamente scoperta. È proprio il tipo di problema che il passaggio deve far emergere.

Il risk register di un evento riceve le minacce future con trigger e risposta. Il foglio di consegna riceve promesse e gap già presenti. Se un'assunzione può saltare, la riga collega il rischio senza copiarlo.

Definisci l'accettazione del pacchetto

Il Teal Book indica che il passaggio dovrebbe avere criteri di accettazione e una configurazione nota. Adattato a un evento, significa che operations non accetta una cartella. Accetta un set identificato e una lista di gap espliciti.

Un gate minimo può richiedere:

• set fonti congelato,
• 0 righe senza riferimento,
• 0 conflitti nascosti,
• owner sulle promesse operative,
• scadenza sulle domande bloccanti,
• esclusioni confermate,
• firme o esiti dei 2 reviewer,
• data e versione del pacchetto.

Accettare non significa che ogni dettaglio è chiuso. Significa che ciò che resta aperto è visibile, assegnato e compatibile con la data del progetto.

Apri un cambio dopo il passaggio

Dopo l'accettazione arriveranno modifiche. Non riscrivere il pacchetto iniziale.

Registra richiesta, fonte, impatto e decisione:

change_id: CHG-012
requested_at: 2026-08-20T11:24:00+02:00
source: client-confirmation-007
change: expected_attendance 220 -> 240
impacts:
  - room-layout
  - catering
  - registration-desk
decision: pending

Il run of show dell'evento può dipendere da orari, sale e cue emersi dal passaggio. Una modifica approvata aggiorna i documenti collegati attraverso il loro processo di versionamento.

Non usare la chat come registro delle modifiche. La chat può aiutare a trovare la frase. La decisione vive in un oggetto identificato.

Un esempio completo

Scenario fittizio. Una DMC passa a operations un evento aziendale di 1 giornata. Le fonti congelate sono RFP, proposta versione 4 e 6 chiarimenti numerati.

ID	Tipo	Oggetto	Fonte	Owner	Stato
H-001	promessa	2 sale con regia	proposta v4, §3	technical producer	accepted
H-002	assunzione	accesso dalle 7:00	chiarimento Q12	venue manager	clarify
H-003	esclusione	traduzione simultanea	proposta v4, §7	account lead	accepted
H-004	domanda	formato contributi speaker	RFP, §5.2	content producer	due 22/08
H-005	conflitto	partecipanti 200 o 220	RFP e proposta	account lead	blocked

Operations accetta H-001 e H-003. H-002 riceve una scadenza. H-004 entra nel piano speaker. H-005 blocca layout e catering finché commerciale non conferma la fonte valida.

Il pacchetto non produce ancora cue, risk response o comunicazioni. Distribuisce verità e lavoro.

Misura il passaggio

Conta righe senza fonte, conflitti aperti, owner mancanti, domande oltre scadenza, cambi emersi dopo l'accettazione e problemi operativi riconducibili a una consegna incompleta.

Non trasformare il numero di righe in una gara. Un pacchetto con 18 righe precise può essere migliore di uno con 140 estrazioni che nessuno decide.

Il tempo di compilazione conta solo insieme alla qualità della consegna. Se l'AI dimezza il tempo e raddoppia i conflitti nascosti, hai accelerato il punto sbagliato.

Errori che fanno perdere la promessa

• riassumere una cartella non congelata,
• usare incluso senza riferimento,
• fondere promessa e assunzione,
• ignorare le esclusioni,
• chiedere all'AI quale versione abbia valore,
• assegnare owner a un reparto,
• accettare il pacchetto con conflitti invisibili,
• sovrascrivere il set iniziale dopo un cambio,
• copiare dati personali che non servono al passaggio.

La promessa senza owner

Prendi l'ultima proposta accettata. Cerca 1 frase con incluso, garantito, supporto o un numero operativo. Aggiungi fonte, assunzione, esclusione, owner, prova e scadenza.

Poi chiedi a operations di accettarla senza spiegazioni a voce.

Se serve una telefonata per capire cosa significa, quella riga non è ancora stata consegnata.

Porta a MAIKER HUB RFP, proposta e piano operativo. Nel percorso Think -> Build -> Enable costruiamo il workflow di estrazione, il doppio controllo e il registro dei cambi senza lasciare all'AI l'ultima parola.