I'm at the Utah Technology Council's CTO P2P forum this morning. Nate Bowler, a former collegue at Excite@Home and CTO of @Task is speaking about SaaS, software as a service.

Nate says that his number one take-away from this talk is: Pick a market that is underserved or could benefit from the improved delivery model of a SaaS platform and serve it in a non-trivial manner. Emphasis on "non-trivial." Often companies dumb down their SaaS offering. Nate stresses the importance of using the same technology stack for on-premise and on-demand options.

In order to deliver SaaS, you have to be able to support billing, provisioning, and back office tools over and above the base level of software functionality. Beyond that you probably also need multi-tenancy.

And, of course, there's the scalability issue. A critical question is how scalability concerns line up with the business model. What are the hardware demands per customer? Per user? This information needs to be fed back into the product pricing.

Billing can be a big deal. Many people start out with home grown billing systems that limit their flexibility. Most companies start off with a single "this is how we're going to price things" plan, but clients have different ideas. Are you going to pass up a client because they want to pay in a way that you're billing system doesn't support? Instead you'll probably end up constantly hacking the billing system.

You need to be able to monitor every component of your application stack: systems, network, and processes; availability; application functionality; and user experience. In addition to monitoring these things, you need to be watching trends to avoid surprises.

Security is obviously a big deal. You need instrusion detecion systems, SAS70 compliance for business processes, and external auditing of security issues like XSS, data partitioning, and software patch levels to protect customer application data. Automated testing needs to be rigorous.

Some thoughts from Nate on pricing:

• You can't offer SaaS level service for traditional pricing (perpetual licensing) and survive. You can get by in the out years with just maintenance dollars (typically 20%).
• Price on-demand and on-premise the same and keep release cycles in lock step.
• You need the discipline to walk away from deals that won't accept a term license.
• Term pricing value to customer breaks down in 2 conditions: when the contract duration is greater than 3 years and when the user count grows beyond 200 users.
• Terpetual pricing is an option: customer pays 180% of annual price in first year and pays 35% in years two and three. The idea is that it's still cheaper than a perpetual license deal for the customer in year one, but is more inline with how they're used to buying software--big upfront fee followed by maintenance.

@Task has had good luck selling on-premise software with term licensing.

One of the ideas Nate brings up that's pretty interesting is implementing a Digg-like feature for your product roadmap and letting your customers vote for features that are important to them.

@Task has found that most customers opt for on-demand rather than on-premise contrary to conventional wisdom. Similarly, they haven't found that a self-sign up with free trial was an effective strategy for generating leads. This may be specific to @Task that has a fairly complex, group-oriented product. The enterprise nature of the activity means that free trials have to be carefully orchestrated.