event-vip-social-program

Event VIP Social Program

You run a room that not everyone can walk into, at an event where everyone can walk into everything else. Three decisions, and only three, cover the job:

• How the seat list gets assembled when more than one party is putting names forward.
• How the invitation and the door work without publishing that a tier exists.
• Where the gathering sits against the public programme.

The default answer is that there is no separate room. That is a rung on the first menu, not a refusal to help, and at a community-run event it is the most common correct outcome.

How little this skill owns, and why that is deliberate

Almost everything a reader means by "VIP social programme" already has an owner. What is left is narrow.

• Whether a named-guest programme exists at all → not yours. samber/dev-event-organizer-skills@event-vip-management decides it, on a test it states as an obligation, never a title, and its own most common correct answer is that nobody is left in scope. It also owns the escort depth, the guest's own visibility, and the obligation roster.
  • Run it first. If it finds nobody, this skill has nothing to do.
• What is served, and whether an evening exists → not yours. samber/dev-event-organizer-skills@event-hospitality decides the catering style, the alcohol posture, and whether an evening or social programme exists at all. Its reference file already separates the two artifacts you are standing between: "the evening event" and "an invited dinner" are different artifacts; it designs only the first.
• The speakers' dinner → not yours. samber/dev-event-organizer-skills@event-speaker-experience owns it, on its own budget line, and event-hospitality says from its own side that it will never re-decide a speakers' dinner, a volunteer meal or a VIP table. That budget line describes speakers and nobody else. Never carry it over to the rungs below.
• A gathering that was sold → not yours to allocate. samber/dev-event-organizer-skills@event-sponsor-fulfillment delivers what a signed agreement promised, gated on payment. Be precise about the split, because it is easy to get backwards:
  • A sponsor asking for seats at your gathering is this skill's allocation problem.
  • A gathering the agreement sold is that skill's deliverable, and you do not get to ration it.
• Somebody else's party → not yours. samber/dev-event-organizer-skills@event-side-event-coordination approves and deconflicts events run by third parties, and states the seam from its own side: Where that skill's evening is the thing you provide, yours is the thing you permit. A sponsor-hosted reception is theirs. Yours is a room you host.
• The social track everyone can join → not yours. samber/dev-event-organizer-skills@event-official-social-program designs the announced social programme for the whole audience. If the honest answer to "who is this for" is "anyone who wants to come", you are in that skill, not this one.
• Choosing an invite-only dinner as the whole event → not yours. samber/dev-event-organizer-skills@business-event-formats picks between company-run shapes where the dinner is the event. Here the dinner is a room inside somebody else's conference.

What survives all of that is the private-gathering mechanics, and only those. event-vip-management hands them over explicitly and then designs none of them: A guest's table is therefore yours; the food on it is not. This skill is that table.

How to use the menus and defaults

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

• A venue with a side room.
• A team member who already owns the relationship with whoever is asking for seats.
• A list that survived from last edition.
• An organizer who already knows every guest personally.

No quantity is prescribed anywhere - no seat count, no cap, no lead time, no headcount - because invented numbers read as benchmarks. Every number that does appear is either quoted from published guidance or a reader's own words about their own room, never a threshold this skill sets.

The named owner

Designate one contact person who holds the seat list, builds it, sends the invitations, works the door, and answers every refusal. Governance and organizational practice establish the pattern. That same person decides any exception to the list at the door.

• Carries over to a private gathering: the role.
• Does not carry over: a protocol office's own staffing, or its authority over a building.

Interview

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

1. Has samber/dev-event-organizer-skills@event-vip-management already run, and did it find anybody in scope? If not, stop and run it. It decides whether a named-guest programme exists at all, and this skill assumes that answer rather than re-deciding it.
2. Who owns the event and what does its register say about status - flat and explicitly anti-hierarchy, or comfortable recognizing who is in the room?
3. Name each guest the gathering exists for, and say in one sentence what the room does that the general evening cannot. For each: did they, or their office, ask not to be identified, listed or photographed?
4. How long until doors, and are the room booking, the schedule and any printed programme still open? Does any guest have a fixed arrival or departure window, and does any existing slot fit inside it?
5. Who else is asking for seats - sponsors, speakers, board members, your own team - and what did each ask for, in their words? Has anybody already been told yes, and by whom?
6. What does the room seat, and who set that number: the venue, the budget, or the conversation you actually want to have?
7. Who owns this by name - builds the list, sends the invitations, works the door, and answers the party who gets refused? Are they also running the main event that day? Reversibility is not symmetric here: a seat can be added, and an issued invitation cannot be withdrawn without costing more than the seat did.
8. One-off, or does this recur edition after edition? And has anything about it already been published or promised, in what artifact - a prospectus, an agreement, a schedule, an email?
9. Which assets re-rank the defaults: a venue with a usable side room, a team member who already holds the relationship with whoever is asking, a list from last edition?

Community vs vendor pole

Who owns the event moves one menu, on the same community-versus-vendor split the rest of this collection argues.

• Community pole. A room not everyone can enter contradicts the register samber/dev-event-organizer-skills@event-cultural-identity sets. Menu A's fold is not a compromise at this pole. It is usually the right answer, and the burden sits on whoever wants the room to name what it does that the general evening cannot.
• Vendor/corporate pole. A private room is ordinary and often the reason a guest came. The seats are then scarce for a stated reason, and the defensibility half of Menu A's value carries most of the weight.

Say which pole a recommendation assumes wherever they differ. The pole moves Menu A's default and nothing else. Menus B and C hold their order across both.

Workflow

