Allocate Exhibitor Pitches and Record Layout Changes
A practical exhibitor pitch allocation template for community events: link exhibitor and pitch registers, match requirements, review neighbors and log every layout change.
Contents
The short answer
A workable exhibitor pitch allocation template has two linked registers: one for what each exhibitor needs and one for what each pitch can actually provide. Match every exhibitor first on mandatory requirements, then on preferences. Before you confirm any pitch, check what is happening on either side of it. Keep one master register with a status for every pitch and a log entry for every move. Any PDF, sample or year-specific version you hand out should be generated from that master, not edited separately.
This guide is for organizers of community fairs, tournament side events, markets and similar gatherings who assign stalls, tables or outdoor pitches to exhibitors. Organizer choices such as preference rules and status names are yours to set. Pitch dimensions, permitted uses, utilities and restrictions come from the venue or the relevant local authority, so record them as confirmed only once that party has confirmed them.
Set up two linked registers
The most common allocation mistake is mixing up what an exhibitor asked for with what a pitch can deliver. If requests and confirmed provision sit in separate tables, you can see the gap between them before it becomes a problem on setup day.
Exhibitor register
| Field | What to record |
| Exhibitor ID | A short unique code, for example E12 |
| Activity description | What the exhibitor will do at the pitch: sales, demonstrations, sign-ups, sampling |
| Requested footprint | The space the exhibitor says they need |
| Equipment | Tables, gazebos, displays, vehicles or anything else they bring |
| Requested utilities | Power, water or other services they have asked for |
| Access needs | Vehicle access, step-free access, loading times |
| Preferences | Preferred area or neighbors, kept separate from requirements |
Pitch register
| Field | What to record |
| Pitch ID | A short unique code tied to the site plan, for example P07 |
| Layout revision | Which version of the site plan this pitch belongs to |
| Venue-confirmed dimensions | The size the venue has confirmed, not an estimate |
| Approved uses | Activities the venue permits at this location |
| Available services | Utilities the venue has confirmed are available here |
| Restrictions | Limits such as no vehicles, no open flame or quiet hours |
| Allocation status | Requested, proposed, confirmed, changed or released |
Link the two tables through the allocation itself. Each confirmed pairing should carry the exhibitor ID, the pitch ID and the layout revision it applies to. If you are using a spreadsheet, a third tab for allocations works well, with one row per pairing.
Match exhibitors to pitches
- 1. For each exhibitor, list the requirements that are mandatory, such as a utility connection, vehicle access or a minimum footprint.
- 2. Filter the pitch register down to pitches whose venue-confirmed details meet every mandatory requirement. These are the candidate pitches.
- 3. Among the candidates, compare the exhibitor's preferences, such as a preferred area or proximity to a partner organization.
- 4. Mark the best fit as proposed rather than confirmed.
- 5. Review the neighbors of every proposed pairing (see the next section).
- 6. Confirm the pairing once the review is clear, and notify the exhibitor.
When two exhibitors want the same pitch, settle it with allocation criteria you have written down in advance, and record the reason for each decision in the register. The criteria might be registration order, accessibility needs, returning exhibitors or event priorities. Which criteria you use is your choice. Applying them consistently, with a recorded reason each time, is what makes the decision easy to explain afterward.
Review neighboring uses before confirming
A pitch can meet every requirement on paper and still fail on the day because of what is next to it. For each proposed pairing, record the activities on adjacent pitches and note any of these conflicts for review:
- Noise: amplified demonstrations or music next to an exhibitor who needs conversation space
- Waiting areas: a stall likely to draw a queue that would block a neighbor's frontage or a walkway
- Deliveries: an exhibitor needing vehicle or restocking access beside a pitch that cannot be crossed
- Services: two exhibitors relying on the same utility point, or cables and hoses crossing another pitch
If a conflict cannot be resolved by adjusting layout or timing, go back to the candidate list and propose a different pitch. Record the conflict and the outcome either way, so the next person editing the plan knows why the pitch was chosen.
Worked example (hypothetical)
This illustrative example shows how mandatory requirements outrank preferences. Exhibitor E12 has requested a utility connection and would like to be near the entrance. Pitch P03 sits at the entrance but has no confirmed connection. Pitch P07 is further in, and the venue has confirmed a provision that matches what E12 requested.
P07 becomes the candidate because it is the only pitch that meets the mandatory requirement. The entrance preference does not override that. P07 is marked proposed, its neighbors are checked for noise, queuing, delivery and service conflicts, and it moves to confirmed only once that review is clear. The register notes that P03 was rejected because it has no confirmed utility connection.
Record every layout change
Plans change: a venue revises the site map, an exhibitor withdraws, or a neighbor conflict surfaces late. A simple status sequence keeps everyone clear on where each pitch stands:
| Status | Meaning |
| Requested | The exhibitor has asked for space; no pitch assigned yet |
| Proposed | A candidate pitch is identified and under neighbor review |
| Confirmed | The pitch is assigned and the exhibitor has been notified |
| Changed | A confirmed pitch has been replaced; the change log holds the details |
| Released | The pitch is free again after a withdrawal or move |
Every move should add a row to a change log with these fields:
Exhibitor ID | Former pitch | Replacement pitch | Reason | Approver | Affected neighbors | Notification dateThe affected-neighbors field matters because a move changes the surroundings of other exhibitors as well. Use it as a prompt to rerun the neighbor review for those pitches and to tell those exhibitors if anything near them has changed. If the venue issues a new site plan, update the layout revision on the affected pitches rather than overwriting the old details. That way you can still trace earlier decisions.
Keep one master and produce views from it
Keep a single master register. Exhibitor packs, volunteer setup sheets and venue submissions often go out as PDFs, and you may want a cleaned-up sample to show new volunteers or a copy filtered to one year. Generate each of these from the current master. Do not maintain them as separate files. Mark each export with the layout revision and the date it was produced, so anyone holding a printed copy can tell whether it is current.
Reusing last year's register as a starting point is fine. Treat the pitch details as unconfirmed until the venue confirms them for the new event, because dimensions, services and restrictions can change between years.
Related articles
Plan a Community Event Information Desk Enquiry Workflow
Build an information desk enquiry workflow for a community event or tournament: desk reference sheet, enquiry log template, referral steps and a printable desk copy.
Plan and Maintain a Community Event Attendee FAQ
Build an attendee FAQ from approved event information, with a named owner for each answer, publication approval and clear triggers for rechecking.
Prepare a Community Event Committee Handover
A practical handover template for community event and tournament committees: what to record, how to transfer each work area, and how successors confirm ownership.
Define Roles and Responsibilities for a Community Event Committee
A practical way to assign committee roles for a community event or amateur tournament: name an owner for every deliverable, set approval authority, map dependencies and agree when changes get reviewed.
Specify the Information and Presentation for an Event Ticket
Build a ticket design brief for your tournament or community event: confirm the required details, set a clear visual hierarchy and lock down print or digital output needs before design starts.
Compare Volunteer Management Software Against Event Requirements
Compare volunteer management software against your event's real needs with a requirements worksheet, scripted demo tests, like-for-like pricing and fair scoring.
Plan a Community Cleanup Event
A practical guide to planning a community cleanup: define the purpose and area, assign named owners, confirm collection arrangements and send participants a clear, final plan.
Plan Waste Collection and Cleanup for a Community Event
A step-by-step plan for community events and amateur tournaments: reduce materials, map collection points, assign volunteers and close out cleanup with confirmed collection.
Coordinate Community Event Accessibility Requests
A practical template for collecting, answering and confirming accessibility requests at community events and amateur tournaments, with restricted tracking and clear delivery owners.
Plan Accessibility Across a Community Event
An event accessibility checklist for community events and amateur tournaments: build an accessibility plan from publicity to arrival, venue, activities, vendors and emergencies.