What a seat map needs for online booking
Updated
A picture of your venue is not yet a seat map. To sell from it, every seat on the picture has to be a record your booking system can find.
A stable ID for every seat
Your booking system stores orders against seats. If the IDs change every time someone edits the plan, old orders point at the wrong place. Each seat needs an ID that survives moving it, renumbering the row or re-exporting the plan.
Section, row and number
Buyers and staff talk in labels: section, row, seat. Those labels belong on the ticket and in confirmation emails. Keep them as data next to the ID, not only as text drawn on the picture.
Category and price
Most venues price by area or category rather than by individual seat. Attach a category to each section (VIP, Premium, Standard) so the booking system can look up the price without a separate spreadsheet.
Status
A map that sells needs to show what is still for sale. Every seat should carry a status (free, reserved, sold, blocked) that the booking page can change as orders come in, and the map should colour itself from that status.
Something you can click
On the web, the simplest seat map is an SVG image where each seat is its own element with its data attached. A developer listens for a click on the image, reads the seat ID from the element, and passes it to the checkout. No special library, no image map coordinates to maintain.
A plan you can change
Venues change: a row is removed for a sound desk, a table is added on the terrace. The plan should stay editable, and a new export should keep the IDs of the seats that did not change.
How seatorio helps
seatorio exports every plan as an SVG in which each seat carries a stable ID (data-seat-id), its section and its status as data attributes, together with a JSON file holding the full plan with row and seat labels and section categories. Your developer reads one click event; your booking system keeps the rest.
Planning for theatres? See seatorio for theatres and the theatre seating chart template.