How to prepare an EPiServer CMS demo

Determine what features to demo

• 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

• 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

• 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. 

• 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.

• 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

• 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".