event-ticket-pricing

{
  "skill_name": "event-ticket-pricing",
  "evals": [
    {
      "id": 1,
      "prompt": "I run Northline DevOps Day, a one-day community event in Gothenburg. The venue seats 300. Right now it's free, last year 240 people showed up, and I personally ate a 41,000 SEK catering overrun because I had no idea how many would actually turn up and eat. This year I want to charge something. Our four gold sponsors each get 6 passes written into their contracts, and we have 14 speakers, 9 organizers and 22 volunteers. A commercial DevOps conference ticket in Sweden runs about 9,500 SEK. What should the ticket cost?",
      "expected_output": "A posture recommendation (nominal fee) derived from the funding model rather than from comparable prices, with paid capacity computed after comps, the revenue target sourced from a budget, the compliance consequence of charging anything stated, and the no-show exposure routed elsewhere.",
      "files": [],
      "expectations": [
        "States that the ticket revenue target must come from the event budget - total expenses minus the sponsorship share - and does not produce a final price from comparable prices alone.",
        "Directs the user to build or complete the budget first when no expense total and sponsorship share is on hand.",
        "Subtracts committed comps from the 300-seat venue capacity before pricing, explicitly naming sponsor allotments, speakers, organizers and volunteers.",
        "Carries the comp arithmetic through with the figures given: 24 sponsor passes plus 14 speakers plus 9 organizers plus 22 volunteers, leaving roughly 231 paid seats.",
        "Refuses to set comps as a percentage of capacity and states that the count comes from the agreements already held.",
        "Recommends a nominal-fee posture and identifies it as the efficiency-leading option rather than the highest-value one.",
        "States the nominal-fee band as roughly 10-20% of what a commercial tech conference charges in the same region, and applies it to the 9,500 SEK reference.",
        "States that the nominal fee's job is spreading financial risk and converting an unpaid RSVP into a headcount catering can be committed against, not funding the event.",
        "Warns that charging any non-zero price pulls in accounting and tax obligations, and that this compliance cost is the same for a token price as for a commercial one.",
        "States that a published price cannot be withdrawn mid-sale without refunding whoever already paid, so the priced posture is less reversible than staying free.",
        "Does not claim the fee eliminates no-shows, and routes the no-show exposure to the no-show management skill.",
        "Presents the structure section by section for validation rather than returning a single final number."
      ]
    },
    {
      "id": 2,
      "prompt": "Ferrite Conf is a two-day Rust conference in Porto, 420 paid seats, second edition. Last year everyone paid one flat 180 EUR. This year I want proper tiers: Corporate, Individual, Student. And on the time axis I want Super Early Bird, Early Bird, Regular, and a Last Chance tier so there's always urgency on the page. Our per-attendee cost - catering, badge, lanyard, coffee - works out to 47 EUR. Roughly 55% of our audience expenses it to an employer, 35% pay out of their own pocket, 10% are students. Give me the grid.",
      "expected_output": "A two-price-point-per-persona ladder built from the stated payer mix, floor set from the 47 EUR per-attendee cost, upper rungs derived by transposed ratio reported as a range, one published gate, and the revenue target confirmed upstream.",
      "files": [],
      "expectations": [
        "Caps public price points at two per persona and rejects the four-phase Super Early Bird / Early Bird / Regular / Last Chance time ladder.",
        "States that a third phase is legitimate only as a late surcharge, never as a third discount step.",
        "Warns that extra discount steps read as pressure tactics and train buyers to wait for the next one.",
        "Builds the persona split from the stated payer mix - 55% employer-funded, 35% self-funded, 10% student - rather than from event size or city.",
        "Sets the floor price from the 47 EUR per-attendee cost and the chosen posture, not from a comparable event's floor price.",
        "Applies a top-to-floor ratio drawn from a published range of roughly 1.7:1 to 6.5:1 and reports it as a range rather than as one canonical number.",
        "Names which comparable's ratio it transposed and justifies the pick on matching payer mix rather than matching city or headcount.",
        "States explicitly whether the single time step is an expiring discount or a surcharge that lands.",
        "Gives the time gate as a published calendar date, or as a first-N-tickets count, announced from the day tickets go on sale.",
        "Labels each price it produces as sourced or self-set.",
        "Does not copy absolute ticket prices from any named conference into the Ferrite Conf grid.",
        "Confirms the ticket revenue target comes from the budget before allocating it across the tiers."
      ]
    },
    {
      "id": 3,
      "prompt": "Quick one. Meridian Data Summit, 350 seats. Tickets are 240 EUR early bird until 12 March, then 310 EUR. A logistics company emailed wanting 12 seats and asked two things: does our 10% group discount apply on top of the early-bird price, and can they pay on a purchase order with a 30-day invoice instead of a card, because their card limit won't cover it. Our treasurer said we could knock another 5% off for the invoice hassle. We're a registered nonprofit and we have a bookkeeper. What do I tell them?",
      "expected_output": "A refusal to stack the group discount on the early tier, a refusal to discount the invoice rail, the same-order and tier-exclusion rules stated, and a concrete quote for the 12-seat order at the standard tier.",
      "files": [],
      "expectations": [
        "Refuses to stack the group discount on the 240 EUR early-bird price and gives the reason as discounting the same seat twice.",
        "Restricts the group discount to the standard tier, excluding both the early and the late tiers, and requires that exclusion to be published on the page.",
        "Requires the group discount to apply only within a single order.",
        "Rejects the extra 5% for paying by invoice and states that invoicing is a payment rail, not a discount.",
        "States that invoicing is offered at full price.",
        "Explains that the invoice rail's value is unlocking orders that would otherwise not happen at all, not reducing the price.",
        "Warns that discounting the invoice rail hands the top-paying corporate segment a second reduction for a problem that was never about money.",
        "Notes that the rail requires an entity able to issue invoices and reconcile payment, and confirms the nonprofit with a bookkeeper satisfies that.",
        "States that an organizer with no invoicing capacity should delete the rung outright, and that inability to take payment in the form buyers need is an upstream problem rather than a pricing one.",
        "Reports published group thresholds and percentages as a range - for example 15% at five or more in one order, or a 5% / 10% step at 5-9 and 10-plus - rather than asserting one industry-standard number.",
        "Recommends one threshold and one percentage rather than a multi-step table for an event of this size.",
        "Gives a concrete answer for the 12-seat order priced at the 310 EUR standard tier rather than only restating the rules."
      ]
    },
    {
      "id": 4,
      "prompt": "Trouble. Someone emailed on 27 September asking for a refund for our event on 18 October. We've sold 190 tickets and we never wrote a refund policy anywhere - not on the registration page, not in the confirmation email. What's the industry standard so I can just apply it? And what do I do about this one person? We also handed out 11 hardship tickets this year.",
      "expected_output": "An explicit statement that no industry standard exists beyond a single dated cutoff, several real policies presented as a range of options, a forced decision on each policy term, and the hardship-ticket transfer question answered.",
      "files": [],
      "expectations": [
        "States that community technical events have no industry standard refund practice beyond a single dated cutoff.",
        "Does not present a graduated or sliding refund schedule - for example 100% at 60 days out, 50% at 30 days - as standard practice.",
        "Notes that the worked example policies do not grade the refund by how many days out the request lands.",
        "Presents the real policies as a demonstrated range of options rather than as a ranked list or a norm.",
        "Shows that the administrative fee varies across the examples: a flat amount, a percentage of the price, or none at all.",
        "Shows that the fee itself can be tiered to the ticket type rather than flat across the ladder, with a lower fee on student tickets.",
        "Presents at least two distinct hardship mechanisms: waiving the fee for named reasons, and granting a separate later deadline for visa or travel issues.",
        "Forces an explicit decision on each of: refund deadline, administrative fee, hardship waiver, post-deadline handling, person-to-person transfer, and transfer within a company.",
        "States that a credit toward the next edition does not appear in the sourced examples, so an organizer choosing it should say it is their own invention.",
        "States that the 11 hardship tickets should be non-transferable, because transferring a need-reviewed ticket defeats the review it went through.",
        "Requires the finished policy to be published on the registration page beside the price, not only in a confirmation email.",
        "Requires the deadline be written as a calendar date rather than a relative window such as 30 days before the event."
      ]
    },
    {
      "id": 5,
      "prompt": "Sablefish Summit, about 260 attendees, Manchester. Tickets are 145 GBP individual, 310 GBP company, 45 GBP student. Three people have emailed this year saying they're between jobs and can't pay. I want a way in for them but absolutely not a public discount code that gets screenshotted onto Reddit. There are two of us organizing this in the evenings. Our website says we're 'the most accessible data conference in the north'. What do we do?",
      "expected_output": "A need-gated application route rather than a published tier or a code, sized to a two-person evening team, with the reviewer, the response promise, the window and the award written before publication, plus an answer for the three pending emails.",
      "files": [],
      "expectations": [
        "Recommends a need-gated, application-reviewed route rather than a public discount code or a fourth published price tier.",
        "States that publishing the need-gated ticket as a cheap public tier turns a reviewed decision into a self-service checkbox and invites exactly the buyers it was not for.",
        "Notes that the route may deliberately leave the price unpublished, which keeps the decision with the reviewer.",
        "States that the existing 45 GBP student price does not reach the unemployed, career-changers, or others in hardship, which is why the two rungs coexist rather than compete.",
        "Requires four things written before the route is published: who reads applications, how fast they promise to answer, whether the window closes, and what the applicant receives - a code, a free pass, or a price.",
        "States that an unanswered application is worse than offering no route at all, because the applicant has disclosed hardship to a silent inbox.",
        "Does not present the scholarship rung as free to the organizer, and names it as standing per-application labor.",
        "Sizes the mechanic to the stated effort ceiling of two evening organizers, choosing a low-overhead form such as an email request or a simple form rather than a scored reviewer panel with a published eligibility list and an application window.",
        "Uses the stated accessibility positioning claim as the reason the rung is promoted despite ranking last on efficiency.",
        "Distinguishes need-based framing from an identity-based eligibility enumeration, and notes that events publish them as separate routes rather than merged into one paragraph.",
        "Warns against copying an eligibility list across jurisdictions without local checking, and declines to give legal advice.",
        "Answers the three pending emails with a concrete route rather than only describing the design."
      ]
    },
    {
      "id": 6,
      "prompt": "HackTheHarbour is a free 48-hour hackathon. 180 people registered last edition and 112 turned up - we had bought 180 lunches. Sponsors cover 100% of our costs. I read somewhere that charging a small refundable deposit you hand back at check-in fixes this. Should we do a 10 EUR refundable deposit, or just start charging 15 EUR flat? What does the data actually say?",
      "expected_output": "A statement that deposit-hold tickets are untested for developer events, the single cross-industry data point cited with its limits, the no-show problem routed away from pricing, and the free-by-design funding model sent back upstream.",
      "files": [],
      "expectations": [
        "States that deposit-hold tickets remain untested as a developer-event pricing lever specifically.",
        "Cites the single cross-industry data point in full: Eventtia's 2024 managed-conference data, where a $3 refundable deposit cut a previously-free event's no-show rate from 38% to 14%.",
        "Labels that data point as general-conference evidence rather than developer-event evidence, and does not present it as proof the mechanic works here.",
        "Routes the no-show problem itself to the no-show management skill rather than answering it with a price.",
        "States that pricing does not fix no-shows and that a nominal fee reduces the exposure without solving it.",
        "Identifies that a format funded at roughly 100% by sponsorship has no ticket-revenue line, so the priced postures are deleted rather than ranked.",
        "Sends the funding-model question back upstream to the budget skill rather than settling it as a pricing question.",
        "States that free-by-design is an argued legitimate posture rather than a failure to price, and notes that a full multi-track conference exists that charges nothing and requires no registration at all.",
        "Warns that charging 15 EUR pulls in accounting and tax obligations the free model currently carries none of.",
        "Notes that a published price is not reversible mid-sale without refunding whoever already paid, unlike the free posture.",
        "Computes the observed no-show rate from the numbers given - 112 of 180, roughly 38% - rather than asserting a generic rate.",
        "Does not recommend the refundable deposit as a proven fix."
      ]
    },
    {
      "id": 7,
      "prompt": "We run Cascade API Conf in Seattle - 700 seats, corporate $850, individual $420, student $120. Next year we're cloning it in Berlin, Sao Paulo and Bangalore, same two-day format, about 300 seats each. Give me the purchasing-power-adjusted price grid for all three cities. Also, our new marketing hire wants the corporate tier listed first on the page as an anchor, with individual positioned as the obvious middle choice. Does that work for conferences?",
      "expected_output": "An explicit refusal to invent a purchasing-power formula, each market's ladder rebuilt from its own cost and payer mix, the anchoring tactic rejected as unconfirmed for tickets, and the existing Seattle ratio checked against the published range.",
      "files": [],
      "expectations": [
        "States that regional and currency price parity for one format run in several countries has no established method, and declines to produce a purchasing-power formula as though it were a standard.",
        "Leaves the per-market price decision with the organizer rather than resolving it with an invented conversion.",
        "Rebuilds each market's floor from that market's own per-attendee cost and posture rather than converting the Seattle prices.",
        "Does not apply an exchange-rate or purchasing-power multiplier to the $850 / $420 / $120 figures to generate the three new grids.",
        "States that anchoring and decoy ordering is unconfirmed for event tickets and should not be imported from software pricing.",
        "Notes that published registration pages list personas in plain reading order rather than in an anchoring order.",
        "Asks for the payer mix in each market as the axis that sets each ladder's shape.",
        "Checks the existing Seattle top-to-floor ratio - roughly 7:1 from $850 to $120 - against the published range of about 1.7:1 to 6.5:1 and flags that it sits above it.",
        "Transposes ratios rather than amounts between markets.",
        "Sanity-checks each market's top rung against what an employer in that market approves without a purchase order.",
        "Requires each market's own ticket revenue target from its own budget before any price is set.",
        "Labels every new figure it produces as self-set rather than sourced."
      ]
    },
    {
      "id": 8,
      "prompt": "Brightpath (Series B, observability tooling) is running our first user conference - 600 attendees, Austin, two days. Marketing owns the budget line. Our VP wants to charge $1,200 because that's roughly what the big cloud-native conferences charge. We also want a 'Supporter' ticket at $2,200 that includes front-row reserved seating, a private dinner with our CTO, and a limited-edition jacket. About half our attendees are existing customers whose companies pay, the rest are individual practitioners we're trying to win over. Sign off on this?",
      "expected_output": "Approval withheld: the ladder rebuilt on the payer split rather than on vendor-run status, the $2,200 tier reclassified as a VIP upsell rather than a supporter tier, the $1,200 figure sent back to the budget target, and comps subtracted from the 600 seats.",
      "files": [],
      "expectations": [
        "States that the vendor-run versus community-run distinction bounds the price band but does not pick the ladder's shape.",
        "Builds the ladder from the stated payer split - employer-funded customers versus self-funding practitioners - rather than from the vendor-run status alone.",
        "Rejects the $2,200 'Supporter' ticket as described, on the grounds that it buys the buyer benefits and is therefore a VIP upsell rather than a supporter tier.",
        "Defines a supporter tier as a voluntary pay-more ticket whose premium visibly funds access for other attendees.",
        "States the promotion condition for a supporter tier: a named scholarship or aid program must already exist for the tier to point at.",
        "Notes that supporter-tier uptake is small, so its cash value is modest against the effort of running the program it funds.",
        "Confirms the commercial-price posture is legitimately available here, because a company-run event priced against marketing budgets meets its promotion condition.",
        "States that the commercial posture tops both value and effort so it never leads on efficiency, and names the sales and refund machinery it drags in.",
        "Requires the $1,200 figure be justified against the budget's ticket-revenue target rather than against what other conferences charge.",
        "Warns against copying a named conference's absolute ticket price and transposes ratios instead.",
        "Subtracts committed comps - customer invitees, speakers, staff, sponsor allotments - from the 600 seats before pricing.",
        "Does not approve the plan as submitted."
      ]
    },
    {
      "id": 9,
      "prompt": "Five weeks to Solstice Systems Conf. 250 paid seats, we've sold 91. Early bird ended three weeks ago at 190 EUR, regular is 240 EUR. The team's proposals are: (1) cut regular to 165 EUR immediately, (2) run a 48-hour flash code at 40% off this weekend, (3) add a 90 EUR 'last week' surcharge starting next Monday, which we never announced anywhere, (4) let the 15% group discount apply to any tier. Pick the ones to run.",
      "expected_output": "A refusal to diagnose the slow sale as a pricing failure, the unannounced surcharge and the flash code rejected, the mid-sale cut flagged for its refund consequence, the group discount restricted, and the pace read framed as a self-set measure.",
      "files": [],
      "expectations": [
        "Declines to treat the slow sale as a pricing failure by default, and names demand, marketing execution and price as the three candidate causes.",
        "Routes the diagnosis to the market-fit skill before any price is changed.",
        "Rejects the unannounced 90 EUR late surcharge because a price increase the buyer could not have seen coming was never published from the day tickets went on sale.",
        "States that the whole structure - every price, every date, every gate - should have been published at once when the sale opened.",
        "Flags that cutting the regular price to 165 EUR mid-sale leaves the 91 people who already paid 190 EUR or 240 EUR needing a decision, and does not treat the cut as free.",
        "States that a published price cannot be withdrawn mid-sale without refunding whoever already paid.",
        "Rejects the 48-hour flash code as a third public price point beyond the two-step ladder already published.",
        "Notes that extra discount steps read as pressure tactics and train every buyer to wait for the next one.",
        "Rejects applying the 15% group discount to any tier, restricting it to the standard tier and excluding the early and late tiers.",
        "Notes that a surcharge is a legitimate third phase only when it was announced in advance.",
        "Frames the 91-of-250 position against a self-set measure such as paid share of the revenue target by the gate date, rather than against an industry benchmark.",
        "States that ticket-ladder design has no industry benchmark to score against, so any pace measure here is self-set."
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "What should we charge for tickets to our 300-person DevOps conference?",
      "should_trigger": true
    },
    {
      "query": "Set up an early-bird tier for our Python conference",
      "should_trigger": true
    },
    {
      "query": "corporate vs individual vs student ticket prices",
      "should_trigger": true
    },
    {
      "query": "Should our conference be free or paid?",
      "should_trigger": true
    },
    {
      "query": "how much do people usually pay for a community tech conference ticket",
      "should_trigger": true
    },
    {
      "query": "We need a student rate but I don't want randos claiming it",
      "should_trigger": true
    },
    {
      "query": "Someone wants their money back three weeks before the event",
      "should_trigger": true
    },
    {
      "query": "Write our refund policy before tickets go on sale",
      "should_trigger": true
    },
    {
      "query": "Can a company buy 15 seats and pay by bank transfer?",
      "should_trigger": true
    },
    {
      "query": "Do we give a discount for bulk orders?",
      "should_trigger": true
    },
    {
      "query": "What's a fair price ladder for a two-day conference?",
      "should_trigger": true
    },
    {
      "query": "diversity tickets for people who can't afford to come",
      "should_trigger": true
    },
    {
      "query": "We want to give free passes to career changers without publishing a code",
      "should_trigger": true
    },
    {
      "query": "Our sponsors get 10 free passes each - how does that change what we charge everyone else?",
      "should_trigger": true
    },
    {
      "query": "how many seats can we actually sell once comps are out",
      "should_trigger": true
    },
    {
      "query": "Should we add a late-bird surcharge or just let the early price expire?",
      "should_trigger": true
    },
    {
      "query": "our tickets are free and I'm nervous about signing the catering contract",
      "should_trigger": true
    },
    {
      "query": "is charging 10 EUR worth the accounting headache",
      "should_trigger": true
    },
    {
      "query": "supporter tickets to fund our scholarship program",
      "should_trigger": true
    },
    {
      "query": "what should the early bird cut-off date be",
      "should_trigger": true
    },
    {
      "query": "I want a ticket tier that companies will expense",
      "should_trigger": true
    },
    {
      "query": "pricing for our first edition, 150 people, no track record",
      "should_trigger": true
    },
    {
      "query": "how do we invoice a corporate buyer for a block of seats",
      "should_trigger": true
    },
    {
      "query": "should students pay anything at all",
      "should_trigger": true
    },
    {
      "query": "we're thinking of three discount phases before the regular price",
      "should_trigger": true
    },
    {
      "query": "Can I just copy KubeCon's ticket prices for our 200-person event?",
      "should_trigger": true
    },
    {
      "query": "we sold out in four hours last year, should we charge more",
      "should_trigger": true
    },
    {
      "query": "can someone hand their ticket to a colleague if they can't make it?",
      "should_trigger": true
    },
    {
      "query": "Our attendees are all self-funding - what does that mean for the price?",
      "should_trigger": true
    },
    {
      "query": "How do I decide between free entry and a small fee?",
      "should_trigger": true
    },
    {
      "query": "what has to go on the registration page next to the price",
      "should_trigger": true
    },
    {
      "query": "define the tiers for our conference registration",
      "should_trigger": true
    },
    {
      "query": "unemployed developers asked if there's a reduced rate",
      "should_trigger": true
    },
    {
      "query": "We need 18,000 EUR from tickets - how do I split that across tiers?",
      "should_trigger": true
    },
    {
      "query": "cancellation and refund terms for a conference",
      "should_trigger": true
    },
    {
      "query": "hardship tickets",
      "should_trigger": true
    },
    {
      "query": "our CFO wants to know why we'd charge anything at all",
      "should_trigger": true
    },
    {
      "query": "help me write the ticket section of our event site",
      "should_trigger": true
    },
    {
      "query": "what top-to-floor ratio should our ticket types have",
      "should_trigger": true
    },
    {
      "query": "should the group discount apply to early bird too",
      "should_trigger": true
    },
    {
      "query": "an attendee's visa was refused and they want a refund after the deadline",
      "should_trigger": true
    },
    {
      "query": "we're moving from free to paid this year, how do we announce it",
      "should_trigger": true
    },
    {
      "query": "do we charge separately for the workshop day or bundle it into the pass?",
      "should_trigger": true
    },
    {
      "query": "I need a number for the student tier and a defensible reason for it",
      "should_trigger": true
    },
    {
      "query": "our event is free by design and sponsors cover everything - is that defensible?",
      "should_trigger": true
    },
    {
      "query": "how many price points is too many",
      "should_trigger": true
    },
    {
      "query": "structure the ticket types for a 500-person conference",
      "should_trigger": true
    },
    {
      "query": "we want it cheap enough that indie devs come but high enough to cover the food",
      "should_trigger": true
    },
    {
      "query": "who should get in for free at our conference and how does that hit our numbers?",
      "should_trigger": true
    },
    {
      "query": "we want to keep prices flat year over year for a recurring conference",
      "should_trigger": true
    },
    {
      "query": "Build the sponsorship rate card for our conference",
      "should_trigger": false
    },
    {
      "query": "How much should a gold sponsor tier cost?",
      "should_trigger": false
    },
    {
      "query": "What do sponsors actually get for their money?",
      "should_trigger": false
    },
    {
      "query": "Build the full P&L for our conference",
      "should_trigger": false
    },
    {
      "query": "Model our fixed versus per-head event costs",
      "should_trigger": false
    },
    {
      "query": "We have a 40% no-show rate - how do we fix it?",
      "should_trigger": false
    },
    {
      "query": "What overbooking ratio should we use against the room capacity?",
      "should_trigger": false
    },
    {
      "query": "Is there real demand for this event concept at all?",
      "should_trigger": false
    },
    {
      "query": "Which channels should we use to sell tickets?",
      "should_trigger": false
    },
    {
      "query": "Write the email sequence that goes to registered attendees",
      "should_trigger": false
    },
    {
      "query": "Build the registration page and the site around it",
      "should_trigger": false
    },
    {
      "query": "Should we provide childcare and travel grants for attendees?",
      "should_trigger": false
    },
    {
      "query": "How much should first prize at our hackathon be?",
      "should_trigger": false
    },
    {
      "query": "Negotiate the venue rental rate down",
      "should_trigger": false
    },
    {
      "query": "Get quotes from three caterers and compare them",
      "should_trigger": false
    },
    {
      "query": "Turn the signed sponsorship into a term sheet",
      "should_trigger": false
    },
    {
      "query": "What's our cancellation insurance exposure if the event doesn't happen?",
      "should_trigger": false
    },
    {
      "query": "Design the pricing page for our SaaS product",
      "should_trigger": false
    },
    {
      "query": "How should we price our developer tool's usage-based plans?",
      "should_trigger": false
    },
    {
      "query": "Free tier strategy for our API product",
      "should_trigger": false
    },
    {
      "query": "Set up Stripe checkout on our website",
      "should_trigger": false
    },
    {
      "query": "Which ticketing platform has the lowest per-ticket fees?",
      "should_trigger": false
    },
    {
      "query": "Write our event's code of conduct",
      "should_trigger": false
    },
    {
      "query": "Design the badge pickup and check-in desk flow",
      "should_trigger": false
    },
    {
      "query": "How do we lay the accepted talks across three tracks?",
      "should_trigger": false
    },
    {
      "query": "Pick the date for next year's conference",
      "should_trigger": false
    },
    {
      "query": "How many volunteers do we need and what do they do on the day?",
      "should_trigger": false
    },
    {
      "query": "Write the call for papers for our conference",
      "should_trigger": false
    },
    {
      "query": "Run the organizing team retrospective after the event",
      "should_trigger": false
    },
    {
      "query": "What questions go in the post-event attendee survey?",
      "should_trigger": false
    },
    {
      "query": "How do we price exhibitor booths on the expo floor?",
      "should_trigger": false
    },
    {
      "query": "Should we run a user conference or a multi-city roadshow?",
      "should_trigger": false
    },
    {
      "query": "What's the ROI of our developer conference and who should fund it?",
      "should_trigger": false
    },
    {
      "query": "How do we run structured 1:1 meetings between buyers and vendors?",
      "should_trigger": false
    },
    {
      "query": "Plan the speaker dinner the night before",
      "should_trigger": false
    },
    {
      "query": "What do we pay our keynote speakers?",
      "should_trigger": false
    },
    {
      "query": "What does a media partner get in exchange for promoting us?",
      "should_trigger": false
    },
    {
      "query": "Write the prospectus PDF we send to prospective sponsors",
      "should_trigger": false
    },
    {
      "query": "How do we run the stream for the remote half of the audience?",
      "should_trigger": false
    },
    {
      "query": "Design how the hands-on workshop actually runs on the day",
      "should_trigger": false
    },
    {
      "query": "Set the judging rubric for our hackathon projects",
      "should_trigger": false
    },
    {
      "query": "How do we handle escort and protocol for a VIP guest?",
      "should_trigger": false
    },
    {
      "query": "Build the work-back timeline from doors-open",
      "should_trigger": false
    },
    {
      "query": "Write the minute-by-minute run of show for day one",
      "should_trigger": false
    },
    {
      "query": "How do we grow from 200 to 500 attendees next year?",
      "should_trigger": false
    },
    {
      "query": "Price our consulting retainer for event production clients",
      "should_trigger": false
    },
    {
      "query": "Draft the press release announcing our conference",
      "should_trigger": false
    },
    {
      "query": "What should our conference stand for against the other three in this city?",
      "should_trigger": false
    },
    {
      "query": "How do we vet third-party side events around our conference?",
      "should_trigger": false
    },
    {
      "query": "Choose the AV vendor and camera setup for recording the talks",
      "should_trigger": false
    }
  ]
}

# Access rungs and group mechanics

How the three disclosure rungs actually work on real registration pages, and what each one costs the organizer to run.

## Contents

- The three rungs compared
- Published persona tier: mechanics
- Discretionary scholarship: application mechanics
- Eligibility framing
- Group orders and invoicing
- What this rung structure does not cover

## The three rungs compared

|                  | Published persona tier | Date-or-volume gate           | Discretionary scholarship         |
| ---------------- | ---------------------- | ----------------------------- | --------------------------------- |
| Price visible    | Yes                    | Yes                           | Usually not                       |
| Gate             | Self-identification    | Calendar date or ticket count | Human review of an application    |
| Buyer effort     | Checkout               | Checkout                      | Write and wait                    |
| Organizer effort | One-time               | One-time                      | Standing, per application         |
| Reaches          | A named category       | Everyone, earlier             | Need a category definition misses |

They combine. Several events run an informal student discount code _and_ a broader hardship route, because a fixed student price excludes the unemployed, the career-changer, and the non-student in difficulty.

## Published persona tier: mechanics

- The tier is a **price**, not a benefit change: the same seat, the same access, a different amount by payer type.
- The gate is the honor system, occasionally an institutional email domain check, and nothing beyond that.
- Name the tier after who pays, not after who deserves it - "Corporate", "Business", "Individual", "Personal", "Student", "Education" are the labels real ladders use, and each reads as a self-description a buyer can pick without justifying it.
- Registration pages list personas in a plain reading order, not in an anchoring order (highest tier first, decoy in the middle). Do not import anchoring advice from software pricing here; it is unconfirmed for tickets.

## Discretionary scholarship: application mechanics

Community-conference pages offering a reduced or free ticket for students, unemployed, or underrepresented attendees gate it behind an application, never a self-service checkbox. In rough order of organizer effort:

- **Discount code on request by email** (devopsdays Boise 2019/2020) - unpriced; the organizer replies with a code. Lowest overhead, no written criteria.
- **Flat scholarship price, email with motivation** (devopsdays Amsterdam 2024: €50; 2023: €20 two-day / €30 conference-plus-workshop) - a published price, but the route to it is an email an organizer reads.
- **Unpriced "significant discount", email application** (devopsdays Prague 2023) - deliberately vague on amount, which keeps the decision with the reviewer.
- **Form with a stated window and named reviewers** (devopsdays Austin 2023) - a Google Form open until the day before the event, routed to three named local organizers who "respond as quickly as we're able."
- **Two named routes** (devopsdays Halifax 2026) - "inclusive access tickets" for financial hardship, plus a separate students and underrepresented-communities voucher, both by email request.
- **Formal scholarship program with a reviewer panel** (devopsdays Auckland 2019) - a complimentary pass, possible travel and accommodation support, a panel scoring need and impact, a published eligibility list, and an application window that opens and closes on a schedule. The highest-effort, most targeted end of the rung: closer to a small grants program than a ticket tier.

Write these before publishing the route:

- who reads applications
- how fast they promise to answer
- whether the window closes
- what the applicant receives: a code, a free pass, or a price

An unanswered application is worse than no route at all - the applicant has disclosed hardship to a silent inbox.

## Eligibility framing

- Auckland's published list - LGBTQ, women, people of colour, disabled people, students - is the one example of an explicit eligibility enumeration. Other pages frame on need ("financial hardship") rather than identity, or combine a need route with a separate underrepresentation route.
- Framing on need reaches cases an identity list omits. Framing on identity is legible and reduces reviewer judgment. Several events publish both, separately, rather than merging them into one paragraph.
- Do not copy an eligibility list across jurisdictions without checking it locally. How these categories interact with local law is a local question, and this skill does not give legal advice.

## Group orders and invoicing

- **Threshold and percentage**: published thresholds run from five tickets (15% off, one community event) to a 5-9 / 10+ step at 5% and 10% (GopherCon). Pick one threshold and one percentage; a multi-step table for an event selling a few hundred seats is machinery with nothing to do.
- **Same-order requirement**: the published wording is "in the same order". Without it, a group discount becomes a code that circulates.
- **Tier exclusion**: GopherCon applies group discounts only to its standard tier, never to early or late tiers. Say which tiers the discount may touch, on the page, before anyone asks.
- **Invoicing is a rail, not a rate**: a company that cannot pay by card at checkout buys nothing without it. Offer it at full price, on request, and only if an entity can actually issue the invoice and reconcile the payment. An event that cannot process money in the form its buyers need has an upstream problem - one organizer guide states plainly that discovering this late has rescheduled and cancelled events.

## What this rung structure does not cover

- **Regional or currency price parity** for one event run in several countries: no established method. Say so rather than inventing a purchasing-power formula.
- **Comp allocation as a share of capacity**: practice subtracts sponsor, speaker, organizer, and volunteer comps from expected sales, but sets no percentage. Count the seats you have actually committed.
- **Deposit-hold tickets** (a refundable deposit returned on attendance): untested for developer events specifically. Eventtia's 2024 managed-conference data reports a $3 refundable deposit cutting a previously-free event's no-show rate from 38% to 14% - general-conference evidence, not developer-event-specific.

# Published ticket ladders: real prices and dates

Every figure here belongs to one named event, on one date, in one market. Each event's own dates are given inline. Transpose the **ratios**, never an amount, across scale, region, or year.

## Contents

- Persona ladders (two full, published examples)
- Gating mechanics (date, ceiling-only, volume)
- Group and bulk mechanics
- Cross-subsidy tiers
- The free-by-design case
- How to transpose

## Persona ladders

**PyCon US 2026** (`us.pycon.org/2026/attend/information/`):

| Tier               | Price |
| ------------------ | ----- |
| Corporate          | $899  |
| Individual         | $469  |
| Student / academic | $139  |

Ratios: corporate:individual ≈ 1.9:1, individual:student ≈ 3.4:1, corporate:student ≈ 6.5:1. Tutorials are priced separately at $150 each - an add-on, not a rung of the ladder.

**EuroPython 2026** (`ep2026.europython.eu/tickets/`): three pass types (tutorial-only, conference-only, combined), each split Business / Personal / Education. Conference-only, for example: Business €500 + VAT, Personal €300, Education €135.

Ratios run lower than PyCon's: business:personal ≈ 1.67-1.78:1, personal:education ≈ 2.1-2.2:1, business:education ≈ 3.7-3.8:1.

The same three-way payer split (employer-funded, self-funded, student or educator) recurs under different label words with materially different ratios. Across these two events the top-to-floor range is roughly **1.7:1 to 6.5:1**, so report the range, not a single number, since one number would just be an average of two events.

## Gating mechanics

Three distinct mechanics exist, and none of these events runs more than two public price points in its time ladder. Where a third phase exists, it is a surcharge, not a third discount step.

- **Date-gated, surcharge form** - EuroPython 2026: regular price until 26 June 2026, then a "late-bird" step up (conference-only Personal €300 → €450, a 1.5x step). The price rises on a published date rather than a discount quietly expiring.
- **Date-gated, two-phase discount form** - devopsdays Austin 2023: Early Bird 15 Feb – 14 Mar, General Admission 15 Mar – 3 May. Prices sat behind a ticketing widget and were not published on the page; the two-phase date structure is the sourced part.
- **Ceiling-only disclosure** - devopsdays Minneapolis 2024 published one number: "before the price goes up to $299 on April 16th". The post-deadline price is public, the early price is not. A legitimate minimal shape: one announced date, one announced ceiling.
- **Volume-gated** - PyCon US: "the first 800 tickets sell with an Early Bird discount, and go fast" (PyCon 2016 registration post). The gate is a ticket count, not a calendar date, which caps the discount's cost instead of its duration.

## Group and bulk mechanics

- **devopsdays Halifax 2026** (`content/events/2026-halifax/registration.md`): "Groups of 5 or more get 15% off in the same order" - a flat percentage, self-service, stacked on whatever base price is active.
- **GopherCon** (gophercon.com): 5% off for 5-9 tickets, 10% off for 10 or more, applied **only to standard general-admission tickets** - explicitly not to the "Early" or "It's Go Time (Late)" tiers. This exclusion is the mechanic worth copying: it stops one seat being discounted twice.
- **devopsdays Amsterdam 2023-2024**: pay by invoice on request for bulk company orders. This is a **payment rail, not a discount** - full price, different rail. Sourced pages describe it as solving a corporate procurement problem, never as a price reduction.

## Cross-subsidy tiers

- **RailsConf** (railsconf.org): "Supporter Tickets… priced at a premium to help fund our programs and operations, including the Scholars and Guides program" - a voluntary pay-more tier whose premium is earmarked for a named accessibility program, distinct from a VIP upsell that buys the buyer something.
- **PyCon US**: the same cross-subsidy achieved through sponsorship rather than a ticket tier - a needs-based financial aid program (average grant roughly $700 in 2017) with reduced-rate tickets reserved for aid recipients, funded by sponsorship revenue.
- **PyCon US price commitment** (PyCon blog, 2016): "not only have we kept our Individual and Corporate prices stable as the conference has moved into larger and more expensive venues, but we have slashed our Student ticket prices by more than 40% over five years." The sourced counter-example to "scaling forces price increases" - prices held or cut deliberately, funded by sponsorship.
- **XOXO 2024** (xoxofest.com/guide/inclusion): pass price cut from $500 to $250 by shortening the program, framed as "a fair compromise" for "a small, independent festival" after losing the sponsorship that had funded roughly 20% free passes in 2018. Prices can move **down** as an event scales back.

## The free-by-design case

**FOSDEM** (`fosdem.org/2026/practical/`): "FOSDEM is free to attend. There is no registration. Just turn up!" - no ticket, no badge requirement, no registration step. Funded by sponsor contributions and on-site merchandise; donations accepted, never gating entry.

This is a full multi-track conference that could charge and deliberately does not. It is not the same as a free hackathon, where the format has no ticket-revenue line to begin with - FOSDEM is the sourced case of a priced model being available and refused.

## Nominal-fee rule

One organizer guide (devopsdays, `content/page/organizing.md`, "Ticket Pricing" → "Minimal Cost") publishes an actual rule rather than a price: charge **10-20% of what a typical commercial tech-conference ticket costs in the region**. The ticket's job is financial-risk spreading rather than funding. The same guide targets 75-80%+ of the budget from sponsorship (its budgeting section says "up to 75%", its Good/Better/Best targets say 80%+).

It also names the cost side: charging anything pulls in accounting and tax overhead, and the guide's own cross-border example is an organizing company needing a tax ID in another country, at a cost that "would take a significant portion of the event money."

## How to transpose

1. Pick the comparable whose **payer mix** matches yours, not whose city or headcount matches.
2. Set your floor price from your own per-attendee cost and your posture, never from the comparable's floor.
3. Apply the comparable's **ratio** to get the next rung up, then sanity-check the top rung against what an employer in your market approves without a purchase order.
4. Where two comparables disagree by 2x on a ratio - as PyCon and EuroPython do on corporate-to-student - pick the one whose funding model matches yours and say which you picked.
5. Re-read the source page before reusing any figure here. Registration pages change every edition. Each number above is a snapshot, not a standing fact.

# Refund and transfer policy: four examples and a checklist

Treat the four worked examples below as examples, never as an industry norm: community technical events have no single standard refund, transfer, or cancellation practice. They share one structural trait - see "What they agree on" - but every other term is answered differently by every one of them. Where the checklist below asks a question the examples do not answer, the organizer decides - do not present a default as though it were a standard.

## Contents

- The four worked policies
- What they agree on
- Decision checklist
- Writing the published wording

## The four worked policies

**PyCon US 2026** (`us.pycon.org/2026/attend/information/`):

- Refunds available until **1 May 2026**, minus a **$50** administrative fee.
- The fee drops to **$25 for student tickets** - the fee itself is tiered to the ticket, not flat across the ladder.
- The fee is **waived entirely** for health and visa reasons.
- **Transfers within the same organization**: allowed at any time.
- **Transfers to a different person outside the organization**: allowed before 1 May 2026; a **$50 fee applies if the two tickets' prices differ**, which is the mechanism that stops a corporate ticket being resold as an individual one.

**EuroPython 2026** (`ep2026.europython.eu/tickets/`):

- Full refund until **7 June 2026**. No administrative fee stated.
- No transfer policy stated on the page at all - silence, not a prohibition.

**RustConf 2026** (`rustconf.com/faq`):

- Refunds available until **23 August 2026** - 15 days before the 8-11 September event - full refund including processing fees.
- A separate, later deadline of **5 September 2026** applies to visa or travel issues only, with the same full-refund terms: hardship gets an extended window instead of a fee waiver.
- Requests received from **24 August 2026** onward: no refund at all, not a reduced one.
- Tickets are **generally non-transferable**; the organizer reviews a transfer only case by case, on request, for "special circumstances."

**KubeCon + CloudNativeCon North America 2026** (`events.linuxfoundation.org/kubecon-cloudnativecon-north-america/register/`):

- Refunds available until **26 October 2026** - two weeks before the 9-12 November event.
- A flat **6% processing fee** is deducted from every refund issued in that window - there is no fee-free period, unlike PyCon US or RustConf.
- Refunds are credited only to the original payment card, 7-10 business days after cancellation.
- **Transfers ("Transfer Registration")** are free, self-service, and offered as the default alternative to canceling: attendees sign into their registration and hand the ticket to another named person, no fee and no case-by-case review.

## What they agree on

- **A single dated cutoff.** All four events pick a calendar date (RustConf effectively two: a standard one, and a separate later one carved out for visa and travel issues) after which the ordinary refund terms stop. None of the four grades the refund by how many days out the request lands - there is no sliding scale anywhere in the sample.

That is the only point all four agree on. Everything else is answered differently by every one of them:

- **Fee on refund**: PyCon US and KubeCon both retain one ($50, or $25 for students; 6% of price). EuroPython states none. RustConf charges nothing before its cutoff and refunds nothing after it - the cutoff itself does the job a fee does elsewhere.
- **Hardship accommodation**: PyCon US waives its fee for health and visa reasons. RustConf gives visa and travel issues a later deadline instead of a fee waiver - a different mechanism aimed at a similar risk. EuroPython and KubeCon make no hardship exception at all.
- **Transfers**: KubeCon actively offers a free, self-service transfer as the default alternative to a refund. PyCon US allows transfer with conditions (free within an organization, a fee if the two ticket prices differ). RustConf calls tickets "generally non-transferable" and handles exceptions case by case. EuroPython says nothing about transfers at all.

Four events is still not a distribution large enough to call anything but the dated-cutoff point a default. Treat the rest as a demonstrated range of options, not a ranked list of which is more common.

## Decision checklist

Answer each of these explicitly before tickets go on sale. Record the answer even when it is "none" - a stated silence is a decision; an unstated one is a surprise.

1. **Refund deadline**: which date, and what does it line up with - the catering headcount, the badge print run, the venue's own cancellation curve? All four sourced events use a single dated line, not a formula based on days-out; the cutoffs in the sample sit anywhere from two weeks (KubeCon) to roughly 15 days (RustConf) to a month or more (PyCon US, EuroPython) before the event.
2. **Administrative fee**: retained or not, flat or tiered by ticket price, or a flat percentage of price (KubeCon's 6%) instead of a flat amount.
3. **Hardship waiver**: which reasons waive the fee entirely and who decides, or - as RustConf does it - which reasons get a later deadline instead of a waiver. PyCon US names health and visa refusal; RustConf names visa and travel issues.
4. **Post-deadline requests**: refused outright (RustConf, after its cutoff), or converted into something. KubeCon converts a late cancellation into a free transfer instead; PyCon US and EuroPython offer no credit at all. None of the four sourced events offers a credit toward the next edition - if you do, you invented it, so say so.
5. **Transfer to another person**: allowed, and until when. The sourced range runs from actively encouraged and free (KubeCon) to allowed with an anti-arbitrage fee (PyCon US) to generally disallowed with case-by-case exceptions (RustConf) to unstated (EuroPython). Note the price-difference case explicitly, or a top-tier ticket becomes a resale of a cheaper one.
6. **Transfer within a company**: often looser than person-to-person, since the buyer has not changed. PyCon US allows it at any time.
7. **Scholarship and comp tickets**: transferable or not. A need-gated ticket transferred to someone else defeats the review it went through. Say so on the application page, not afterwards.
8. **Organizer cancellation**: what attendees get if the event does not happen. This is a different question from an attendee changing their mind, and it interacts with contracts and insurance - the term-sheet and risk work lives in `samber/dev-event-organizer-skills@event-sponsor-agreement` and `samber/dev-event-organizer-skills@event-risk-management`, and neither this reference nor this skill gives legal advice.
9. **Where the policy is published**: on the registration page beside the price, not in a confirmation email. A refund policy the buyer sees only after paying is a policy they will argue with.

## Writing the published wording

- One paragraph, one date, one fee, plainly stated. All four sourced policies fit in a few lines each.
- Give the deadline as a calendar date, never a relative window like "30 days before" - unless, like RustConf, the policy genuinely needs two calendar-anchored deadlines for two different causes, in which case state each on its own line.
- State the fee as an amount or a percentage (KubeCon's 6% of price) and name the cases that waive it or get their own deadline, so no one has to ask whether their case counts.
- If transfers are not offered, write that they are not offered. Silence reads as "ask us", and every ask becomes a case-by-case decision an organizer makes under pressure the week of the event.

---
name: event-ticket-pricing
description: Set attendee ticket prices for a technical event - free, nominal or priced against the funding model, comps subtracted from capacity, a ladder split by who pays (employer-funded, self-funded, student), gating on a date or a ticket count, the need-gated scholarship rung, group and invoicing mechanics, and the refund and transfer policy written before tickets go on sale. Use whenever the user mentions ticket prices, early-bird tiers, free versus paid entry, student, diversity or group rates, invoicing an employer, or a ticket refund policy - even if they never say "pricing". Do NOT use for sponsor tiers - use samber/dev-event-organizer-skills@event-sponsor-pricing; no-shows are samber/dev-event-organizer-skills@event-no-show-management.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.0"
---

# Event Ticket Pricing

You price attendee tickets. This covers:

- whether to charge at all
- how many public price points
- which personas get their own price
- what gates a discount
- who gets in for free or nearly free
- what happens when someone asks for their money back

`samber/dev-event-organizer-skills@event-budget` owns the revenue target this ladder has to hit upstream, and `samber/dev-event-organizer-skills@event-sponsor-pricing` owns the sponsorship share that cross-subsidizes it. You set attendee numbers and policy. You do not:

- build the budget
- price sponsor tiers
- run acquisition campaigns
- design no-show mechanics

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 signals like these:

- an event that already sells out
- a free-to-attend funding model decided upstream
- a volunteer team with no accounting capacity
- an audience that is overwhelmingly self-funding

Each one overturns a default rung. Axis lines carry no currency amounts.

The real published prices, each with its event and date, live in [references/published-ticket-ladders.md](references/published-ticket-ladders.md). Treat them as ratios to transpose, never as figures to copy across scale, market, or year.

## Interview

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

1. Does a budget exist, with a total expense figure and the share it assigns to ticket revenue? If not, stop and run `samber/dev-event-organizer-skills@event-budget` first - a ladder built without a target under-prices tier by tier.
2. Who pays for a ticket in this audience: an employer's training or travel budget, the attendee's own wallet, or a mix? Ask for the rough split. This decides the ladder's shape before any number.
3. What is the room's paid capacity, and how many seats are already committed as comps - sponsor allotments per their signed tiers, speakers, organizers, volunteers? Comps come off capacity before pricing, not after.
4. Is the event free to attend by design, or is charging genuinely open? A free-to-attend funding model is a budget decision, not a pricing one - say which was already made and by whom.
5. Which comparable events' registration pages are in hand - same community, same region, same scale, with the date you read them? Numbers with dates, not memories of numbers.
6. When must ticket revenue land? A hard date promotes date-gated mechanics and a shorter ladder. No deadline pressure leaves room for the slower access rungs.
7. Is this a one-off edition or one year of a recurring event? A recurring event promotes price stability and a published community-price commitment over squeezing this edition.
8. What is the effort ceiling - organizer hours during the sale, anyone who can review applications, an entity that can issue invoices and handle tax? An organizer with no invoicing capacity deletes the invoice rung outright.
9. Who runs the event: an independent community group, or a vendor or company?
10. Is accessibility a stated positioning claim the event has to be able to defend?

## Who pays for the ticket

The axis that changes the pricing work is who pays for the ticket:

- an employer's budget
- the attendee's own money
- an institution's

Every sourced published ladder encodes this split, under different label words: corporate/individual/student at one conference, business/personal/education at another. Ask Q2 and say which mix the ladder assumes.

The community-run versus vendor-run pole this collection branches on elsewhere still bounds the _price band_ - a vendor conference charging against marketing budgets sits an order of magnitude above a community event - but it does not pick the ladder's shape. Community and vendor events alike split by payer.

## Free, nominal, or priced

The posture decision, made against the funding model, before any ladder exists. Ranking (default, not a law - re-rank against Q1, Q4, Q7):

- effort (price-setting work plus the per-order handling each posture demands during the sale): `commercial price > community price > nominal fee > free-by-design`
- value (budget covered plus headcount certainty bought against committed venue and catering spend): `commercial price > community price > nominal fee > free-by-design`
- compliance cost (what charging obliges the organizer to register and declare, and how reversible the posture stays once prices are public): `commercial price == community price == nominal fee > free-by-design`
- efficiency: `nominal fee > community price > commercial price`

**Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations.** Clean only by construction, and by-construction is never a pass.

- Value and effort share one blocking mechanism: the posture that covers more budget costs strictly more price-setting and per-order handling.
- That same mechanism blocks the three pairs against free-by-design too, since free-by-design loses on value rather than winning anything for free.
- The compliance axis ties the three priced postures, so it cannot rescue a pair: the effort half is already lost in every one.

The check catches nothing here. The efficiency line rests on the arguments below.

The three priced postures tie on compliance cost because the obligation is triggered by charging at all, not by the amount: any non-zero price pulls in accounting and tax handling, and a cross-border sale can require registering in another jurisdiction. Free-by-design sits at the floor as the only posture raising no tax, invoicing, or refund obligation, and the only one that stays reversible - a published price cannot be withdrawn mid-sale without refunding whoever already paid.

Free-by-design is deliberately absent from the efficiency line: a ratio of revenue to effort is false precision on a posture that raises no ticket revenue by construction. It is chosen upstream on funding-model grounds, not won on efficiency.

- **Nominal fee** - the efficiency default: a token price, roughly a tenth to a fifth of what a commercial tech conference in the same region charges. Its job is not funding but risk-spreading: a paid registration converts an unpaid RSVP into a headcount you can commit catering and venue capacity against. It buys most of that certainty for a fraction of the pricing work, which is what puts it first on efficiency - but it carries the full compliance cost of any priced posture, so it is never the free option it looks like.
- **Community price** - the default once ticket revenue has a real job in the budget: priced to cover per-attendee cost with sponsorship carrying the bulk of the budget (the published community-conference target is 75-80%+ from sponsorship). Pairs with an explicit, publicly stated community-price commitment on a recurring event (one large conference held individual and corporate prices flat across venue step-ups while cutting its student price by more than 40% over five years, funded by sponsorship cross-subsidy).
- **Commercial price** - the starved option: tops value and tops effort, so efficiency never leads with it. It requires a program, a brand, and an audience buying on an employer's budget, plus the sales and refund machinery that comes with real money. **Promotion condition, keyed to Q9**: a vendor or company-run event priced against marketing budgets, or a community event that sold out fast at the community price with demand visibly unmet - a read owned by `samber/dev-event-organizer-skills@event-market-fit`, not re-derived here.
- **Free-by-design** - an argued legitimate posture, not a failure to price: a full multi-track conference can be free to attend with no registration at all, funded entirely by sponsorship and merchandise (one such conference states plainly that there is no ticket and no registration step). Once this is the funding model, every rung in the next menu collapses to nothing. Free tickets also carry a consequence this skill does not solve - the no-show rate on a seat nobody paid for. Hand it to `samber/dev-event-organizer-skills@event-no-show-management` rather than answering it with a price.

If the format has no ticket-revenue line at all - a free hackathon, where sponsorship is close to 100% of funding by construction rather than by target, delete the priced postures rather than ranking them, and return to `samber/dev-event-organizer-skills@event-budget`.

## Access architecture

Three disclosure rungs appear on real registration pages, and they are complementary, not competing - real events combine two or three. Ranking (default, not a law - re-rank against Q2, Q6, Q8):

- effort (setup, plus the standing work each demands during the sale): `discretionary scholarship > published persona tier > date-or-volume gate`
- value (revenue captured plus attendees reached who otherwise could not come): `published persona tier > discretionary scholarship > date-or-volume gate`
- efficiency: `published persona tier > date-or-volume gate > discretionary scholarship`

- **Published persona tier** - the default and the largest single lever: a fixed price per payer type, listed publicly, bought self-service with no application. Published top-to-floor ratios run roughly 1.7:1 to 6.5:1 across the two events with full ladders - report the range, never one number, and transpose the ratio rather than the amount. The only gate is self-identification, sometimes an institutional email check.
- **Date-or-volume gate** - near-zero effort, configured once: either a calendar date that moves the price, or a first-N-tickets allocation. Three mechanics are all real - a date that ends an early price, a date that adds a late surcharge on top of the regular price, and a volume-gated early-bird capped at a ticket count. Its second payoff is a forecasting checkpoint the sale can be read against, which belongs to `samber/dev-event-organizer-skills@event-market-fit`; react to that read here, do not re-derive it.
- **Discretionary scholarship** - the starved option: tops effort (every application is read and answered by a human) and carries real access value that no fixed category definition reaches - the unemployed, career-changers, and anyone in hardship who is not a student. Practice gates it behind an email or a form, reviewed by organizers, and frequently leaves the price unpublished; the most developed version runs a scored reviewer panel against a stated eligibility list and an application window. **Promotion condition, keyed to Q8 or Q10**: the organizer can staff the review, or accessibility is a stated positioning claim the event has to be able to defend. Never present it as free - it is organizer labor a published tier does not cost.

On a free-by-design event, delete all three rather than ranking them. Design details, application copy, and worked examples for each rung are in [references/access-rungs-and-group-mechanics.md](references/access-rungs-and-group-mechanics.md).

## Bulk and cross-subsidy mechanics

What sits on top of the ladder once its shape is fixed. Ranking (default, not a law - re-rank against Q2, Q8):

- effort (setup plus per-order handling during the sale): `supporter tier > pay-by-invoice rail > flat group discount`
- value (orders unlocked or enlarged, and programs funded): `pay-by-invoice rail > flat group discount > supporter tier`
- efficiency: `flat group discount > pay-by-invoice rail > supporter tier`

- **Flat group discount** - the default: one published percentage off for a minimum head count in a single order, self-service, no approval step (one community event gives 15% off for five or more in one order; a larger conference steps 5% for five to nine and 10% for ten or more, and applies it only to its standard tier, never stacked on the early or late tiers). Copy that exclusion: a group discount stacked on an early-bird price discounts the same seat twice.
- **Pay-by-invoice rail** - highest value, because it unlocks orders that otherwise never happen: a company that cannot pay via a card checkout buys nothing at all. It is not a discount and must never be described as one (published practice offers invoicing on request for bulk corporate orders at full price). It costs real per-order handling and requires an entity that can invoice. Delete this rung outright when the organizer has no such capacity - an event that cannot process money in the required form has a payment-handling problem, not a pricing one, and that belongs upstream.
- **Supporter tier** - the starved option: a voluntary pay-more ticket whose premium visibly funds accessibility for others (one conference priced a supporter ticket at a premium explicitly to fund its scholars program). Uptake is small, so the cash value is modest against the effort of running the program it funds. Promotion condition: a named scholarship or aid program already exists for the tier to point at, which makes it a positioning asset as much as a revenue line.

Sponsorship cross-subsidy is the other real way accessibility gets funded, but it is set in `samber/dev-event-organizer-skills@event-sponsor-pricing`, not here - this skill only spends what that ladder raised.

## Workflow

1. Run the interview. Fix the payer mix, the posture, the capacity, and the constraints.
2. **Take the revenue target from the budget, never from the ladder.** Total expenses minus the sponsorship share is what tickets must raise. If that number does not exist yet, stop and run `samber/dev-event-organizer-skills@event-budget`.
3. **Subtract comps from capacity before pricing.** Count the actual committed seats - sponsor allotments from their signed tiers, speakers, organizers, volunteers - and price against the paid seats that remain (published checkpoint math is expressed as expected sales _minus_ those comps). No budgeting rule sets comps as a percentage of capacity; count them from the agreements you hold and say so, rather than adopting a fabricated ratio.
4. **Pick the posture** from the free/nominal/priced menu. Say which funding model it assumes and which upstream decision fixed it.
5. **Design the persona ladder**: pick the payer types from Q2 and set the ratios, carrying across the published ranges from the reference rather than copying prices. Keep the public price points to two per persona at most, since no published event runs more than two public price points in its time ladder.
6. **Set the date or volume gate**: one announced step, dated on the calendar and published from the day tickets go on sale. Decide explicitly whether the step is a discount that expires or a surcharge that lands, since the sourced events do both, and never announce a price increase the buyer could not have seen coming.
7. **Add the access rungs** the architecture menu selected - a published student or education price, a discretionary scholarship route, or both. Write the application mechanic and the reviewer before publishing the route, not after the first request arrives.
8. **Layer the bulk mechanics**: the group threshold and percentage, which tiers it may stack on, and whether invoicing is offered.
9. **Write the refund and transfer policy before the first ticket sells.** Fix a refund deadline, whether an administrative fee is retained and whether it is waived for hardship categories, and whether tickets transfer to another person, to another company, or not at all. Four events' policies are sourced in [references/refund-and-transfer-policy.md](references/refund-and-transfer-policy.md) - treat that reference as four worked examples plus a decision checklist, never as an industry norm beyond the one point they share (a single dated cutoff, not a graduated schedule), and make the organizer decide every other line rather than inheriting a default nobody chose.
10. **Publish the whole structure at once**: every price, every date, every gate. Validate it with the user, section by section:
    - target
    - ladder
    - gates
    - access rungs
    - bulk mechanics
    - refund policy

    Then hand acquisition to `samber/dev-event-organizer-skills@event-marketing-plan`.

If your harness has persistent memory, record:

- the revenue target and the arithmetic behind it
- the final ladder with its ratios
- the gate dates
- the refund policy as published
- how each tier actually sold, after the event

Next edition's pricing starts from that record instead of a blank page.

## What not to invent

Say these out loud when the question comes up rather than inventing an answer:

- **Refund, transfer, and cancellation norms** have no industry standard for community technical events beyond a single dated cutoff, which all four sourced events share. Present the four worked policies in the reference as examples, not as a standard, on every other term (fee, hardship handling, transferability).
- **Regional and currency price parity** for a format run in several countries has no established method. Say so and let the organizer decide.
- **Comp allocation as a percentage of capacity** has no budgeting rule behind it. Count committed comps from the agreements instead.
- **Deposit-hold tickets** - charging a refundable deposit returned on attendance - remain untested as a developer-event pricing lever specifically. One cross-industry data point exists (Eventtia's 2024 managed-conference data: a $3 refundable deposit cut a previously-free event's no-show rate from 38% to 14%), general-conference rather than developer-event evidence. If the organizer raises them, treat it as an idea with adjacent-industry support and route the underlying no-show concern to `samber/dev-event-organizer-skills@event-no-show-management`.

## Failure modes

- **Building the ladder before the budget target exists.** Each price looks reasonable against a comp while the ladder sums below what the event needs. Target first, allocation second.
- **More than two public price points per persona.** A third phase only works as a late surcharge, never as a third discount step. Extra steps read as pressure tactics and make every buyer wait for the next one.
- **Publishing the scholarship as a priced tier.** A need-gated ticket is application-reviewed and often unpriced on purpose; listing it as a cheap public tier turns a reviewed decision into a self-service checkbox and invites exactly the buyers it was not for.
- **Inventing a refund policy instead of deciding one.** A policy inherited from a template nobody read is discovered by the first person who asks for their money back, in public. Decide the deadline, the fee, the hardship waiver, and the transfer rule explicitly.
- **Copying a vendor-conference price at community scale.** A commercial conference's ticket can exceed a community event's entire ticket-revenue target. Transpose ratios - top-to-floor, group percentages - never amounts.
- **Free tickets bought and not used.** Pricing does not fix no-shows; a nominal fee reduces the exposure but does not solve it. Route to `samber/dev-event-organizer-skills@event-no-show-management`.
- **Calling the invoice rail a discount.** It changes the payment method, not the price. Discounting it too hands corporate buyers - the segment paying the top price - a second reduction for a problem that was never about money.
- **Stacking the group discount on an early-bird price.** Standard practice excludes the early and late tiers from group discounts precisely to stop the same seat being discounted twice.
- **Reading a slow sale as a pricing failure by default.** Slow sales can be demand, marketing execution, or price. `samber/dev-event-organizer-skills@event-market-fit` separates the three; act on the pricing side only once it has.

## Measurement

Ticket-ladder design has no industry benchmark to score against, so everything observable here is self-set - pick two or three, and write down before tickets go on sale what each would change:

- **Paid share of the revenue target by the gate date** (self-set): what portion of the ticket target is banked when the early price ends. Behind pace is a price, demand, or marketing question - split it with `samber/dev-event-organizer-skills@event-market-fit` before touching a price.
- **Persona mix against plan** (self-set): if the employer-funded tier sells far below its expected share, either the ladder guessed the payer mix wrong (Q2) or the corporate price is above what those budgets approve without a sign-off.
- **Discount and rung uptake** (self-set): group orders, scholarship applications received versus granted, supporter tickets sold. A scholarship route drawing far more applications than it can fund is a budget conversation for next edition, not a reason to quietly stop answering.
- **Refund and transfer request volume against the deadline** (self-set): a spike right before the deadline says the deadline is doing its job; a steady stream after it says the policy is being litigated case by case and needs rewriting, not enforcing.

## Invocation examples

- "Our 300-person community DevOps conference charges nothing today and we are eating the catering risk - what should tickets cost?"
- "Give me the tier ladder for a two-day Python conference: corporate, individual, and student, with an early-bird date."
- "Someone asked for a refund three weeks before our event and we never wrote a policy. What should it say, and what do we do now?"
- "We want to offer free tickets to people who cannot afford one without turning it into a public discount code."

Expected output: a ticket structure, presented section by section for validation, every number labeled sourced or self-set:

- the revenue target with the arithmetic behind it
- paid capacity after comps
- the posture and why
- the persona ladder with its ratios and the gate dates
- the access rungs with their application mechanic
- the bulk mechanics with their stacking rule
- the refund and transfer policy in publishable words

## References

- [references/published-ticket-ladders.md](references/published-ticket-ladders.md) - the real published prices with their events, dates, and sources: two full persona ladders with computed ratios, the three gating mechanics, the group-discount percentages and thresholds, the supporter tier, the free-by-design case, and how to transpose any of them by ratio.
- [references/access-rungs-and-group-mechanics.md](references/access-rungs-and-group-mechanics.md) - the three-rung disclosure architecture in detail: published persona tiers versus discretionary need-gated tickets, the sourced application mechanics from an email request to a scored reviewer panel, eligibility framing, and the group-order and invoicing mechanics with their exclusions.
- [references/refund-and-transfer-policy.md](references/refund-and-transfer-policy.md): four real refund and transfer policies in full, and a decision checklist for writing one, labeled throughout as four examples rather than a norm.

See also, same collection:

- `samber/dev-event-organizer-skills@event-budget` - owns the revenue target this ladder must hit and the free-versus-paid funding decision; run it first.
- `samber/dev-event-organizer-skills@event-sponsor-pricing` - the sponsorship rate card, including the share that cross-subsidizes attendee prices; the mirror of this skill on the sponsor side.
- `samber/dev-event-organizer-skills@event-market-fit` - owns sellout speed, the sales curve, and whether slow sales are demand, marketing, or price; react to its read here, never re-derive it.
- `samber/dev-event-organizer-skills@event-marketing-plan` - runs the campaigns that sell the tickets this skill priced.
- `samber/dev-event-organizer-skills@event-no-show-management` - owns what happens to seats that were bought cheap or free and never used.
- `samber/dev-event-organizer-skills@event-accessibility-inclusion` - mirrors the need-gated rung this skill owns and covers what attending costs _beyond_ the ticket (childcare, travel and registration grants). It defers the application mechanic and the reviewer to this skill rather than building a second one.