Case Study
Demo Infrastructure: Turning bespoke SE work into a reusable sales system
I built and maintained a demo repository that gave the sales team access to close to 100 reusable technical demos, with the context, setup and guidance needed to run them without depending on an SE every time.
- Enablement & Leadership
- Technical Sales
- Technical Build
The Problem
Surfly, and later Webfuse, was extremely configurable.
That was useful in a sales process because we could make a demo look very close to the problem a prospect actually had. A bank interested in privacy and audit controls needed a very different story from a support team looking at co-browsing or a company trying to connect Webfuse to Slack.
The downside was that good demos took work.
I was building these kinds of environments as part of live opportunities. Once I had solved a problem, there was no reason another AE should need me to build the same thing again.
There was also no point handing someone a folder of scripts and calling that enablement.
They needed the working demo, but they also needed to know who it was for, why they should use it, how to set it up and how to present it.
Why It Mattered
I wanted AEs to be able to run a strong technical demo without an SE having to sit in every call.
That didn't mean removing SE from deals. It meant using SE time where it was actually useful.
If we had already solved the technical problem behind a use case, an AE should be able to pick that work up and use it.
Then I could spend my time on whatever was genuinely new.
The Insight
The useful thing about a bespoke demo is that it starts with a real customer problem.
I didn't want to stop building them. I just stopped treating the work as disposable afterwards.
If I solved something once, I wanted the next salesperson to be able to use it without needing me there.
That meant removing whatever was specific to the original opportunity, making the technical setup reusable and adding enough context around it that somebody else could actually sell with it.
What I Built
I took over a company subdomain and built a demo portal for the commercial team.
Over time it grew to close to 100 reusable demo environments, covering different industries, integrations, product capabilities and customer problems.
An AE could go into the portal, find something relevant to the deal they were working on and deploy it into their own environment.
I tried to make every demo page answer the obvious questions:
- Who is this for?
- What problem does it demonstrate?
- How do I set it up?
- How should I run the demo?
- What should I actually show?
I usually recorded myself giving the demo too.
The AE shouldn't have to understand how every script, API call or integration worked before they could use the result.
What Sales Actually Got
The repository wasn't just an index of technical assets.
Each page packaged the implementation with the information needed to use it in a deal.
The Custom Pin Flow demo, for example, included the working environment alongside the use case, ICP, setup instructions and a short runbook explaining how to present it.
That last part mattered. Giving somebody access to a demo is not the same as teaching them how to use it in a customer conversation.
The same format worked for very different technical scenarios.
The Slack Webhooks demo involved a different integration and a different customer problem, but the AE still knew where to look for the setup, the target use case and the demo flow.
I wanted the repository to feel predictable even when the demos themselves were not.
How It Worked
Most demos started with a real sales opportunity.
Once the original problem was solved, I would go back through the implementation and remove whatever tied it to that customer or to my own environment.
Hard-coded values became inputs. Account-specific configuration was removed. Scripts and integrations were generalised where it made sense.
Webfuse later made this easier through Spaces, which let me package complete environments in Git and install them into another Webfuse account.
For the AE, most of that complexity stayed underneath the surface.
They could install the environment, add whatever values were specific to their prospect and follow the instructions on the page.
The underlying implementation could be fairly technical. Using it didn't need to be.
Tracking what people actually used
I also wanted to know whether the repository was useful rather than just assume it was.
I tagged calls to the Surfly JavaScript API in different demo flows, then used SQL queries against our session-history records to track which demos were being used, by whom and which parts of them people were interacting with.
That gave me actual usage data.
I could see which demos were getting picked up, which flows were popular and which parts of the repository were worth spending time maintaining.
As the product changed, I updated the demos that people were actually relying on rather than treating the repository as a static archive.
Impact
The repository became part of the sales team's normal workflow.
It grew to close to 100 demo environments, which were deployed approximately 1,900 times.
AEs had somewhere to go when they needed a technical story for a deal. They could find something relevant, understand the use case, install it into their own environment, see how I presented it and run it themselves.
That saved me from rebuilding the same things repeatedly, but that wasn't really the point.
The bigger benefit was that the sales team could do more without everything depending on SE availability.
When something genuinely new came up, I could spend my time solving it.
If it was likely to be useful again, I would generalise it, document it and put it back into the repository.
Then the team had one more thing they could do without me.