To compete in today's software services market, it's become essential for an IT company supply their applications via a Software as a Service (SaaS) model. Based on my experience leading SaaS development teams, I've written up some recommendations that can help a company successfully plan and implement a move into the SaaS arena.

1. M OVING TO S AA S
Some Practical Advice
To compete in today's software services market, it's become essential for
an IT company supply their applications via a Software as a Service
(SaaS) model. Based on my experience leading SaaS development
teams, I've written up some recommendations that can help a company
successfully plan and implement a move into the SaaS arena.
Margaret A. Menzies
10/27/2011

2. 10/27/2011
INTRODUCTION
Moving to SaaS will require changes in how you do business
Software as a Service (SaaS) is no longer considered cutting edge from a business or software
development perspective. Today's almost ubiquitous Wi-Fi and 3G services provide easy
access to on-line applications via a web browser or mobile client. Combined with the trend to
use cloud computing services to simplify infrastructure and lower IT costs, a software
company now needs to make their offerings available via a SaaS to remain competitive in the
software application market.
Most current software development literature and many blogs cover the basics for developing
a SaaS based application. Many options are based around using Agile development methods,
direct web marketing and a subscription sales model. Today two programmers with a good
idea working with a newly
minted MBA can easily
launch a SaaS product with a
minimal capital investment.
But it can be difficult for an
existing company to convert
an established desktop
application to a SaaS offering
if there is not some realistic
transition planning done in
advance. Establishing a new
SaaS product or simply
moving a traditional client-
server application to the
cloud will impact all business
units and can radically
change how business is
conducted. Thus SaaS
product planning needs to be
considered company-wide and
not be confined to product
development.
Over the past 10 years, I have been involved in a variety of SaaS development efforts. I've
managed development and support teams, acted as product manager and even created trial
marketing campaigns. Drawing on my experience, I've put together some practical
recommendations that should be considered when planning a SaaS application project. The
information is geared towards an existing small company of 10-100 people that already has a
product or software development team, but can also be applied to a division of a larger
company. It's not a complete guide, but offers some advice and best practices to use when
planning your own company's SaaS initiative.
1

3. 10/27/2011
BEFORE YOU BEGIN
Make the SaaS move a company-wide objective
Management may make a decision to develop a SaaS offering, but all staff members need to
accept the idea. While everyone in a company may not be involved with the new SaaS
application at the beginning, they need to know how the offering will be positioned on the
company roadmap and what business implications it may have in the future. In particular,
people will want to know how this will affect their tenure, and if their jobs will change or
even be eliminated.
For example, if there's a consulting department that does product installations and upgrades,
what will they do after their product moves to the cloud? Will their jobs be eliminated or
their functions be converted to something else? If you have a transition plan for them, share
it from the start. Or admit that you don't know yet but you're working on the transition.
Invite them to submit their suggestions on what to do. Being honest and up front with the
information surrounding the decision to develop a SaaS offering will be vital in retaining key
staff members, especially technical staff.
RECOMMENDATIONS
1. Hold a company meeting or series of meetings to explain the plan.
2. Solicit staff feedback and ideas on how to move to the SaaS model in their department or
area.
3. Give them a problem or challenge to solve as a group to encourage team building.
4. Post the launch plan publically and regularly report on progress or changes.
TRANSITIONING AN APPLICATION
What do you want to build and why?
Don't start with just a development plan. A company needs to base the development around
the reason they're making the move to SaaS. This can vary greatly from the need to produce
a new browser-based product to simply offering the existing client-server product as a hosted
model. It helps to create a full business plan around the SaaS initiative so that all aspects
of the effort are explored including how to transition or move existing customers to a new
product if that's a goal. Don't forget to consider staffing and new infrastructure costs along
with how any new or revised subscription pricing may impact sales and marketing
campaigns.
Remember too, that not all desktop applications will smoothly make the transition to the
cloud. Calculation intensive applications or graphics intensive functions may still require a
desktop client. Reporting and printing are also areas that can be tricky to move into a pure
browser-based form, especially if an existing application allows for a variety of data selection
and fancy formatting. This doesn't mean it can't be done, but features like this will take
more time in development.
2

