Why Can't We Use the Feature the Demo Showed?

Usually because the demo and your account are not the same system. The demo runs on clean sample data, on the top plan, down the one path that was built to impress. Your account runs your data, on the plan you bought, down every path your team actually takes.

This is the fifth pattern in Friction, Found, our series on the friction we see most often inside growing companies. We call it the demo gap.

What is the demo gap?

It is the distance between what a system appeared to do when someone showed it to you and what it does when your own records go through it. The gap is rarely a lie. A demo is a performance, and it is built to show what is possible. The trouble starts when a plan gets built on the performance instead of on the account.

It shows up in three forms, and most growing companies meet all three eventually.

What if the screen is there but nothing is behind it?

Picture an owner who inherits a system with a full row of tabs: scheduling, reporting, a client portal, automations. The screens open. The buttons are there. Plans get made around them.

Then someone runs a real job through the reporting tab, and nothing comes back. The tab was a front end. The work behind it was never built, or was built for a version that no longer exists.

Screens are cheap to make and easy to believe. The only proof that a feature works is a real record going all the way through it and coming out the other side correct.

What if the feature is on a plan you do not have?

This is the most common form, and the least dramatic. The sales rep showed the automation. It was real. It was also on a higher tier.

Picture a team that spends two weeks designing a workflow around an automation feature, then finds out at setup that their plan does not include it. Now there are three choices, and none of them were in the budget: upgrade every seat, redesign the workflow without the feature, or bolt on another tool to fill the hole.

The plan tier is the hidden gate on about half the automation ideas in a small business. Checking it takes five minutes, and it almost never happens before the design work starts. We wrote about how those extra tools pile up in the AI subscription graveyard.

What if people only want one part of it?

The third form runs the other way. The platform works. It is just much bigger than what anyone needs.

Picture an owner who puts a new product in front of real users and pays attention to what they reach for. Around the core there are dashboards, settings, reports and a dozen menus. What people actually value is one thing: the score it produces. Everything else gets a polite look and no use.

That is a demo gap too. The demo sold the whole surface. The value lived in one piece. Whoever builds or buys the whole surface carries the cost of all of it, the training and the support included, for the one part that matters. We covered why that hurts in overbuilt is as dangerous as underbuilt.

Why does nobody catch it sooner?

Because every incentive points at the demo. The vendor wants the sale. The buyer wants the problem solved and would like to believe it is. The team is busy and has already seen the screens. Nobody is paid to run the boring test.

The boring test does not feel urgent until the plan is built. By then the gap is expensive, and the conversation is about who missed it instead of what to do next.

How do you test for the gap before you plan?

Three checks, each short, each done with your own data rather than sample data.

• Run one real record end to end. Pick an ordinary job from the past week and push it through the feature you are counting on. Not a test record with tidy fields. A real one, with the messy parts.
• Ask for the tier in writing. Which plan includes the feature, what it costs per seat, and whether any part of it is limited, metered or still in beta.
• Notice what people use. Put the tool in front of the people who will live in it and see which part they reach for first. That is the part worth paying for.

If a feature passes all three, plan on it. If it fails one, you have found the gap while it is still cheap.

Where should you start if you see this in your own company?

Start one step before the tool. Write down the process the feature is supposed to serve: what comes in, who touches it, and what has to come out. Then test the tool against that process, with one real record, before anyone plans a quarter around it. A demo can only show you a tool. Your process is what tells you whether the tool fits. Process first, then the tool.

If you want help with that, bring it to a Friction Audit. Give us 45 minutes and we will map the process the tool has to serve, run the checks above against the system you have or the one you are considering, and show you where the gap is. The Leverage Map that comes out of it is yours to keep.