Government CRM Software


By Paul Greenberg
customer relationship management


All good, but what of the lingering doubts?  The press has been relentless over the years about issues that dog software as a service. The issues have been consistently the same ones – scalability, integration and most notably for the public sector, data security and the corollary, compliance with security standards.

You’ll be happy to know, those aren’t issues anymore.


This is perhaps the most ironic of all concerns. When SaaS became part of the public agenda in the early years of the decade, the focus was always around either small or medium businesses. In fact, the way that SaaS typically was used in the larger enterprises, according to legend (and fact in the earlier days) was within a single department. Now, to give you an indication of how things have changed, there are deployments of anywhere from 1,000 to 45,000 seats. Even more telling, Eweek reports that over 75 percent of the revenues that SaaS generated comes from enterprises over $1 billion. This is supported by research from AMR, Gartner Group and Forrester Research among others.

Integration - All Shapes and Sizes

This remains the single most significant IT challenge in SaaS environments. Industries that have highly complex, process-intense requirements or high volume real time transactions are likely to have serious integration problems. Integration remains at least a perplexing but, in many cases, solvable issue. For example, SaaS may not be a good choice for a large manufacturing concern that needs to integrate multiple proprietary systems that are organized around production of goods. Where it can be a concern for the public sector in agencies with large on premise ERP systems. The difficulty comes because of what have been typically highly customized processes that are used in highly complex or active environments – for example the agencies that are enforcing regulations with high impact. As SaaS comes up with increasingly specialized offerings, these problems will be less of a concern. Until then, there are several things that you can do to ease the pain of integration if you address them with the vendor. At a high level they are:

  1. Making sure the vendor seamlessly integrates their version of web services and the data that you’re pulling from.
  2. Making sure that the vendor works closely with you to reconfigure the data from your legacy format to the vendor’s format if necessary.
  3. Making sure that the business rules that you are actively using are understood by the workflow that the vendor has available to it. This is less of a problem as more and more vendors are using fully realizes service oriented architectures (SOA) which are aimed at exactly that. For example, if the workflow and business rules are coherent, then there should be no problem easily distinguishing and flagging duplicate records but also no problem recognizing that the same name doesn’t always mean the same person, so to speak.

Security, Data Handling and Compliance

That’s a brainful of a heading – and probably the biggest concern – whether real or imagined – that any government agency has when it comes to software as a service.  Interestingly, the issue has nothing to do with the capabilities or functionality of the application. It is premised on a concern that the host of the service will control the data which rests on their servers. The fear is that potential breaches – if not carried out by the host – are not resolvable under the control of the government agency being breached.

One government agency with highly sensitive data keeps that data on their own classified servers but provide large subsets of less critical data for residence on the on demand host’s servers.

But that actually begs the question. Is the security of the host substantial enough to alleviate the security concerns and delegate them to the realm of the imagined?

This is not trivial by any means. The Office of Management and Budget in 2007 issued its annual guidance to the heads of executive departments and to agency chiefs. Since SaaS was recognized as a viable technical and business model, as long as it met the security controls and standards for the Federal Information Security Management Act, the agencies could use it. So clearly, security was a major concern as well it should be.

To alleviate those concerns, here is a typical SaaS vendor datacenter and its security schema

Physical Security – All hardware (e.g. servers) are housed in a secure “caged environment; Security guards are there 24X7. Security cameras monitor the cage; Access via biometric or some other form of deep ID including picture; Escorts often necessary for customer access to data center zones/areas
Internet Security – SSL encryption at 128-bit for all internet traffic; Global step-up certificates to ensure international compatibility to the encryption; VeriSign or some other authoritative digital security certification
Network Security – Hardware firewalls; minimal routable IP addresses; Network Address Translation (NAT) for all servers so that available places for an attack are minimized; Denial of Service (DoS) protection to shut down DoS attacks; proactive log monitoring to scan for unusual network activity; Logs archived in data warehouses for historic comparison; integrated comparisons of logs to current patterns of activity
Operating System Security – Hardened operating system; unnecessary ports and services inactive; root services stay untouched and protected
Application Level Security – passwords stored and securely encrypted; no way to decrypt or display end-user passwords; multiple password security levels to choose from; can activate lockout of invalid password use; can restrict access via user profile so granularly that you can even allow individual user to login at only specific times; security validation required in a regular and timely fashion

But it doesn’t stop with that. There are even more stringent compliance standards out there that some of the SaaS vendors meet such as ISO 20071 which is the standards and procedures for the Code of Practice for Information Security Management. Certification is optional, but I would suggest you check and see if the vendor candidates you are considering for a SaaS public sector implementation are certified or not. It’s an extra layer that can both help a great deal because of the stringency of the certification and can provide an additional measure of psychological comfort.

One other salient fact: There has been only one security breach at a SaaS vendor since the on demand model surfaced in its current form in 2003 and that was due to an erring employee, not an IT problem or cyber attack.


There is no question that if relationships between citizens and agencies, or among agencies or both, matter to you, then CRM and the on demand version of it can be important choices for you. If your interest is in restoring the faith that your constituents have in the institutions of government, then SaaS CRM can provide you with the capability. If you are just interested in more effective interagency responsiveness, SAAS CRM can support your mission. If you are looking to compete with the private sector for sales or other agencies, SAAS CRM can provide you with the tools you need to be successful. Does that mean that SaaS is a good choice for everyone? No. But it’s a really good choice for many. So start looking, make plans, and talk to who you have to, listen to your constituents and get going. The time isn’t tomorrow. It’s today.