4. 10/27/2011
It's also tempting to hold an initial SaaS release until it is close to being on feature parity
with an existing client-server application. Don't! It will take too long to match an existing
product feature set, which is probably a moving target anyway. Plan for incremental releases
that start with a core foundation of features you can market and build up on this base. Move
customers using the desktop or client-server product to the SaaS application as the key
features they need become available. It may take some time, but along the way you'll be able
to market what's currently available in the SaaS application to new prospects while
demonstrating to existing customers that you're serious about your cloud commitment.
RECOMMENDATIONS
1. Start the planning process by outlining a business plan for the SaaS application.
Keep it simple and lightweight, but make sure to consider your potential new
customers and set expectations for current customers about how they may or may not
want to transition. First agree on the plan, then create a project timeline.
2. If a SaaS rewrite of your existing product is your goal, review the current feature set
carefully. Feature development should be prioritized based on what you identify as
your success criteria. Identify the core value, what makes your product different or
what your existing customers like. Then find-out what it is going to take to re-create
that functionality using a SaaS model.
3. Be ready for change. As development progresses, technical issues may cause delays or
UI plans may need to be re-worked to deal with alpha and beta feedback. If there is a
delay, having backup plans to swap features or enhancements can help mitigate the
overall problem.
4. Strongly consider a "soft" launch. It's easier to deal with changes or delays if the
product is unveiled slowly to a limited audience or a select group of customers. Use
their feedback to fine tune the application and make it stronger. This also gives
marketing and sales staff longer to use the product themselves and which can aid in
their efforts.
5. Finally, like launching any product, getting a SaaS effort off the ground takes time,
so be realistic about the timelines and revenue expectations.
TRIALS AND SUBSCRIPTIONS
Keep sign-up and subscription plans simple
One of the reasons to build a SaaS application is the
ability to provide low-cost evaluations of your
products. A SaaS application can have a
"Freemium" subscription model that allows someone
to use a certain set of features free indefinitely or for
a specific time period. A trial model is usually full
featured but time limited. After a certain date, a
customer login will no longer work and he/she will
be asked to pay. 30 and 10-day trial periods are
standard. Both models may also have a limit on
how much data may be created or how much storage may be used.
3

5. 10/27/2011
Trial sign-up should be as easy and fast as possible; name, email address and password are
standard. About the only thing that should be required is an email address although asking
for a name helps provide personalization in the application. Safeguards against spam bots
should be built in, such as typing in words or a phrase or confirming the account via an email
link, but the key is to get prospect into the application and using it ASAP.
Trials are often fully automated and will not involve any direct intervention by sales staff.
An on-line registration form takes care of everything. Yet if a product requires a sales rep to
start the trial, it should feature some special system configuration or personalized training as
a perceived value-add to counteract any set-up delay. What type of trial model is used should
be a decision made by marketing and sales in consultation with development, to make sure
that any conditions or restrictions can be implemented.
Trials should always have follow-up. This can be a series of automated emails containing
tips on how to use the product or emails and/or phone-calls from sales reps. Example:
• an email sent automatically on sign-up that has some getting started info
• an email sent 3 days later that cites information on how other customers use the app
• a personalized email from a sales rep with purchase information sent after 7 days
• an email sent 3 days before the end of the trial period warning of the expiration and
repeating purchase info
A trial's follow-up email system can be built in the SaaS application or managed through a
company's CRM system (if the sign-up process is linked into a company's CRM system).
RECOMMENDATIONS
1. Establish a flexible subscription model so it can be easily tweaked or changed. Hard
code as little as possible! For example, make it possible for a customer support or
sales rep to easily extend a 30-day trial period or add more users over a trial
subscription limit.
2. Manage subscriptions through a database so that any changes or additions can be
easily made and tracked.
3. Plan for subscription upgrades and downgrades from the start, particularly
downgrades. Do some "what if" scenario planning to be ready for change requests
especially regarding lower limits in data storage and what to do with saved
information that may go over a new limit imposed after a downgrade.
4. Ideally trials and new subscriptions should have wizards or walkthroughs available
when a user first enters the application. If not available when the application
initially launches, these should be added ASAP afterwards.
5. Link the trial mechanism to a CRM lead system. When a new trial is created on the
SaaS site, create a lead in the CRM system. A system for how the lead is processed
within the CRM system should be established, especially as it regards trial follow-up
emails and customer contacts.
6. Make any follow-up email system easily editable so the emails can be updated with
new information and special offers. Localized trial emails are a big plus.
7. Don't set up too many subscription plans! Keep them simple. Don't give customers
"special" subscriptions which differ from those publically available. Make special
deals with pricing, not the functionality or subscription mechanics or the system gets
too unwieldy to manage.
4

