Application Strategy and Design for a Profitable SaaS Application Strategy and Design for a Profitable SaaS (Part II)
Note: This is the second half of a
two part article on strategy and design for a profitable SaaS, written
by Paul Giurata of Catalyst Resources. If you missed part one, be sure
to read it here.
Purchase Experience
Traditional Software
Sales models are predicated on typically long sales cycles (6-18
months) executed by highly compensated, direct sales teams of account
executives, sales engineers, and services consultants. The deals are
larger, the targets are often fewer. Often an installment must be
$100K to $250K to justify investment in sales effort.
SaaS
The business relies on a high-volume, low-cost demand generation
that is metrics-focused. In almost all cases there is a large portion,
if not all of the purchase experience completed online. A SaaS
can become profitable through just online sales. This opens up the
opportunity for software applications with annual revenues as low as
$250-1,000 per year.
Strategy
Purchase experience becomes an extension of the product and should
be designed aright along with the product. This includes full access
trials, options for occasional use, and a friction-free sign up
experience that is given the same level of usability testing as the
application itself. With an effective trial user experience, the
barriers to entry can be more or less eliminated. Just sign up, login
and start using.
Deployment and Customization
Traditional Software
Offers little easy customization, which forces the user to utilize
the out-of-the-box solution. Extensive and sophisticated
customization that can generally be achieved by technical consultants.
SaaS
Typically a need for some level of customization. Customers
often want the online experience to appear as their own application and
to modify basic graphics and terms. User initiated
customization becomes a strong reason to stay loyal to a SaaS solution
and not switch. The challenge is to find the balance point. If the
customization is too significant, ongoing refinement of the application
is not reasonable and support costs will increase.
Strategy
1
Print this article
Email this article
Talk Back!
Write to Editor
