Moving to SaaS by Margaret Menzies

Margaret A. Menzies

10/27/2011

MOVING TO SAAS

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.

10/27/2011

1

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.

10/27/2011

2

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.

10/27/2011

3

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.

10/27/2011

4

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.

10/27/2011

5

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.

10/27/2011

6

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.

10/27/2011

7

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!)

10/27/2011

8

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.

10/27/2011

9

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.

10/27/2011

10

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/27/2011

11

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.

10/27/2011

12

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 [email protected], on

Twitter @MargaretMenzies or on my mobile phone at +31 6 144 995 45.