6. 10/27/2011
8. Decide how to handle code escrow requests. If you offer this service, make this its own
subscription or or-add on cost or that it is included in a higher priced subscription.
PRODUCT DEVELOPMENT TECHNIQUES
Agile works - but only if you actively support it
Google "SaaS product development" and you'll find a plethora of information on how to go
about organizing development and selecting tools for SaaS applications. The articles usually
mention some current development best practices such as incremental releases, automating
testing and using current standards for data integration and exchange. Agile methodologies
are often recommended for rapid prototyping and for delivering frequent releases. From
what's currently available, I've listed some advice that I've found particularly useful in actual
practice.
RECOMMENDATIONS
1. Use an Agile process like Scrum for product delivery. Make sure your team
understands how to create user stories from requirements and how the overall
process really works. Hire or train a person committed to the process and who will
keep it going after the initial enthusiasm wanes.
2. Make sure your product management and marketing teams are also trained in how
the Agile process works. They will need to work tightly with development and
understand how to help organize and expand the requirements/user stories.
3. Integrate your QA team tightly with
engineering and automate your build and test
systems right from day one. The cost of
creating widespread automated tests is more
than made up the time and effort it saves in
speeding up release cycles.
4. Promote peer programming and testing on a
regular basis. While this may initially slow
the pace down, the benefits of stronger, less
defect prone code will outweigh any delays.
It's also an inexpensive way to provide cross-
functional training. As the team gets more
comfortable with the peer process, the pace
will usually pick up again.
5. Have members of the development team help out with product support on a regular
basis. They should be encouraged to help write FAQs, answer customer questions in
a forum or assist support staff in troubleshooting. The more real-world feedback and
experience they get with customers, the better.
6. Consider using prebuilt components and/or open source for both the product and
testing. There's no value in coding a java pie chart generator when there are
hundreds on the market to choose from. Using open source code may require you to
acknowledge it in some way, so make sure to note if you do so and then have product
management take care of correctly providing the legal documentation.
5

7. 10/27/2011
BUILDING YOUR DEVELOPMENT TEAM
Be smart about new hires and using existing staff
Your current development and QA staff may have the skills you need and it's always good for
moral to use them on a new project. In particular, developers with superior object oriented
skills or advanced computer science degrees usually can quickly learn a new language or use
their skills somewhere on to a web based initiative. However, it's highly likely that you'll
have to hire new staff, especially if you're moving to a new server platform or doing a
complete rewrite in another language. Be prepared to make changes in the team, especially
if you'll be putting an older product in maintenance mode to focus on the new SaaS initiative.
RECOMMENDATIONS
1. Don't make SaaS development a skunk works project. This will only serve to alienate
any new SaaS developers who will usually need support from current engineers for a
transition effort. Co-location is preferred as long as the different teams have space to
collaborate and work together without disrupting one another.
2. Don't split a developer's time between an older project and the new SaaS application.
There can be a transition period from one project to another but have them focus on
just one; they will not be productive if they have to keep switching back and forth.
3. Hire good graphics and UI help. An easy-to-use, interesting UI will set your
application apart in the market and keep users happy, but it usually doesn't come
cheap. Consider using independent contractors instead of design firms or hiring staff
to keep costs down.
4. Don't try to outsource the SaaS development effort if you haven't done outsourcing
before or don't currently use it. New projects with constant change are the worst to
try to outsource, especially if you don't have an outsourcing system already set-up.
5. Forming a new team is a good time to update developer job descriptions and change
or reset their objectives and goals.
6. Don't settle for filling positions with mediocre talent or you'll have mediocre results.
Hiring exceptional people may cost more, but it will be worth it.
HOSTING
Select and manage with care
A wide variety of hosting companies have sprung up in the past few years making it easier to
find the services you need. The company you select to host your application should be able to
provide a variety of CPU options, system monitoring and backups. They should offer a good
SLA and understand that you'll be hosting a commercial application, not just your office
Exchange server. Bigger firms are not always better. Make sure that if you go with a smaller
firm that they have a contingency plan for handling your data and applications should they
encounter business problems or go out of business.
6

