Also set it up to store the errors locally on the servers as XML so you can browse tehm later (though with email you almost never use this)

Make sure your logging on it’s most verbose level logs the entry and exit of every function, especially in your libraries.
this way you’ll almost always be one page of code from your error immediatlye after browsing the call stack & the logs in the exception. Once things are stable, you can turn this down to get more performance. (though you will pretty quickly become addicted and want to keep it on all the time)

http://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213

Production can be a very revealing time if pre-production has taken a different tack or has been approached with less rigor or professionalism. You fight like you train. You release in production like you release in pre-production. If that frightens you, then go back, change your pre-production patterns to those that more-resemble full production and try to release another beta. If it is much harder then you have done well. If it is the same, either you are too rigid in pre-production or you don’t know what it’s like to run a production pathway.

Your exception-noting loop must contain communications, discrimination (what is worst, what is next), replication and remediation pathways, remediation plans, and full version release processes.

The release process includes feature/bug tracking, feature addition/bug fix, release definitions, change control, versioning, test candidates, test harnesses, final builds, test results, and release candidates with their release installers.

The only thing worse than introducing a bug in software is introducing more while you fix the first. For this reason, the version release process can never short-circuit any of your testing and durability design validation processes.

Application revisions must be strictly (but that is not to say tightly) controlled. Any build and release process must follow the same steps regardless of urgency. A release candidate must be a complete build. It must be built using the exact same process as previous releases (of the same major version). It must be tested with the same (or more) unit, data, interactivity, automation, and other testing. It must only be released if verified 100% by the same person tasked with releasing every build.

Feedback from the customer is vital. So, too, is personal and compassionate response to customer feedback. It is essential that every company offering consumer products have a consumer advocate on staff. In a software company, this person should intimately understand the software, but still be able to take the customer’s side. “We can’t make it do that,” is not a valid response to a bug report.

Before a release, take a team poll. Everyone must agree that this release candidate satisfies all requirements and durability for a production release. If not, then do not release the product. Go back. You still have plenty of time until the moment you release. Then you are now and forever out of time.

Give it some thought.

1. Support in place to handle a bunch of questions from new users, many of whom will do things you would have never thought of.

2. Administator(s?) to handle accounts, roles, permissions

3. Some kind of doc/video showing how to use the application.

Make sure you have a good way of not only logging the errors, but getting access to them (if possible), or at least an easy way for them to forward the bad ones to you.

In the end, we have started putting elmah onto our prod apps with only the devs having access and it’s helped us provide far better support for our clients.

It’s been invaluable in turning around user feedback into action items.