如何应对2B客户的定制化需求？模块化、变化控制、需求梳理……|议桌局精华

洪强宁

洪强宁，爱因互动联合创始人兼CTO，2B 行业新兵，为企业提供对话机器人解决方案，也是此次话题发起人。拥有十余年互联网从业经验，资深Python程序员。曾任豆瓣网首席架构师与宜信大数据创新中心首席架构师。关注对话机器人、人工智能、云计算与容器技术。

我是2B行业的新兵，经验比较浅，但我们在做这个事的过程中，也花费了很多心思去思考到底该怎么做？可以跟大家分享一下我们在这方面的一些探索。

2B业务面临的挑战

我们是一家做对话机器人的技术服务公司，主要的业务场景是帮助客户搭建对话机器人，客户可以通过这个机器人去和用户进行交互，来完成他的业务需求，像解答用户问题、协助用户操作、根据用户标签推荐产品等都是目前典型的业务场景。

我们一开始创业的时候，就定了“以项目推产品”的原则。我们要形成产品，而不是一直一个项目一个项目地做下去，这样没有积累。但我们碰到的问题是，我们无法在最开始就清晰的定义产品，因为这是一个非常前沿的行业，之前并没有太多的经验可供借鉴，一切都需要我们自己去摸索。

那到底在什么场景下，对话机器人的技术可以更好的发挥商业价值，这就需要我们去尝试、去探索，所以我们只能不停的尝试推出各种形态的产品，从中发现效果最好的，然后把它打造的更好，最后再去复制它。

应对之道：设计可扩展架构

出于这些考量，从技术角度出发，我目前推行的办法就是，尽可能设计一个相对比较灵活的架构，不把它限制的太死，只把我们确定可以共通的那些需求做出来，剩下的都用可扩展的方式来做。

目前的架构，我们把它分成了多个层次，第一层是接入层，不同的客户通过怎样的接入点去接触用户是有差异的，可能包括微信、API、其他聊天平台等多种接入方式。另外，每个客户所做的事情不一样，各个项目的差异非常大，所以对于每一个客户的应用场景，我们都会去造一个机器人的大脑，我们称之为Brain，每个Brain都是可以独立上线、独立变更、独立优化的。

接入层到Brain之间是一个消息通道，因为从我们目前的见解来看，不管哪种应用，最后都可以归一成聊天的场景，所以虽然可能是基于不同的用户、不同的应用场景，但我们最后都把它统一成一个统一的对话的格式进行传输。

同时，一个机器人背后可能会有多个 Brain，通过这种方式，我们可以通过不断扩充Brain的方式来扩充机器人的能力，去应对不同的客户、不同的场景。

标准化、模块化应对客户不同需求

但这个过程中，我们又发现了另外的问题，虽然每个客户的需求都不一样，但他们之间还是会有一些共同点，比如说问答的场景，基本上每个客户都会有。

那我们的应对方法就是，在做不同的Brain的时候，做标准化、模块化。目前我们抽出了这么几个模块，一个是问答的QA Bot，职责就是来一个问题，给一个解答；一个是Form Bot，就是表单机器人，定义好问题之后，就可以通过机器人发给用户收集反馈；

一个是推荐机器人，可以根据用户标签匹配商品，然后把商品推荐给用户；一个是任务机器人，可以识别用户指令，并匹配知识库里的命令形态，看是否可执行，并以此给用户反馈；最后一个是路由机器人，就是判断用户的命令该交给哪个机器人去执行。

目前我们是创造了这样五个机器人，等于做了五个积木块，然后在实现客户需求的时候，就可以用搭积木的方式，去把这些模块拼接成一个能够满足需求的机器人。

这是我们目前在做的方向，但挑战也非常大，因为每个客户还会有一些定制化的需求，特别是在和客户系统做对接的时候，就会碰到这几个机器人都涵盖不了的情况。那我们现在的解决方法就是为了这些特殊需求再专门造一个机器人、造一个Brain出来，然后再把它们做拼接。