1. Run the interview. If Q1 says no named-guest programme exists, stop and route to samber/dev-event-organizer-skills@event-vip-management.
2. Answer Q3's second half first: what does the room do that the general evening cannot? If nothing survives that question, Menu A's default is the answer and the rest of this skill does not run.
3. Set the seat-list construction rule (Menu A). Then build the list - its fields, its named owner, its circulation, and its deletion date, decided now - from references/invitation-and-door-mechanics.md.
4. Set the invitation and access mechanics (Menu B). Issue invitations from the same reference: individually, privately, by the person holding the list.
5. Set the placement against the public programme (Menu C), then hand the slot to samber/dev-event-organizer-skills@event-run-of-show and the grid clash to samber/dev-event-organizer-skills@event-schedule-design. Tell them the slot. Never move a public session to make room for a private one.
6. Write the refusal rule down before the first ask arrives, and cite the same one to every party. The rule is the whole of the defensibility, and it is cheap only in advance.
7. Hand off what is not yours:
   • Catering and drink for the room: samber/dev-event-organizer-skills@event-hospitality.
   • Any access need: samber/dev-event-organizer-skills@event-accessibility-inclusion - a guest who cannot enter the room is an access question first.
   • Anything a guest's own security detail requires: samber/dev-event-organizer-skills@event-vip-management.
   • The code-of-conduct reach over a private room: samber/dev-event-organizer-skills@event-code-of-conduct, which decides which spaces its scope clause covers.
8. Present section by section - purpose, list rule, list, invitation and door, placement, refusal rule - and get explicit approval per section before finalizing.

If your harness has persistent memory, record per edition:

• What the room was for.
• Who asked for seats, and what each was told.
• Which rule was cited.
• Whether the list was deleted on its date.
• Whether any attendee mentioned the room afterward.

Next edition starts from that instead of re-arguing the same asks.

Menu A - seat-list construction rule

How the list gets assembled when the organizer, sponsors and speakers all have names to put forward. Two value axes run close to opposite, which is why this menu prints two value orderings rather than one.

• effort (organizer-hours, arbitration between asking parties, the conversations a refusal costs, records kept): open nomination with published criteria and a host veto > host list + capped nominations per asking party > host-nominated only > no separate list
• value, the room is right (the people the gathering exists for are actually in it): host-nominated only > host list + capped nominations > open nomination with criteria > no separate list
• value, the answer is defensible (every party who asked can be told why, and the same rule was applied to each): open nomination with criteria > host list + capped nominations > no separate list > host-nominated only
• compliance cost (review triggered, reversibility spent): open nomination with criteria > host list + capped nominations > host-nominated only == no separate list
• efficiency: no separate list > host list + capped nominations > host-nominated only > open nomination with criteria

Dominance check: four rungs, six pairs, zero strict dominance relations - and two distinct mechanisms account for all six, not one.

Four pairs are blocked because the two value axes run opposite, and in each the rung that puts the right people in the room is the rung whose rule is hardest to defend:

• Open nomination against capped nominations.
• Open nomination against host-nominated only.
• Capped nominations against host-nominated only.
• Host-nominated only against the fold.

The remaining two pairs are blocked by cost rather than by opposition, the busier rung winning both value axes and losing on effort:

• Open nomination against the fold.
• Capped nominations against the fold.

This menu is clean by construction on four pairs and by a cost trade on two, which is not a pass either way. The efficiency line rests on each rung's own argument below.

The compliance == is argued: compliance is the one axis on which the two cheap rungs come out equal, since effort already separates them and this axis deliberately does not.

• Host-nominated only: creates a small named-person list carrying one retention decision. A list nobody was told about can still be shortened - it holds an artifact and spends no reversibility.
• The fold: holds no artifact at all. Every invitation it issues is verbal, unrecorded and impossible to withdraw cleanly - it spends reversibility and holds nothing.

Equal exposure, opposite halves. The two busier rungs sit above both because capped nominations means holding names a sponsor supplied about somebody else, and published criteria are a commitment you can be held to next edition.

• No separate list - the default: there is no private gathering, and the guest is walked into the general evening by a named person. It is also the only rung that cannot produce a tier.
  • It wins the ratio because near-zero effort only pays when what the rung buys is still non-zero, and here it usually is. Most of what a private room buys is a short, nameable set of conversations, and those can be made by walking up to people.
  • Done properly, it has its own mechanics in the reference file: a named companion, the introductions written down in advance, a stated exit time. Done lazily, it is a guest holding a drink at the edge of a room, which is worse than not inviting them.
  • Promotion condition, keyed to Q3: move up one rung when Q3 names something the room does that the general evening genuinely cannot - a discretion request a public room breaks, or a conversation that needs a fixed set of people and no others. "It would be nice for them to meet" is not that, and it is the answer this question exists to catch.
• Host list + capped nominations per asking party - the organizer builds the list, and each asking party gets the same stated allowance. Second on both value axes and second on effort, it wins the ratio over host-only because the asks arrive whether or not you have a rule for them.
  • The cap is the cheapest artifact that turns every ask into one answer, and it costs one number and one sentence over building the list alone.
  • Published event-planning guidance for exactly this scenario states the same mechanic: agree a funding party's allocation as a number before any money changes hands, since "you have 20 spots" is a different conversation than "who would you like to invite."
  • Promotion condition, keyed to Q5: this is the rung whenever Q5 names more than one party already asking for seats.
• Host-nominated only - the organizer builds the list and accepts no nominations. Tops the room-is-right axis, because nobody knows the must-have names better than the host and every seat given to a nomination is a seat the host did not allocate.
  • It sits third on efficiency because its saving is real, and the grievance it generates lands precisely on the relationships the room was meant to serve.
  • Promotion condition, keyed to Q5: this is the rung when Q5 finds no

...