May 14, 2008
Until the model has matured, and standards of expectation and performance are settled, SaaS can be a slippery ride. Just because the press is shouting "Surf's up!" doesn't mean that you can just go do it, dude.
Since the balance of negotiating power changes on contract signing, it's critical to cover the details up front. For example, it's not uncommon for an agreement to contain early-out options for both parties if the relationship can't be made to work (e.g., performance for buyer, profitability for service provider). What are the guardrails, including equitable financial resolution, for these decisions?
An agreement might initiate payment for services upon "acceptance" (e.g., production over time at committed service levels without any severity level 1 incidents). What are the service levels, and what incidents qualify for severity level 1 treatment? How does the agreement resolve the challenge of enabling ongoing modification?
This discussion has an added complexity when the service provider uses a common instance of the software, an underpinning of most SaaS models. How does the purchaser keep his business processes unaffected if the provider goes out of business? At the end of the agreement, what transition help and data is the service provider required to give, for what compensation?
All these questions (and many more) are easily resolvable, but they require a detailed understanding by both parties of the services to be provided and the conditions of, and compensation for, provisioning those services. It's not uncommon for the pre-contract effort to take as long as the implementation effort.
What will increase the value of SaaS and hasten its adoption? One part of the endless-summer ride won't change: Success will still require price and the perception of feature and function. But a new advantage will be service. In the past this has been the world of CIOs, not software developers, but it's becoming a competitive differentiator among SaaS vendors. Here are four service-level metrics to explore in detail in your requirements and to include in any agreement:
Average response time. Pick a small number of standard, frequently used transactions, measure, and provide incentive for their delivery.
Average availability. Net after a limited amount of scheduled maintenance is accounted for over the measurement period.
Maximum resolution time for severity level 1 issues.
Maximum failover recovery time.
Depending on the criticality of the service to your organization, you might have to audit the vendor's disaster recovery capability and test it annually. One interesting opportunity with some SaaS vendors is to have them process an application over two sites (yours and theirs), effectively providing warm-site failover.
Once you have a successful SaaS relationship, help your vendor be successful. Look for places within your organization to extend the use of its services, giving it more revenue and you more value. Look for opportunities outside your organization to help the vendor, providing prospects, serving as a reference, and promoting the model. Finally, work with your vendor to improve the quality and profitability of its service.
Grab your stick and let's beat it. SaaS and surf's up!
After stints with Pepsi, Nike, and Gap, Ken Harris now enjoys life as CIO of Shaklee. He lives near the beach in California.
Continue to the story:
SaaS To The Rescue
About the Author(s)
You May Also Like