广州市聚星源科技有限公司
广州市聚星源科技有限公司、某某家居股份有限公司计算机软件开发合同纠纷民事一审民事判决书
来源：中国裁判文书网
广州知识产权法院
民 事 判 决 书
（2019）粤73知民初1278号
原告（反诉被告）：广州市聚星源科技有限公司，住所地广东省广州高新技术产业开发区。
法定代表人:田兆俊，该公司总经理。
委托诉讼代理人：田兆全，该公司工作人员。
委托诉讼代理人：靳中山，广东法制盛邦律师事务所律师。
被告（反诉原告）：***家居股份有限公司，住所地广东省广州市增城区。
法定代表人:江淦钧，该公司董事长。
委托诉讼代理人：李涵，广东南方福瑞德律师事务所律师。
原告（反诉被告）广州市聚星源科技有限公司（下称聚星源公司）与被告（反诉原告）***家居股份有限公司（下称***公司）计算机软件开发合同纠纷一案，原由广东省广州市天河区人民法院立案受理。该院后于2019年7月23日作出（2019）粤0106民初8248号民事裁定书，以本案为专属管辖案件为由裁定移送本院管辖。本院受理后依法组成合议庭进行审理，先后组织双方当事人举行庭前会议、技术勘验及公开开庭。聚星源公司的委托诉讼代理人田兆全、靳中山，***公司的委托诉讼代理人李涵到庭参加诉讼，本案现已审理终结。
聚星源公司起诉请求判令:1.***公司支付聚星源公司项目费用409500元及相应的逾期付款违约金（其中351000元的违约金自2017年10月30日起计；58500元的违约金自2018年10月29日起计，均按银行同期贷款基准利率标准计算至款项付清之日止）；2.***公司支付聚星源公司因诉讼需支付的律师费30000元;3.***公司负担本案全部诉讼费。
起诉主要事实与理由:2017年5月3日,聚星源公司与***公司签订《***微信客服系统项目实施合同》，约定***公司向聚星源公司购买FICC呼叫中心系统V6.0-微信客服管理，聚星源公司负责实施及开发，合同总金额为716800元，并约定了付款方式，同时亦约定败诉方负担胜诉方的律师费。合同签订后，聚星源公司依约提供了系统硬件并经***公司验收合格，同时完成安装开发工作。但***公司仅支付了307300元，且有逾期支付的情形，目前还欠聚星源公司余款409500元。经聚星源公司多次催收，***公司均拒付。聚星源公司认为，双方合同合法有效，聚星源公司已依约提供了产品，***公司使用至今且从未提出任何异议，其应履行付款义务，现尚有余款未付，严重侵犯了聚星源公司的合法权益。
***公司答辩称，请求驳回聚星源公司的全部诉讼请求。主要答辩理由：聚星源公司开发的项目至今未能达到验收标准，未通过验收，已经给***公司造成严重损失。项目因聚星源公司原因未能完成开发，合同约定付款条件不成就。聚星源公司因自身原因不能完成开发，应当承担全部责任，***公司在合同履行过程中不存在任何过错，不需要承担任何责任。***公司无须承担聚星源公司的律师费，且聚星源公司提交的合同反映律师代理的还包括其他案件并非仅本案，聚星源公司支付的实际费用与其主张的数额也不相符。
***公司反诉请求判令:1.聚星源公司向***公司支付违约金164936元;2.聚星源公司向***公司支付律师费40000元;3.聚星源公司负担本案全部诉讼费用。
反诉主要事实和理由：2017年5月3日,聚星源公司与***公司签订《***微信客服系统项目实施合同》，约定***公司向聚星源公司购买FICC呼叫中心系统V6.0-微信客服管理，聚星源公司负责实施及开发。2017年5月8日项目启动后，***公司依约于2017年6月22日向聚星源公司支付了第一、二阶段费用共307300元。但因聚星源公司自身技术水平问题，导致所开发的系统存在严重问题，无法在约定的2017年8月18日完成开发，***公司本着友好合作目的，同意项目延期至2017年9月18日，但聚星源公司仍未完成项目开发，无法提交符合验收标准的开发成果。2017年10月13日首次部署在线上测试，但不属于整体的完成交付。2017年12月7日，聚星源公司承认基于目前开发设计无法解决系统问题，提出从底层通讯到上层应用重新设计微信客服系统。2018年1月至2018年6月，聚星源公司提交了变更后的项目系统开发成果进行测试，但相关问题仍未能完全解决。2018年6月13日，聚星源公司发函要求验收，但经测试系统无法达到验收标准，未能通过验收。双方于2018年6月30日围绕项目存在问题召开验收标准讨论会，聚星源公司承诺在2018年7月16日前完成项目所有功能开发，保证测试不会出现问题。但在该日之后，聚星源公司不但未履行承诺，且开始对***公司采取置之不理、不予回应的态度，涉案项目完全搁置，至今再无进展。根据合同约定，涉案项目最基本的要求为具备良好的沟通功能和营销功能，在较多人数同时接入时应当仍然具备稳定性，但由于聚星源公司的技术问题，该部分核心的沟通功能、营销功能一直无法正常实现，包括机器人智能回复答非所问且出现大量令人啼笑皆非、极其影响***公司品牌形象的回答，系统在人数达到一定程度时即出现严重的不稳定情况，无法持续正常使用。***公司认为，聚星源公司至今未能完成项目开发达到验收交付标准并通过验收，严重违反了合同关于开发期限的约定，给***公司造成严重的损失，应当承担逾期开发的违约责任。违约金根据合同第6.2.3条约定，以合同总额716800元为基数，按照每日万分之三的标准从2017年9月19日起计算至***公司提起反诉之日的2019年10月26日。
聚星源公司对反诉答辩称，请求驳回***公司的反诉请求。主要答辩理由：（一）聚星源公司开发的第一版微信客服系统经检测合格，于2017年10月13日正式上线，且系统运行正常，无重大系统故障。1.聚星源公司先后开发完毕合同约定的沟通模块、知识库、与内部系统对接部分、营销功能、数据统计、客服管理六大模块，***公司于2017年9月24日确认“系统各功能模块已达上线标准，可以部署上线。”该系统于2017年10月13日上线，上线前就已经进行测试，系统持续正常运行近两年，不能仅因***公司拒绝验收、没有验收报告即否认系统验收开发完毕及运营正常。2.***公司称系统存在严重问题与事实不符。所谓的问题要么是***公司的电信网络不稳定、网络闪断导致，要么是属于售后服务阶段系统运营过程中出现的系统维护问题，但这些问题均已及时解决。从2017年12月聚星源公司提出开发新版本一直至2018年6月申请验收的半年中，双方之间的沟通文件均显示是针对新版本进行，没有提及旧版本。3.涉案的FICC呼叫中心系统V6.0、微信应用平台V2.0是取得版权登记的标准产品，且经第三方国家工信部泰尔实验室测试合格。（二）聚星源公司开发的微信客服系统项目新版本是旧版的升级版，比旧版本性能更好、功能更强大，完全符合合同约定的验收标准。***公司为达到拒付款目的而故意不验收、不上线。1.系统的第一版是按合同约定开发的。因***公司系统不稳定而造成使用故障，为解决这个问题，如果在第一版上处理起来困难，故聚星源公司打算重新设计一个新版，增加一些容错处理。此外，***公司单方提高技术标准，要求达到800并发和1000并发，聚星源公司本着诚意合作，尽最大努力不计成本为***公司开发。2.新版本出现的全部问题已经解决，***公司故意制造障碍拒绝验收。按合同约定，聚星源公司于2018年6月19日提交验收申请，***公司没有验收，而在6月30日开会讨论所谓的验收标准，超过一周该项目视为默认在2018年6月26日通过验收，所以不存在***公司所述不符合合同约定标准的问题和至今未交付的问题。3.关于机器人回答的问题，机器人只是一个工具，客户问什么就回应什么，这些素材需要***公司提供。聚星源公司找***公司配合建知识库内容，但***公司以工作忙为由拒绝配合。4.***公司盖章的《终止合作协议》《已履行项目内容清单》表明，聚星源公司已完成合同约定的开发内容，不存在系统不稳定、系统基本模块未达到使用需求的问题。（三）因聚星源公司不存在违约，***公司反诉主张迟延违约金的请求不应得到支持。按合同约定，聚星源公司只有在没有按照合同确认的项目进程履行相应义务造成项目延迟时才应支付违约金，本案中充分证据证明聚星源公司早已完成项目开发，只是未能进行验收。关于超过三个月开发期限的问题，延期的主要原因是***公司变更数据库需求及基础环境不具备。聚星源公司的产品是基于SQLserver数据库开发，在需求调研SOW工作说明书对数据库没有特别约定，则通常以产品标配的数据库为准。***公司在开发过程中的8月25日邮件才要求转换数据库为MYSQL，聚星源公司需要对数据库重新开发，属于重大需求变更，增加了开发工作量和开发成本。涉案证据中的邮件已经列明***公司未提供80端口导致微信授权失败。基于上述原因，***公司同意延长至2017年9月18日完成开发。另外,违约金计算标准过高，应以未付款相应的比例计算。
当事人围绕诉讼请求依法提交了证据，本院组织当事人进行了证据交换和质证。对当事人有争议的证据和事实，本院认定如下：
聚星源公司提交证据6《民事委托代理合同》、增值税专用发票及银行电子回单，拟证明因本案开支律师费。***公司以合同内容与本案无关为由不予认可。本院经审查认为，聚星源公司提交的合同为与广东智洋律师事务所签订，委托事项还包括另外因《技术服务合同》的纠纷,因聚星源公司此后另提交了与广东法制盛邦律师事务所签署的《民事委托代理合同》，本院对前份合同及相应的票据不予采纳作为本案认定事实的依据。
聚星源公司提交证据13***区域电销工作群（2018年9月），拟证明***公司网络不稳定，网络闪断，造成消息发不出去等故障。***公司质证认为，该工作群来源、人员真实性无法确认,且没有谈话背景，从表面判断涉及的是西宁、扬州地区的网络问题，本案涉及区域是广州及广州增城，内容亦与本案争议无关。本院经审查认为，因聚星源公司无法进一步证明相关内容与涉案争议具有关联性，不予采纳作为本案认定事实的依据。
聚星源公司提交证据14计算机软件著作权登记证书（2本）、呼叫中心系统验收测试报告，拟证明涉案的软件系统FICC呼叫中心系统V6.0，微信应用平台V2.0，系取得法定证书的标准产品，且经过第三方测试合格。***公司质证认为，著作权登记证书远早于涉案合同签订日期，与本案显然无关；测试报告软件为“MCN客户服务呼叫中心”，非本案的“FICC呼叫中心系统”，测试报告没有原件，不作确认。本院经审查认为，涉案系统为在标准软件基础上作进一步开发的项目,基础软件是否合格,与二次开发的项目是否符合开发需求,两者之间没有必然的因果关系,测试报告没有原件可供核对。本院对证据14不予采纳作为本案认定事实的依据。
聚星源公司提交补充证据2019年7月29日的微信工作群聊天记录，中有内容称“大家早上好！电销新系统上线时间是8月1日18：00，新系统上线以后旧系统只保留查询旧资料的功能，其他呼叫功能、短信功能、新资料分配保存等功能将无法使用。”聚星源公司拟据此证明***公司一方面说涉案系统达不到条件，另一方面又持续使用到2019年8月1日才上线其他新的系统。***公司认为，聊天记录中提及的电销系统是双方签署的《***电销呼叫中心项目合同》所涉项目，聊天内容与本案无关。本院经审查认为，由于聚星源公司确认有与***公司签署过《***电销呼叫中心项目合同》，微信聊天群中的聊天内容不完整，无法反映与涉案争议项目直接相关，本院不予采纳作为本案认定事实的依据。
对当事人无异议的证据，本院予以确认并在卷佐证。根据当事人陈述和经审查确认的证据，本院认定事实如下：
（一）主要签约事实
2017年5月3日,***公司（作为甲方）与聚星源公司（作为乙方）签订《***微信客服系统项目实施合同》（下称合同），约定由乙方为甲方提供项目实施服务。
合同第一条“项目内容”约定包括：1.1项目主题为FICC呼叫中心系统V6.0—微信客服管理。1.2项目内容参见附件一开发需求，开发工期为三个月，项目阶段包括项目启动、蓝图设计(业务需求调研、X计划接口调研、原型页面确认)、系统实现（微信客服功能开发调试、***微信第三方后台数据同步，X计划接口开发调试、报表开发、知识库布置、微信坐席程序部署）、用户测试（微信系统功能测试）、上线准备（文档验收、正式环境迁移、系统试运行）、上线支持和正式上线，正式上线时间为2017年7月18日。
合同第二条“项目实施费用”约定包括：项目服务费用总额为716800元（含17%增值税专用发票），包括两部分，分别是，***微信客服系统包括沟通模块、知识库、与内部系统数据对接部分、营销功能、数据统计、客服管理、微信群监控模块、QQ群监控等8大模块，计585000元；服务器配置包括录音服务器（DELLR730服务器）1台、数据库服务器（DELLR930服务器）1台、微信服务器（DELLR730服务器）1台，计131800元。
合同第三条“付款方式”约定包括：3.1项目实施费用按照3个阶段来支付。合同签订后10个工作日内，甲方向乙方支付本合同费用的30%即215040元。乙方硬件服务器送货至甲方，甲方开箱检验合格后向乙方出具收获验收单，经验收合格后10个工作日内，甲方向乙方支付服务器配置项费用的70%货款即92260元。乙方微信系统完成开发，经双方验收合格后10个工作日内，甲方向乙方支付微信客服系统费用的60%即351000元。从微信项目验收合格通过之日起12个月的10个工作日内，甲方向乙方支付微信客服系统费用的10%即58500元。每个阶段付款前3日内，乙方应就该部分款项向甲方开具符合甲方要求的发票，如因乙方迟延开具发票，甲方有权将付款期限相应顺延。
第四条“项目实施时间和地点”约定包括：4.1本合同实施阶段从2017年4月18日起至2017年7月18日止；本合同项目实施完毕后，乙方将继续为甲方提供上线服务支持。
第六条“相关权利和责任”约定包括：6.2.3乙方应严格依照双方确认的项目进程履行相应义务，若因乙方原因造成项目迟延，每延迟一天乙方需向甲方支付合同总额万分之三的违约金，甲方有权在未付款项中予以扣除。非因甲方原因需要加班的，超出工时的费用由乙方自己负责。6.3乙方对该系统提供终身维护，对本次项目新增的开发内容提供一年免费维护。6.4乙方向甲方免费提供2天培训工作。
合同第七条“项目验收”约定:7.1本项目的验收约定项目进程为依据，乙方完成开发内容后通过邮件方式向甲方提交验收通知，甲方在收到验收通知后的3个工作日内组织双方人员进行验收，验收完成后双方签署项目验收报告，如甲方在收到验收通知后一周内未作验收可视为本项目默认验收通过。7.2验收报告在双方项目负责人签字确认时生效，并视为甲方已确认该验收报告所对应的项目实施阶段验收完毕。7.3项目验收标准:按约定开发内容，具体可参考附件一《***微信客服系统项目SOW》进行验收，系统可正常运行，无重大系统故障。
第八条“知识产权”约定包括：8.2呼叫中心系统软件产品的知识产权归乙方所有。甲方具有该系统的使用权。
第十一条“合同签订地、适用法律和争议解决”约定包括：11.4双方同意败诉一方应按败诉比例承担胜诉乙方因诉讼产生的费用，包括但不限于胜诉人律师的合法收费等。
合同附有《***微信客服系统》，共有7部分。其中，“3.项目概述”对沟通模块、知识库模块、与内部系统数据对接部分、营销功能、统计模块、客服管理模块等六大模块的功能需求进行细化,并在“3.2功能需求”中详细列明。
3.2.1“沟通模块”中的“一、消息接入”功能包括：“消息可设置自动接入或者手动接入，可设置自动接入数量，最好自动接入数量可以超过100以上。”“设置消息接入的优先逻辑：带有订单标识的客户优先接入；并能自定义显示客户信息：基本资料、订单、上次咨询备注、聊天记录等。”“机器人接入按照机器人的回复规则和设置的话术库回复。”“二、话术库”功能包括：“设置话术库后，所有客服账号都以调用话术库内容并选择话术向用户推送。”“三、沟通”功能包括：“聊天过程中，客服可填写工单标注是否处理完成、咨询类别（投诉、咨询定制、报名、环保、价格、员工、活动、咨询订单等，类别可自定义增减），工单跟呼叫中心打通，可转接给400客服处理，处理完毕返回信息。”
3.2.2“知识库”中的“二、接入智能客服”功能包括：接入智能客服回复分析，模糊词的推理分析，缩略词识别，错别字识别。”
3.2.4“营销功能”中包括：“一、能实时从***微信第三方后台同步更新关注的用户，可通过剩余沟通时间，关注时间，咨询次数，用户地区等维度筛选用户。”“五、可以在页面上添加搜索功能，例如接客户的状态，新申请等。”
“6.项目验收标准”约定包括：1.完成本文档3.2所有功能;2.通过可行性测试、性能测试;3.所有功能运行平稳，无重大问题;4.项目成果物如期提交;5.完成关键用户培训，关键用户能独立操作和解决简单问题。
（二）主要履约事实
2017年5月18日，聚星源公司向***公司提供了DELLR730服务器2台和DELLR9304U机架式服务器主机1台、内存条4条〔见聚星源公司证据2〕。2017年5月19日，聚星源公司向***公司开具FICC呼叫中心系统V6.0费用发票111150元和103890元共计215040元。
2017年5月19日，***公司工作人员李健明发送邮件称，微信客服系统项目于2017年5月8日正式启动，计划于2017年8月18日结束。邮件附件有需求确认表，表中部分功能需求已确认。
2017年6月1日，聚星源公司向***公司开具DELL服务器费用发票92260元。
2017年6月22日，***公司向聚星源公司支付软件平台费用215040元和92260元。
2017年8月19日，***公司工作人员李健明发送邮件“微信客服系统项目周报（20170814-20170818）”。周报载明，因聚星源开发团队原来运行环境是SQLserver数据库，但***公司同意的数据库为MYSQL，需进行数据库环境转换故上线时间延迟到2017年9月18日，另还需解决不能提供带有80端口固定IP的问题，否则微信不能成功授权。
2017年9月15日，***公司工作人员李健明发送邮件称，微信客服项目已进入测试阶段，并于当天进行了UAT测试。李健明列出测试中发现的12个问题，要求聚星源公司尽快修复。
2017年9月17日，***公司工作人员李健明发送邮件称，经过周末两天测试发现，测试情况不理想，经评估明天项目不能上线。存在3个主要问题。
2017年9月21日，***公司工作人员李健明发送邮件称，经修复与优化，原先发现的46个BUG都已解决，暂未发现新BUG。经压力测试，在模拟1000个用户并发和在线用户37609人时，机器人在高强度运行状态下出现报错，但已找到报错原因，需再验证。
2017年9月22日，***公司工作人员李健明发送邮件称，经大规模UAT测试发现8个问题，对上线计划不会造成影响。
2017年9月24日，***公司工作人员李健明发送邮件称，经过测试结果表明系统各功能模块已达上线标准，计划在次日即9月25晚上正式上线，需要各部门做准备。次日，***公司工作人员李俊芳发邮件，建议切换到正式环境使用测试号再行测试，确保系统稳定后再商榷具体上线发布时间。
2017年9月26日，聚星源公司工作人员陆国辉发送邮件“***智能客服系统项目问题跟踪和上线准备”，其中包括62个问题，其中大部分问题标记为已解决，未解决的问题聚星源公司均逐一分析并提出处理方法。同日，陆国辉还发送邮件“***智能微信客服项目（网络排查计划方案）”。
2017年9月29日，***公司工作人员李健明发送邮件称，经9月27日-28日双方对微信客服系统服务器所使用网络进行故障排查，9月28日对微信客服系统进行大规模测试，测试是否还存在因网络问题引起的掉线和客户端卡顿等问题。经测试，已基本排除因***公司网络会引起微信客服系统使用不稳定的问题，但发现2个新问题，10月9日-10日将再次安排测试。
2017年10月13日，***公司工作人员李健明发送邮件称，微信客服系统已于昨晚（2017.10.13）切换到正式环境，系统上线后还需优化数据报表功能（10.17完成）、素材同步接口（10.20完成）、微信客户端用户体验功能调整（10.20完成）和登记工单功能（待确认）。
2017年10月16日，聚星源公司向***公司发送了聚星源智能机器人后台操作手册和***微信客服系统操作手册。
2017年10月26日，***公司工作人员李健明发送邮件称，微信客服系统已经在10月13日正式上线，后续还需优化素材同步接口和关键字权限回复。
2017年11月18日，***公司工作人员郑技博发送邮件称，经客服反馈，系统还存在不稳定和卡顿两大问题。2017年11月20日，聚星源公司工作人员陆国辉回复邮件称，郑技博所提到的问题大部分都是同网络因素相关，聚星源公司已着手优化一些问题，但无法解决网络质量问题。
2017年12月6日，***公司工作人员李健明发送邮件称，距离上次微信客服系统存在问题会议结束已过去4天，相关问题还没解决也无答复，对客服人员造成很大困扰，要求聚星源公司尽快跟进。次日，聚星源公司工作人员田兆全答复称，聚星源公司一直在研究解决问题办法，但受网络影响出现好多莫名的问题（其他用户使用同样的系统没有此问题）。虽然是比较小的细节问题，但处理起来还是比较困难的，通过补丁方式很难解决的彻底，拟花大力气把从底层通讯到上层应用全部重新设计，虽然工作量比较大一些，但这样改善的效果会好很多很多。暂时***公司先用这个版本，新版本出来后再更新，预计本月底会完成。
2018年1月26日，***公司工作人员李健明发送邮件称，昨天我们组织100人左右的新版客服转人工测试，测试情况不是很理想，主要存在客服发送消息至人工客服没有提醒、刚接进来的客户不能发送信息或自动退出、对话内容突然消失等问题。
2018年3月2日，***公司工作人员李健明发送邮件称，经过本周对新版客服系统的测试验证，还存在问题影响系统正常使用。2018年3月16日，李健明发邮件，表示新版微信客服系统仍有24个测试问题未解决。2018年3月26日，李健明发送新版微信客服系统最新一版问题汇总。
2018年3月29日，聚星源公司工作人员田兆全发送邮件给***公司工作人员称，系统操作手册和报表公式已经发送，要尽快确认并一起校对数据。
2018年4月10日，***公司工作人员李健明发送邮件称，经昨天对新版客服系统群测，还发现7个问题，通过对最近几次测试情况统计，发现新版客服系统测试效率极低，项目进度极度缓慢，且花费了项目组成员大量时间，以前修复过的问题会重复出现，系统稳定性得不到保障，测试效果跟原计划相差很远。
2018年5月4日，***公司工作人员李健明发邮件称，微信客服项目于2017年5月8日正式启动，计划于2017年8月18日结束，截止当天已延期9个月交付，经多轮测试，聚星源公司开发的系统不能满足验收标准。问题包括，已修复的BUG屡次出现；对突发性的BUG响应速度非常慢；未对客服系统内部测试；多次修复后仍存在影响客服正常使用的核心问题，如消息丢失问题，客户发送的消息客服也会有概率收不到（已排除由网络原因引起）。
2018年5月22日，***公司工作人员李健明发送邮件称，今天对新版客服系统进行测试，反馈问题包括历史消息中图片缩略图显示不正常、小概率会出现接入后无反应等，另还存在核心问题“已接入客户，在聊天过程中，历史消息自动折叠，点击查看没有数据，点击右边的历史消息可正常查看历史消息记录”没有解决，其他优化类问题请跟进，处理完成后请务必先进行内部验证和UAT测试。
2018年5月23日，聚星源公司工作人员陆国辉发送邮件称，经过聚星源公司内部讨论，确定了问题点以及功能调整的处理完成时间。对其中问题的最后处理完成时间为2018年5月30日。
2018年6月2日，***公司工作人员李健明发送邮件给聚星源公司工作人员田兆全称，经过上次测试已经反馈问题，希望安排至少200人测试，如出现一些重大系统bug，***公司将不予进行下一次测试。田兆全回复称，暂不安排群测，要求***公司先自测再由双方高层召开项目会议，***公司网络闪断造成消息发不出和消息记录缺失不属于聚星源公司问题，聚星源公司不能通过软件改善***公司网络。
2018年6月10日，聚星源公司工作人员田兆全发送邮件称，微信系统经过内测，已达上线要求，要求双方共同安排群测，共同检验系统。
2018年6月12日，聚星源公司工作人员田兆全向***公司工作人员刘志辉发信息称，旧版本聚星源公司没有在维护，放着新版不用，明知旧版不好可***公司还在继续用，用出问题还记在聚星源公司头上。***公司工作人员刘志辉回复表示，经过大半年测试和试用，仍然未能满足用户需求，如信息收发和存储，可能是因为网络或者其他原因，不能单以技术角度评判。
2018年6月13日，***公司工作人员李健明发送邮件称，由于聚星源公司开发的微信客服系统BUG较多，影响到微信客服部门的正常工作，经讨论决定于6月14日23点后客服系统切换回微信官方系统，新版客服系统会跟呼叫中心系统一期寻找新的供应商。
2018年6月19日，聚星源公司向***公司发出邮件称，微信新客服系统已完成新版功能开发，并经聚星源公司自测，符合验收条件，要求***公司组织验收。
2018年7月2日，***公司工作人员李健明发送邮件“微信客服系统验收标准讨论会会议纪要”称，2018年6月30日验收标准讨论会会议记录包括：7月16日进行最后一次验收测试，我司会对测试用例文档进行检查并补充验收标准，讨论项目合同中不确定的需求点和上次用户测试中存在的问题。邮件中列出了5个不确定的需求点。聚星源公司工作人员陆国辉回复称，其中4个需求点双方经沟通已确认，第5个需求点提出建议解决方案。***公司工作人员李健明再回复确认了5个需求点。
2018年7月13日，***公司工作人员李健明发送内部邮件称，聚星源公司已优化最新一版客服系统，***公司需要对该系统进行最终验证，但在验证前，先组织***公司内部相关人员进行内部验证，要求提前准备。
2018年7月17日，***公司工作人员李健明发送内部邮件称，经2018年7月17日组织内部人员对最新版本的客服系统进行测试验证，系统还存在11个问题，稳定性较差，参与测试的用户与客服坐席都比较少，系统就暴露了各种问题，聚星源开发团队内部测试还不够严谨，前期解决的问题重复出现。2018年7月20日，***公司工作人员刘志辉将该封邮件转发转聚星源公司田兆全。2018年7月21日，田兆全发送邮件回复称，前期会议中提出的问题全部解决没有再出现，附件所列问题由田兆全详细做了分析和回复，对提到的几个重点再强调一下：1.转人工转不了是因为取消关注；2.不能打标签是因为接口异常或数据被清除；3.超过最大接数也能接入，其他坐席转入不受限。
2019年1月，聚星源公司收到***公司提出的一份盖有***公司印章的《终止合作协议书》文本。文本主要内容是，双方就已签订《呼叫中心合同》《呼叫中心维保合同》《微信客服系统合同》的终止事宜达成协议。其中包括：3.双方同意自2018年12月19日起微信客服系统合同终止，乙方已履行的服务内容详见附件一《已履行项目内容清单》。甲乙双方确认，合同终止后双方不需履行合同的剩余内容，互不追究合同相关责任。附件中包括序号1-37涉及微信沟通模块、微信营销功能等模块的需求，序号38-53涉及微信系统功能性和稳定性的问题，均标记为“已完成”。诉讼中，***公司解释发送前述协议文本的原因是，由于聚星源公司一直没有办法完成本约定的系统开发并解决所有问题，所以双方准备签订一揽子的终止合作协议，协商一致达成条款以后，***公司对确定的合同条款盖章邮寄给了聚星源公司，聚星源公司收到之后反悔且拒绝协商；关于附件中各个模块的开发进度表，***公司从来没有否认聚星源公司有对软件进行开发，但聚星源公司的开发始终不能达到需求标准，无法通过验收。
（三）涉案技术争议及勘验相关事实
1.技术争议
在2018年7月17日***公司工作人员李健明就系统发现的11个问题知会聚星源公司并配相关系统界面截图。聚星源公司于诉讼质证时提交具体回应内容（问题8未作回应）。相关的内容见本判决书附表1“最后测试中的11个问题”。
在诉讼过程中，***公司主张聚星源公司开发的涉案微信客服系统项目在沟通模块、知识库模块、营销功能模块、系统稳定性等方面存在共21项不符合验收标准的问题。沟通模块问题主要表现为：访客接入成功率低，客户丢失、混入、客服接入错误；坐席自动接入数量设置无效或错误；消息接入的优先逻辑设置未完成；机器人会话规则设置逻辑存在严重问题；工单页面功能不符合要求。知识库模块问题主要表现为：调用话术库设置错误，机器人答非所问。营销功能模块问题主要表现是：无法向客户正常发送图片、文字等营销消息，无法查看已发送的历史消息。系统稳定性问题表现为：系统经常不稳定，出现闪屏、卡顿现象，客户信息数据丢失严重。
聚星源公司针对该21项问题作出回应后***公司进一步予以回应。该部分的事实见本判决书附表2“诉讼中的21项问题”。
2．技术勘验
为进一步核实已开发的项目是否存在相应的技术争议，双方当事人及代理人同意自行共同勘验。2020年1月16日，本案双方当事人、代理人及相关技术人员一齐到达***公司服务器所在地，就案涉“FICC呼叫中心系统V6.0-微信客服管理”系统是否存在***公司所称21项问题进行勘验。
双方当事人在勘验中对涉案项目对应的服务器“微信服务器（正式70）”以及其他可能存储的9个服务器进行查找，未能发现用于存储涉案系统的“agent_sfy”文件夹，勘验无法进行。
就前述勘验过程，聚星源公司与***公司的意见分别是：（1）聚星源公司意见是，系统就存储在70服务器中。涉案项目部署前均由***公司团队划出指定服务器，给出登陆地址账号密码，再由***公司工作人员李健明统一提供并全程跟进。***公司相关技术人员不可能不知道系统具体部署在哪里。2018年7月最后一次测试后，***公司就关掉聚星源公司的远程登录权限，所有服务器全部由聚星源公司独立保管。现无法找到系统，合理解释是***公司删除或隐匿该系统。另外，聚星源公司备份的只是标准产品程序，开发过程中产生新的程序都备份到***公司服务器。（2）***公司意见是，系统在服务器中部署时均是聚星源公司技术人员操作，应由聚星源公司负责找到系统程序的具体位置。***公司原工作人员李健明是产品经理不是技术人员，不具有服务器操作权限。双方停止合作后，聚星源公司工作人员陆国辉仍在一定时间内有远程登录权限，无法确定其是否更改、删除文件。***公司已全力配合提供所有服务器登录方式供查找，同时安排了3名坐席服务人员和170名模拟客户准备配合开展测试，尽力配合技术勘验工作。
（四）其他事实
聚星源公司于本案中提交与广东法制盛邦律师事务所签订的《民事委托代理合同》和30000元律师费发票、银行电子回单，主张为本案支出律师费30000元。
***公司亦于本案中提交与广东南方瑞福德律师事务所签订的《民事委托代理合同》和40000元律师费发票，主张为本案支出律师费40000元。
本院认为，本案为计算机软件开发合同纠纷。综合当事人的诉辩意见，本案主要争议是，1.聚星源公司是否迟延履行交付义务；2.聚星源公司交付的开发成果是否符合约定开发需求；3.***公司是否需要继续支付开发费用以及支付相应的逾期付款违约金、赔偿律师费损失，聚星源公司是否需要支付迟延交付违约金及赔偿律师费损失。
（一）关于聚星源公司是否迟延履行交付义务的问题
涉案合同约定，合同实施阶段从2017年4月18日起至2017年7月18日止。在合同履行过程中，***公司确认，因需进行数据库环境转换故上线时间延迟到2017年9月18日。2017年9月15日，***公司确认涉案微信客服项目已进入测试阶段。双方停止合作之后，***公司于2019年1月出具《终止合作协议书》，协议附件记载涉案项目相应模块已完成。本院认为，从前述事实可以反映，聚星源公司于2017年9月15日前即约定履行期限届满前已向***公司交付可以进入测试状态的开发成果，相关的模块已经开发完成。
（二）关于聚星源公司交付的开发成果是否符合约定开发需求的问题
涉案合同的“项目验收”对验收程序及验收标准作出约定，即乙方发出验收通知后甲方组织双方进行验收，验收通过后签署验收报告，验收标准是附件一约定要求且系统可正常运行，无重大系统故障。
从涉案查明事实可以反映，双方没有就涉案项目签署验收报告。聚星源公司主张第一版微信客服系统经检测合格于2017年10月13日正式上线，且系统运行正常，无重大系统故障。本院对此认为，从查明事实反映，***公司与聚星源公司工作人员在2017年10月13日前对涉案项目进行了大规模的排查、测试，在2017年10月13日将涉案系统切换到正式环境。但从之后发生的相互交流的邮件内容可知，系统还存在不稳定和卡顿。聚星源公司当时对此表示研究解决问题办法，并承诺把从底层通讯到上层应用全部重新设计，形成新版本。故聚星源公司主张交付的第一版微信客服系统经检测合格，与事实所述不相符。
根据查明事实，从2018年1月26日至2018年7月17日，聚星源公司与***公司工作人员持续对聚星源公司提交的新版本涉案项目进行测试、整改，表明***公司愿意接受聚星源公司进一步的整改,但因双方最终没有达成通过测试的结论。
在本案诉讼过程中，***公司以聚星源公司开发的涉案项目存在21个问题为由主张不符合约定开发需求。双方对该21个问题拟共同自行作技术勘验，但因在***公司服务器上无法找到相应的程序而未果。聚星源公司及***公司均指称是对方可能存在删除或隐匿已开发成果的行为，本院对此认为，双方互称对方可能删除或隐匿已开发成果，均没有提供必要的证据支持或提出合理性说明，本院不予采纳。但是，聚星源公司称只保有标准版本的备份，对于新开发内容可能涉及***公司的商业秘密而不能备份，该解释合理。涉案开发成果部署在***公司服务器上，***公司在双方争议发生后有义务保全相关的开发成果。现由于归于***公司的原因不能对其所称的21个问题进行核实，则本院对***公司称涉案项目存在21个问题的主张不予采纳。
***公司于2018年7月17日最后一次测试完毕提出11项问题同时配送了系统界面相应截图，聚星源公司当时亦作回应，可以表明当时相关问题存在。本院针对该11项问题结合涉案合同约定开发需求、整个开发及测试过程的相关事实，对聚星源公司交付的项目是否符合开发需求作出认定如下：
问题1涉及机器人无法回答问题后无法自动转人工服务。聚星源公司回应称测试时设置自动回则无法转人工服务。本院认为，此问题应属使用者对系统设置不熟悉所致，不属开发问题。
问题2涉及机器人智能回复问题。本院认为，合同附件3.2.1“沟通模块”约定“机器人接入按照机器人的回复规则和设置的话术库回复”，聚星源公司称机器人不能对表情图片予以识别，以该领域一般技术人员的认识角度，该解释合理，不属开发问题。
问题3涉及用户首次关注及再次关注公众号后是否能够得到接入客服服务的问题。聚星源公司回应称属于测试时的设置问题，本院认为，此应属于使用者对系统设置不熟悉所致，不属开发问题。
问题4、10涉及系统响应速度问题。聚星源公司称是因***公司的网络问题导致，与聚星源公司的开发行为无关。本院认为，鉴于涉案项目确实需要配合***公司的网络使用，而且双方在测试过程中亦反复就网络稳定与否问题进行过讨论，确实不能排除该问题是***公司的网络原因导致，但聚星源公司作为技术提供方，本应在项目调研需求时将该问题予以重点考察，且可以通过优化提升软件容错能力来适应实际运行环境的变化，但相关的实施效果仍不明显，故应认定聚星源公司开发的系统存在相应缺陷。
问题5、11涉及数据传输或丢失问题。聚星源公司称可能是***公司X计划的接口问题导致。本院认为，使用涉案项目时需要通过接口调取***公司X计划的数据来实现，但同上述所列认定同理，聚星源公司作为技术提供方，本应在项目调研需求时将该问题予以重点考察，应积极配合寻求问题原因并予以解决，但仍存在相应问题，故应认定聚星源公司开发的系统存在相应缺陷。
问题6、7、8涉及到客服坐席设置的逻辑问题。本院认为，该功能主要在于客服分配逻辑规则的确定，聚星源公司作为技术提供方，可以通过整改优化予以处理，故该问题应属于开发的瑕疵问题，而非缺陷问题。
问题9涉及到营销功能中的消息查看问题。聚星源公司认为营销消息列表是包含收到过消息和发出去的消息的和未发出的消息。本院认为聚星源公司的解释合理，不属于开发问题。
综合以上的分析，本院认为，根据合同约定，涉案开发的系统需要实现微信客服功能开发调试、***微信第三方后台数据同步，X计划接口开发调试、报表开发、知识库布置、微信坐席程序部署，前述问题可以反映，聚星源公司所开发的系统未能够有效与***公司X计划实现衔接，亦未能够解决系统的稳定性问题，难以认定聚星源公司所开发的系统符合合同约定的开发需求。
（三）关于***公司是否需要继续支付开发费用以及支付相应的逾期付款违约金、赔偿律师费损失，聚星源公司是否需要支付迟延交付违约金及赔偿律师费损失的问题
对于***公司的民事责任。聚星源公司要求***公司继续支付余下全部开发费用以及支付相应的逾期付款违约金、赔偿律师费损失。本院对此认为，本案中，聚星源公司一再对项目成果进行整改以试图令其符合开发需求，主观上积极履行合同，但***公司经多次测试以不符合开发需求为由拒绝认可测试通过并拒绝付款，此为成讼原因。本院最终通过对11个问题进行分析认定聚星源公司所开发的系统存在不符合约定开发需求的缺陷，而经分析，主要开发缺陷可能来自于委托方自身的网络以及自身的其他配合使用的系统，不能确定全部来自于开发方。但是，本院亦考虑到，由于软件技术的快速发展及技术本身所具有的复杂性，导致一项软件的最终开发效果能否符合当事人的预期有较高的不确定性，因此，无论是委托方还是开发方应当对可能存在的影响合同目的的风险有所预估。但是，在系统开发过程中，作为开发方的聚星源公司应当针对客户的使用目的进行详细调研并针对在标准产品上进一步开发作出详细规划，可以说，相较于委托方，聚星源公司作为开发方对技术难点应有更强能力作出预先评估并予以解决。综合前述的考虑因素，本案开发成果无法最终符合开发需求，聚星源公司要求***公司支付全部余款缺乏依据，但考虑到***公司有进行一定时间的使用，以及如前所述，并非所有的开发失败原因均归于聚星源公司，本院确定，***公司仍应向聚星源公司支付微信客服系统费用60%即351000元中的部分比例计30%即351000元*30%=105300元。由于双方对技术问题有争议导致***公司未付款，聚星源公司要求***公司支付逾期付款违约金本院不予支持。关于律师费损失，因合同有支付依据，本院亦参考前述的支付比例予以计算为30000元*30%=9000元。
对于聚星源公司的民事责任。***公司要求聚星源公司支付迟延履行违约金及赔偿律师费损失，本院认为，承前认定，聚星源公司并无迟延交付行为，本院对***公司的相应请求予以驳回。
综上所述，依照《中华人民共和国合同法》第一百零七条、《中华人民共和国民事诉讼法》第六十四条第一款规定，判决如下：
一、被告（反诉原告）***家居股份有限公司应于本判决生效之日起十日内支付原告（反诉被告）广州市聚星源科技有限公司技术服务费105300元；
二、被告（反诉原告）***家居股份有限公司应于本判决生效之日起十日内赔偿原告（反诉被告）广州市聚星源科技有限公司律师费损失9000元；
三、驳回原告（反诉被告）广州市聚星源科技有限公司的其他诉讼请求；
四、驳回被告（反诉原告）***家居股份有限公司的反诉请求。
如未按本判决指定的期间履行给付金钱义务的，应当依照《中华人民共和国民事诉讼法》第二百五十三条的规定，加倍支付迟延履行期间的债务利息。
本案本诉受理费8620.46元，由广州市聚星源科技有限公司负担6034.46元，***家居股份有限公司负担2586元。广州市聚星源科技有限公司已预交前述受理费，其同意对方当事人就应负担部分于执行判决时向其迳付，则本院不作退收。本案反诉受理费2187.00元，由***家居股份有限公司负担（已缴纳）。
根据《中华人民共和国民事诉讼法》第二百二十四条和《最高人民法院关于知识产权法院案件管辖等有关问题的通知》第六条的规定，本案需要强制执行的，由广东省广州市中级人民法院或者被执行的财产所在地中级人民法院执行。
如不服本判决，可在判决书送达之日起十五日内，向本院递交上诉状，并按对方当事人的人数提出副本，上诉于最高人民法院。
审 判 长 刘培英
人民陪审员 梁建峰
人民陪审员 胡秀芳
二〇二〇年十二月二十一日
技术调查官林奕濠
书记员郑佩敏
（2019）粤73知民初1278号民事判决书附表1：最后测试中的11个问题
问题
***公司的意见
聚星源公司的回应
跟机器人对话，回复了3条内容，机器人回答不上问题，按照之前的逻辑是默认转人工，现在此功能不见了。
在客服坐席软件上有一个设置，如果***人员在测试的时候设置了自动回复，那是无法转人工的。
机器人智能回复有问题，发表情会回复其他关键术语
机器人主要对文字的内容进行匹配，对一些表情图片识别不到的情况默认推送营销信息，这是符合微信系统的最终营销目的，机器人永远不可能同人一样，你发一个笑脸，机器人也同你笑一下，机器人强项是对文字的内容进行匹配答复。也可以是语音，语音也是通过ASR软件将语音转成文字再进行匹配知识库内容。
首次关注公众号，接入人工客服成功(未推出对话)，然后客户取关了公众号，再重新关注，无任何回复(疑似在接入人工客服状态)
第一问题:首次关注公众号，接入人工客服(未推出对话)，这是***测试人员人为的关掉自动接收设置，在关掉的情况下，当然不会推对话内容的。打上勾才能推送内容:亲，我来了，10001号专家客服很高兴为您服务。
第二个问题:在测试人员与客服人员沟通过程中，***人员取消了关注公众号，然而这个会话坐席软件并未关闭，还是保持正常的连接中，然后***测试人员在取消关注后又重新关注，那么这通的坐席会话ID仍然保留刚才的，并没有创建产生新的一个新的会话，系统自然不会当新的访客进行内容推送了。
转接窗口点击【确定】没有反应，需要过几分钟后才有响应
从刚才描述点击确定过几分钟后才有响应，表明系统在是在运行的，也能转接成功，说明程序上是没问题的。要过几分钟后才有响应主要是网络引起的。
是订单客户，但没有其他订单信息
这个订单信息是来自***X计划业务系统的数据，双方是通过接口实现的，微信系统获取不到订信息，只有两个可能，一是***X计划接口出现故障没有将订单信息推送过来，二是***单方面改变了接口协议。
其他客服坐席忙碌，只有一个客服空闲，此客服最大接待数为2,己接待了2人，第三个人进来，在排队列表中排队10秒后就消失了，不知道分配去哪里，其他客服也没有分配到。
只有一个客服空闲，此客户最大新接待数为2，已接待了2人，则说明这个客服是不能再有消息接入的在排队中排队10秒后就消失了，说明系统在排队10秒钟后己找合适的坐席并将来话分配给了这个坐席，至于说不知道分配到哪里，其他客户也没有接到，从所提供的截图并不能反映事实。
客服坐席设置最大接待数为2,其他客服坐席转接客户给此客服，应该受到限制，而不是全部都可以转进来，现在转接功能不受最大接待数限制
线上客服设计对于其他坐席转入的是不受最大接入数限制，因为其他坐席在受理接入后是有过沟通的，正在服务进行中，这时转接一定是有求于其他座度的协肋，必须要把这个正在服务中的客户服务做完结，这个不做限制是系统设计的规则。
客服坐席忙碌状态能接入客户，有空闲客服席在线，且接待数不满。
主动营销发送给客户后，客户信息中【营销消息列表】中查看客户收到过的营销消息，现在是能看到包括还没发送成功的所有消息
这里是系统运营的正常情况，营销消息列表是包含收到过消息和发出去的消息的和未发出的消息，这根本不是问题。
正常登录客服系统，提示异常
网络故障，坐席获取不到服务器的VDN信息
昨天测试，我给自己打了标签，今天消失了，怎么刷新也看不到
打标签后是要将标签信息回传到X计划系统，访客咨询的时候是将从X计划调取标签信息，从现象描述可能是***的数据接口关闭或***业务接口故障所致
（2019）粤73知民初1278号民事判决书附表2：诉讼中的21个问题
序号
功能分类
***公司主张的验收标准
***公司主张的实际实施效果具体情况
聚星源公司的质证意见
***公司对聚星源公司质证意见的回应
沟通模块消息接入
人工接入---消息可设置自动接入或者手动接入，可设置自动接入数量，最好自动接入数量可以超过100以上
1．当大量访客（50-100人）进入系统时，转入人工成功率低，导致无法及时为客户提供服务。
相关问题的邮件是2017年9月22日，当时处于开发测试阶段，后续已经解决。
1．没有证据证明已解决。聚星源公司在该程序转接人工逻辑设置上显然一直存在问题。
2.当50-100个访客进入，转入人工成功率低，证明人工接入模块不够稳定，客户不能成功接入人工，体验上差，容易造成客户投诉，甚至引发潜在客户丢失，将导致程序开发合同目的不能实现，是不符合系统开发要求的非常严重的问题。
2．接入100个访客以后，出现客户丢失的情况，甚至出现当前客户混入另一个客服的情况，导致无法正常为客户提供客服服务。
客户丢失是***公司网络断开情况发生的。不存在接入100个访客以后出现客户丢失情况。证据材料显示，按800和1000用户模拟测试都未客户丢失，说明丢失客户与接入数量多少无关。当前客户混入另一个客服是不可能的，客户均共享客服，并非一个客户固定一个客服。不是问题。
1.***公司有监控在测试时无断网情况，而且即使有断网，也不应发生这种情况；
2.***公司是实体测试，聚星源公司是压力测试，是通过工具进行测试，***公司是通过实体测试。
3.其他客服坐席忙碌，只有一个客服空闲，此客服最大接待数为2，已接待了2人，第三个人进来，在排队列表中排队10秒后就消失了，不知道分配去那里，其他客服也看不见，导致无法为客户服务。
设立最大接入为2，后面再有客户来访就无权接入。排队10秒不见，说明客户等待时间过久，主动退出而已。不是问题
1.该项问题是在测试过程中出现，测试时没有进行客户主动退出的操作，聚星源公司的回复明显没有回答该问题，回避真实情况；
2.在客户没有进行退出操作的情况下，其在排队列表中忽然消失，这显然是系统程序和逻辑存在问题。
4.客户在接入的过程中，客服操作界面已经接入成功，但是客户还是收到排队指示，导致无法正常服务客户。
涉及该问题的邮件是2018年5月4日，2018年5月新版本增加了网络断开以后重新连接机制。这时候网络虽然断开，但客服无法目测到，系统断开后又自动重新连接，连接成功后重新进行信息排队，这是正常现象。不是问题。
1．本情况不涉及断网问题，聚星源公司的回复明显是文不对题、回避问题。
2.坐席操作中已经成功接入客户，但是客户仍然显示排队收到等待提示，显然不是正常运作状态，明显是系统程序和逻辑存在问题。
5.客户正常输入“转人工”指令后，有部分客户不能接入客服系统，导致无法服务客户。
是网络断开导致发的转人工消息未发出去。不是问题。
1.根据***公司2017年9月29日邮件显示，在网络正常状态下，客服空闲也无法接入，聚星源公司解释是断网导致的问题文不对题，而且该解释也根本不能成立。
2.客户正常输入“转人工“指令后不能接入客服系统，此问题对于业务部门来说会造成很大影响，客户如果有人工咨询的需求，且需求得不到解决，会造成此类客户的流失，是不符合系统开发要求的重大问题。
6.有空闲客服在线且接待数不满的情况下，仍然将客户接入忙碌的客服坐席而不是接入空闲客服，接入逻辑存在问题。
***公司的分配规则是，一个没有过服务记录的陌生客户，来的信息就是谁空闲分配给谁。但如果这个客户有过服务历史，根据熟客优先原则，会将这个会话仍然交给原先服务过的座席，而不是给空闲座席，故不存在逻辑问题，不是问题。
1.所开发系统存在“平均分配客户”和“熟客优先”两项优先规则，***公司一直要求先熟客优先，再饱和度低有限，再平均分配。但聚星源公司一直没有按照这个规则进行设置，详见***所列问题第3.
2.聚星源公司的回复自相矛盾，与事实相悖。虽然熟客优先，但在熟客客服出现忙碌状态时，应当自动执行饱和度优先逻辑，而不是让客户长时间等待，该状态恰好证明聚星源公司设置的逻辑存在问题，容易导致客户长时间等待。
3.测试中，是在非熟客状态下出现该问题。聚星源公司的解释不能成立。
4.结合整理问题第2点用户转接逻辑存在问题的情况，第3.2熟客优先逻辑设置存在问题的情况，5.1、5.2无法区分标注工单优先逻辑存在问题的情况，足以反映聚星源公司在系统逻辑设置方面明显存在矛盾冲突问题，不能妥善解决系统对各项指令优先度进行处理的逻辑问题
7.客服坐席设置最大接待数为2，其他客服坐席转接给此客服，未受到人数限制，坐席可以无限转接，导致客户长期无限等待，无法及时为客户提供服务。
坐席最大接入数为2，是表示不再接受其他访客，但不对内部座席转接过来的消息做限制，因为内部其他同事（无能力解决来访客户问题）座席转接过来的是表示正在服务中的客户，不能中止服务。而这个座席转接过来，肯定是有求于被转接的座席，这完全是从用户体验角度。正是为了减少用户无限等待，不存在***公司所称“导致客户长期无限等待，无法及时为客户提供服务的问题。不是问题）
1．聚星源公司的解释在逻辑上不能成立。接入数量限制是为了提高效率，保证及时转接客户、避免客户长期排队而设置，如果按聚星源公司说的对内无效，那么该项目的如何实现？设置限制有何意义？聚星源公司的回复显然是强词夺理。
2．为了达到高效率服务的目标，当某一客服设置最大接入量为2人时，如果达到2人，其他客服不能转接给他，应该要提示：当前该客服最大转接量已满，请转给其他客服。该项设置在技术上不存在困难，明显是聚星源公司自身开发中未妥善处理，设置逻辑存在问题。
8.订单客户，但没有其他订单信息，无订单标识，无法区分消息接入优先逻辑。
订单和客户的消息来自***公司的X计划系统，两者是通过接口实现的。聚星源公司判断是***公司修改接口逻辑而又不通知聚星源公司同步修改，必然会导致接口异常。
关于与***公司X计划系统，在系统开发的初期，聚星源公司就提出目前这种接口方式会存在不稳定和影响操作体验。
1．系统上显示是订单客户，即表明在系统中有记录，表明可以正常通过接口调用档案记录。聚星源是有关X接口出现问题的解释不能成立。
2.系统显示是订单客户，系统应当将其与陌生客户进行分类，并对订单客户适用“熟客优先”等逻辑。但聚星源公司开发的系统没有完成该优先逻辑配置，显然存在系统问题。
3.聚星源公司一再将问题推脱至***公司的X计划根本不能成立。首先聚星源公司明知***公司以X计划作为其核心系统配置，该X计划系统接入数百个程序，在聚星源公司承接项目开发时就知道只能自己适应该系统，而不可能更改该核心逻辑来适应聚星源公司的开发。其次聚星源公司除了开发本案程序，还另行开发“电销系统”程序，聚星源公司提交的其他项目开发沟通记录不适用于本案。
9.所有客服在线时，应根据上次服务过的客服进行分配，而不是随机分配，如熟客优先原则，不符合消息接入优先逻辑设置要求。
***公司所列证据邮件并无此问题内容。
大量证据证明存在该情况
机器人接入信息：机器人接入按照机器人的回复规则和设置的话术库回复
10．机器人不能按照设置的回复规则及时回复问题，对客户不能回复或者不能针对性地正确作出相应的回复。
机器人的回复规则是，当客户咨询某一个问题，如果机器人检测到知识库有对应的知识答案就是精确推送给客户，如果机器人获取不到相匹配的答案就推荐类似或相近的答案内容给客户。这些规则的答案来源于***公司提供的知识库内容。如果客户问了机器人而机器人没有回答或延时几个小时回答，则是机器人不能按照设置的规则及时回复问题。***公司提供的证据材料，没有任何一个证据证明机器人不回复或延时回复。
不能正确性的作出相应争取正确回复，这完全取决于***公司提供的知识内容。如果知识库知识对客户问询的问题并不具备针对性，那么机器人回复出来的内容也就没有针对性了。该问题并非聚星源公司系统开发问题。
1．机器人的存在是希望其自动回复问题，否则机器人无存在的必要。但是该系统中均认可机器人只是辅助，机器人解决不了的问题还是主要通过人工解决，因此，程序开发过程中必须考虑机器人能力有限时如何处理，客服项目必须以客户体验作为第一考虑，这正是***公司一直要求对机器人无法回答问题及时设置“转人工”选项的原因。
2.对该情况，正常的设置是先由机器人自动回复，回复中应当包含对回复不满意可以转人工的选择项。如果机器人无法找到合适的回复，或者客户认为回复不合适的，应当及时提示转人工服务或提供转人工选项。而聚星源一直未能实现和设置该项逻辑。导致机器人的使用存在大量问题。
3.***公司认可机器人首先调用知识库内容，问题在于，当知识库中没有该项内容时，聚星源公司应当设置无法找到准确答案时系统应转接人工服务的程序逻辑，而不是放任机器人没有规则地进行搜索并提供不着边际的答案。机器人不能准确的回答问题不是根本问题，聚星源未设置机器人及时转人工服务的选项和提示才是其开发不符合验收标准的根本问题。
4.聚星源公司的回复不能成立。自动回复与提示人工服务并不是相互冲突、不能兼容的选项。如果聚星源公司开发的程序在后台设置“自动回复”就完全排除“转人工”，那么显然是聚星源公司的逻辑设置存在严重问题，甚至可以反映聚星源公司对客服项目的理解以及合同目的的理解都存在严重的问题。
11.跟机器人对话，机器人回答不上问题，按照之前的逻辑是默认转人工，但系统中此功能不见了，无法转接人工。导致无法正常服务客户
***公司把后台配置设置为自动回复，当然无法转人工，故意设置问题。
12.机器人智能回复规则和逻辑设置存在严重问题，胡乱调用与问题毫不相关的回复，造成对品牌形象的严重不良影响。
机器人的回复规则是，当客户咨询某一个问题，如果机器人检测到知识库有对应的知识答案就是精确推送给客户，如果机器人获取不到相匹配的答案就推荐类似或相近的答案内容给客户。这些规则的答案来源于***公司提供的知识库内容。如果客户问了机器人而机器人没有回答或延时几个小时回答，则是机器人不能按照设置的规则及时回复问题。***公司提供的证据材料，没有任何一个证据证明机器人不回复或延时回复。
不能正确性的作出相应争取正确回复，这完全取决于***公司提供的知识内容。如果知识库知识对客户问询的问题并不具备针对性，那么机器人回复出来的内容也就没有针对性了。该问题并非聚星源公司系统开发问题。
沟通模块沟通功能
聊天过程中，客服可填写工单标注是否处理完成、咨询类别（投诉、咨询定制、报名、环保、价格、员工、活动、咨询订单等，类别可自定义增减），工单跟呼叫中心打通，可转接给400客服处理，处理完毕返回信息。
13.客服填写工单标注，工单页面信息出错。
、工单标注指，座席人员在受理业务时对这项业务的属性进行打标签，然后将标签内容通过借口方式保存到***的X计划系统中。如果***的X计划系统接口发生故障或***单方面修改接口规则，会导致工单标注数据保存失败，系统返回错误码提示（就是工单页码出错），是被告问题。
1．系统上显示是订单客户，即表明在系统中有记录，表明可以正常通过接口调用档案记录。聚星源是有关X接口出现问题的解释不能成立。
2.系统显示是订单客户，系统应当将其与陌生客户进行分类，并对订单客户适用“熟客优先”等逻辑。但聚星源公司开发的系统没有完成该优先逻辑配置，显然存在系统问题。
3.聚星源公司一再将问题推脱至***公司的X计划根本不能成立。首先聚星源公司明知***公司以X计划作为其核心系统配置，该X计划系统接入数百个程序，在承接项目开发时就知道只能自己适应该系统，而不可能更改该核心逻辑来适应原告的开发。其次聚星源公司除了开发本案程序，还另行开发“电销系统”程序，原告提交的其他项目开发沟通记录不适用于本案。
14.客服填写标注过的订单客户，再次接入后没有标注信息和其他订单信息。
同上一问题，工单标注因为***接口问题，导致保存不成功，再次接入当然无法显示标注信息和其他订单消息，这是被告的问题。
知识库
设置话术库后，所有客服账号都可以调用话术库内容并选择话术向用户推送，接入智能客服回复分析，模糊词的推理分析，缩略词识别，错别字识别。
15.除***公司的专业知识库外，设置的话术库和其他知识库存在明显问题，机器人对于用户问题答非所问，使用不合适的网络用语，调用不专业的回答，与客户交互内容影响品牌形象。
该问题包含两个问题：第一个问题，机器人对于用户问题答非所问，设置的话术库和其他知识库存在明显问题，调用不专业。首先机器人的知识库和话术库的所有内容均由***提供的，其知识内容的准确与否、合适与否是经过***人员内部审核后才上传到知识库的，机器人回答用户问题都是从知识库（或话术库）里查找答案。如果机器人检测到知识库和话术库有对应的知识答案就精确推送给客户，如果机器人获取不到匹配的答案，就推荐类似或相近的答案内容给客户，这是机器人知识库调用的操作流程该问题与我方系统无关。第二个问题是使用不合适的网络用语。***提供的证据材料中没有此部分内容，不清楚网络用语指哪些内容。该问题与第10个问题重复。
1．机器人的存在是希望其自动回复问题，否则机器人无存在的必要。但是该系统中均认可机器人只是辅助，机器人解决不了的问题还是主要通过人工解决，因此，程序开发过程中必须考虑机器人能力有限时如何处理，客服项目必须以客户体验作为第一考虑，这正是***公司一直要求对机器人无法回答问题及时设置“转人工”选项的原因。
2.对该情况，正常的设置是先由机器人自动回复，回复中应当包含对回复不满意可以转人工的选择项。如果机器人无法找到合适的回复，或者客户认为回复不合适的，应当及时提示转人工服务或提供转人工选项。而聚星源一直未能实现和设置该项逻辑。导致机器人的使用存在大量问题。
3.***公司认可机器人首先调用知识库内容，问题在于，当知识库中没有该项内容时，聚星源公司应当设置无法找到准确答案时系统应转接人工服务的程序逻辑，而不是放任机器人没有规则地进行搜索并提供不着边际的答案。机器人不能准确的回答问题不是根本问题，聚星源未设置机器人及时转人工服务的选项和提示才是其开发不符合验收标准的根本问题。
4.聚星源公司称索菲来公司故意设置问题更是不能成立。自动回复与提示人工服务并不是相互冲突、不能兼容的选项。如果聚星源公司开发的程序在后台设置“自动回复”就完全排除“转人工”，那么显然是聚星源公司的逻辑设置存在严重问题，甚至可以反映聚星源公司对客服项目的理解以及合同目的的理解都存在严重的问题。
营销功能
1．能实时从***微信第三方后台同步更新关注的用户，可通过剩余沟通时间，关注时间，咨询次数，用户地区等维度筛选客户；可以在页面上添加搜索功能，例如接客户的状态，新申请等
2、用户提供的48小时内可沟通的用户接口，来进行图文素材、图片、文字、模版消息发送的营销功能
16.主动营销发送给客户后，客户信息中[营销信息列表]中查看客户收到过的营销信息，现在是能看到包括还没发送成功的所有信息，但客服却无法从聊天界面查看到该历史消息。
发送消息历史包括已发送和未发送的全部消息，这是正常情况，不是问题。
1.客服看不到历史消息，将使得客服无法了解之前的客户沟通状况，无法准确地和客户进行交互，严重影响沟通效果。这是无法实现开发目的的严重问题。
2.正常情况下，应当是“客服”能够看到所有消息，包括已发送和未发送的全部消息；“客户”只能看到已发送的消息，不应该看见客服未发送的消息。而聚星源公司开发的程序恰恰相反，客服什么历史情况都看不到，而客户不但能看到应该收到的发送成功的消息，而且能看到没有发送的消息。这显然是聚星源公司将“客户”“客服”的数据库和角色进行了错误的界定，显然是严重的错误。但聚星源公司一直没有解决和改正该问题。
17.信息发送缓慢，存在图片、文字无法正常发送的情况。无法发送正常品质和大小的图片，发送降低质量的图片、文字品质不佳，不能满足用户要求。
关于信息发布缓慢，图片和文字无法正常发送的问题，这是***网络导致。关于文字品质不佳的问题，无任何证据显示该问题的存在。关于历史消息显示缩略图不正常，这只是一个显示分辨率配置的小问题。这个问题在2018年5月23日聚星源公司项目经理陆国辉发邮件表示当天已解决。
怎么证明已解决，未进行验收【对方提供2018-5-23邮件反映已解决】
聚星源公司提供的邮件仅仅现实优化调整了历史消息中图片缩略图现实不正常的问题，但***公司提出的不是历史消息中的图片问题，而是未显示解决了截图卡住问题、无法发送图片问题。
系统稳定性
系统开发标准：
1、完成本文档3.2所有功能，
2、通过可行性测试
3、所有功能运行平稳，无重大问题。
18.系统不能适应在正常工作网络环境中使用，一旦出现网络波动（丢包率小于1%），消息在操作界面会丢失，只会保留在服务器中。导致客服人员无法正常与客户进行交流，严重影响客服人员工作效率和工作质量，对于客服操作体验上造成了重大困扰。这也是迟迟没有切换上正式环境的主要原因。
合格的工作网络环境是：丢包率小，不能连续丢包。允许网络有轻微的波动，网络波动需要在一个允许合理的丢包率范围，大于1%就算很不正常了。如果丢包率很严重，则会造成系统卡顿、消息发送不畅，客服操作体验不好，更不能出现直接网络中断，一旦网络中断，就会导致客服人员无法正常与客户交流。信息系统运行的基础就是通过网络进行信息传输，网络是微信客服系统运行必备的前提条件。网络与微信系统的关系类似于桥梁和车辆的关系。
微信客服系统工作原理是：微信客服系统是基于腾讯微信公众号SDK接口开发的一个多媒体交互平台，客户向公众号发送消息，先由微信服务器收取并存储到本地，后根据排队规则将消息非赔给对应微信客服座席。同理，微信客服人员向客户发送消息，先提交给微信服务器，后由微信服务器发给腾讯微信平台。工作原理可以看出，***所称“只会保留在服务器中”，是因为微信座席提交了消息，但只是先提交到微信服务器。如果外网断开，微信服务器就无法发出消息。此时会出现一个场景，座席人员微信系统里有一条提交发送历史记录，服务器里收到这一条消息，但是客户始终未收到消息。
***的网络环境并非其所说的“正常网络环境”和“正常的网络波动”实际上是经常性断网。断网的原因很多，线路故障、设备故障、路由错误。这些基础网络并非由我司提供，是***公司提供和维护的，只能由***公司的技术人员来解决。总之，***公司所说的“迟迟没有切换上正式环境的主要原因”完全是其原因，不是聚星源公司系统开发问题【提交了电销工作群的微信聊天截图】。
这是电销工作群的聊天记录，是另一个系统，故意混淆。同时这是网络重连机制的问题。
19.正常登陆系统，提示异常（偶发性）
提示异常是提醒网络有故障。
这是聚星源公司设置的登陆系统存在问题，与网络没有任何关系。证据中显示的情况是：账号密码错误没有提示，正常登陆却提示异常。
20.在聊客户，前端聊天记录客服和客户的对话消失。（严重影响客户体验，需要大量用户测试才能验证）
是网络断开的原因，网络断开的症状是客服发的消息发不出，客户发的消息收不到。
1.作为任何一个程序系统，都必须考虑网络可能出现波动的情况，断网保护机制是一个程序最基本的配置。在网络迟延、断开的情况下，给予缓存保护，历史信息能够正常找回、系统内信息能够保持或停留在断网前的状态，是一个用户最基本的期待和最基本的要求，也是一个程序开发商最基本应该给予实现的要求。而原告显然不但不能实现这一要求，而且根本没有设置任何最基本的断网保护机制。
2.涉案网络是要在现实环境中使用的，而不是放在聚星源公司的理想和想象中的，面对现实环境中的各种问题正是进行上线测试和试运行的意义所在，这也证明了“测试”和“上线”并不等于“验收”。
3.聚星源公司除了开发本案程序，还另行开发“电销系统”程序，其提交的其他项目开发沟通记录不适用于本案。
4.***公司2018年9月29日邮件已经明确显示，出现相关情况已排除网络问题。
5.只有聚星源公司的程序没有断网保护和不能适应极小的网络波动，其他人开发的程序没有该问题。替代聚星源公司进行开发的新程序也完全没有该问题。
6.聚星源公司开发的系统严重不稳定，不能适应现实网络环境，而且没有设置任何的网络波动、中断保护机制，是该系统不能正常使用、无法通过验收的根本问题之一。
21.坐席接待访客过程中，中途刷新浏览器或重新登陆坐席，该坐席之前接待的访客会在列表中消失，导致无法持续与访客沟通，无法实现服务和销售功能。
刷新浏览器或重新登陆座席，是系统信息初始化，座席的状态回归到初始阶段。并不在之前接待的访客状态，会话列表自然没有。这是自然现象，绝非问题。