8. 10/27/2011
It's good to designate a staff member or small team for setting up and maintaining the entire
application hosting environment at the data center. This responsibility can start off in
development and be a good job for a configuration engineer or someone responsible for
building and releasing client-server applications. The team can be extended to use customer
services staff, especially if round the clock monitoring is needed.
RECOMMENDATIONS
1. In addition to a hosted production environment, at least two other hosted
environments should be set up. This includes a "staging" or mirror environment of
the production system. New releases are deployed and fully tested here before going
into production. A QA test system that closely mirrors the production system should
also be established. While it can be argued that a QA system can be set up and used
internally, having one or more purely test systems in the cloud assures that the QA
experience will adhere closer
to the production system.
2. You'll need an individual or
small team internally to
handle data center
monitoring and to do
application updates and
backup. This can be done by
a developer, but a staff
member currently working in
a traditional IT manager role
can also pick this up. If
recruiting new staff for this
work, consider targeting
hosting companies to find people with the necessary skills.
3. Scalability should be a watchword when developing the SaaS application backend,
including the costs associated with server and database licensing. Consider carefully
if you want to develop on the Windows platform, as back end costs for scaling
Windows and MS SQL servers can be much higher than a Linux or UNIX system.
The same advice goes for Oracle systems.
4. Have a plan for application and code backup which includes a code escrow plan. If
you have enterprise customers, they'll will want an escrow plan as insurance.
5. Build in automated system support tools into your application from the start. If
something goes wrong, having good system monitoring with alarms or flags will cut
troubleshooting time and service support costs significantly.
6. There are always going to be some companies or governments who do not want to use
a SaaS application over the internet, despite any security you may build in. They will
want to have a version installed on site for their use, either on pre-configured servers
you provide or on their own equipment. If you want to pursue such sales, your
hosting team should be ready to do these installations and be ready to support them.
(However, an extremely high price for these services may serve as discouragement!)
7

9. 10/27/2011
TERMS AND CONDITIONS
A new license or usage agreement will be needed
Terms and conditions for a SaaS application are different than for a licensed product. Often
these will include service up time guarantees and application upgrade conditions. These
terms should be developed right along with the SaaS application and deployed as early as
possible.
RECOMMENDATIONS
1. Make sure you are dealing with a legal firm that has some previous experience with
SaaS agreements! You don't want to have to educate them.
2. Begin talking with legal staff well in advance of any alphas release. 3 months ahead
is not too early to start. Have the final agreement or a beta agreement ready to use
by beta launch, if not for an alpha launch too.
3. Make sure legal staff understand what the SaaS application will and will not do and
what type of assurances and guarantees you're willing to provide when they write up
the agreement.
4. Don't forget to cover code escrow if that will be provided.
5. The legal team should know how the terms and conditions will be accepted (check-box
on-line or paper signature), and if the trial terms and conditions will be different from
those for a paid subscription. This information may impact how the agreement is
written or presented.
6. Make sure there's a user story or requirement written to incorporate the terms and
conditions and how acceptance will work. Have someone in development share this
responsibility with product management to insure that any agreement updates or
changes are implemented in a timely fashion.
7. If your customer is moving from a licensed product to the SaaS offering, make sure
that there is a checklist of any licensing differences that the customer should be
aware of, especially if there are functional differences between the two applications.
Sales and Marketing may want to make this part of any upgrade sales information.
It can also be made part of a support knowledge base.
WEB PAYMENTS AND ACCOUNTING
Automated payment systems still need good planning
Purchase mechanisms for many SaaS offerings are self-service, with the payment and
invoicing systems fully automated. This can cut down on accounting costs by reducing
manual payment processes but oftentimes will then require procedure changes to existing
company billing and invoicing systems. Introducing credit card or PayPal processing will
require new procedures to deal with problems and exceptions. Customers are also buying
services not licenses. Bookkeeping practices to record them may now be different. Make sure
that the accounting staff knows about these differences and is aware of what has to be
recorded for all types of subscription or service sales.
8

