第一类是各类虚拟运营商，亦即VoIP圈子，基于IP电话的应用，VoIP从业者具备一些线路资源，往往从成本的角度切入市场，所以，在搭建语音短信/语音通知平台时，更关注搭建成本及性能。
第二类是短信服务提供商，亦即短信SP圈子，与VoIP圈子很大不同，短信SP本身已经具备大量的短信客户，对客户的短信场景及应用理解深刻，开展语音短信/语音通知平台时，更加关注平台的业务功能是否能够满足业务场景需求。
特别的，一些短信SP，兼做大数据服务，那么结合大数据开展语音短信/语音通知业务时将更加具有针对性，此时，短信SP对平台的API接口能力将提出更高的要求。
第三类是存在大量通知需求的终端用户。基于语音短信/语音通知是基于大量数据的通知，这类终端用户要么特别注重数据安全，要么对业务场景有独特的要求，在搭建语音短信/语音通知平台需要结合自身的业务平台进行集成开发。
搭建语音短信/语音通知平台时，不同的群体，对市场需求/业务场景的理解也各不相同，考察系统的着眼点也必然不同，但一些关键点被忽视极可能带来业务上的灾难。
首先，是语音短信/语音通知的业务特点。由于语音短信/语音通知业务，在大多数业务场景下不具备可持续性，高峰期业务量爆棚，业务低潮期陷入停滞也不少见，那么，配套的服务器、线路资源如果使用弹性配置将更加合理，相应的，语音短信/语音通知平台按使用量收费，将更加匹配业务特点，既不用担心业务高峰期性能不够，也不会在业务低潮期为系统成本额外买单。当然，业务量是否大起大落，要结合自身情况考虑。
其次是运营的需求。语音短信/语音通知业务，业务逻辑简单，起量快，而市场信息瞬息万变，需要及时把握；此时，通过建立层级代理的方式，分出部分利润，获得更多的市场机会，以尽可能扩大业务量。那么，不支持层级代理运营&计费体系的语音短信/语音通知系统基本可以排除在外。
再次，系统的突发性能需要考虑。由于语音短信/语音通知具有爆发量大的特点，几千路同时呼出非常常见，那么，系统的吞吐能力将是对很多系统的一道考验。
另外，语音短信/语音通知系统的功能点也需要注意，例如，支持TTS变量以支持带参数的语音通知，收集客户按键以进一步做分析，与挂机短信配合通过设定不同的触发条件以达到更好的通知效果。
最后，API接口能力最容易被忽视。语音短信/语音通知的最终用户，很多自有业务系统，业务场景需要与客户自有系统进行集成开发，此时，API接口能力就会凸显，准确不错漏，实时不积压，需要双方系统的良好配合，在业务高峰期千线万线并发时是不小的挑战。
音短信/语音通知系统，经历市场多年打磨，推出多种商务合作模式，贴近市场实际，欢迎新老朋友洽谈合作。
