Facebook and the Downsides of Software As a Service

The tizzy created by Facebook’s page design changes point out some valuable lessons that we should keep in mind as we head more into a SaaS and cloud-based world.

1. Choosing when to change

There are lots of differences between how shrink-wrapped applications and software as a service (SaaS) work, but one of them is that customers of shrink-wrapped software choose when, and if, they upgrade. They kick the tires to look around at the changes beforehand, download a trial, poll other users, wait for the .1 rev and the kinks to get worked out.

With SaaS, changes get pushed out without those wait-and-see possibilities. Facebook is discovering that this can lead to unpleasant surprises for customers, who have no say in whether they want to adopt them right then.

When something is embedded into the flow of everyday life in the way that Facebook (or Twitter) is for many people, any change, whether it’s ultimately better or worse, is going to cause complaint. People get used to patterns of doing things. Even when you change their work-arounds sometimes they don’t like it.

2. Conversation is a double-edged sword

Having said that, on the flip side, SaaS is more responsive when there is feedback. It can turn around updates based on input more quickly, and obviously more universally. But do this too often and you whiplash your users with multiple changes that set and unset particular features, preferences, design decisions, and so on.

Facebook is going to have to tread carefully in the coming weeks as it decides how to respond to the considerable complaining  about the new layout. Facebook is quite different than most “applications” because there are such a variety of ways that people use it, and the experiences that each user has are going to be quite different. (All the more so because of the openness of the platform.) That makes it hard to design for, and all the more important to check one’s assumptions at the door about what people want to do with it, and what features will support those needs.

On a more macro scale, Facebook (and SaaS in general) are emblematic of the more two-way relationship that now exists between companies and customers. The real-time nature of the conversation, and with something like Facebook the ability of customers to vocalize and organize, is a precursor to what the majority of companies will have to deal with in the future. As the  “Cluetrain Manifesto” presciently argued, all markets are going to be more conversational in the future.

3. Don’t design by committee

But that doesn’t mean everything should turn into design by (user) committee, or tyranny of the majority. That’s not how excellent products get made. There has to be a balance between responding to feedback, and recognizing when you see possibilities that your users, for the time being, do not. Your job as a designer and a company is to create capabilities on their behalf, and not just implement exactly what users ask for. (Not in a high-handed way; users’ needs and best interests should always be the focus.)

(It so happens that we had a very lively e-mail thread running around the frog offices about this exact topic recently. Do you stick to the vision or respond to feedback by changing the vision? The answer: “It depends.” Not very satisfactory perhaps, but unfortunately basically true. There are well-known examples of hits and flops based on both approaches.)

Watch what happens…

We should all be watching very carefully how Facebook acts in the coming weeks as it responds to the conversation. It will undoubtedly provide lessons for the future for all of us.

Article found on CRN.com…

Five Best Practices for Implementing SaaS CRM

1.  Build the Right Business Case  

Weigh both SaaS & traditional on site solutions against criteria more comprehensive then just costs.   Depending on your business model, consider differences in business benefits, flexibility and risks when comparing your different deployment options.

In order to understand the total cost of SaaS CRM… you should include license fees, internal labor implementation costs, professional services fees, user training expenses, mobile & offline/online system access, industry-specific functionality, storage capacity fees and premium help desk support.

Two other areas to consider are whether the SaaS vendor’s technology will allow a company to migrate to an onpremise application in the future & the viability and long term prospects of the selected SaaS vendor.

2) Negotiating the Right Contract  

Protect yourself from these contracting pitfalls. 

 Hidden costs when the amount of data and transactions increase on the SaaS application, so too with the cost of the overall deployment

Unexpected Service Outage  Most SaaS SLA contracts have 99.5% guaranteed uptime built into the SLA but few contracts include planned maintaince windows into that uptime and few users track actual uptime.   Users generally shoulder the responsibility for tracking & requesting payouts (and service credits) themselves.  Just make sure you are aware.

Declines in customer support  Initially the customer support is good, but over time the quality of support you could get support from senior level and key developers may decrease.  Again, just be aware.

Obscure disaster Recovery procedures  Make sure to do due diligence around disaster recovery prior to signing the contract

3.  Follow the Right Implementation Approach

Typically SaaS solutions are easier to implement then on premise offerings but customization is more limited.  However whether you are implementing and administering a new CRM SaaS solution, rely on the vendor or use a vendor’s third party professional service partner “successful implementation and integration requires that you follow sound practices”  Define your objectives before you begin the rollout, take a step back & reconfirm the critical business objectives that the CRM SaaS solution will support.   Build a team.. an executive sponsor, a steering committee that includes a user group representative, a CRM SaaS solutions administrator, and a CRM SaaS vendor development consultant.   Define the time line upfront that outlines the major tasks, milestone dates and accountability for implementing the solution.  Configure the solution for user relevance to the specific needs of the users in your organization.

4.  Adopt The Right Data Security Procedures

One of the most common fears of adopting a SaaS CRM programs is security is management.  Require data protection guarantees and compliance with industry standards.  Insist that SaaS vendors provide details about security levels of data centers, disaster recovery capabilities and how data is protected.  If your applications are hosted by a third party, get your hosting provider to detail its security and redundancy capabilities and conduct a site tour to verify its claims.    Be sure to define role and access rights.  Establish vendor data integration conversion & exit blueprints.

5.   Establish the Right Support Structure

SaaS Solutions usually have easy to use point & click tools so that business users can set  up & configure solutions with little technical knowledge and minimal specialized training.  However, a clear governance structure is still required to make sure your organization achieves the benefits intended.   Decide how SaaS will be managed, who will be responsible for meeting IT standards, where the support resources come from and how IT works with third party providers.   In addition, the support staff needs to be clearly identified for users, help desk and training & support offered & backup procedures established – just as companies would with its in house system and support procedures.