What floor software actually solves

The problem is not storing information: that already happens, spread across a spreadsheet, a folder of PDFs and the head waiter’s memory. The problem is that the room has measurements and the information does not. When the plan is drawn in a slide deck, nobody can say for certain whether there are ninety centimetres or sixty between table 12 and the column, and the answer turns up on Saturday morning with the caterer unloading.

Floor software solves exactly that: the drawing is to scale, and the selling decisions — how many fit, whether the dance floor fits, where the top table goes — get made against the room’s real measurements rather than a hunch. What it does not solve is the commercial side: it does not call clients, send quotes or take payment.

The seven functions, one by one

None of the seven is an extra. Take one away and the work it saved goes back to being done by hand, and the program stops saving time and becomes one more place to write down the same thing.

  • Plan at real scale: with the room’s walls, columns and doors measured, not an approximate rectangle. That is what separates a plan from a drawing.
  • Operating capacity: how many covers fit while leaving the service gangway and the escape routes clear. It is nearly always a smaller number than the capacity on the licence.
  • Seating: the guest list seated on the plan, with its groups, its menus and its requirements. Not a list beside the plan: on top of it.
  • Paperwork for the day: the plan printed to pin up in the office, and the set-up sheet with each table, its coordinates and who sits in each chair.
  • A link for the client: an address you send over WhatsApp where the couple see their wedding and place their own people, with no account and nothing to install.
  • Team permissions: whoever sells does not need to be able to move a wall, and the end client does not need to see the other weddings.
  • History: what was laid out at each event and how it went, so the layout that worked gets repeated instead of reinvented.

What looks essential and is not

Three functions show up in almost every demo and none of the three is floor software. A wedding CRM runs the sales funnel — visits, quotes, follow-up — and anyone who already has one does not need a second one inside their floor program. Invoicing is a regulated product with tax obligations attached, and no plan-drawing tool does it well. And a booking website solves a different business: a wedding venue does not sell on online availability, it sells on the visit.

The useful question in front of a demo is not «does it do this too?» but «does it do this well, or does it do it so it can say it does?». A half-built invoicing module means keeping two sets of books.

Signs you are about to be sold the wrong thing

Three of them show up in the first ten minutes of a demo, and all three mean the same: the product was not built by people who have laid out a room.

  • The capacity it shows is the licensed one. If the cover count does not drop as you place tables, the program is counting chairs, not space.
  • The plan has no scale. If you cannot type «this wall is 18.40 m» and watch everything else adjust, the drawing is decorative.
  • The PDF does not print properly. The set-up plan gets pinned up in the office and read from two metres away: if it comes out A4 in eight-point type, nobody will use it.

What it should cost, and what should not cost extra

For a venue running between 30 and 120 events a year, the sensible order of magnitude is 30 to 90 euros a month. Below that it is usually a generic drawing tool; above it, a hospitality ERP with a plans module bolted inside.

What should not be charged separately: your team’s users, the link for the end client, exporting the set-up paperwork, and migrating the rooms you already have. If the price goes up every time one more person from the team joins, the program ends up being used by one person, which is exactly the problem it came to solve.