总的来说，我们现在主要的应对方法就是造积木、搭积木，碰到了不通用的需求，就单造一块定制化的积木，然后再搭积木。

当然这个过程中还有很多问题需要解决，比如对话机器人这件事和客户的业务逻辑联系非常紧密，一旦客户的业务逻辑发生变化，机器人就得相应做出改变，工程师可能就得去改背后的代码，有点疲于奔命。虽然已经通过搭积木的方式简化了一些这种情况，但压力仍然非常大。

王勇睿

王勇睿，百融金服合伙人、互联网事业部总经理。百融金服是是一家利用大数据技术为金融行业提供客户全生命周期管理产品和服务的公司。为信贷行业用户提供包括贷前营销获客、贷中管控以及贷后管理在内的客户全生命周期产品和服务；为保险行业用户提供精准营销、存量客户管理以及个性化产品定制等产品和服务。

先分享一个案例，我一朋友出来创业，做了一个教育的AI，类似题库，学生在上面做题，它会根据你的答题情况，反馈给你不同的评价、不同的难度等，相当于不断的迭代和训练。但跟学校合作试运营之后，就发现不同的学校、不同的老师的要求都不一样，需要他做对应的调整。

这其实挺典型的例子，这个问题，从算法的角度来讲，就是要收缩共性的问题，拎出你最强的点，在你能够服务的业务场景中，把它作为最通用的那部分去做。原则上是这样，但实际中，考虑的因素要多得多。

那我目前在做的是征信相关的业务，比方说为银行提供黑名单、反欺诈、供债、不良等信誉评估的数据，毕竟现在贷款的渠道很多，银行可能无法确保对方的信用情况。我们遇到问题就是，在对接这类机构的时候，特别是银行机构的技术需求是比较复杂的，他们会有合规性、安全性等各种要求，同时这些要求还都很高，而我们无法把它们做到共性化，并呈现出一个通用型的技术模块去满足这些要求。

我们为银行的技术对接、技术准备所付出的技术努力，大概占了我们整个技术团队80%的时间精力成本。同时，我们投入了大量的人力、资源去做的事情，却不一定有后续的回报，这是非常纠结的点。

至于解决方法，短期暂时没有太好的方法，但从长期来看，我们可以拿着龙头企业的案例去说服下一个企业，用案例向他们说明那些需求是无用功，只是包装好看而已。所以刚开始可能会多吃一些苦，之后就能拿着之前的案例去说服未来的客户了。

华健：

华健，广联达梦龙，负责研发和技术。公司主要是面向大型施工企业提供信息化服务，标准的2B形态，刚好会碰到大量的定制二开要求，有一些经验，更有很大的困扰，刚好有这个机会可以和大家一起探讨，多多学习。

将共性沉淀为标准产品

首先分享一下我们做的综合项目管理系统的发展，这个系统做了有小十年，它经历了这么几个历程。

第一个阶段跟洪教授那边一样，都是做项目。因为一开始从无到有，就需要从项目启动，那一年时间大概接了四五个项目，每个项目都有自己的代码分支、独立开发。也许底层会有一些通用的技术组件，但基本上就是围绕客户的需求做定制开发。这是一个产品的起步阶段，肯定是绕不过去的，都得做。

第二个阶段就开始抽共性，把不同的项目沉淀成一个标准产品，让这个标准产品慢慢成长。一开始向新客户提供标准产品，可能他需要定制的部分还是比较多，但最终这一层共性的部分会慢慢涨厚。

第三个阶段就是标准产品加定制，共性、通用的部分再涨厚也涨不满，顶多能涨到70%、80%，定制化那一层必然还是要做的。

应对定制化的策略与实践

我们做定制化，一开始的策略是囤人，我们自己招人做，但这会带来比较大的成本的问题。第二个阶段是外包，但这样做虽然可以降低成本，但无法保证质量，因为外包的人员对整个行业的理解不够，会大大影响交付客户之后的效果，经常会出现客户不满意，我们就得重做一遍的情况。

