Nobody picks the wrong system at one location. They find out at five.
Almost nobody discovers they picked the wrong system while they are running one venue. At one location the software is fine. It is fine at two. Somewhere around the fourth or fifth — a second instructor who teaches at both halls, a parent who moves across town, a term that starts in September in one place and October in another — it stops being fine, and the thing that broke was never on the feature list you compared.
That is the pattern in every requirements document we have been sent, and it is the reason this is worth reading even if you run a single site today. The questions that decide whether a system survives your growth are ones you do not have to ask yet. Which is exactly why they are the ones nobody asks.
Start with the version of this you have probably already lived.
It is Thursday evening and there is a quote for a new system on the desk. The feature list runs to two pages and every line has a tick against it. Scheduling, bookings, payments, attendance, parent communication, reports. Tick, tick, tick, tick.
The first thought is relief. They do everything.
The second arrives a minute later and it is worse: a tick does not mean you can use it next week. It might mean we will configure that for you during onboarding. It might mean we would build that for you. Occasionally it means it is on the roadmap. Three completely different futures, one identical tick — and nothing on the page tells you which one you bought.
That gap is not a small thing. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects for Harvard Business Review and found that one in six did not merely cost more: it became a different project from the one that was approved, with an average cost overrun of 200% and a schedule overrun of almost 70%. The mechanism is boring and it repeats. A scope the two sides never pinned down, because nobody wrote it down precisely enough for anyone to be caught breaking it.
Four documents turned up, and they were not what we expected
Between 2024 and 2026, several multi-location networks sent us a formal requirements document before they committed to anything. A priority-ranked spreadsheet. A written specification with a data model sketched out. A plain list of questions after the first demo, which turned out to be the sharpest of the three.
We expected feature lists. What we got taught us something else: the feature list is the part that discriminates least. Every serious vendor is ready for scheduling and payments and attendance. Nobody loses a tender there.
What decided things was a different set of questions — the ones a single-site operator never has to ask — and a way of asking them that most buyers never use.
So we have published the lot: 75 questions across 15 areas, merged and anonymised so no line traces back to a source, with our own answers printed next to each one. Free to use, on us and on everyone else.
Here is the short version.
The theory: sort your own list first, in four buckets
The single most useful thing any of those networks did, they did before contacting a vendor.
They sorted their own requirements into must have, should have, could have, won’t have. That is MoSCoW — the name is nothing but those four initials with a couple of lowercase o’s dropped in so you can say it out loud, and it has nothing to do with the city. Dai Clegg came up with it in 1994 and later gave it to the DSDM Consortium, which means it is a recognised standard: a vendor receiving a MoSCoW-sorted list already knows what the labels mean.
Two things make it work rather than becoming another colour-coded spreadsheet.
The must-have test. Ask what happens if a requirement is not met. If the honest answer is that you would cancel the project, it is a must have. If not, it is not. Most people mark everything as essential, which marks nothing as essential.
The effort split. DSDM suggests must-haves should account for no more than about 60% of the effort, with roughly 20% each in should and could. If 90% of your list is a must have, you have not prioritised it yet — and a vendor will price it as if you meant it.
Then there is the fourth bucket, the one everybody leaves blank. Writing down what you are not buying is what stops scope creep six months in, and it stops a vendor quoting you a platform for a problem you had already decided not to solve. An exclusion that exists only in your head gets reopened. One that is answered in writing does not.
The practice: demand five states, never a tick
This is the fix for that Thursday-evening quote. Refuse yes and no. Make every line land in one of five states:
- Available as standard — usable this week, with a link into the vendor’s product documentation rather than a marketing page, so you can check it without them.
- Configuration we do with you — real, but it is set-up work during onboarding, not a switch already flicked. Ask who does it, how long it takes, and whether it is included.
- We would build it — not there today. In writing, with a date, and ask who maintains it afterwards; an unmaintained custom branch is worse than no build at all.
- Not in the product — not there, and not dressed up. Scoped and quoted for phase two, or dropped.
- Out of scope, agreed — your own exclusion, answered anyway so the line holds.
A vendor who will not separate we have it from we could build it is the single biggest risk in the exercise. That distinction is worth more to you than any feature on the list.
The questions a network asks that a single site never does
Five areas came up in every network document and almost no single-site one. Since this is our page, our answers are next to them — all of them linking into our product documentation rather than a marketing page, which is the standard we just asked you to hold everyone to.
Data separation. Ask whether separation between franchisees is architectural or a permission setting someone can get wrong. In Zooza each location is its own account; the franchisor joins them into a Network that gives HQ reporting across all of them. A franchisee cannot see another branch’s data because it is not in their account. When a family genuinely moves branch, Bulk Network Transfer carries their debt, their credit, their notes and your custom fields across, with a dry run first — and we document what does not move, because payment history and direct-debit mandates belong to the original company.
Royalties. Ask which base the figure uses — invoiced, collected, net of refunds, net of tax — and agree it before comparing vendors, because they will not all assume the same one. Then ask whether the royalty is invoiced afterwards or taken at source, which are two different builds. Ours is calculated in the Network Application from real transactions under your network’s own rules, sitting next to received payments, net revenue and unpaid debt so you can see the base. Taking it at source depends on how each branch collects, and we scope that rather than claim it.
Standardisation. The question is not can we standardise but what mechanism makes standard the default. Ours is copying: a new branch is built by copying a master programme and its classes, with the schedule shifting to the new dates automatically. Product codes assigned by HQ keep differently-named programmes comparable in reporting. And the honest half: there is no single button that changes a price in every branch at once, because programmes live inside each account. That is the cost of franchisee autonomy, and we would rather say so.
Network reporting. Almost every document contained a line meaning an automatic version of the dashboards we keep by hand. Ask what is reported network-wide with no custom build, and whether it slices branch against branch. Ours covers enrolments, payments, net revenue, unpaid debt, royalties and sessions by company, place, product and period, with a Companies/Places toggle for franchisees running several venues. Lifetime value is the gap — that leaves through Power BI or an export.
Localisation. This is the one networks underestimate most, and the one where an adjective is worthless. Do not accept the system is multilingual; ask which half, and then ask about everything that is not language. Our answer is a list rather than a claim: invoicing engines per market (Fakturoid for CZ/SK, Számlázz.hu for Hungary, SmartBill and Oblio for Romania, ABRA Flexi, Xero internationally), accounting exports per market (Omega, Pohoda, SAP), and payment rails per region — FastPay for UK BACS Direct Debit, Global Payments across the EU/EEA with a separate merchant account per legal entity, GoCardless, Stripe. Language is three independent settings, so your office can work in one while parents read another.
And the part everyone forgets to ask about
Vendors demo a clean enrolment. Your actual week is trials, waiting lists, missed sessions, a child joining in week six, a child moving up a group, and a parent who wants to stop at the end of next month rather than today.
That gap is where the admin hours live. Three questions catch most of it:
- Can a cancellation be scheduled for a future date, rather than only now or never? Looks tiny, comes up constantly. Ours can, and it can be revoked.
- Is a late joiner’s price calculated pro-rata automatically — and can you find everyone who joined late? In Zooza late bookings are a first-class case: per programme you choose whether they are disabled, need approval, or confirm automatically, whether the price drops pro-rata, and every one carries its own status so finding them is a filter rather than an audit.
- When the year turns over, how do continuing children move up? Ours is a documented checklist — new billing periods, copy each continuing class so the schedule shifts itself, choose whether bookings come too, then auto-enrolment re-enrols the families who are staying. What Zooza will not do is work out on its own that a child has moved up a year; your year structure is mapped once with us and the September promotion runs on top. Configuration, not magic.
While we are here, two more worth stealing for your own list. Capacity in Zooza is two numbers: the booking form only ever sees Capacity, while make-ups and trials also see Extra capacity — so a room of seven can be sold as five plus two, holding places for the people who should get them without ever overselling. And shared sessions make two classes in the same room at the same time count against the room’s real capacity, instead of booking twenty people into ten places. That one is marked beta in the product, and we would rather you heard it here than found the label yourself.
The best signal is still a no
Ask one more question out loud, near the end: what should we not use you for?
A vendor with a clear answer is showing you the edges of what you are buying, and you cannot get that information any other way. A vendor who has nodded along to every line has either not read your document properly or will not tell you where the limits are — and you will find them yourself later, at your own cost.
Which cuts both ways, so here are some of ours, printed on our own page next to the things we are proud of: certification expiry alerts for instructors are not in the product, and a note is not a reminder. There is no single button for a network-wide price change. Lifetime-value reporting leaves through Power BI rather than arriving as a standard report. Automatic deletion on a retention clock is something to ask us about rather than assume. Shared sessions is beta.
None of that is comfortable to publish. All of it is cheaper for both of us than finding out in month four.
And “not in the product today” is not the same sentence as “no”. Every one of those lines on our page carries a way to ask for it, because a fair share of what Zooza does now exists precisely because a network raised it during exactly this conversation. A gap you can see and request is worth more to you than a tick you cannot verify — which is, in the end, the whole argument.
The full 75 questions are here, with our answer under every one of them. Tick the ones that matter to your network, print the result as the first draft of your own requirements document, and take it to everyone you are talking to — including us.
Sources. Bent Flyvbjerg & Alexander Budzier, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, September 2011 — a study of 1,471 IT projects in which one in six was a “black swan” with an average cost overrun of 200% and a schedule overrun of almost 70%. MoSCoW prioritisation — created by Dai Clegg in 1994, later donated to the DSDM Consortium. Every Zooza capability referenced above links to our product documentation at help.zooza.online.
