• Publisert
  • 6 min

How to prepare an EPiServer CMS demo

Developing in EPiServer is one thing - demonstrating the product is quite another. Preparation is key for a successful demo.

If you're an EPiServer developer, you know the product like the back of your own hand, right?
Installation, configuration, integrations, models, views and controllers - piece of cake!

But what if you were asked to prepare an EPiServer demo for a breakfast seminar or a room full of editors?
What about an important sales pitch for a prospective client? 
Or setting up a demo site that sales can play around with in client meetings?

Chances are, API details or NuGet delivery will not be relevant to their expectations.

I've fumbled my way through a few demos over the years - here are some tips to help yours go smoother.

Why you need to prepare

Though EPiServer probably can't verify this, here's my pet theory:
Of all the sections on the Developer Certification exam, developers score lowest on "User interface".
Developers are notoriously rusty when it comes to UI and presentations.
We will find that button or menu option eventually, but that sort of hesitation doesn't look too good in a demo situation.
Whether you are doing the demo yourself or just preparing a demo site for your sales team, ask yourself the following:
  • Do you "play editor" often enough - to be able to effortlessly demo key features?
  • Can you predict your audience's expectations - to make your demo as relevant as possible?
  • Do you have a backup plan - to deal with things that go wrong

Determine what features to demo

Depending on the situation, audiences have different expectations for your demo.
You need to adapt your demo accordingly. You're looking for that balance between "too basic" and "too advanced".

Not everyone will be impressed by WYSIWYG editing and mobile display channels.
In fact, many features that were once big selling points for a CMS vendor are now "old news", because most products have similar features.

You'll want to focus on the feature combinations that makes EPiServer a clear choice for that particular audience:
  • Ask your sales team about previous talks. The client may have mentioned special business needs or hinted at features their current site/CMS is lacking.
  • Read RFPs or specifications provided by the client. Although these are often vague matrices of Every CMS Feature Ever Invented, they may also contain more specific clues.
  • Investigate their current site. By determining which CMS they currently have, you can research and compare those features to what EPiServer offers. 
    You may discover parts of their site that could be solved more elegantly with the new capabilities of EPiServer. 
  • Read whitepapers written for (or by) EPiServer. EPiServer regularly engages analysts to outline trends and current demands. Although the language in a lot of these will sound like buzzword bingo to a developer, they contain some useful clues to what may impress your audience.
  • Make sure the features provide value for the client. Don't waste time demoing flashy features that don't fit with the client's profile, ambition level or strategy. Forcing features on them without being able to visualize how it will add value to the solution, will likely leave your audience overwhelmed (in a bad way). Thanks to Jacob Khan in the comments for reminding me.


Synch your demo with the sales team

Normally, your demo is just one part of a bigger presentation.
Your sales team will have an agenda to go through, which may include build-up to your demo. 
  • Familiarize yourself with the agenda. Read through the presentation material of the people speaking before or after you, so you have a clear idea of what they will be discussing.
  • Take advantage of transition and linking opportunities. Demos and presentations flow best when sales and tech complement each other, e.g. when sales discuss common website challenges, which you demo an elegant solution for using the CMS. Rehearsing is never a bad thing.
  • Agree on which features to demo. You've determined which features are most relevant to your audience, so stick to it. Make sure sales doesn't blindside you with a request to improvise demoing something you are totally unprepared for. 
  • Make sure you get enough time for your demo. Time your demo in advance, and make sure sales knows how long you'll need. There's nothing worse than having to rush a demo, or starting the demo too late in a presentation, when everyone's just looking at their watch. In fact, if you are really squeezed for time, it's better to drop the demo and give your sales people that time, rather than rushing the demo. Remember, your audience tends to remember visuals better than words. If your demo sucks, that impression will taint the whole presentation.

Setting up a demo site

For most demos, a plain Alloy site will go a long way:
  • Use Alloy for basic features demo. It's quick to set up, it works, there's even a functional demosite hosted by EPiServer. Your audience will appreciate that they can try it out for themselves after your presentation.
  • Remember to install the extras beforehand. Little things like the TinyMCE Spellchecker, the Languages gadget, Social Reach, Self-Optimizing Block, Publish From Office etc are very useful tools (and common requirements) in sales demos. Unless you plan to demo the Add-On Store live, make sure these are pre-installed before your demo. 

For more 'wow' factor, prepare a real reference case or custom site:
  • Real reference cases have more credibility than a dummy demo site
  • Your audience can relate more to real life examples than a generic site with minimal design and meaningless copy.
  • Use reference cases with similar business needs as your audience. If you're demoing for a union or member organization, demo what you did for another similar client. If your audience are interested in personalization, show how you used Visitor Groups for another client. You get the point.
  • Combine reference cases if necessary. If you're lucky, you have a reference case that contains everything you need to demo. If not, you may have to demo a little bit from several reference cases. 
  • Don't mess with production environments. If you need to demo something that you haven't prepared a dummy version of, avoid falling for the temptation to demo it on a live production site - unless you have their explicit approval. Instead, setup a copy of the site, or use the test/staging environment for your demo.

For convenience, make your demo site re-installable:
  • Create a backup of your demo site. When your demo site is all set up, backup the database, blobs and web files to an image that you can easily reinstall next time you need to run the demo. Or you could set up some automated smoothness to re-deploy the site at regular intervals, like the official Alloy demo site.

Prepare for the unexpected

Sometimes, no matter how well you prepare, things just don't go your way. Minimize the risk factors:
  • Don't depend on specific firewall permissions. Unless the meeting is in your own office, you have no control over what kind of external traffic/ports are allowed. You may not be able to hook up your VPN or access those webservices.
  • Expect slow (or no) internet access. Problems connecting to the ethernet/wireless, slow or unstable connections, are factors you should take into account.
  • Run locally if possible. If you have the necessary tools available in your demo environment (SQL Server, IIS, .NET etc), run your demo site from that local machine. 
  • Create demo content before the demo. Ideally, you'll have time to create pages or blocks, process images and whatnot during your live demo. But if you run out of time or the wifi is slow, you can use what you created beforehand and still save the demo. In extreme cases, use screenshots instead of a functional web site.
  • Have a fallback plan.  If you don't have time for what you planned to demo, or technology fails, or it becomes apparent your audience wants you to demo something else, at least give them something. Improvise a demo of another feature. Fallback to screenshots. Talk about specific reference cases. Discuss how EPiServer helps solve common problems or meets current trends and requirements. Anything but "uhm, this isn't working".