10. 10/27/2011
RECOMMENDATIONS
1. The payment process should be planned and implemented as a cross-departmental
effort. Someone in both development and accounting should be assigned to handle
the feature development and do testing.
2. Automate as much payment as possible and provide a wide variety of payment
methods (Credit card, PayPal, wire transfer, check). There will be costs associated
with setting up the automation for all of these, but it will save time and
administration costs in the long run.
3. Decide on payment methods early and don't leave the choice to just development or
accounting alone! If you will be accepting credit cards, get information from different
credit card processors such as World Pay on what the technical and administrative
processes will be along with any fees. See what types of reporting and invoicing
services they offer and the types of APIs and test systems they provide. Do both a
business and technical review to select which one fits your requirements.
4. Check with your bank about credit card processing and any new invoice processing
fees that you may now have as a result of adding a new payment mechanism.
5. Decide how to handle purchase order requests. It's extremely likely that you will get
PO requests and need to have a way to handle them efficiently, whether it is
automated or done manually. Even if you choose not to implement an automated
system right away, make sure that the purchase process has a field blank for a PO or
request number for customers to use for their own reference.
6. Decide how to handle resellers. Some firms cannot purchase software services
directly and go through a 3rd party. Write up how you'll deal with reseller inquiries
and post this information prominently in any payment system you set-up.
7. Decide how customer invoicing will be done, what invoices need to be available on the
web and who will have access to them. Make sure that the appropriate accounting,
sales or customer support staff has access to the same invoices a customer may see to
help with any purchase inquiries or issues.
MARKETING AND SALES
Make the most of your direct connection
Like development process, there is a lot of
information readily available on how to market
and sell a SaaS product. A key point worth
remembering is that a SaaS application gives
you more access to data about product usage. It
also provides a direct customer feedback
channel through the application in addition to
email. Use web based analytics and consider
incorporating newer web based "customer
experience management tools" to help you
creatively make use of this direct channel,
being careful of course not to abuse it.
9

11. 10/27/2011
Subscription sales for SaaS applications are often self-service mechanisms, even for
enterprise sales. Users today are accustomed to testing a product using an evaluation
version and then quickly purchasing a paid subscription using a credit card. The sales
process should be as quick and easy as possible, even for enterprise customers.
RECOMMENDATIONS
1. On the company website and support site, build in social networking tools like
Twitter feeds, blogs or Google+ pages to aid in viral marketing efforts. However,
only add the tools you'll be keeping updated. If you add a Facebook link, then make
an effort to read the comments and refresh the info there regularly. Same goes for
any other social network. There's nothing worse than checking out a Twitter feed
and seeing the last tweet is over 3 months old. Consider adding a Social Media
marketing person or expanding an existing marketing position to specifically plan
and manage these social marketing initiatives.
2. Use Google Analytics or other CRM system statistics to keep track of which
knowledge base articles, videos, or forum entries are being viewed. This can give you
insight about product functionality questions or usage problems that can be fed back
into new requirements or a marketing message.
3. If the SaaS application is intended to replace an older application, have an end of life
plan for the older product and a timeline for migrating current customers to the new
application. Share the timeline with them as appropriate and encourage them to give
you feedback and suggestions to keep the experience positive. It's likely they may
look around for another solution, but there's a good chance they'll stay with you if
they feel they are being supported well.
4. Keep the subscription levels simple and easy to understand. If there are add-on
products like an escrow service or premium support, use an automated shopping cart
check out system to streamline the payment process and simplify invoicing.
GOING MOBILE
Start simple and make them look good
Mobile applications are perfect companions for many SaaS applications. In today's market,
not only can they provide convenience for a variety of users, but they can be showcased to
generate some additional publicity for a service. However, not all services extend well into
the mobile arena. Form factor, memory/data constraints and the adolescent nature of many
mobile tools can cause development issues. Cost should also be a major factor when
considering a mobile app, as it may require a separate development effort apart from the
SaaS development team or take away a subset of these resources.
RECOMMENDATIONS
1. Do a quick cost/benefit analysis before launching a mobile app initiative. Make sure
there is a real target audience and enough demand or marketing benefit to justify
starting a project and maintaining it over time.
10

