The event pack

Event scorecard — <event_id>

Go / no-go instrument. Score before any money or exec time is committed. Method: knowledge/01-strategy-and-selection.md. For paid sponsorships, complete sponsorship-evaluation.md first and carry its numbers in here.

• event:
• date(s) / location:
• type: owned / sponsored / attended (speaking) / attended (non-speaking)
• bu: consulting / hospitality (Active; paid acquisition frozen, enumerated gated claims apply — see knowledge/hospitality/) / cross-portfolio
• business objective served: (which BU goal or campaign this feeds — one sentence)
• scored by / date:

Evidence pulled (before scoring — no evidence, no score)

• Past attendee list or sponsor roster: (link / attached / unavailable)
• Prior-year agenda: (link)
• Named-org overlap with INTO target-account list: (list up to 10)
• Who we know attending (clients, prospects, partners): (names)
• Access model: (attendee list access? meeting tool? side-event rules? booth traffic only?)

Score (weighted, 0–10 each)

Decision bands

Mode recommendation

(owned dinner / owned workshop / sponsor tier N / speak only / attend-and-hunt / pass — and why this mode beats the next-cheapest alternative for the same objective)

Kill criteria (pre-commit)

(What, discovered later, voids this decision — e.g. attendee list under N, headline speaker drops, our must-have clause refused. Carried into 00-event-brief.md.)

Decision

• Call: go / go cheap / pass
• Decided by: (CMO; + Jay if spend exceeds envelope)
• Date:

Goals and jobs — <event_id>

Response objectives + crew manifest. Locked at committed, before logistics spend. Method: knowledge/02-objectives-goals-and-jobs.md. "Brand awareness" is not an objective; a number, a name-class, and a deadline is.

Response objectives

Primary (pipeline) — the event fails or succeeds on these:

Secondary (relationship + brand) — counted, never substituted for primary:

Per-person quotas

Every attendee travels with a number. No passengers.

Crew manifest (DRIs — one name per row, named before commitment)

On-site cadence

• Daily standup: (time + place — 15 min, quotas + intel + fixes)
• Evening debrief: (time + place — capture sheet reconciled, CRM entries done before dinner)

Sign-off

• Event lead: — date:
• CMO: — date:

Budget and ROI worksheet — <event_id>

Fully-loaded cost, expected value, and the investment test. Approved before any commitment. Method + benchmarks: knowledge/03-budget-and-roi.md. Spend over the campaign envelope is Class C — CMO + Jay (TEAM.md §6.4).

• currency:
• campaign envelope this draws from:
• prepared by / date:

Fully-loaded cost

Count everything. A "free" event with four people flying is not free.

Expected value (pre-commit)

Conservative / base / stretch. Use CRM history for rates; if no history, use playbook defaults and mark Inference per SOP §12.

The investment test (all three, on the BASE case)

Fails a test → downgrade the mode (cheaper tier, attend-and-hunt, or owned dinner instead) and re-run. A "brand" justification may override once per year per BU, capped and named by the CMO in the brief.

Payback framing

• Consulting: expected first-engagement revenue vs cost; note the 6–16 week cycle — T+90 readout may precede close, so track pipeline maturity at T+90 and T+180.
• One-line payback statement: "If we win ___ engagement(s) of ~$___, this event pays back ___×."

Approval

• Within envelope: CMO — date:
• Over envelope (Class C): CMO + Jay — date:
• Approved total: — kill/withdraw deadline (last refund date):

Logistics tracker — <event_id>

Everything that must be booked, contracted, shipped, and insured — with status. Method, timeline norms, and contract gotchas: knowledge/05-logistics-booking-and-travel.md.

• logistics owner:
• event dates: — setup access from: — strike by:

Master countdown

Anchor dates first, then work the checklist. Status: todo / booked / contracted / paid / done / n/a.

Contract register

One row per signed contract. Read before signing: attrition, minimums, cancellation ladder, force majeure.

F&B + dietary + accessibility

• F&B minimum committed: — current forecast vs minimum:
• Dietary capture method (from registration / invitees):
• Accessibility requirements collected + venue confirmed:

Shipping manifest (booth/materials)

Risk + contingency

• Single-point-of-failure people (who, and the cover plan):
• Tech failure plan (demos offline? backup hardware?):
• Weather / travel disruption plan:
• On-site crisis: route to PR & Communications immediately (per SKILL.md).

