Part 1: The stage, where it really is
Place the stage as a rectangle, a rounded shape or an ellipse, then move and resize it. Buyers orient themselves by the stage, so a map that lies about it is worse than no map.
Seating
Draw the room once, price it properly, and sell an exact seat instead of a general admission guess.
Verimly includes a full seating chart editor: you generate sections as rows × seats, group them into coloured zones, place the stage where it really is, and set a price for every ticket type in every zone. Buyers pick a specific seat, which is held for them while they pay. Door sales through the POS draw from the same availability, so a seat cannot be sold twice.
The numbers on the screen above mark the parts that do the work. Here is what each one is.
Place the stage as a rectangle, a rounded shape or an ellipse, then move and resize it. Buyers orient themselves by the stage, so a map that lies about it is worse than no map.
You do not place seats one at a time. Say twelve rows of twenty-four, and the block appears numbered and ready to drag, rotate around its own centre, or bend into place.
A zone is a part of the room — stalls, balcony, the standing floor. It carries a name and a colour, and nothing else. What it costs is decided separately, per ticket type.
A pillar in the way, a seat held for production, a row kept for accessibility. Mark it blocked and it is drawn as unavailable everywhere, online and at the door.
A venue you use often is saved once and applied to every future event. Pricing is per event, so the same room can be cheap on a Tuesday and premium on a Saturday.
The editor works the way a room does. Generate a section as a block of rows by seats, drag it into place, rotate a whole selection around its centre when the stalls curve, and set the stage where it actually sits. Marquee-select across a group to move or recolour it in one motion. When the layout matches the room, save it as a template so the next event in the same venue starts finished.
Zones and ticket types are separate things, and Verimly keeps them separate. A zone is a part of the room. A ticket type is Early Bird, Standard or Premium. Each combination gets its own price, so Early Bird in the balcony and Early Bird in the stalls are different numbers, edited side by side in one grid.
A seat is held the moment a buyer places it, for ten minutes while they finish choosing, extended to thirty once they enter payment. If they abandon, the hold expires and the seat returns to the map on its own — nobody has to sweep up. The claim is enforced in the database rather than in the interface, so two buyers reaching for the same seat in the same instant produce one sale and one clear message.
The buyer chooses quantities per ticket type first, seeing a "from" price for each, then places each ticket on a seat. Chips along the top track how many of each type still need a home, so nobody has to remember what they were doing. Availability comes from real seats rather than a stock count, so a seated event never shows a false sold out.
Seats sold at the box office on the night come out of the same availability as online sales. There is no reconciliation step and no window where the two disagree, because there is only one source of truth. A seat sold at the entrance disappears from the storefront in the same moment.
What you actually do, in order, the first time.
A switch on the event's tickets page while it is still a draft. Everything else follows from it.
Rows by seats, one block at a time. Drag, rotate and place them until the drawing matches the room.
Colour each part of the room, then give every ticket type a price in every zone, switching off the combinations you do not sell.
Verimly checks that every seat has a zone and every used zone has a sellable price before it lets the event go live.
| Editor | Section generator (rows × seats), zones, bulk rotate, marquee select |
|---|---|
| Stage | Rectangle, rounded or ellipse, moved and resized freely |
| Pricing model | Every ticket type × zone combination has its own price |
| Not for sale | Any type × zone combination can be switched off, distinct from a price of zero |
| Seat holds | 10 minutes while selecting, 30 minutes through payment |
| Double-sell protection | Single atomic database claim; the second request is refused, never duplicated |
| Reusable layouts | Save a venue as a workspace template and apply it to the next event |
| After sales begin | The layout locks; prices and availability stay editable |
An event is either seated or general admission. For a venue with a seated floor and a standing area, model the standing area as its own zone in the seat map and price it accordingly — buyers still pick a place, and you still get one availability pool.
Yes. Prices and the not-for-sale flag stay editable after sales begin. The seat layout itself locks once seats are sold, so an existing ticket can never point at a seat that no longer exists.
No. Save any layout as a workspace template and apply it to future events. Pricing is per event, so the same room can be priced differently every night without touching the drawing.
One gets it. The seat claim is a single atomic database operation, so the second request is rejected and that buyer is asked to pick again. There is no window in which both succeed.
Ten minutes while the buyer is still choosing, extended to thirty minutes once they enter payment. An abandoned hold expires on its own and the seat returns to the map.
Yes. Any seat can be marked blocked, and it is then drawn as unavailable on the storefront and in the POS. Blocking is a property of the seat, so it survives being moved, rotated or included in a template.
Get started
No subscription, no setup fee, nothing to cancel. Build the whole thing, and decide at the end whether to publish it.