从寿险公司的需求角度来看，保全业务的外包将会是继新契约业务外包以后的寿险公司（超大型寿险公司除外）的必然的选择。寿险公司的每年的保单存量是依赖与前一年的新契约业务量程阶梯状增长的，寿险公司在追逐和陶醉于首期业务的高速增长的同时不可避免的导致了其保单存量的逐年骤增，相应也就引起了保全业务量按年的阶梯状增长。于此同时逐渐走入成熟的次生代寿险公司又面临这巨大的成本压力，根据保全业务量的增长比例来配给客服部门的人力变得不现实，这就要求寿险公司将这块工作内容交给成本更低的外包合作伙伴来处理。保全BPO业务需求的主要来源应该为次生代寿险公司。这一类公司有规模、有成本压力，如果需要进一步的成长必须通过一系列的革新来实现。
- 从BPO公司的供给层面来看，对于成熟的寿险BPO公司（如笔者的老东家）基本上已经和目前的寿险公司里面有实施BPO想法的公司就新契约BPO业务签约完毕，接下来必须寻找新的利润增长点——人们很容易就想到了运营业务流程上的另外的两个重要环节：保全和理赔。保全和理赔的BPO笔者都实施过，个人的观点是保全业务的门槛更低，实施风险更小。理赔BPO目前做得更多的是医疗单证的处理、无历史赔付额的简单理算。这里面临这4个棘手的问题：A、各个地区社保政策不统一导致各个地区理算逻辑不一致，这导致了系统实现层面的一些困难；B、各个医院的医疗单证格式不统一，造成无法对理赔单据像新契约和保全那样做精确的光标定位，这导致了录入速度和准确性的降低；C、对ICD－10库录入的处理人员要求非常高，一般要有医学背景，能否组织起一只有基本医学背景的录入队伍是一个非常大的挑战；D、中国的团险有太多的通融赔付，而这些是不可能做到集约化大规模处理的，导致了在实施了BPO之后寿险公司的理赔审核人员仍然有很多的工作要做，留给他们的感觉是BPO并没有给他们的工作压力带来明显的改观，造成了BPO项目有可能的推动不利。……鉴于以上原因BPO公司可能在新契约之后更倾向于提供保全BPO服务。
这里解释一下为什么超大型寿险公司（如中国人寿、平安）不需要或者需求意愿相对较低：BPO初始阶段最吸引寿险公司的地方是它的低成本，它的低成本主要两个经济学里面的重要理论的实践：规模经济效益和比较优势理论。金融BPO公司就是通过服务与多家寿险客户来达到规模经济效益的，这样做的前提是接受服务的单个寿险公司自身的规模达不到规模经济效益。然而超大型寿险公司自身的规模足以大道规模经济效益，所以国寿和平安都选择了构建自身的后援中心来解决这些问题而不是选择BPO公司做为合作伙伴。另外BPO公司自身也不是特别希望有超大型寿险公司加入自己的客户列表，因为它们的业务量太大了，这样的“大块头”的存在使得BPO公司的峰值业务量不再可以用极大似然估计法来估计，经常出现没有征兆的业务量的突然增大使得BPO公司运营交付能力不足。同时有了如此大的业务量也有可能使得BPO公司走向另一个极端规模不经济。
实施保全BPO业务系统的前提条件（针对寿险公司）
- 保全业务的全影像化、操作流程的统一和标准化
- 核心业务系统的数据集中完成
理想的保全BPO系统模式
- 以保全项目为单位分析、设计、开发并推广。个人认为无论从系统开发层面还是成个BPO项目的实施层面来说保全BPO都应该一个保全项目一个保全项目的推广。原因很简单虽然保险公司的风格不尽相同，所用的生产系统不同，对风险管控的要求也不同，但是目前的保险公司的保全项目大同小异。多数的保全项目我们可以从中抽取出公共的处理方法来统一处理，这样我们就可以从不同的客户的实施经验上面取长补短。另外不同的保全项目很可能有不同的时效要求，有的项目可能要求的是即时回传（2－3分钟以内） ，有的时效要求则没有那么高。我们需要根据不同的保全项目来定制不同的程序处理流程。
- 根据保全项目的不同特点动态生成录入任务，实现流程级别的程序复用。如果要真正的实现动态的生成录单任务，则我们在录入之前的某个时点一定要从客户那里得到该任务是何种保全项目的信息。得到这些信息一般有两种途径，一个是通过影像文件的命名，一个是在传输影像文件的同时一并转过一个录单任务信息的文件（推荐为XML格式）。笔者更倾向与后者，因为后者对客户实施方的核心系统的改造相对较小，更容易为客户所接受。另外要注意从不同公司的保全项目中抽象出相同的子流程以实现流程级别的复用——这里就这样简单说说吧，如果要完全说明白那就是一个完整的解决方案了……另外这里在BPO业务系统流程设计方面一定一定一定要处理好两个细节问题：A、同一张变更申请书申请了多个保全项目，那么这多个保全项目的处理顺序问题——因为处理顺序错了非常有可能得到完全不同的结果。B、同一张变更申请书申请了一个保全项目，而这个保全项目要影响以某个客户为中心的多张保单——这里要看客户的核心系统的锁机制是否完善，否则很可能因为其中某一张保单因其它原因被锁定而导致整个保全项目交易操作失败。
- 以规则引擎实现事前限制性校验和事后标记性校验相结合的规则控制。从系统层面上说保全规则是比投保规则更为复杂的规则。如果还是一条规则一条规则的Decode，这将是一个吐血的工作量，而且很难保证效率和后期需求变更的敏捷性。所以这里我们最好的选择是借助某个成形的产品来帮助我们处理这部分东西，这也就很容易想到了规则引擎。实际目前的一些开源的规则引擎是完全可以满足现在寿险公司BPO业务系统甚至核心系统对于规则的要求的，个人认为比较好的开源产品是Drools。虽然Drools采用的是相对来说比较别扭的“正向推理”，但是它比较完美的实现了“Rete”算法、真正实现了逻辑与数据相分离、知识（抽象规则）的集中化、用业务语言来编写规则——这就足够了。这一部分内容也有两点重要但又非常可能做不好的地方：A、业务规则的识别——什么算一条规则？举个简单例子：X险种可以接受的投保范围是5－65周岁，X险种与附加险Y的比例限制为1：10——虽然前者可能白纸黑字写在客户提供的投保规则里面，但是把前者的业务逻辑放到规则引擎去实现是一个显然的错误，后者才是一条真正要在规则引擎里面的规则。具体原因就不解释了相信大家都理解，我并不是要写教材：）B、如何去组织并抽象规则，规则一定要用分组的方式来管理的，否则很难管理，但是如何分组是一个非常值得研究的事情。另外值得研究的问题是对规则的适度抽象——此处绝对不是越抽象越好，因为根据笔者的过往经验，过渡抽象会引起设计人员和规则开发人员的沟通困难，并且过度抽象会引起实际开发中的把抽象规则实例化的工作量的增加。
保全BPO系统实施所面临的潜在竞争——网上保全没有比让客户自主完成保全变更更好理想的保全解决方案了；而且信用卡网银的功能里面有的功能是和简单的寿险保全类似的，似乎是可以借鉴的成功经验。但是网上保全也面临这一些问题：
- 减小了业务员与客户接触的机会，也就减少了二次展业的机会，这也就是说至少不能获得来自业务部门的支持（很可能是反对）。
- 由于不能面对面交流所可能引发的一系列问题，如因为误解而造成的投诉的增长等。
- 目前尚缺少有公信力而且廉价的CA（认证）机制，有可能引发纠纷。
考虑到这些问题，尤其是第一个问题——由网上保全本身引发的问题，很难完美解决，所以个人认为寿险保全BPO业务，以及其业务系统是非常有前途的。
