Key Takeaways

• AI turned demo production from a scarce sales engineering skill into something every AE, CSM, and marketer can do, so the constraint on a demo program moved from production to ownership.
• Most revenue teams have an owner for every individual demo and no owner for the library as a whole, which is why libraries grow fast and degrade quietly.
• Demo operations is the function that owns the demo layer as a system: library architecture, who can build what, which demos need review, whether the program is working, and when assets retire.
• Review should be tiered by risk. Master templates that reach many buyers need a sign-off; a one-off personalization of an approved template usually does not.
• Program health is measured in usage, not output. Which templates actually get sent, by whom, and whether paid seats are active tell you more than how many demos were built.
• Demo operations belongs with presales in most mid-market and enterprise teams, with product marketing owning the story and enablement owning adoption.

Most revenue teams can tell you who owns any single demo. Almost none can tell you who owns the demo library. That gap was harmless when demos were scarce. It is expensive now that everyone can build one.

Three years ago, building a good demo took a sales engineer and a week. Today an AE can produce a personalized one before lunch. That is real progress, and it created a problem nobody budgeted for. When everyone can build, the library stops being a collection of a few careful assets and becomes hundreds of variations with no one responsible for the whole. Demo operations is the discipline that fixes that.

This post defines what demo operations owns, makes the case for who should run it, and gives you a minimum viable version you can stand up this quarter without new headcount.

Why Demo Production Stopped Being the Bottleneck

For most of the last decade, the demo program was limited by supply. Demos were expensive to build, so there were few of them, and the people who built them, usually SEs, were the de facto owners by default. The library was small enough that one presales leader could hold it in their head.

AI broke the supply constraint. Capture, editing, personalization, and copy can now be done by people who have never opened a demo editor before. We have argued that the hard part of AI demo creation is knowing what to show, not producing the screens. The organizational version of that point is this: once production is cheap, the scarce thing is ownership.

Here is what that looks like inside a typical team after a year of AI-assisted building:

• Forty variations of the core product demo, half of them built by people who have since changed roles
• No record of which version is the current master
• Regional teams quietly maintaining their own copies because the central one never fit
• A renewal conversation where nobody can say how many of the purchased seats are in use

None of these are production failures. Every demo in the library was built competently. The failure is that no one owns the system the demos live in.

What Is Demo Operations?

Demo operations is the function that owns the demo layer of your go-to-market as a system rather than as a set of individual assets. The closest analogy is revenue operations. RevOps does not close deals; it owns the systems, data, and rules that let everyone else close deals consistently. Demo operations does not build most demos; it owns the architecture, permissions, review rules, measurement, and lifecycle that let everyone else build them well.

The distinction matters because it changes the question leaders ask. “Who built this demo?” is a question about one asset. “Who decides what our demo library contains, who can change it, and when something leaves it?” is a question about the system. Most teams can answer the first and not the second.

A working demo operations function owns five things. Each one is covered below, and each one can be started small.

How Should a Demo Library Be Structured?

Library architecture is the first job of demo operations, because every other decision depends on it. The core distinction is between masters and derivatives.

Masters and derivatives

A master template is the canonical, approved version of a story: your core platform demo, a use-case demo, a persona demo. Derivatives are copies made from a master for a specific account, segment, or region. Derivatives are where personalization happens, and they should be disposable. Masters are where the story lives, and they should be few.

The most common architecture failure is a library where derivatives become masters by accident. An AE builds a great version for one account, it gets shared in Slack, and six months later it is the unofficial standard, built on a messaging decision nobody made deliberately. Demo operations prevents that by making the promotion path explicit: a derivative becomes a master only by being reviewed and adopted as one.

Variation without copies

The second principle is to vary the content, not the asset. If ten segments need the same story with different company names, metrics, or terminology, ten copies of the demo is the wrong answer. Values that change by segment belong in variables or presets attached to one master, so a fix to the master reaches every segment at once.

For how to split work between a small set of SE-owned demos and the self-serve layer AEs use, the three-level library model in our SE scaling guide is a good starting structure. Demo operations is what keeps that structure intact once a hundred people are building inside it.

Who Should Be Allowed to Build What?

Permissions are the second job, and they are where most teams default to one of two bad extremes. Either everyone can edit everything, which is how masters get overwritten, or only presales can build, which recreates the bottleneck AI was supposed to remove.

