自毕业到现在，在呼叫中心这个行当滚打了那么多年，不能说是见识了多少风风雨雨，但是经历形形色色的客户倒是事实，特别是外包业务的呼叫中心，更是如此，你能碰到的客户可能是一个长期的客户：一做就是几年；要不就是短期的：1－2个月就搞定的。于是对于不同的客户以及不同的客户需求，就有着很多中实现方案了。以下，我就几点系统开发和规划方面的经验与大家一起分享以下。
市场调研项目：
这种项目应该说是比较简单的项目，只要打出电话去，联系客户，收集要的资料，保存呼叫结果，就可以了，这种项目一般情况都是比较短期的，除非有些特别的客户，例如咨询公司、数据公司等。
技术标准：
数据的准确性——这点应该是市场调研公司的注意的关键地方，很多公司要求给的数据有长度的限制，字节的限制，选项的相互逻辑性的控制等，以确保数据的准确性，而且这个也将成为KPI来处理。
数据的可重复利用——一般情况来说，市场调研的标准是数据的准确性，要求提供多少份合格的数据就可以了，但是有时候会出现数据量不够或很差的情况，大的咨询公司可能还要求给出更详细的数据使用情况报表，因此这点也是技术上要考虑到的。
数据的真实性——这点要就要求而言，不同的公司仍然有不同的要求，但是我相信如果没有录音系统，那么这点对与技术而言就没有什么意义了。
可变性——这点一定要注意，不要给自己找麻烦，因为这样的客户，往往会在不同的时候给出不同的变化，如果是短期的，可能不会，但是如果是中期或是长期的话，一定会发生这样的情况。
实现方案：
一个数据库就可以了，但是就情况来说，不是什么都用一个数据库，如果是很简单的甚至给个Excel就可以满足要求了，如果是大的或是要求复杂的公司，那么建立一个系统是个很好的方法，利人利己。
方案1.
短期项目，要求不高，收集的资料没有特定的逻辑或是逻辑相当简单，AGENT数量不多：建议使用EXCEL来作，只要一个TEAM LEADER来分配数据，每天收集成功的数据，进行数据筛选就可以了。一般不需要工程师的支持，如果需要的话，也就是给个好用点的EXCEL模板。
方案2.
中期项目，要求不高，但是问卷的内容存在变化，存在简单逻辑，建议使用.NET技术开发，更新也好，发布也好很方便，但是需要数据库的支持，因此需要有一个数据库开发工程师，一个.NET开发工程师。
方案3.
中长期项目，要求很高，既需要字段的长度，又需要字段内的内容不存在全角或是特别字符，又要求符合逻辑，一定使用数据库支持，同时前端建议使用DELPHI或是C++开发可以很好的控制字段内容和逻辑，为什么不建议使用VB那？因为VB的字段长度控制存在问题。需要一个数据库开发工程师，一个前端开发工程师；
（注明，以上的方案中，都假设有现成的CTI支持，因为不同的公司有自己不同的CTI，不同的排队机也有不同的CTI，可能有直接提供OCX控件的，当然也可能只是给了个2次开发的DLL）
电话销售：
项目的目的很简单，能很好的联系客户，进行销售，成功的订单量是最主要的目的了，于是对于系统的要求也就是“信息”——其中包括了FAQ,相应的新的优惠措施等，但是这些都可以在TEAM LEADER的BRIEFING中得到信息，但是毕竟一开始的时候这些东西是十分重要的，在对于一些大的客户的电话销售的项目中，还要注意真个系统的开发尽量降低流程的关节，能够一个人一通电话结束就最好。
技术标准：
流程简洁——一般的电话销售都认为流程很简单，其实必定存在不可确定的因素：例如上门送货后失败了，用户没有来，用户反悔了等，这些情况必然会引起后续流程的出现，这些流程的出现将导致2个严重的问题：1，报表，一天和一天的报表是固定的，如果有退单的情况出现，那么对于前一天的报表就存在问题，那么就需要表明，或是用别的方式将实际数字和情况表示出来，虽然这些是营运要考虑的问题，但是作为IT，他们一定会来和你说“我只要一个准确的报表，不关你用什么办法”，于是就把压力转交到你这里了，所以在一开始的设计时候就要考虑到这点。
质检——这点和上面的不同，因为这次的质量检测指的是对必须信息的必要性的检查，因为这样做可以提高订单的准确性。
预约数据的控制——不要引起客户的反感，所以对于预约的数据或是BUSY NO ANWSER的数据都要做次数的控制。
实施方案：
方案：
一般电话销售存在以下几个步骤：
A． 数据的提取，进行电话销售；
B． 销售成功，成功订单；销售不成功，决定是否有机会再做销售；预约；
C． 核实订单，决定上门的时间和地点；
D． 上门的结果反馈；
E． 成功：标记成功，失败：表明原因，有销售人员决定是否可以再跟进；
这个项目的实现没有什么技术上的限制，可以用你喜欢的技术，根据开发时间的长短来决定，但是还是建议使用B/S方式，一定要注意状态的明确，时间和人也一定要明确。一个数据库开发工程师，2－3个开发工程师。
客户服务：
这个应该是INBOUND的业务了，没有固定的标准，因为可能客户有了他们自己已经很成熟的CRM系统，你要做的就是给他们一个CTI就可以了，让他们可以打电话接电话，然后给他们像CMS这样的报表就可以了，当然，也可能从头到尾的CRM都要你来开发，这样的项目我是比较喜欢的，比较有挑战性，一般就不是2－3个工程师能完成的任务了，如果时间紧迫的话，那么就需要更好的控制了。
技术标准：
IVR——一个少不了的INBOUND东西，没有语音流程就没有好的客服了，能让用户在IVR里面结束他们的问题就最好了，那么就可以降低AGENT的工作量，那么IVR的设计就尽量简洁明了，不要多而繁琐的IVR，因为可能客户还会问你要IVR报表来考核你。
完善的CASE系统——对于客户服务来说，CASE系统是少不了的，用户的每一通电话都将是一个CASE，所以CASE的分类，CASE的解决方案是你在开发的时候要考虑到的，而且这点东西一定在不断的增加当中的，你可以用数据库来保存，但是我的已经是用个文本文件来保存更好，因为这样起码可以降低不必要的数据库请求，因为CASE库是很庞大的，在上面做的东西很多的。而且CASE的状态的变化也是可能会变的。
复杂的DSS——对于客户服务而言，营运部门一定会问IT要数据分析的很多报表了，这点你要做好思想准备，CASE的分类，解决方案的分类那是一个不可能缺少的东西，每天的，每周的，每月的报表也是，所以你要建立一个CONTACT HISTORY来保存CASE在每天的结果，那么无论是天还是周还是月的话，报表是不会错的，否则只留一个状态，你就哭去吧。
速度——有的公司要求ACHT的时间有控制的，因此慢的很的系统建议你不要用，用的话，责任就都是你的了，营运会把ACHT的原因进行详细分析，然后，如果存在一点点系统的延时引起的ACHT长度增加的话，那么你的责任就大了，所以，建议不要用J2EE，那个东西在人少的时候还可以（10－20个），如果（50）那么就慢死你了，然后系统开销又大，老板的钱不会随便花的。
录音——请保证你的录音一定有。
实现方案：
J2EE方案：开销大的方案，除非出于客户的需求和你有很强的技术人员，否则建议不用这个方案；但是他的好处呢，可以移植，作个完整的，以后还可以出去卖，一个很不错的第三产业；
.NET方案：强烈内部推荐的方案，速度快，懂的人多，系统开销小，维护方便多了；
以上都是一点点我的经验啦，由于边幅的问题，很不具体，如果你是IT的或是对我们的IT很敢兴趣或是有什么好的经验或问题都可以发邮件来联系我，哈哈。
无聊的时候写写文章也不错。学习还是硬道理….
www.51callcenter.com注:
作者联系方式:netis_sun@hotmail.com
呼叫中心行业资讯网