Travel manifest — <event_id>

One owner, one sheet, every traveller green before anyone boards. INTO's team is internationally distributed — never assume a nationality; check per person. Rules of thumb + visa lead times: knowledge/05-logistics-booking-and-travel.md §Travel.

• manifest owner: (one name — the logistics owner unless delegated)
• destination country/countries: — entry requirements as-of date checked:
• official source used: (government site URL — airline/blog summaries don't count)

Per-traveller status

Doc status: green / amber (action open) / red (blocker) — the manifest owner chases amber weekly, daily inside T-2w.

Entry requirement checks (per destination — verify on official sources, log date)

• Passport validity rule for destination (6-month rule? blank pages?):
• eTA / visa-waiver requirement per nationality on the manifest (e.g. US ESTA, UK ETA, Canadian eTA, EU ETIAS status):
• Business-visa cases (invitation letter needed? processing time? appointment backlog?):
• Onward-ticket or proof-of-funds requirements:
• Health/vaccination requirements:

Rule: any traveller needing a consular visa is identified at committed stage — not at flight-booking. If lead time is tighter than the official processing time + 2 weeks, swap the traveller or drop them from the manifest.

Booking notes

• Flight booking window target (see knowledge/05): booked by T-__w
• Same-flight risk: execs split across flights? y/n — decision:
• Hotel: conference block vs independent — decision + walkability note:
• Per diem / expense policy pointer:
• Travel insurance / medical coverage confirmed for all travellers:

Emergency protocol

• Off-site escalation contact (from run-of-show):
• Lost passport abroad: nearest consulate/embassy for each nationality on the manifest:
• Missed connection: who rebooks (traveller vs owner) + budget authority:
• Share: all itineraries + this sheet with the on-site lead and one HQ person.

Comms plan — <event_id>

Who hears about this event, in what order, with what ask. Method + sequence copy patterns: knowledge/07-audience-comms-clients-and-prospects.md. All outbound artefacts are Class B minimum — drafted by Copywriter, Editor pass, human gate before send. Brand forbidden patterns apply (brands/<brand>/README.md).

• comms owner:
• meeting-booking target feeding P2 (from 02):
• CRM segment pulls done (date):

Segment matrix

One row per segment. The ask differs by relationship — never send prospects a client's invite.

Sequence slots (drafts live next to this file as 06a-...md, 06b-...md)

Booking mechanics

• Meeting scheduler link / calendar owner:
• Meeting inventory: exec calendar blocks reserved at the event (slots × length):
• Where booked meetings are logged (CRM stage + 09-lead-capture-sheet.md pre-book tab):

Tracking

Sales onboarding pack — <event_id>

The going team's single briefing artefact. Everyone who travels reads this and attends the briefing call. Method: knowledge/06-team-onboarding-sales-and-attendees.md.

• sales captain:
• briefing call: T-2w, date/time: — recording:
• on-site channel: (Slack channel for the event, e.g. #event-<slug>)

The one-pager (everyone memorises this half-page)

• Why we're here (one sentence, from 00-event-brief.md):
• Team quota (P1–P3 from 02):
• The three messages we lead with: (from the brief; CEF-consistent — Path A / Path B language for Consulting)

  1. 2. 3.

• What we never say: no client names without approval; no "chatbot"; no hype claims; no competitor talk; pricing → "depends on scope — that's a Path A/B conversation."
• The opener that works: (question-first, not pitch-first — see knowledge/09)
• The demo: (which demo, on whose hardware, offline fallback)
• The meeting ask: (exact sentence for booking a follow-up on the spot)

Target accounts on-site

Per-person assignments

Tools + mechanics

• Capture: 09-lead-capture-sheet.md method (app / form / voice note discipline)
• CRM entry SLA: same day, before evening debrief
• Meeting rooms / quiet space identified:
• Business cards / QR profiles ready:

Conduct + logistics reminders

• Dress code: — badge pickup:
• Standup + debrief times (from 02):
• Expenses policy pointer: — receipts discipline:
• Sponsor/green-room confidentiality (SKILL.md): don't post what you saw backstage.

Readiness sign-off (T-1w)

Social amplification plan — <event_id>

Before / during / after. One event should yield a multi-week content ladder, not one "great to be here" post. Method: knowledge/08-social-media-amplification.md. SMM owns execution; Producer owns capture; posts follow the asset state machine + Class B gate.

• social/content owner: — capture owner (photo/video):
• event hashtag(s) / organiser handles:
• exec accounts posting: (who, and who drafts for them)

Before (T-4w → T-0)

During (live coverage SOP)

• Posting cadence: (e.g. 1–2/day company; execs opportunistic)
• Same-day rule: tag people the day you meet them, with a substance line, not "great chat!"
• Session-insight posts: capture one sharp claim per attended session (feeds S2 target in 02).

Shot list (Producer):

After (the recap ladder — see also 10-follow-up-plan.md)

Rules

• Consent before posting faces/names from private formats (dinners are off-record by default — see knowledge/12).
• Sponsor/green-room content: never (SKILL.md confidentiality).
• Brand forbidden patterns apply to every post; editorial pillars + quality bar govern A2/A4.
• Volume guard: >5 published artefacts in 24h = TEAM.md §6.8 escalation.

Lead capture sheet — <event_id>

The at-event working sheet: tiered capture, conversation notes, and the promise ledger. Badge scans are contacts, not leads — the conversation note is the lead. Method: knowledge/09-lead-capture-and-at-event-engagement.md.

• capture method: (scanner app / shared form / voice notes → same-day transcription)
• CRM entry SLA: same day, before evening debrief — enforced by sales captain
• campaign/source tag in CRM: <event_id>

Tier definitions (decide the tier at capture, not later)

Pre-booked meetings (from 06)

Capture log

One row per conversation. Note fields are mandatory for A/B — a tier-A capture without a next step is a tier-B capture.

Promise ledger (extracted at evening debrief — every promise gets honoured)

Daily reconciliation (evening debrief)

Notes for the follow-up owner

(Patterns heard, objections recurring, sessions worth citing, competitive intel — internal only.)

Follow-up plan — <event_id>

The event's second half. Value realised T+0 → T+21; pipeline judged at T+90. The follow-up owner (named in 02) runs this — not "sales, eventually". Method + benchmarks: knowledge/10-follow-up-and-conversion.md. Outbound copy: Copywriter draft, Class B gate.

• follow-up owner:
• T+0 date: — 21-day sprint ends: — T+90 readout due:

SLAs (non-negotiable)

Sequence slots (drafts live as 10a-...md etc.)

Personalisation rules

• First line references the conversation, the session, or the table topic — never "great to connect at <event>".
• Attach the thing we promised before asking for anything.
• One CTA per touch. Meetings > content > connection, in that order of preference.

The 21-day sprint board

T+14 audit ("no lead left behind")

• Every A/B row has ≥1 logged touch: y/n — gaps assigned to:
• Promise ledger cleared: y/n
• CRM hygiene: every capture tagged <event_id>: y/n

Rolling results (feeds 11-post-event-report.md)

Post-event report — <event_id>

Two passes: the T+7 debrief (honest, fast, while memory is fresh) and the T+90 ROI readout (when pipeline has matured). Event Manager + Analyst co-own. Method: knowledge/11-post-event-engagement-and-measurement.md. Closes the event to closed and improves the pack for the next one.

Part 1 — T+7 debrief

• held on: — present:

Numbers vs targets

Budget actuals

• Fully loaded budget vs actual (from 03): — variance + why:
• Cost per qualified conversation (actual):

What worked (do again)

1. 2.

Kill list (never again)

1. 2.

Surprises / intel

(Market signals, competitor presence, format observations — route notable items to the Researcher.)

Pack improvements

(Concrete edits to propose to templates/event-pack/ or the playbook — PR to marketing-studio. This is how the template gets better every event.)

Part 2 — T+90 ROI readout

• prepared: — by: Event Manager + Analyst

Attribution notes

(Sourced = first touch was this event. Influenced = event touch existed on the opp. Count both, never sum them into one number. Self-reported "how did you hear about us" mentions logged here too.)

Decision (CMO + Event Manager)

• Repeat / scale / shrink / kill (this event, next edition):
• Reasoning (one paragraph):
• If repeat/scale: next edition's scorecard opens with this report attached. Booking deadline for early-bird:

Close-out checklist

• Promise ledger 100% cleared
• All A/B leads dispositioned in CRM
• Content ladder (A1–A4) shipped
• Deposits/refunds recovered; contracts closed
• Log entry appended (data/logs/event-manager.md) + rollup updated
• state: closed in 00-event-brief.md

Synthesized countdown — <event_id>

The one page for the people running the event. Every other pack file answers what and why; this answers when, who, and what it stops. Assembled from the chapters — method: knowledge/event-playbook.md and the chapter each row cites.

This is the one pack file that is NOT a 1:1 rendering of a chapter. It is a synthesis, and synthesis is where invention creeps in. Two rules hold it honest:

1. Every row cites its source — a chapter (ch.NN §Section) or another pack file. A row with no source does not belong on this page.
2. Where a row is your own operating doctrine rather than a chapter rule, it says so. Never let a local decision read as playbook doctrine.

• event: — date anchor: (shift every row if the date moves; the sequence does not change)
• bu: — approval class: (SOP §8 — C if the event involves client-named content)
• event lead: — exec sponsor: — follow-up owner:

Gate legend

Use the marks sparingly. If most rows are gates, none of them are.

Phase 1 — evaluated → committed

Phase 2 — committed → planned

Phase 3 — planned → live

Phase 4 — follow-up → debriefed → closed

The gates that actually stop this event

(Pull out 4–6. A long table hides them; this list is what a reader remembers.)

1. 2. 3. 4.

What this page deliberately does not contain

• Costs — 03-budget-and-roi.md. A countdown carrying money becomes a second budget and the two drift.
• Rationale — the chapters and the instance README. This page is for the person checking what is due on Tuesday.
• Content — the script, the talk track, the sequence copy. Timing appears here; the words do not.

Partner package — <event_id>

Instantiate this file only when INTO is a sponsor or partner rather than a plain attendee or speaker.

What it is for: a sponsorship is not a purchase, it is a set of deadlines someone else owns. This file exists so none of them arrives as a surprise.

• owner: <event lead>
• approval class: C if any entitlement produces client-named or externally-published material
• status: <are the terms documented? If not, that is a blocker in STATUS.md>

The failure mode this file prevents. INTO committed a Les Affaires partnership in June 2026 and nobody wrote down what it contained. Three months later the event pack was still describing the slot as "accepted editorially, not bought", had scored the event's cost advantage as a strength, and could not name a single organiser deadline. The fee itself was never recorded. A committed spend whose amount nobody wrote down is epistemically worse than an explicit assumption — an assumption is visible and gets challenged; an absence gets treated as zero.

So fill §1 and §2 from the organiser at the moment of commitment, not at T-8w.

1. The commercial terms

Every figure here carries an SOP §12 label. A price recalled from a conversation is Based on internal context, not Source-backed.

2. The event itself, per the organiser

Everything in this table comes from the organiser's own material or the event lead's correspondence. None of it may be inferred, and none of it may be inherited from a different edition of the same event.

3. Entitlement tracker

One row-block per deliverable INTO owes or receives. The organiser-deadline field is the point of this file — those dates are not ours to move.

For each entitlement, record: what it is · why it matters · how many · dates available · the organiser's deadline · specs · reach data · destination URL · language · owner · approval class.

Common entitlements and the trap in each:

Every asset needs a destination. If the website it should point at is not ready, that is a gate, not a detail — decide the fallback (dedicated landing page) early.

4. The deadlines we do not know

Fill this in even when it is embarrassing. A list of unknown external deadlines is the most actionable page in a sponsor pack, because each one can be missed in complete silence.

Then note how many of them one request to the organiser would close. Usually all of them, which makes that request the highest-value hour available on the project.

5. Rules that bind every entitlement

1. Market language. For a Québec event, FR is the artefact and takes the Editor pass; EN is an internal working copy. Playbook §Market language.
2. claim_lint_pass on every piece of copy — scripts/check-claims.sh <draft> --bu <bu>. Non-negotiable.
3. No client named externally until §6.3 approval is recorded in decisions.md. Not in a newsletter blurb, not in a webinar title, not in a social teaser.
4. The BU's forbidden claims and the pack's never-cite list apply to sponsor assets exactly as they apply to a stage. A sponsor slot is not a licence to say more.
5. The organiser's audience is not INTO's list.

<event_id> — <Event name>, <city>, <date>

What this folder is

This folder is the project. It aggregates every input about the event, records what was decided, and manages the work to the day. If something about this event is not written down here, it is not being tracked.

Method lives in the playbook; this folder holds only what is true about this event.

Read in this order

The spine

Numbered 00–11, one per lifecycle stage, the same in every event pack. Full definitions: event pack.

<!-- Delete the rows that do not apply yet; do not renumber. -->

Format modules in this pack

Named, never numbered — a number would imply a lifecycle position these do not have. List only what this event actually uses.

<!-- e.g. sponsor-deliverables.md · partner-package.md · webinar-plan.md · panel-script.md · run-of-show.md · speaker-pack-<name>.md · countdown.md -->

Who owns what

House rules for this folder

1. Never invent a fact. Unknown is TBC, and TBC on a blocking field is

   a flag, not a placeholder to live with.

2. Every external claim is labelled in evidence.md before it ships.
3. Decisions go in decisions.md, append-only — a reversal is a new entry

   that supersedes, never an edit.

4. Re-read the BU and brand files at each artefact, never inherit

   governance prose from a template or a sibling event.

5. Run ./scripts/check-claims.sh <draft> --bu <bu> on anything going out.

STATUS — <event_id>

The front door. Open this first. The live state of the project: where we are, what is blocked, who owes what. Everything else in this folder is reference that this page points into.

Refresh cadence: weekly by the event lead, plus immediately after any decision. If "as of" below is more than 7 days old, treat every status on this page as stale and re-derive it before acting.

• as of: <YYYY-MM-DD>
• refreshed by: <role/person>
• lifecycle state: <scouted | evaluated | committed | planned | live | follow-up | debriefed | closed>
• T-minus: <n days to the first event day>

The one-liner

<One sentence: what this event is for, and whether it is on track.>

Blocked — needs a human

Anything here stops work. Empty is a valid and good answer.

Next gates

The gate is the date that binds, not the event date.

Owed, by whom

Changed since last refresh

<!-- Two or three lines. What a reader who saw this a week ago needs to know. Anything that was a decision also belongs in decisions.md. -->

Known-stale

Fields carried forward that nobody has re-verified. Being explicit here is what keeps the rest of the page trustworthy.

Decision + change log — <event_id>

Append-only. New entries at the bottom. Never edit or delete a past entry — if a decision is reversed, add a new entry that supersedes it and say so.

This is the record of what we decided and why, so that 11-post-event-report.md can test the reasoning rather than re-guess it. Format follows TEAM.md §5.

Every entry carries: the decision, who made it, what it came from, and what it changed. A decision with no named decider is not a decision — it is a drift.

<YYYY-MM-DD> — <short decision title>

• decision: <what was decided, in one sentence>
• decided by: <person> (<role>)
• approval class: <A | B | C | D — per the AI Studio SOP §8>
• source: <the message, meeting, file or gate this came from>
• reasoning: <why this and not the alternative>
• changed: <which files/fields this moved, and what they said before>
• supersedes: <entry date, or "—">

<!-- Next entry below. Do not reorder. -->

Sources — <event_id>

The aggregation index. Every input that fed this pack, what it contributed, and how much weight it carries. If a claim appears anywhere in this folder and is not traceable to a row below, it does not belong in the folder.

Companion file: evidence.md labels the claims. This file indexes the inputs. Keep them separate — a good source can still support a weak claim, and a weak source occasionally supports a claim that is true for other reasons.

Source tiers follow reference/source-taxonomy.md. Tier 7 is confidential — it may inform a decision but must never be quoted into an outbound artefact, and using it is a TEAM.md §6 escalation.

Organiser + first-party

What the organiser told us, and what we hold ourselves.

Internal records

Prior events, board projects, strategy packets, CRM, role logs.

External research

Anything published outside INTO. Every row here needs a matching label in evidence.md before anything it supports goes out.

Asked for and not received

The gaps. Naming them is what stops a missing input quietly becoming an assumption.

Evidence layer — <event_id>

The provenance layer for this event. Two label systems, deliberately not merged — conflating them is how a vendor's marketing number becomes a planning input.

External claims — research labels

Internal claims — INTO confidence

Claim ledger

Every non-obvious claim this pack makes, and what stands behind it.

Claims we removed

Kept deliberately. A claim that failed verification is worth more as a record than as a deletion — it stops the same number being re-imported next quarter.

Gated + forbidden for this BU

Re-read business-units/<bu>/README.md and brands/<brand>/README.md at the time of writing each artefact — never inherit governance prose from a template or a sibling event. Governance moves; templates do not.

Gate every outbound draft: ./scripts/check-claims.sh <draft> --bu <bu> (exit 0 clean · 2 blocked · 3 gated without an approval reference).