If your client doesn t trust you, there s nothing you can really do. I build trust with my clients so when something like this happens, they believe me when I give them an explanation. And when I tell them what I m going to do to prevent future problems, I make sure to follow through.

Depending if this is a "final" demo or if its a mid-project demo will also affect whether you can really alleviate the customers concerns. There s very little you can do to make the customer happy if it s the end of the contract and there s no more budget for testing and bug-fixes.

One generic strategy I ve used: if you have someone in the room document the exception/problem in front of the customer and let them know it is going into the bug tracking system for investigation and testing, that will demonstrate to them due-dilligence and alleviate some concern. You, of course, need to follow through and make sure to fix the problem.

Just tell the truth but humorously, like saying apparently our software is still not that perfect, and we are keeping making it perfect.

don t ever lie or try to cover it up. clients are not dumb.

I d say it depends on what stage you re in. If you re selling something, my experience is that it is always preferable to just bring static material for demonstration. Powerpoints are alright, but printed screenshots that the clients can toss around the table are unbeatable. It allows you to only show exactly what you want, in a very controlled manner, while still looking very professional.

If the client has already bought the project, and the demo is related to, say, a launch that s coming up, the best you can do is to smile and say "as you can see, we re still working out a few quirks"

I usually let the client know up front that I m running off a live dev environment so we might see some weirdness. If I am aware of parts that have issues (inconsistent crashes..) I let the client know about them before I show that section (along with the fact that production won t do this and I am working on it already).

Update: based upon other responses, I agree that early demos with static material are better for generating discussion.

The last time I presented a project to a conference, I planned a live demo, but I actually had a set of slides headed "If you can see this, the live demo didn t work!" with big screen shots. Inevitably the live demo didn t work (it needed a globally routable IP address and this wasn t available) and the slides were called for.

I think it personally depends on your relationship with the client and how satisfied they are with your product this far.

I usually tell them it was bad data from testing or jokingly say that was a test to see how the application handles errors (if you have a generic, catch-all error message/page). You can also use the time to reiterate the importance of user testing/acceptance.

I ve never done a demo where I didn t set expectations beforehand. If this is a work in progress, make sure they know that up front. This goes a long way towards keeping them positive. EVERYBODY has issues during demos. Just smile, tell the truth and continue.

Probably the best way to help keep your client positive is to project positivity and confidence yourself. If you seem unsure of yourself it ll show as being unsure of your app.

Possible strategies:

Telling the audience "we re all going to stay here until whoever did that owns up".

Complaining about the prevalence of evil monkeys.

Seriously, I m majorly against public product demos. Don t attempt demos until you re 99.99999% sure the damn stuff works. And even then it s a bad idea, you re setting yourself up to fail with all the variables that can go wrong - which may not even be with your software. If you must do it, attempting to impress customers with a flashy UI is best done one-on-one. That s the way we ve always done it.

Is this shipping product or still under development?

Assuming it s a shipping product, just recover and move on. Work the room while recovering (rebooting, restarting the app, etc.) and don t dwell on what happened. Customers understand stuff happens.

I was an applications engineer and this happened frequently. IMO, the key to recovering from this starts at the beginning of the relationship / sales process / demo, not one particular event. Establish trust and build credibility with your audience as early as possible. If you have this and an exeption gets thrown, the audience will probably trust you enough to think nothing about the software failure and just move past it. Yeah, you will have the occassional person looking to crucify you regardless of what you do but that comes with the territory.

Be honest if someone asks (they probably won t) and never talk negatively about your product. I also found when questioned about a fatal error, it helps, and they are very foregiving, if you can explain what happened in terms the audience understands. It demonstrates your knowledge of the software process and goes back to trust.

Write down the Exception and why/how it occurred IMMEDIATELY. Then they will see that you will be fixing it.