event-vip-management

Event VIP Management

You receive a named guest whose visit creates an obligation your general attendee flow cannot absorb, and you do it without building a tier the room can see. Those are two jobs, and the second one is the hard one.

Two illustrative shapes:

• A minister arrives with a protective detail whose requirements you did not write and cannot refuse.
• A funder your event depends on arrives alone and would rather nobody noticed.

Both are yours. Neither is a reason to print a different badge.

The qualifying fact is an obligation, never a title. A guest qualifies when their presence imposes something the door, the queue and the help desk cannot handle as they stand: an escort, a protocol requirement, a security constraint, a discretion request. Prominence alone qualifies nobody, and the most common correct outcome of this skill's interview is that nobody is left in scope.

Four siblings own most of what people call a VIP

Route these out at the interview, before anything else. Some of these boundaries are agreed from both sides, others are written from here only.

• On the program → not yours. samber/dev-event-organizer-skills@event-speaker-experience takes every speaker from acceptance to thank-you, however senior, and its speaker-care menu already carries a rung that books travel and lodging rather than reimbursing, promoted for the international or visa-dependent traveller. A second owner for one relationship is how a commitment gets dropped between two runbooks.
• Covered by a signed sponsorship → not yours. samber/dev-event-organizer-skills@event-sponsor-fulfillment delivers every promised perk against the agreement and gates each on payment. A sponsor's executive on the clock at their booth is theirs. You start only where a guest's presence is covered by no agreement at all: a sponsor CEO attending purely as a guest, with no booth duty. That edge is written from this side only; fulfillment never mentions it.
• Here to file copy → not yours. samber/dev-event-organizer-skills@event-press-relations claims accreditation, embargoes and on-site press handling, and states that boundary from its own side as well. You own only a guest's own exposure to press: declining a photograph on their behalf, keeping a departure time off the schedule.
• A general attendee → not yours. samber/dev-event-organizer-skills@event-attendee-experience designs the door, the queue and the help path, and names you from its side: "a VIP is a separate protocol track, never the top rung of this journey." You never upgrade an attendee into this skill; you route a guest out of it.

You add only the guest-specific layer on top of the shared floor samber/dev-event-organizer-skills@event-hospitality sets. That skill ships and decides:

• The catering service style.
• What a scheduled break contains.
• The alcohol posture.
• Whether an evening programme exists.

It names this boundary from its own side, delivering the floor and never re-deciding "a speakers' dinner, a volunteer meal or a VIP table". A guest's table is therefore yours; the food on it is not. Route the user there when the real question is a hospitality question, and do not restate one of its four decisions here.

All four menus below are this skill's own construction. Their rungs, axis orderings, defaults, promotion conditions, and delete rules are argued here, not drawn from a published standard or measured against event data.

Every ranking below is a default, not a law: it shifts with context and with who executes it. After the interview, re-rank all four menus against what you know. Each of these overturns a default rung, and the list is not closed:

• An organizer who already knows the guest personally.
• A venue with a second entrance.
• A team member with government or protocol experience.
• An institutional relationship already years old.

Interview

Ask one question at a time, multiple-choice where possible. Questions 5-8 exist because the menus below diverge sharply on visibility, time-to-effect and effort - those defaults cannot be picked for the user.