毕竟外包人员的业务能力都很弱，但如果占用我们团队业务人员的精力的话，团队精力又不够分配了，所以这个阶段后来也被我们否定了。

最近的一个阶段，我们采用了一种比较极端的方式，就是压客户化，强制不再做定制化了。当然这是有前提的，主要由于这些年的打拼，我们做到了第一，我们在这个领域的市场占有率第一，因为我们对业务的理解最深。

第二，我们会采取一些策略，比如如果是客户合理的需求，我们会告诉对方之后迭代的哪个版本会解决这个问题，到时免费就能获取，用这样的方式去打动他们。第三，做客户关系，毕竟说实话，做这种2B的大客户，客户关系占的比例有时并不小。

策略后续的问题

这样做之后，我们目前的成本兜住了，也会有些盈利，规模也没有受太大的影响，但本质上，这种做法是错误的。因为2B服务就是为了满足客户的业务和需求，但你用这种非常规的手段把他的需求卡死了，不满足他，后续发展肯定会出问题。这也是我们目前的困扰，只不过由于成本的问题迫不得已这样做。

如果我们以后要持续围绕大客户做运营的话，肯定不能像现在这样一刀卡死，还是得针对定制化需求做二开，但目前也没有特别想明白到底该怎么做，这也是比较困扰我的问题。

其实我们也发现，那些做了大量二开工作的客户，他们用我们的产品是用得最好的，因为特别符合他的业务需求。虽然做的那些二开工作中至少有一半是被浪费的，但是至少还有一半起到了作用。

另外，做定制化，还有一个问题就是你做了之后，当期的可以兜住成本的，但越往后兜住成本就越困难。因为做了大量定制化的客户，之后就不能随着你的标准版升级了，但标准版有了新功能之后，客户肯定会想要，就比较麻烦。

比如今年建筑行业营改增，营业税改增值税，它会深刻影响到你系统里的几百个模块，那么之前做了大量定制化的老客户就升不了级。一个一个去帮他们升级的话，成本太高又升不起；不去帮他升级的话，又有可能丢掉这些客户，是一件非常恐怖的事情。

源数据定制化

所以，我们希望做了定制化的产品也能跟着标准版升级，这是很重要的事情。对此，我们的做法是搭建了一套完整的源数据体系。之后再做定制化，是针对源数据体系做定制化，它会形成一个Delta，再把这个补丁打到新的标准版上。这样做会产生一定冲突，但这个冲突解决起来相对会容易一些。这是我们从技术层面做的工作。

另外，为了解决应对变化的问题，公司当年还投了一个多亿，花了一百多人团队三四年的时间做了一个底层技术平台，虽然客户业务发生的变化，永远无法用配置全部解决，但我们希望通过这个平台能解决的越来越多。

关于之前洪教授提到的问题，我这边也有一些想法。第一就是行业选择问题，我觉得洪教授那边比较大的风险就是没有选定行业，你刚才提到的都是技术架构层面的解决方法，但做2B，要满足的是客户的业务需求，需要你对客户业务有深刻的理解，同时他们的业务也会深刻影响到你的技术逻辑。

第二，选定行业之后，才好建立行业影响力。因为做2B的服务，你永远无法让客户全部满意，否则你肯定无法兜住你的成本。那么，你就需要增加你面对客户时的谈判资本，树立你在行业里的核心竞争力，这样即使你有些地方无法满足客户，综合考量之后，他们依旧会选择你。

对未来发展的趋势，我们对标的企业肯定是SAP、Oracle，我们都是跟随者，多多学习他们是怎么做的。SAP、Oracle的做法很简单，就是价值链外包，有大量的团队围绕着它去做定制工作。但这有个前提，就是你的市场足够大，你才能吸引到价值链上的伙伴，否则就没人跟你玩。我们现在就面临这个问题，我们想把价值链外包，甚至愿意让利，也很少有人跟你玩儿。

喜欢我们的会点赞，爱我们的会分享！