Demo Theater: The Franchise Software Demo Questions That Break the Script

Franchise software demo questions should aim at the parts a demo is designed to skip: ask to see the product loaded with your own material, ask what the third week of use looks like, and ask which feature customers ignore. A vendor who answers all three plainly has earned a second meeting.

I sell software. I have given the demo this post is about, and watched buyers let me get away with it.

Nothing below is a trap. These questions move the conversation from what a product can do to what it is like to own, and a good vendor is relieved to be asked.

A demo is a performance, and that is not an accusation

Assume everyone in the room is honest and the problem remains, because a demo is built for forty-five minutes of attention:

• The data is chosen, assembled by people who know what the product renders well.
• The path is rehearsed. Nobody clicks the thing that takes eleven seconds to load.
• The presenter is the best user in the company, and has never hunted for a menu item in a single-user account with no permissions in it.

None of that is deception. Demoing well is a skill, and a vendor who demos badly is not more honest — only worse at a job. The polish tells you about the sales team, not the product.

What a demo hides is the empty state, the second week, the administrator, and anything depending on somebody else. Every question below aims at one of those.

Know who the vendor builds for. FRANdata's forecasting model tracks approximately 4,000+ US franchise brands, per the IFA and FRANdata economic outlook, and no product serves all of them. A roadmap gap is rarely an oversight but a decision about which slice pays, and you can ask which slice you are in.

Ask to see it with your material

Send something real forty-eight hours ahead: a manual section with its formatting mess intact, one location's accounting export, a week of a group chat with names stripped. Then watch the parts that are not the answer.

• Did they load it, or build "a similar example"? The substitution is the finding.
• Who loaded it, and how long did it take? If a solutions engineer spent a day on it, that day is yours whenever your material changes.
• What broke, and what did they skip? Your documents are messier than their sample. Something renders badly, and how they narrate it is the most useful ninety seconds of the hour.

"We cannot show that today" is a good answer, and a vendor who volunteers it is easier to buy from than one who improvises. The tell is not the limitation but who raises it.

One prerequisite is yours either way: if your material is four versions of a manual in a shared folder, the demo will look bad for reasons that are not the vendor's fault — prepare your franchise manual for AI.

The franchise software demo questions that break the script

Five questions, asked in the demo rather than the negotiation. Give the answers room.

1. Show me this doing the job with the material I sent — the job from your brief, end to end, including the part where somebody types, and the screen your users actually live in rather than the one on the first slide.
2. What does the third week look like for a manager who missed the training? You are asking them to describe a person, not a screen. Watch whether they can.
3. Which feature do your customers not use? The best one here; its own section below.
4. Who keeps this current at your smallest customer, and what do they do weekly? Every product has an unpaid administrator somewhere. Find out whether it is you.
5. What did your last lost customer say on the way out? Every vendor with real customers has lost one. "Nobody churns" means no customers or no candour.

None are franchise-specific: they work on any vendor in the stack you are adding to. Ask them here because a franchisor's mistake propagates to every location rather than one office.

The third week is where the product actually lives

Week one is novelty, and novelty makes any tool look adopted. Week three is when a busy person decides whether this is how they work now or a login they will quietly let expire.

So push on it. What does someone open it for on an ordinary Wednesday? What does it send them, and who decided that? What happens when a location ignores it for a fortnight?

Then ask for the recurring five-minute task. Every product that survives has one: something done often enough to build a habit around. If a vendor cannot name it, you are buying an archive people visit when reminded — a different purchase, with a lower ceiling.

Two answers are worth trusting: a specific, unglamorous routine described without enthusiasm, or an admission that usage dips in month two followed by what they do about it. Both mean somebody has watched customers rather than a dashboard.

The ignored-feature question, and why it is the best one

Ask which feature customers do not use and you learn three things: whether the vendor measures usage, whether they will say something unflattering, and where the product's real centre is.

A good answer sounds like a shrug and a specific name. "The report builder — people ask for it in sales cycles and then export to a spreadsheet anyway." A vendor who says customers use everything either does not read their own data or has decided you cannot handle it.

Cross the answer against your one page. If the capability you are buying for is on their ignored list, the meeting is over and you have saved a quarter.

One companion question, straight afterwards: which feature do customers use for something it was not built for? That names the product's actual job as distinct from its intended one, and it is the highest-signal sentence you will hear all week.

The test to run afterwards, alone

Back at your desk, take each moment that impressed you and ask: could a competent person with a general chatbot and a copy of your manual reproduce this in an afternoon?

Where the answer is yes, the capability is no reason to choose anybody, though still a reason to use the product. Where it is no, ask why not — usually because it needs data a public account cannot reach, which is the part worth paying for. We hold our own roadmap to that rule and it costs us demos: which AI features are worth paying for.

A demo cannot tell you whether a product is good. It tells you whether the people selling it know where it is weak, and what they do with a question they would rather not have been asked — which, unlike the feature slide, is exactly what the second year will feel like.

Who in your network would tell you the truth about week three? Hand it to them — running a franchise software pilot program with three awkward franchisees.