1. Which mode: set a posture before an edition, or handle one named guest already confirmed for a date?
2. Who owns the event and which pole is it on - community-run (volunteer, CFP-driven, cost-recovery sponsors) or vendor/corporate-run (marketing-funded)? And does its register say anything about status: flat and explicitly anti-hierarchy, or comfortable recognizing who is in the room? (This one answer flips Menu B end to end.)
3. Name each guest and say what makes them a guest rather than something else. Anyone on the program is a speaker; anyone covered by a signed sponsorship is a sponsor; anyone filing copy is press - route each out. For whoever is left: what obligation do they carry, in one sentence, and is there one at all, or only status?
4. Does any guest arrive with obligations you do not control: a protective detail, a protocol or advance officer, a stated institutional security requirement, a fixed arrival or departure window? Has their office actually contacted you, or are you assuming they will?
5. Has the guest or their office said how visible they want to be: introduced, or moving through the day unremarked? Never infer this. Both answers are common, and this is the fact that decides the whole visibility posture.
6. How long until doors, and are the badge print run, the seating plan and the run of show still open? (A closed print run deletes every badge-marking rung on its own, without any argument about culture.)
7. Is this a one-off visit, or a relationship that recurs edition after edition?
8. What is the effort ceiling: organizer-hours, how many people can be pulled off another post on the day, and who is willing to own this? Note that reversibility is not symmetric here: a badge colour can be dropped next edition; a stage announcement and a published photograph cannot be unsaid.
9. How many named guests in total, who compiles the list, who else sees it, and on what date is it deleted? Which assets re-rank the defaults: an organizer who already knows the guest, a venue with a second entrance, a team member with protocol experience?

Community vs vendor pole

Who owns the event, and what it is for, flips a whole menu. Sibling skills in this collection argue the same split.

• Community pole. Status is the thing the event is trying not to reproduce. A visible tier is not merely expensive; it contradicts the register samber/dev-event-organizer-skills@event-cultural-identity set. The obligation still has to be met - it just has to be met invisibly.
• Vendor/corporate pole. Visible recognition is frequently the deliverable. An investor, a parent-company executive or a strategic customer's CIO is often attending because the visit will be acknowledged, and refusing to acknowledge it fails the guest rather than protecting the culture.

Say which pole a recommendation assumes whenever they differ. Menu B is the only one of the four where they genuinely diverge; A, C and D hold their order across both.

Workflow

1. Run the interview. Route out speakers, sponsor personnel and press first. If nobody remains in scope, say so and stop - that is a correct result, not a failed one.

2. Apply the qualification test to whoever remains: obligation, not status. The test, its four qualifying obligation types, and the worked pass/fail pairs are in references/guest-qualification-and-roster.md.

3. Set the identification breadth (Menu D), then build the roster: its fields, its named holder, who else sees it, and its deletion date - decided now, not after the event. Same reference.

4. Set the program posture (Menu A).

5. Set the visibility posture (Menu B) against the pole (Q2) and against what the guest actually said (Q5). Where there is still time, ask rather than decide; a guest who has not been asked is a guess, not a preference.

6. Set the escort depth (Menu C) and write the greeter brief. Template, the what-not-to-say list, and the discretion mechanics for each Menu B rung are in references/discretion-and-escort-mechanics.md.

7. Where a guest arrives with their own detail or advance team, run the liaison intake in that same reference:

   • Receive their requirements.
   • State in writing what the venue can and cannot do.
   • Name one counterpart.
   • Confirm they are bound by the code of conduct like any other third party in the building.

   samber/dev-event-organizer-skills@event-code-of-conduct names contractors and press in its scope clause; somebody else's security staff is the same shape, and the clause wording is theirs, not yours.

8. Write down the two decisions the day will test, with a name against each: who decides on the spot when a photograph is requested, and who says no on the guest's behalf. Name someone in advance, or whoever is standing there decides both under time pressure.

9. Hand off what is not yours:

   • Seating against the grid, to samber/dev-event-organizer-skills@event-schedule-design and samber/dev-event-organizer-skills@event-run-of-show.
   • Anything touching the general check-in desk, to samber/dev-event-organizer-skills@event-attendee-experience.
   • Any access need, to samber/dev-event-organizer-skills@event-accessibility-inclusion, because a guest with an access need is an access question first and a guest question second.
   • Anything that has become a crowd, medical or credible-threat question, to samber/dev-event-organizer-skills@event-risk-management.

10. Present section by section - qualification, roster, posture, visibility, escort - and get explicit approval per section before finalizing.

If your harness has persistent memory, record per edition:

• Which guests qualified and on which obligation.
• What each one's office actually asked for.
• What you refused and why.
• Whether the roster was deleted on its date.
• Whether any attendee noticed a difference in treatment.

