To track venue enquiries, tours and deposits you need one shared list where every booking moves through the same stages, and everyone who deals with couples can see and update it. Per-user fees work against that, because they make you ration logins among the very people who need the information.
The pipeline, stage by stage
- Enquiry: date wanted, guest numbers, source, and who replied and when
- Tour booked: date and time, who is showing them round, and what they asked about beforehand
- Tour done: what they liked, their concerns, the quote given, and the date you said you would follow up
- Hold: which date is held, until when, and whether anyone is waiting behind them
- Signed: contract date, package, agreed price and any special terms
- Deposits: each payment due, the amount, the due date, and whether it has arrived
- Event: handed to whoever runs the day, with the full history attached
Every record should have a next action and a date. A pipeline with no next dates is just a list of names.
Who needs access
The owner wants the whole picture. The coordinator lives in it daily. Weekend staff need to see tomorrow's tour and log what happened, because weekend tours can fall on the coordinator's days off. Whoever does the accounts needs the payment schedule and nothing else. Seasonal or part-time staff may need it for a few months.
With per-user pricing, each of those is a monthly charge, so there is a pull towards economising. Weekend staff get a printout. The bookkeeper gets an emailed export. Two people share one login, which may breach the terms and destroys any record of who did what. The result is that notes from Saturday's tour reach the system on Tuesday, if at all.
As an illustration only, suppose a login costs 35 dollars a month and six people should have one. That is 210 a month, or 2,520 a year. Cut to two logins and you pay 840, and the saving of 1,680 is bought by keeping four people in the dark. Put your own figures into our per-seat software bill calculator, a free calculator that shows the yearly and three-year totals.
What a shared view needs
- One screen showing every live enquiry by stage, sortable by event date and by next action date
- A calendar showing holds and their expiry alongside confirmed bookings
- A payments view: due this month, overdue, received
- Notes that carry a name and a time
- Roles, so weekend staff can add tour notes without seeing the finances
- Use on a phone, since tours do not happen at a desk
- An export of everything, at any time
When a spreadsheet plus calendar is fine
For a venue with a modest number of events and one or two people handling enquiries, a shared spreadsheet with one row per enquiry and a shared calendar for holds does this perfectly well, and costs nothing per user. Use fixed stage names, a next-action date column and a separate tab for payments. Sort by next action every morning.
It starts to strain when holds and second options multiply, when payment reminders are forgotten because checking the tab is nobody's job, or when you want staff to see some columns and not others.
Between the spreadsheet and the per-user platform
If you have outgrown the spreadsheet but resent paying by the login, those are not the only two choices. Our guide to owning your software covers what is involved in having a system built, and when it is not worth it.
Hiro's pricing is one flat monthly amount with no per-seat fees, so the whole team can be added without the price moving. The page for wedding and event venues describes what venues commonly rent and what can be rebuilt.