The questions franchisors ask before they buy.

Questions, not answers — and that is deliberate

Between 2024 and 2026, networks in the children’s-activity sector sent us formal requirement sets before signing anything. They ranged from a handful of venues to large international networks, across the UK, Central Europe and beyond. Some arrived as a priority-ranked spreadsheet, some as a written specification, some as a list of questions after the first demo.

What you are reading is the union of those sets, with every identifying detail removed and every line rewritten. No client, brand, territory or number appears here, and no sentence traces back to one document.

It contains questions and no answers, for three reasons. Half the answers we gave in 2024 are different today, because products move — a requirement list from 2024 is still a good requirement list. A question like “how do you stop one franchisee seeing another’s revenue?” belongs to nobody; the way one network phrased it belongs to them. And the question set is the more useful artefact anyway: most networks discover the thing they forgot to ask only after they have signed.

So take it and use it. Against us, and against everyone else you are talking to.

Then insist on more than yes or no

A tick in a box is where tenders go wrong. Make every answer land in one of five states, and the whole picture changes.

Available as standard

Usable this week. A claim like this should come with a link into the vendor’s product documentation, not a marketing page — then you can verify it without them.

Configuration we do with you

Real, but it is setup work during onboarding rather than a switch already flicked. Ask who does it, how long it takes, and whether it is included.

We would build it

Not there today. Get it in writing, with a date and a commercial position, and ask who maintains it afterwards.

Not in the product

Not there, and not dressed up. Either scoped and quoted for phase two, or dropped. This answer is a good sign, not a bad one.

Out of scope, agreed

Your own exclusion, restated back to you. Answered regardless, so the line stays where you drew it and cannot be quietly redrawn later.

A vendor who will not distinguish “we have it” from “we could build it” is the single biggest risk in the whole exercise. That distinction is worth more to you than any feature on the list.

Common questions about running a system tender

• What should a franchise network ask before buying a class-management system?

  Cover fifteen areas rather than a feature list: network structure and data separation, onboarding and standardisation, royalties, network reporting, the family data model, the enrolment lifecycle, payment models, scheduling and capacity, instructors and pay, your website and booking flow, communication, localisation, data protection, integrations, and the vendor relationship itself. The feature list is the easy part and the part every vendor is ready for. The areas that decide whether the project succeeds are separation, standardisation and the mid-term operational reality.
• What is the difference between must-have, should-have, could-have and won’t-have?

  A must-have is functionality the project cannot work without — if it is missing on launch day, the project has not delivered. A should-have adds real value, often in workflow quality, but you could launch without it. A could-have is wanted eventually and is honestly phase two. A won’t-have is explicitly ruled out, at least for now. Sorting your own requirements this way before you contact a vendor takes an afternoon and changes every conversation that follows.
• Why does the “won’t have” list matter in a software tender?

  Because an exclusion that exists only in your head gets reopened, and one that is answered in writing does not. Writing down what you are not buying stops scope creep six months into the project, and it stops a vendor quoting you a platform for a problem you had already decided not to solve. Ask for an answer against every line including those, so the boundary is on the record and nobody redraws it by accident.
• How should a vendor answer a requirements document?

  Line by line, with no blanks, and in states rather than ticks: available as standard, configuration done with you during onboarding, we would build it, not in the product, or out of scope as you agreed. Claims of “available as standard” should link to the vendor’s own product documentation rather than a marketing page, so you can verify them without asking. A vendor who will not distinguish “we have it” from “we could build it” is the single biggest risk in the exercise.
• How do you stop one franchisee from seeing another franchisee’s data?

  Ask whether separation is architectural or a permission setting. If each location’s data sits in its own account, there is nothing to misconfigure; if it is one shared database with role flags, the separation is only as good as the last person who edited a permission. Then map your real roles — HQ, area manager, franchisee, venue manager, employed and freelance instructors, host venue, parent — and ask what each one actually sees, including the most limited role available.
• What should we ask about royalty calculation?

  Four things. Whether the figure comes from actual transactions in the system or from a number someone types in. Which base it uses — invoiced, collected, net of refunds, net of tax — because vendors will not all assume the same one. Whether locations can carry different percentages, thresholds, caps or fixed fees, and whether a rate can change from a date without rewriting history. And whether the royalty is invoiced after the fact or taken at source as money flows, which are very different builds and very different cash-flow positions.
• What is the requirement networks most often forget to ask about?

  The mid-term reality. 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. Three specific questions catch most of it: can a cancellation be scheduled for a future date rather than only now or never, is a late joiner’s price calculated proportionally and automatically, and when the year turns over, is progression into next year’s groups configuration or a manual re-keying exercise every summer.
• What should we ask about localisation before opening in a second country?

  Separate the parent-facing languages from the staff-facing ones, because the second is usually thinner. Then ask about everything that is not language: currency and how reporting consolidates, tax rates and registration status per country, locally compliant invoices and numbering, public holidays and school terms and who maintains them, and local payment methods — direct debit schemes differ by country, and bank transfer with a structured reference is routine in some markets and unknown in others. Finally, ask what happens when you enter a market that is new to the vendor too, and get the answer in writing before the second country rather than during it.
• Should head office or each franchisee pay for the platform?

  Both models work and they fail in opposite directions. When each location pays, costs align with usage and franchisees control their own spend, but adoption becomes uneven and smaller locations feel the strain. When head office pays, adoption and quality are consistent across the network and billing is simple, but central cost rises and locations are less accountable for what they use. The point is to decide it deliberately against how your network already charges, rather than inheriting whichever model the vendor proposes by default.
• What should a network ask about data protection and retention?

  Who is controller and who is processor across head office and the locations, and whether a written agreement covers it. Where data is hosted and which sub-processors are involved. Whether you can record which version of a policy a family consented to, with a timestamp. Whether retention deletion or anonymisation actually runs automatically — many platforms cannot do this, so find out before you promise it in a privacy notice. Whether there is an audit trail you can see rather than only the vendor’s engineers. And what exit looks like: what you get, in what format, how fast, and what is deleted afterwards.
• How can we tell a real integration from a promise?

  Make the vendor label every integration on your list as one of four things: native and maintained by them, a generic connector, a one-off build, or your own work against their API. Then check that the API is public and documented, that you can read the documentation before buying, and that it covers writes as well as reads. Ask how you are told when the API changes and how long you have, and whose problem a broken integration is. “We can integrate with anything” is not an answer about something you need on day one.
• What is a good sign in a vendor’s answers?

  A clear no. A vendor who tells you what the product does not do, and what you should not use them for, is showing you the edges of the thing you are buying — which is information you cannot get any other way. A vendor who has agreed with every line of your document has either not read it properly or is not going to tell you where the limits are, and you will find them yourself later at your own cost.