Appearance
Vendors
Vendors apply, get reviewed, get accepted or waitlisted, and then run on exactly the same rails as everything else: contracts, invoices, documents, reminders, and a portal.
Applications
The vendor application is a structured public page, not a form built in the form builder. That is deliberate — the office filters, counts occupancy, and reviews on these fields, which a free-form questionnaire cannot support.
If you need bespoke extra questions for your fair, build those on a form and link it.
An application collects the vendor's details, what they sell, booth photos, whether they are returning, and — for first-time vendors, via conditional fields — references.
Review
Applications land in a filterable list: date applied, returning or new, vendor type, status.
From here:
- Accept — the vendor goes active for the event
- Waitlist — with an automatic email, so nobody is left wondering
Waitlist rather than reject
A waitlist email is easier to send than a rejection and leaves the door open when somebody drops out in July. The automatic email means it costs you nothing.
Occupancy tracking
Set a target space count per vendor type and the review screen tracks it live — 33% of non-food spaces filled. It is the number that tells you whether to keep chasing applications or start waitlisting.
Duplicate flagging
New applications selling the same goods as an already-accepted vendor get flagged as a high risk of repeating, so you can decide rather than discover it on the grounds.
After acceptance
Accepted vendors flow onto the existing rails:
| Contract | E-signed, from your contract templates |
| Invoice | Booth fees, using the same invoice engine with context vendor |
| Documents | Insurance and permit uploads, with expiry tracking |
| Deposits | Cleaning or security deposits |
| Reminders | The same automated chasing as everything else |
| Portal | Their own login — see Vendor Portal |
Nothing here is a vendor-shaped copy of a rentals feature. Vendor invoices are invoices; vendor documents are documents.
Promo broadcast
Upload flyers, logos, and photos once and every vendor's portal gets them for download and sharing. It replaces the annual email with six attachments that half of them never open.
Food vendors
Everything above, plus three things.
Menu approval
The vendor submits an itemized menu — item and price — typed in or pasted. You approve it per item, and the approved list comes back with their offer.
Menu conflict flagging
Menus are checked across the event's accepted vendors, so three funnel cake stands do not get accepted independently by three different people.
Percentage-of-sales rent
A per-fair option. The mechanic:
- The vendor pays a flat deposit up front — say $1,000.
- Rent is a percentage of gross sales — say 20%.
- The deposit is a credit that is consumed first. Until 20% of gross exceeds $1,000, no further rent is due.
- Once it does, percentage rent starts being owed.
Reporting cadence is configurable — daily, or once per event.
From the vendor's portal they enter gross, tax, and refunds, upload their POS sales report, and pay the day's rent right there as they submit.
From your side there is a running sales and rent ledger per vendor.
Credits are consumed in date order
Because the deposit credit is applied in date order, correcting an earlier day's figures recalculates every report after it. The numbers stay right; expect later days to move when you fix an early one.
Minimum guarantee
Where a minimum is agreed, any shortfall is reported at the end of the fair rather than charged mid-fair — so a slow Thursday does not generate an invoice that a strong Saturday would have made unnecessary.
Still to come
- AI menu extraction from a photo or PDF upload. The paste format is already the target shape.
- Vendor placement on the grounds map — see Grounds Map.