One demo environment per rep or one per vertical?
Two reps start calls at 2:00 on one shared demo stack, and the second prospect sees the first prospect's company name on the dashboard. The usual reaction is a stack for every rep. That ends the collision and leaves one environment per rep that needs the next release installed. The count that fits a sales team comes from three inputs: how many demos overlap on the calendar, how many industries need their own data, and whether the product can give each rep a tenant of their own.
Count overlapping demos on last month's calendar
The number of stacks a team needs at one moment is the largest number of demos in progress at once, with the reset after each call counted as busy time. Export last month's demo meetings and find that peak.
Take a hypothetical company, Eddlestone Inventory, whose six reps sell inventory software to breweries, auto parts shops and medical supply distributors. This is its busiest Tuesday, with a 15 minute reset after each call.
| Rep | Call | Stack busy until |
|---|---|---|
| A | 10:00 to 10:45 | 11:00 |
| B | 10:30 to 11:15 | 11:30 |
| C | 11:00 to 11:30 | 11:45 |
| D | 2:00 to 2:45 | 3:00 |
| E | 2:00 to 2:30 | 2:45 |
| F | 2:15 to 3:00 | 3:15 |
Two stacks cover the morning. Between 2:15 and 2:45 three stacks are busy, so the peak is three. Three clean stacks serve all six reps that day, provided each rep books one ahead of the call. A stack per rep removes the booking step and doubles the count.
The length of the reset sets how long a stack stays busy after each call. Resetting a QA environment between test runs puts four reset methods side by side, and the same methods apply to a demo stack.
Preparation counts as busy time too. A rep who uploads a prospect's logo and sample items the afternoon before a call holds that stack overnight. Add the prep window to each meeting, count the peak again and use the second number.
A tenant for each rep inside one stack
If the product is multitenant, a rep's private space can be a tenant. Six tenants then live in one stack, with one install to upgrade. Whether one tenant can be reset while the others carry on depends on how the product stores them.
Microsoft's guide to multitenant SaaS patterns draws the line. Where each tenant has its own database, recovering a single tenant to an earlier point in time restores only that tenant's database and has no impact on other tenants. For many tenants in one database, the guide says operations focused on an individual tenant are more complex to implement, and it gives a point in time restore of one tenant's data as the example.
A product built with a database per tenant can therefore hand each rep a tenant and restore it after every call. One built on shared tables needs a script that deletes and reseeds a single tenant by its identifier. Ask the product's lead developer whether one tenant can be restored while the others stay in use. A yes opens the tenant route, and a no leaves the reseed script or a stack per rep.
Tenants in one stack still share the application version, the global settings and the background workers. The same guide describes the noisy neighbor risk in a shared database, where the workload of one overactive tenant affects the others. A rep who runs a large import during a call can slow a colleague's demo.
When each industry needs its own data
A brewery wants to see kegs and batch numbers, while a medical supply distributor looks for lot expiry dates. If only the records differ, a vertical is a dataset profile: one seed script holds a profile per industry, and the reset loads whichever profile the next call needs.
An industry that changes the install is a different case. A module switched on for one vertical, an integration configured for another, or a separate units setup turns the reset into a rebuild. That vertical gets a stack of its own.
On Petrichor, your reps demo with invented companies that look like real ones, so customer records stay out of the demo. An industry profile is one more set of invented companies, written to look like that industry's customers.
Every stack takes every release.
A demo stack that misses a release shows an older product than the one the prospect would receive. Each added stack is one more install on release day, and Eddlestone ships every two weeks, or 26 times a year.
| Pattern | Stacks | Installs a year | Stops fitting when |
|---|---|---|---|
| Shared | 1 | 26 | Two calls land in one hour |
| Per vertical | 3 | 78 | Two reps demo to one industry at once |
| Pool sized to the calendar peak | 3 | 78 | A rep prepares a stack the day before and needs it left alone |
| Per rep | 6 | 156 | Each rep needs all three industry installs |
| Per rep and per vertical | 18 | 468 | Release day cannot absorb 18 installs |
A product with a database per tenant gets the privacy of the per rep row at the install count of the shared row.
The pool row depends on two habits. Reps book a stack on the shared calendar when they book the meeting. Each stack also shows its loaded profile and the time of its last reset on the sign in page, so a rep can check both before sharing a screen.
We keep a demo environment current with your latest release and reset it when the call ends. Some teams want a shared demo stack, and others want one per salesperson or per industry. Tell us how your team sells and we set it up that way.
Keep prospect trials off the demo stacks
A prospect who wants a login for a week, or wants to load their own records, is asking for a trial. That environment stays out of the demo count. It needs a named access list and a written answer for what happens to the prospect's records afterward, and it comes down when the evaluation ends.
The written spec we agree before building covers servers, network, data, access and how long the environment should live. Some environments stay up all year, and a trial is the kind that lives for one job.
Whatever the count, we keep a demo environment away from production and apart from customer data.
A team with one rep, or one whose demos never overlap, needs a single stack and a reset. The calendar count will say so.
Talk to a consultant and bring last month's demo calendar, with the busiest hour marked.