The useful middle is to grant rights by layer, not by person:

• Masters: a small group, usually presales and product marketing, can edit
• Derivatives: anyone in a customer-facing role can create from an approved master and personalize within it
• Regional or segment masters: regional leads can own a master for their market, inside the same review rules as the global ones
• Viewing and sharing: broad, because the point of a library is to be used

Two operational habits make this hold. First, permissions should follow the org chart automatically, so that a new team in a new region gets the right rights on day one and someone who leaves stops owning assets the day they go. Second, every asset should have a named owner who is still at the company. Orphaned assets are the main source of library rot.

Access is the first layer of running a demo program at scale. Get it wrong and every other control sits on top of the wrong people.

Which Demos Actually Need Review?

Review is the third job, and the right answer is that most demos do not need it, while a few need it badly. Demo operations should tier review by risk rather than applying one rule to everything.

A practical three-tier model:

• Tier 1, masters: any template that will be used to generate buyer-facing demos at scale requires sign-off before anyone can build from it, and an edit sends it back for review.
• Tier 2, high-stakes derivatives: demos for strategic accounts, regulated industries, or anything making pricing or roadmap claims get a lightweight second look.
• Tier 3, routine personalization: a derivative that changes names, logos, and variables inside an approved master ships without review.

The logic is that review effort should sit where a mistake would be copied the most times. A wrong claim in one personalized demo reaches one buyer. A wrong claim in a master reaches every buyer who sees a demo built from it.

This is where the tooling should do the enforcement rather than a process document. In Walnut, approval is set on templates: when an admin turns it on, demos cannot be published from a template until it is approved, and any edit to an approved template moves it to “needs re-approval” automatically. That puts the gate on the master, which is exactly where tier 1 says it belongs, and leaves routine personalization free. For the deeper argument on why the approval step protects your message rather than slowing it down, see how to scale personalized demos without losing control of your message.

How Do You Know Your Demo Program Is Working?

Program health is the fourth job, and it is the one most teams skip, because the default metric is output. Demos built per month goes up after an AI rollout, and it looks like success. It tells you almost nothing.

The questions demo operations should be able to answer every month are about usage:

• Which masters actually get used? A library with forty templates where three generate most of the sent demos has thirty-seven candidates for retirement.
• Who is building, and who stopped? Adoption by team and region shows where enablement landed and where it did not.
• Are paid seats active? Seats with no logins in sixty days are either a training problem or a budget you can reclaim.
• What do buyers do with what we send? Engagement by master, not by individual demo, shows which stories work.

We have written about why demo metrics built on volume and completion mislead at the deal level. The program-level version of the same mistake is measuring how much the team built instead of how much of it is in use.

The practical blocker is usually access to the data. Program health needs member activity, seat utilization, and session data in the same place your revenue reporting lives. The Walnut API exposes per-user activity (role, last login, and how many demos, templates, and playlists each person created), company-wide seat utilization including a per-role breakdown, and demo session data, so a demo operations owner can put adoption next to pipeline in the BI tool the CRO already reads instead of exporting screenshots once a quarter.

When Should a Demo Be Retired?

Lifecycle is the fifth job. Libraries only grow unless someone is responsible for subtraction, and an asset nobody removes eventually reaches a buyer with claims or screens that are no longer true.

Retirement works best as a rule, not a judgment call. Reasonable defaults:

• A derivative with no views in ninety days is archived automatically.
• A master is reviewed every quarter and either reapproved, rebuilt, or retired.
• When a person leaves, their assets transfer to a named owner the same week.
• When the product or positioning changes materially, the affected masters are listed before the change ships, not after.

Archiving is not deleting. The answer is to make retired assets recoverable and invisible by default, so the library people browse stays small while nothing is truly lost.

Who Should Own Demo Operations?

This is the question that stalls most teams, because three functions have a reasonable claim. Presales knows the product and the demo craft. Product marketing owns the story and the positioning. Enablement owns adoption and training. Splitting ownership three ways is how you end up with no owner.

Our stance: demo operations should sit in presales for most mid-market and enterprise teams, with clear contracts with the other two. Presales is closest to how demos are actually used in deals, already owns the most important masters, and has the technical depth to run permissions and architecture. Product marketing should own what the masters say, and sign off on tier 1. Enablement should own adoption, training, and the program health review with sales leadership.

