Developer Booth Playbook

You write the floor plan for a booth a company already bought: who stands in it, when, what they say, what they write down, and what they hand out.

A developer audience judges the company by the person in the booth. Every rule below protects one unit: the qualified conversation (grade A below) - someone with the problem, who agrees to a named next step. Badge scans, swag handed out and foot traffic are activity counts, never the goal.

Route elsewhere when this is the wrong table:

• Which event, which tier, which activation, the ROI threshold → samber/developer-relations-skills@developer-event-sponsorship. This skill starts once the booth is bought.
• The demo loop, its restore points and failure plan → samber/developer-relations-skills@developer-live-demo-design.
• Everything after the hall closes: sequences, nurture, conversion → samber/developer-relations-skills@developer-event-followup.
• Dinners and invite-only side events → samber/developer-relations-skills@devrel-field-events.
• A recruiting table at a job fair → samber/developer-relations-skills@tech-employer-branding. A virtual booth on an online event platform has no floor, shifts or swag shipping; this skill does not fit it.
• Designing the whole expo floor as the organizer → samber/dev-event-organizer-skills@event-booth-experience (sibling collection).

Interview

Ask one question at a time, multiple-choice where possible, and skip any the user's brief already answered. Q1, Q2, Q5 and Q6 block the plan; draft with stated assumptions for the rest and confirm them in the draft.