Government CRM Software


By Paul Greenberg
customer relationship management


But, in 2007-08, constituent engagement, cost and time savings are by no means the only benefits that CRM and SaaS combined provide. Let’s start with a look at time and cost savings and go from there.

Time and Cost Savings

The traditional overhead in software comes with implementation costs and time and maintenance costs and times. The purchase of a software license doesn’t provide the servers, the security that’s required to keep the data safe, the labor time required to maintain the systems nor all the corollary services (e.g. heating/cooling systems, etc.) that are needed to keep the environment free of problems.  With an on demand deployment the monthly subscription buys you all of that at the site that the vendor hosts – so none of those costs and efforts is directly held by you. While it’s all built into the subscription price, since we can presume the vendor isn’t a. losing money and b. doing this out of the goodness of his heart; it still is a significant cost/time reduction. The SaaS vendor will frequently work on a “you pay for what you get” model called metered usage – similar to a utility company.  This way, you can add services and applications or increase the number of users or pretty much adjust as you need to organizationally, and still pay for only what you actually use. This trumps the costs of any traditional IT deployment at the enterprise level. Studies done by Gartner (actually, METAGroup, before they were acquired by Gartner) in 2003, found that 75% of all IT budgets go to maintenance of existing systems and infrastructure. Much of this cost is sucked out by a SaaS deployment because it is assumed by the vendor.  

The time savings are equally as significant.  Nucleus Research, an analyst firm that specializes in enterprise applications, as far back as 2004, estimated that the typical deployment time for a CRM on premise application is 18 months. The CRM on demand deployment is typically 3 months.  That speaks for itself.

But everything isn’t hunky dory either. Keep in mind that the SaaS costs to you as a company have to be seen over time. You are paying monthly or quarterly or whatever-ly you have worked out with the SaaS vendor for each user. This can mount up if you include customization costs, installation costs which might not be free, and the intangible costs of downtime – since you do have to have internet connectivity for SaaS to work for you. In fact, over a 3 year period – the cycle that usually involves an on premise upgrade – the actual costs savings for using SaaS are not insanely high, but they are meaningful. Yankee Group’s analyst/guru Sheryl Kingstone released a Yankee Group study of on premise v. on demand costs for a 30 user full blown (sales, marketing, support) CRM application  and it was rather telling. The difference in the total cost of ownership (TCO) over a 5 year period was about 37 percent with most of that difference coming in the costs of end user support.  Which brings me to…

Infrastructure Efficiencies

One of the most trying concerns that any government agency has is what is often called “support fatigue” – the amount of labor and expenditure that goes into just maintaining IT services such as server administration, data management, end user support, access and password control, and, near and dear to this documents digital and paper heart, both citizen and interagency management.  As Dennis Howlett points out in his paper on “Five Benefits of SAAS” when you subscribe to a web-hosted application, your organization will no longer have to support:

  • “Purchasing and supporting the server infrastructure necessary to install and maintain the software in-house.
  • Providing the equipment redundancy and housing necessary to ensure security, reliability, and scalability.
  • Maintaining a labor-intensive patch and upgrade process”

I would add to that, no longer have to handle end user support either, nor provide the same levels of administration. The IT department can be focused on doing what they have to do for the these business activities that have to stay on premise. But do keep in mind; you are moving some of those core business competencies to the hosted site too. These aren’t usually ancillary processes or insignificant data that you’ve transferred. Don’t believe every article that tells you now that you’ve gone and done this, you can focus on core competencies. Since when are sales (e.g. U.S. Postal Service, Defense Logistics Agency), marketing (e.g. GSA, Defense Logistics Agency) and constituent support (pretty much everyone in the federal, state or local arenas) processes and data not part of your core business?

The Vendor Loves You More Than Usual - Really

One of the oldest mantras in the enterprise software business is “when you buy the application” you buy the vendor.  With public sector SaaS, this is a particularly cogent point.  In a series of interviews with public sector SaaS customers, one of the overwhelming sentiments expressed by those customers was that from beginning to end, the vendor worked closely with the agency to either solve problems or improve processes or to increase the chances for user adoption – even at their own expense. Many of the contracts are performance-based so it is clearly in the interest of the vendor to do well with the client since this is a contract that has vendor “skin in the game.”

But there is more to it than just that. Phil Wainewright, an on demand industry analyst for ZDNet pointed out in his ZDNet Software as Services blog in December 2006 that because SaaS vendors are hosting all the customers on their servers, they have a highly tuned idea of what’s been successful, fitful or outright failing. In fact, that means that the ability of the SaaS vendor to then either provide the customers with the fixes, new features, more efficient processes or even access to the user communities that are engaged with the vendor. Each customer has an intimate relationship that becomes more meaningful as the need to customize the services becomes more paramount as time goes on. Plus, of course, the vendor can fix the problem you report a lot more quickly than the on premise vendor because the problem resides on the servers sitting in front of them, not the hands of the customer. To fix the latter means scheduling technicians and making sure that vendor and customer time are coordinated well. To fix the former is a phone call and work right at the server farm. No customers need to be there. When the fixes are completed, if this is a more universal problem, the fixes can be easily replicated (or not) across as many customers as need be or can be applied to just the customer who called in.

Forward Thinking: Easier Upgrades, New Features

One smaller but important benefit of SaaS is the way that upgrades are handled. As you probably have experienced, the classic upgrade pattern for larger on premise software implementations takes significant resources, causes cultural shifts, breaks a lot of the customization that has gone on using prior versions and involves costs that can be significant. But it just isn’t nearly as difficult to upgrade a SaaS application service.

There are a number of models used for upgrading SaaS applications. They range from incremental upgrades to full upgrades. They range from choose whether or not you upgrade to automatic upgrades. They vary from pick and choose the individual features that might be of interest to its all coming to you at once without choice. Regardless, one of the beauties of the SaaS model is that upgrading is a very easy, almost ordinary process, rather than a major transition in culture and operations of an organization. Never thought the word “ordinary” would be a good thing, did you?