12. 10/27/2011
2. Keep your mobile platform options open. While some applications may lend
themselves more to an Android app than Apple or Rim, the mobile market is
changing fast enough that one platform may not be enough to reach your target
customers. Consider using some of the current cross-platform mobile tools like Rho
mobile or Corona. Building an HTML5 based app or hybrid app may also have
appeal, especially if you
don't want to deal with
different app stores and
multiple client updates.
3. Like the web UI, make
sure any mobile
application will have a
clean and efficient
interface that works well
on a mobile device. Many
browser layouts will not
simply transition to a
smaller format even if
only tablets are targeted.
Ugly or inefficient UIs on
mobile devices are less tolerated by the press and users than web UIs, so prototype
and iterate. Make sure the icon looks good too.
4. Start simple. Trim down the offering on the mobile device using a subset of the SaaS
applications main features. Find out in advance what your mobile customers must
absolutely have and build up using this feature set.
5. Plan on making regular updates to an app. It's become expected that a well
supported app will have a development team that reacts quickly to problem reports
and provides small enhancements on a regular basis. Regular updates also can
provide good marketing content.
CUSTOMER SUPPORT
Plan to exceed their high expectations
Customer support expectations tend to be higher for SaaS applications, even for business
users with their own internal IT support staff. Because a user is connecting directly to a
vendor's servers, the vendor is now seen as responsible for the application and needs to
provide the appropriate support services. Just as most SaaS applications are available 24x7,
support services need to be there too. Users have come to expect prompt attention to
questions as well as having a searchable knowledge base, FAQs and video training. Live chat
and web conferencing where a support rep can see a user's desktop are now common among
tools employed for problem solving.
All of these expanded forms of support need not be costly. Support can be made more self-
service by having a well laid out website and automated tools for suggesting and finding
information. Creating a customer "community" and "crowd sourcing" support where
customers can leave messages and interact with other customers is also a way to lower
support costs along with building product fealty.
11

13. 10/27/2011
RECOMMENDATIONS
1. Community forums, automated trouble tickets, web conferencing and video training
are good to develop right along with the product. Use them to help process alpha and
beta feedback and to gauge their effectiveness.
2. Consider offering regular contests or provide on-line games that users can play to
keep them coming back to the support site. Many users like to show their proficiency
in using a service or application. Consider building in features that can test expertise
levels and give awards or badges for completing tasks or answering questions.
3. Don't build in your own trouble-ticket case handling system. If you don't already use
a CRM or support application, consider linking in a inexpensive 3rd party SaaS based
support system. Choose one with an API that allows you to modify their UI to match
your branding and place specific information from the support knowledge base within
your application.
4. Try to use a single login for the application and support system. It makes the process
simpler for a user and gives the application a more polished and professional feel if
everything appears to be in one system.
5. Good support sites have videos how-to's, so plan to offer them. You can host these
easily on YouTube and link to them on your site if you don't want to host them
directly. They don't need to be fancy, but you should script them in advance and
make sure they receive some basic editing to assure good sound and picture quality.
Keep them short, under 5 minutes to insure people will watch them all the way
through.
6. Pay attention to any standardized text used in tech support emails. Personalize it
and be as specific as possible about why the email is being sent, especially in the title.
This will better insure the mail is opened and read all the way through.
SUMMARY
I'm convinced that moving to a Software as a Service application model is necessary for
established technology companies to compete in today's software services market. This
document does not contain a full guide on how to accomplish everything needed to
successfully launch a SaaS application, but the practical recommendations I've listed can
help a company avoid some of the problems I've seen arise in the past. You're welcome to use
this information as you wish and to reproduce and distribute this document as needed, but
please credit me.
If you have any questions or feedback about the information I've presented, please contact me
to discuss them further. I can be reached via email at margaret.menzies@gmail.com, on
Twitter @MargaretMenzies or on my mobile phone at +31 6 144 995 45.
12