在信息技术愈来愈普及的今天，关于云计算、虚拟化和下一代计算平台的文章比比皆是。这些计算模式的重要性是不容置疑的，但是具体到 CRM，云计算的重要性体现在哪里呢？该如何评估面向CRM应用的平台呢？为此，笔者给出了如下几个建议。
  1 应用编程接口(API)、语言和库的流行程度
  　　与一个只有一小群忠实开发人员的平台相比，一个拥有上百万开发人员的平台要重要得多。谁还记得ABAP编程语言？如果你不能围绕Ruby on Rails建立一支高效的开发团队的话，则这个平台再漂亮都无关紧要。正因如此，所以要以一种注重实际的态度关注开发人员群体，而不是底层技术，VB.net、Java、PHP、PERL和Python等平台才备受青睬。
  2 附件、工具和开发辅助手段的数量和用途
  　　众多库是否有得到一大群用户(可能是开源用户)的审壹的确非常重要。它们会以适当的方式处理UTF-32字符吗？能够适当处理这种字符的库往往不是太多。同时，你还要关注集成开发环境(IDE)的插件和扩展件(Eclipse或NetBeans)、测试用具(Test harness)以及构建环境。
  3 该平台是一种考虑缜密、表现稳定的集成方式？还是一堆唬人的营销大话？
  　　通常，使用云平台有便于开发和便于与其他广泛应用程序集成这两大理由。应当关注API的一致性和适用范围。你能获得CRM系统里面的所有重要对象吗？API是散布于17个动态链接库吗？还是它们是一组逻辑的Web服务？可以使用任何子系统的所有API吗？还是说平台被分隔开来？应用程序能从平台外面开始执行CRM事务或工作流吗？外部系统能够完全参与到CRM应用的触发器和工作流吗？
  4 实际环境的可扩展性
  　　每个月出现的停运时间有几个小时？在忙碌时段响应时间怎么样？平台拥有资源调控限制吗？还是仅仅为了方便CRM供应商，强行使用死板的代码结构？或者有没有简单直观的方法可以一下子处理1万个或10万个记录？你会惊讶地发现，CRM的API里面在可扩展性方面存在太多的局限性。
  5 为所有API操作而实施的一种细粒度的安全模型
  　　需要考虑安全模型的三个级别：底层数据库的C/R/U/D权限、应用程序级别的角色、对象和操作、以及Web服务的方法。
  　　通过以上的分析，我们可以看到，问题的根源就在于细节之中。这主要是因为有可能获得基于一种非常流行的语言的API，但是CRM供应商可以增添专有扩展件，结果拥有再庞大的开发社区也没多大意义;或者有可能拥有完美无瑕的API，但只能适用于存储在CRM应用的数据库里面的那些数据。
  　　笔者认为，要真正知道你的CRM平台对你来说是否足够可靠、灵活，一个可行的方法就是以某个实际应用为对象，开展试点项目。但是这么做，可能需要高昂成本，不过，和选错平台造成的更大代价相比，个人认为，还是值得的。