近期越来越多的保险公司将一部分的业务外包出来，但是就保险业务的特殊性，存在很多需要注意的地方，这些地方将或多或少的影响整个营运的情况已经保险公司的对外包业务的信心和满意度。因此将接触到的一些保险业务中应该注意的地方在这里说明以下。
I．构架
a) 不同的保险公司有着不同的系统，甚至有的保险公司会为不同的险种有不同的系统，这些系统已经在各个公司内部，分公司内容运作的多时，并且也有着一批IT人员在不断的维护着这些东西，因此在构架的时候，应该考虑到保险公司目前系统的情况；除非，保险的险种相对“孤岛”，或是有足够的灵活性对应对多边的参数，否则建议使用已经成熟的系统来作为后台系统。
b) 连接现有系统的方式：
i. VPN方式
这种方式将会给出一个帐号，能让系统与现有的系统进行连接，但是这种方式存在了安全性的问题，一般情况下会只提供个别的连接来获得相应的数据，然后通过其他的方式将数据传输到呼叫中心系统中
ii. WEB SERVICE方式
这种方式是一个相对比价性的技术，但是在保险公司这种性质的公司中，使用这种方式也就仅仅是数据的一部分，或是一些参数才可以公开，这种方式的应用更多的是在场地在保险公司内部的方式中。
c) 分离功能组建
这里所说的功能组建指的是：负责逻辑，负责控制，负责数据，负责连接的各个服务相对或是绝对独立。
好处：当一个简单的逻辑，或是只是一个参数的变动，将不需要将所有的服务全部停止；当存在了新的需求，例如数据完整性同步，DSS，或是在目前的系统中在添加新的功能，那么各个职能模块可以分开并行进行；
缺点：整合的时候将话更多的时间来调试各个组建间的消息机制；系统的效率低。
II． 安全性
这里所指的的安全性是数据的完整性和安全性，因为各个保险公司将客户的资料公布开来的时候必定也就存在了数据的安全性的要求，一方面，对每天处理的数据都要有一定的备份机制，以确保在特殊情况下的数据完整性；其次是数据的安全性，由于客户的有限性，特别是某些特殊的险种，因此要为客户保密数据是非常重要的一点，不要只是以为数据在数据库中是安全的，另外的安全性还存在与备份，建议给你的备份也做一个密码的保护。不能保证有没有什么AGENT无聊的一条一条的记录拷贝出来，但是可以注意的是不要提供ROW DATA这样的数据，无论是给OPERATION也好或是IT，在设计的时候，就要控制ROW DATA。
III．功能
a) 将险别和险种做的灵活
i. 如果是长期的外包，那么这个指标一定要足够的灵活，换句话说就是要能添加和删除或是更改
ii.一个险别或是一个险种也可以包含的参数存在不同，但是可以给为每个险种存在一个记录标记，就参数可以用特殊的技术处理
b) 每个客户可以有多张保单
i.不可以以为一个客户就有一个订单，一定存在一个客户的多个订单，就算是只做单一的险种，说不定也会出现像“强三险”的出现而产生的2张保单
ii.客户有时候可以为不同的东西，或是同一件保2种险，因此在系统上应该留出足够的余地.
c) 潜在客户的存在
i. 这个是每个保险公司最开心的事情了，如果一个客户在购买的时候，同时又推荐了好朋友来参加，那么就会存在2笔或是很多的成功
ii.为你的添加客户多一个查询功能，因为可能推荐的客户已经被别的同事跟进了，或是已经是数据库中的待销售客户，这个时候，数据就存在混乱
iii. 为潜在客户使用独立的分类标识，目的是为了报表的正确性.
d)记录每个保单的中间处理记录
i.不要只保留保单处理中的最终状态，因为太多的情况会出现在慢慢的处理流程中的变故
ii.不能保证没有特殊情况而导致保单跨过中间的环节
iii.报表的处理（线上投保数，核保通过数，退保数等）这些数字都需要根据时间来得出的，因此能很好的保存每个状况变化的时间点，将大大减少以后报表的处理
e) 数据管理
i. 不要以为拿到数据，然后打完，得到一定的成功量就可以了，因为还有很多工作是要求分析的因此数据的内容应该尽量的完整
ii.客户的数据是一次一批一批的给的，并且在每一批的时候一定给出了相应的地点，时间（或是过期日期），或是手机用户和固话用户，这些信息将最为批号的一部分来保存，那么在最终的分析中也可以真实的得到每次给的数据的质量
IV.报表
如果系统和报表来个比较的话，那么可以这么说：系统60％，报表40％，这点是任何一个做外包销售都知道的，除非客户还不是很了解外包而提出的要求不多，因为报表能很好的考核出外包商的能力，能用最少的数据，作出最多的保单，能用最差的数据作出最多的保单，能在最少的时间里作出最多的保单，这些都是各个保险公司的目标，而对于外包商来说，报表也能很好的考核各个电销人员的能力。