There are two exceptions. In product-led companies where most demos are marketing assets on the website and in campaigns, demo operations often belongs with product marketing. In very large organizations, it becomes a dedicated role, typically a demo program manager sitting next to RevOps.

What matters more than the box on the org chart is that one named person can answer, on any given day, what the library contains, who can change it, and what left it last month.

What Does Minimum Viable Demo Operations Look Like?

You do not need a new team to start. A minimum viable version can be stood up in a month by one owner spending a few hours a week. Start in this order:

1. Name the owner. One person, with the five jobs above written into their goals.
2. Inventory and declare masters. List every template, pick the five to ten that are the real standards, and mark everything else as a derivative or a retirement candidate.
3. Set permissions by layer. Masters editable by a small group, derivatives open to customer-facing roles.
4. Turn on review for masters only. Tier 1 first. Add tier 2 later if you need it.
5. Pick three health metrics. Masters in use, active builders by team, and active seats. Review them monthly with sales leadership.
6. Archive the long tail. Anything untouched in ninety days goes out of the default view.

The first month usually removes more than half of the library from active circulation, and nobody misses it. That is the clearest sign the program had an ownership problem rather than a production one.

Why Demo Operations Matters More as AI Does More

The pressure on this function is going to increase, not decrease. As AI takes on more of the building, personalizing, and even administration of a demo program, the volume of assets rises and the number of human hands on each one falls. Buyers are already researching with AI: 45% of B2B buyers used it during a recent purchase, according to Gartner’s 2026 buyer survey, which means more of what you send is read, summarized, and compared without a rep present.

That combination, more assets made with less human attention and consumed with no human present, is exactly the condition where ownership pays for itself. AI can build the demo. It cannot decide which forty demos your company should not have. That decision is the job.

The teams that get value from AI demo creation will not be the ones that build the most. They will be the ones that know what is in their library, who is responsible for it, and what it is doing for pipeline. A hidden cost of letting everyone build without structure is that the library becomes a liability nobody can see. Demo operations makes it visible.

Frequently Asked Questions

What is demo operations?

Demo operations is the function that owns a company’s demo library as a system. It sets the library architecture (which templates are masters and which are derived copies), decides who can build and edit what, defines which demos need review, measures whether the program is being used, and retires assets that no longer earn their place. It is to the demo layer what revenue operations is to the revenue stack.

Who should own the demo library in a sales organization?

In most mid-market and enterprise teams, presales should own the demo library, because SEs are closest to how demos are used in deals and already maintain the most important templates. Product marketing should own the messaging inside master templates and approve them. Enablement should own adoption and training. The key is one named owner, not shared ownership across three teams.

Do all sales demos need to be approved before they are sent?

No. Review should be tiered by risk. Master templates that generate many buyer-facing demos should require approval, and edits should send them back for review. High-stakes derivatives, such as demos for strategic or regulated accounts, deserve a lighter second look. Routine personalization of an approved template, like changing names, logos, or variables, usually does not need review at all.

How do I measure whether our demo program is working?

Measure usage, not output. Track which master templates actually get used to create sent demos, which teams and regions are actively building, how many paid seats are active, and how buyers engage with demos built from each master. Demos built per month is a weak signal on its own, because AI makes it go up whether or not the program is working.

How many demo templates should a team have?

Fewer than most teams think. A healthy library usually has five to ten master templates covering the core platform story, the main use cases, and key personas, with personalization handled through derived copies and variables rather than new masters. If more than a handful of templates are rarely used, they are candidates for archiving.

When should an old demo be retired?

Set rules instead of deciding case by case. Archive derived demos with no views in ninety days, review every master quarterly, transfer a departing employee’s assets to a named owner the same week, and list affected masters before any major product or positioning change ships. Archive rather than delete, so retired assets stay recoverable but out of the default view.

How do I start demo operations without hiring anyone?

Name one owner, inventory the library, declare five to ten masters, set editing rights by layer, turn on review for masters only, pick three health metrics, and archive anything untouched in ninety days. One person spending a few hours a week can do this in about a month, and it typically removes more than half the library from active circulation.

Ready to give your demo program an owner and a system? Start for free with Walnut.