交换机制:
- FLEXQUEUE内置了有线状态机、实时线程技术、分布式、基于内存的容错型数据库，实现交换事件消息的实时触发传递以及查询
- 而Vicidial依赖于SQL数据库查询周期性地轮训对象状态，有多少路呼叫、多少个坐席，就有多少个查询进程，依赖SQL 的事务更新操作去传递事件，这些查询和更新进程会相互竞争。
交换性能:
- FlexQueue的话务交换具备快速、实时、准确、高容错性，以及低资源消耗特性，很容易扩展到几百个坐席，甚至上千个坐席
- 但是对于Vicidial，则很不容易达到，当vicidial的系统系统规模扩大时，要求配置大容量的数据库服务器，适应高速SQL操作需要，系统非常容易出现SQL死锁和缓慢的事件信息传递
365x24不间断服务:
投入运行的呼叫中心系统通常不能承受系统停止、通讯中断的事件，每个来电意味着订单，每次停顿，会损失一批客户.
- 对于FlexQueue，每次维护，包括升级系统，更新配置，系统均处于正常运行服务状态，无需停机、或重启；
- 对于包括Vicidial的其他系统，您必须重启后台服务进程，以使新的修改、新的配置生效。
稳定性:
维护要求：
- 从FlexQueue上线第一天起，系统将一直保持稳定运行，如同第一天，需要非常少，甚至无需维护和管理；
- 但是对于类似Vicidial的系统，你必须非常关注数据库维护、资源耗用、以及头痛的内存泄露。
失败检测与自动恢复：
- FlexQueue内置了针对所有工作线程的超级监控线程，如果有工作线程异常退出，退出事件将被实时传递给超级监控线程，该工作线程将被实时自动重启；
- Vicidial使用进程状态定时检测机制，这个时间间隔是60秒；其它软件也采用类似办法，间隔时间不等；如果有进程异常退出，那么将会有超过60秒的宕机时间。
- Vicidial为了防止与Asterisk的AMI端口连接产生死锁，将每隔24小时，重新连接Asterisk AMI端口，这会导致话务信息的丢失。
可扩展性 :
- 根据Vicidial的作者，建立一个单数据库服务器、坐席数量超过300以上的呼叫中心非常困难，随着坐席数量增加，你必须为mysql配置庞大的服务器阵列。
- 但是对于FlexQueue，这个系统容量的增加非常平滑，包括坐席数量和通话线路数量，FlexQueue不需要高端、或大容量服务器，可以通过增加cpu，或普通服务器，将运算线程分布出去。
实时性 :
- Vicidial及类似系统，不但话务交换和分派，是采用数据库查询和更新操作，以少于1s的时间间隔，不断轮询和分派，获得最新对象状态，或传递事件；其客户端与服务器之间的通信也是采用定时查询技术，所以各个环节均存在延时，您会经常发现您已经听到客户的通话，但还不没有看到客户的信息；
- 对于FlexQueue，没有消耗资源和带来延时的定时或周期性轮询，内置有限状态机，事件触发状态转换，事件触发消息传送，全部实时处理，客户端被动接收消息
二次开发接口(API)和软件定制 :
- Vicidial 没有提供标准的开发接口，尽管开源，但代码冗长，风格很差，难于理解，没有很深的PHP、PERL、JS功力，很难做到二次开发。
- FLEXQUEUE 提供形式统一、基于文本消息表达的API调用接口，可以基于客户端和WEB方式进行二次开发，极易与客户已有系统集成，我们也另外提供集成样例代码