Twelve questions to ask any booking vendor before you shortlist
Ask all of them, of every vendor, including us. The point is not our answers. It is that most of these cannot be answered well from a marketing site, which is exactly why they are useful.
Municipal software evaluations tend to be scored on feature matrices, and feature matrices are the part vendors are best at. Everybody checks every box. The differences that actually determine whether a project succeeds sit somewhere else.
These are the twelve questions we would ask if we were on your side of the table.
On money
1. What is the price, in writing, for our population and scope?
Not a range and not a conversation. If a written quote takes more than a week, ask why. Deferring the number until after a demo is a negotiating position, not a technical constraint.
2. What does renewal look like in year four?
Ask specifically about an automatic annual escalator, and about whether booking volume, transaction count, staff seats or facility count are metered. A lower year-one price with a metered growth clause is not cheaper, it is deferred, and it charges you for succeeding.
3. What is not included?
Payment processing, implementation, integrations, additional modules, hardware, training, support tiers. Get the list. The gap between subscription price and total cost is where municipal budgets get embarrassed.
On compliance
4. Can you send the accessibility conformance report for the resident-facing pages?
Not a statement, not a VPAT for a different product. The conformance report for the pages residents use, including generated permits and invoices. Under ADA Title II your agency carries this exposure, not the vendor, which is why the answer matters more than it looks.
5. Which security certifications do you hold, and which do you not?
The second half is the informative half. Every vendor has gaps. A vendor that will name them before contract is telling you something about how the relationship will run.
6. Where does our data live, and can it move?
Ask for the region, in the agreement, and ask what would have to happen for it to change. For Canadian agencies this is a legal requirement rather than a preference.
On the product actually fitting
7. Configure our fee schedule on the call.
Not a sample. Bring your adopted schedule with its rate classes, minimum durations, surcharges and effective dates, and watch somebody build it. This is the single most predictive fifteen minutes in the whole evaluation.
8. Show us our three hardest cases.
A park special event with four parallel reviewers. A seasonal allocation with competing leagues. Whatever your staff currently handle by exception. Demos are built around easy cases, so supply hard ones.
9. Which of our integrations are in production today, and which would be built?
Both answers are legitimate. Only one is a commitment. If the answer is open API, ask what that means for scope, price and timeline, in writing.
On delivery
10. What is the implementation fee, and is it fixed?
Fixed fee versus time and materials tells you who carries the risk of a project running long. Ask what happens if it does.
11. Who does the implementation, and where are they?
Names and locations. A partner-delivered implementation is not a problem, and can be an advantage. An implementation delivered from a time zone eleven hours away with nobody on site is a different proposition and should be priced as one.
12. Give us a reference that runs the business areas we are buying.
Not the vendor's favourite customer. An agency of comparable size running the same business areas. If the vendor is new to your market, ask them to say so, and ask what they offer instead.
Two ways to use this
First, send all twelve to every vendor in writing before you shortlist, and score the responses rather than the demos. The pattern of what gets answered fully, partially and not at all is more predictive than any feature matrix.
Second, do not write your solicitation from a vendor's feature list. It is the most common way a competitive process quietly becomes a single-source process, because a requirements document assembled from one product's capabilities will select that product. Describe your policy, your facilities and your obligations, and let vendors show how they meet them.
Most of ours are published rather than given in a sales call. Pricing, the certification ledger with the gaps, implementation duration and stages, named integrations, and an FAQ that opens by stating we have no North American municipal customers yet.
Keep reading
More from the blog.
What ADA Title II actually means for your reservation portal
The rule is not about your website. It is about every page a resident has to get through to book a room, and most agencies have not looked at the second half of that path.
September 2, 2026 · 7 minute readOperations and policySix booking systems is a reporting problem, not a software problem
Every one of your booking systems works. That is precisely why nobody has replaced them, and precisely why you cannot answer the question your council keeps asking.
August 19, 2026 · 6 minute readOperations and policyWriting a field allocation policy that survives a contested season
Allocation is the most political thing a recreation department does. The policies that hold up are the ones written before the argument, scored consistently, and published with the reasoning attached.
August 5, 2026 · 8 minute readSee it against your own facilities.
Forty-five minutes, your fee schedule, your approval rules, your three hardest cases. No slides.