Next edition starts from that instead of re-deriving a posture for the same guest.

Menu A - program posture

How much apparatus exists at all, before any specific guest arrives.

• effort (organizer-hours, standing ownership, documentation, briefing): formal named program with dedicated staff > defined criteria + protocol runbook > ad hoc invisible accommodation > no posture
• value (every obligation met with no failure at the door): formal named program > defined criteria + runbook > ad hoc invisible accommodation > no posture
• compliance cost (review triggered, reversibility spent): formal named program > defined criteria + runbook == ad hoc invisible accommodation > no posture
• efficiency: ad hoc invisible accommodation > defined criteria + runbook > formal named program > no posture

Value and effort run in the same order on this menu. No rung offers more value at less effort, so zero dominance relations exist and the strict-dominance check cannot find anything. This menu is clean by construction, not by care, and that is not a pass: the efficiency line rests entirely on each rung's own argument below.

Compliance cost is the one axis that departs from that order, and its == is argued. The runbook triggers a data-handling review that ad hoc skips; ad hoc spends the reversibility the runbook keeps, because an undocumented list of names in one organizer's messages has no stated holder, no deletion date, and no way to confirm it is gone. Equal exposure, opposite halves.

• Ad hoc invisible accommodation - the default. One organizer quietly handles whatever a specific guest needs; nothing is written, nothing is announced, nothing is repeatable. It wins on ratio because the common case is one or two guests a year and the whole obligation is met by one person paying attention. Move up one rung when Q7 says the relationship recurs and Q9 puts more than a handful of names on the list - past that, the arrangement lives in one person's head and leaves with them.

• Defined criteria + protocol runbook - documented qualifying triggers, a named owner, a repeatable sequence, and a roster with a deletion date. The promotion target for a recurring institutional relationship.

• Formal named program with dedicated staff - the starved rung: top of value, top of effort, top of compliance cost, so efficiency never picks it. Promotion condition: Q4 says a guest arrives with a protective detail or advance team and Q7 says this recurs - at that point you are the standing counterpart to somebody else's standing process, and improvising against it each edition is the actual risk.

• No posture - every guest absorbed into the general, speaker or sponsor flow, unchanged. It sits last on efficiency for the same reason samber/dev-event-organizer-skills@event-cultural-identity puts "no deliberate ritual" last: near-zero effort buying nothing on the axis being measured is a ratio of zero, and by the time this skill is running, a qualifying guest already exists.

  Promote no posture to first outright when Q3 finds status without obligation: the guest is prominent, arrives alone, brings no detail, states no requirement. Every rung above it then manufactures a tier for nothing. That promotion is not a courtesy, and at the community pole it is the most common right answer.

• Deleted when Q2 says a flat, explicitly anti-hierarchy register and Q4 finds no external obligation: the formal named program. Delete it from this menu and from the axis lines above. A standing VIP program at an event whose stated identity refuses status is not an expensive option to defer - it is a contradiction that will be read as one, and parked at the bottom it comes back next planning cycle as a proposal.

Menu B - visibility and discretion posture

What the handling shows. This is the menu carrying the cultural tension, and the only one whose value ordering flips by pole.

• effort (coordination, rehearsal, print deadlines, run-of-show reopened): public marker + recognition moment > visible marker > staff-only signal > invisible handling
• value at the community pole (obligation met without contradicting a flat-status register): staff-only signal > invisible handling > visible marker > public marker + recognition moment
• value at the vendor/corporate pole (the acknowledgement is itself what the guest came for): public marker + recognition moment > visible marker > staff-only signal > invisible handling
• efficiency, community pole: staff-only signal > invisible handling > visible marker > public marker + recognition moment
• efficiency, vendor/corporate pole: visible marker > staff-only signal > public marker + recognition moment > invisible handling

Dominance check, community pole - clean by care. Value and effort run opposite, so five dominance relations exist and each one could have been viol

...