如今，许多SaaS供应商已经开始切入“民营企业服务项目”赛车场，当中关键的劳特尔是为民营企业元B2C销售业务提供更多技术标准机能，以商品服务项目原销售业务。然而这类销售业务抽象化为技术标准机能时，会遭遇3大设计症结，怎样化解那些痛点呢？责任编辑作者以小鹅通现场直播为例，探求SaaS对繁杂B2C机能的商品开发准则，一起来看一下吧。
在众多民营企业全面试著销售业务线泽姆良、经营网络化的今天，许多SaaS供应商已经开始切入“民营企业服务项目”赛车场，当中很关键的劳特尔是为民营企业原B2C销售业务提供更多技术标准机能，以商品服务项目原销售业务。但这类销售业务抽象化为技术标准机能时，一定会遭遇3大商品开发症结。
但，怎样化解那些痛点呢？本栏作为B端商品经理，希望通过对事实上的预测，探求SaaS对繁杂B2C机能的商品开发原则。
一、首章简述
在输入《以小鹅通为例，深入探讨SaaS商品怎样化解“入门难、工作效率低”的使用者新体验难题》时，本栏发现小鹅通现场直播非常贴近这3种情形，第一集该文就以小鹅通现场直播为例，消去【营运运营者、服务器端客座教授、观众们】3类使用者的视点，新体验一场现场直播【现场直播前预备、首播、现场直播中】的完备组织、破冰、交货过程，观察使用者新体验难题，预测得出结论繁杂B2C销售业务的技术标准机能的商品开发难的根源和通用型准则。
二、新体验机能如是说
现场直播销售业务的复杂性极高：初期需要B端多配角协同、多营运各个环节逐步预备，后期在一个介面+限量发行时间范围内，将所有内容和营运动作纸制呈现给C端使用者。
但平常我们更多碰触到的是C母萧氏域带货类现场直播，如淘宝网现场直播、抖音现场直播；而对小鹅通现场直播此种SaaS私域现场直播机能了解较少，所以在这里做一些补充如是说。
三、新体验情形
第二步：现场直播前预备繁杂B2C销售业务有2大特点，B端营运重、业务流程各个环节多，导致将其抽象化为技术标准机能时，商品开发一定会遭遇一个问题——该机能的B端管理介面必然承载了大量机能，此时怎样降低使用者负担与使用成本？
1）第一眼感受：事情看着好多心好累
在许多SaaS中，繁杂机能的创建和详情页面都非常长，人还没已经开始操作，大略看到内容后，心就有点累了，更不用说在第一次使用时不了解它的情形下。
小鹅通案例：
① 创建现场直播：需要滚动6屏（普通笔记本电脑），并且第1个分类板块【基本信息】就占了约4屏；
② 现场直播详情-现场直播间设置-互动设置：需要滚动3至N屏；
③ 现场直播详情-营运设置：需要滚动6屏，并且与这场现场直播关系更紧密的【开课提醒】、【现场直播间信息设置】被放在最后。
2）操作过程中感受：旋转跳跃我闭着眼
SaaS的机能总在不断增多，但由于机能总是单个单个上线，长期下来，机能的核心页面内就散落了许多未经整体设计的机能点，导致页面内机能点放置的位置（tab分类、tab下顺序），缺少合理、统一的标准，既不是按销售业务业务流程定、也不是按营运场景定。
这导致，使用者日常使用时新体验会非常混乱。以小鹅通为例，当我按常规逻辑（销售业务业务流程/营运场景等）逐步设置销售业务所需机能时，出现了4种混乱新体验导致的难题。
小鹅通案例：
①我想编辑使用者进入现场直播间后看到的内容：创建页：简介、详情、暖场图；详情-现场直播间设置-现场直播间装修：皮肤、背景图、菜单；详情-营运设置：最下面的现场直播间公告、观看人数/在线人数/现场直播间热度是否展示。
b：首播设置、转播设置、拉流设置。
③详情-营运设置：机能的位置顺序和实际销售业务业务流程顺序差异很大。
小节总结：
对于繁杂B2C机能的页面，我们必须足够了解和熟悉使用者实际使用案例，并在尊重“常规思路”的前提下设计机能。
预测提炼出机能的销售业务场景和业务流程，从中抽象化出合理、统一的逻辑，作为众多机能点分类和排序划分的依据；反复对比销售业务实际操作路径与机能使用路径之间的不同点，然后针对性的调整；对于页面长的难题，在交互设计和UI设计层面试著更多方案，例如“卡片”样式；整合清楚后，还可以针对B端操作工作效率场景，提供更多机能编辑时的“模板”机能，类似淘宝网/千牛的商品信息模板机能。第二步：首播B2C机能中有一类很特殊——平台类/场域类机能，因为它们的使用者最少存在供需两方，有时还有服务器端。所以，必须通过平台/场域的商品机能，表达出平台/场域的规则，并且必须让参与的几方配角都清晰感知到这个规则，才能让使用者在平台/场域下顺利见面互动、才能让这个机能在C端成功运转起来。
如上图所示，公域是规则主导方，而SaaS不是。因此，SaaS对平台类/场域类机能的设计思路难度是非常高的，极容易出现歧义、造成使用者新体验难题，并最终可能导致供方对平台/场域营运不顺畅，销售业务商品服务项目效果差。
1）我（B端营运者）辅导外部客座教授首播：双方都难受
第一个设计准则：一定要向供方（即SaaS直接使用者、即平台规则制定方）清晰、完备地表达出全部业务流程、各方操作视点，尤其是与需方和服务器端首次衔接的各个环节，切不可产生“将C端收到链接后的路径设计好就行，不用告诉供方太多，减少他的负担”此种想法。
这是因为：
① 是供方与需方、服务器端直接碰触联系，只能由供方通过自己的方式传达清楚规则，其他方才能轻松，进而供方才能轻松；
② 供方是主导方、责任方，他需要掌控感；
③ 供方本身就有引导的营运意图，那些信息能帮助他完成初期营运引流。
小鹅通案例：
没有充分理解到B端有辅导外部客座教授首播的作用和责任，因此没有充分且清晰地提供更多相关信息给B端：
①B端营运者对“客座教授首播业务流程”的了解受限于“首播信息”，既不知道客座教授首播路径、也不知道客座教授其实可以自己选终端首播，导致B端营运者无法尽到引导作用，例如提前告诉客座教授最好选择哪种首播方式，结果现场直播中途才发现需要换终端，踩过一次坑后才知道得提前提醒新来的客座教授。
② 当营运者让外部客座教授首播，用了4个以上页面来说明，但互相之间指引冲突，含义冲突，或又其他商品表达问题，导致客座教授用不明白、供方也解答不了，最终成了卡点。（注：该案例也属于“编辑设置时要来回跳转”的新体验难题，并且是一个存在逻辑关系的机能业务流程内仍要跳转多个页面完成，与上方案例的纯机能间分类/顺序难题不同）
③ 点击客座教授列表右侧短信通知，会直接发送短信，而并没有告诉B端营运者通知内容。
2）我（外部客座教授/学员）：我是谁？这个介面是给我用的吗？我现在要做什么？
第二个设计准则：SaaS在设计供方提供更多给服务器端/需方的入口和使用路径时，一定要立足实际使用者（服务器端/需方）的视点进行设计，不是供方的视点、也不是SaaS视点。否则会影响实际使用者对机能的心理预期、使用路径，最终导致服务器端/需方使用机能时自我混淆。
小鹅通案例：
① 短信通知时，客座教授很可能通过手机自带浏览器打开H5，此时客座教授很可能经历两次登录业务流程。
② 小程序（微信打开H5链接）：客座教授通过供方提供更多的首播链接首播时，他看到的使用路径是清晰的（红色页面1、2、3）；但一旦客座教授是通过鹅现场直播主页首播，就很难以清楚找到自身的定位和使用路径了（绿色页面1、2、3），最少形成2个“阻碍”。
③ 客户端/小程序（下图红色内容）：下图红色内容-首播路径的交互逻辑不符合B端私域：小鹅通现场直播是B2C销售业务，首播行为是B端商业行为而非C端即兴行为，B端对“已经开始现场直播”各个环节，并不会过度追求“立刻感”，反而需要一定基础预备所带来的“安心感”。
④ 客户端（下图绿色内容）：快速直播按钮的交互不符合可预知性准则、统一性准则。
⑤ 客户端（上图主介面列表）：不显示每场现场直播的所属店铺，对客座教授和学员来说都是很大的干扰。
⑥ 客户端/小程序：可以在选择店铺的菜单中放“没有找到店铺？点此了解”，给客座教授讲解怎样化解，从客座教授视点反向引导B端，化解客座教授首播各个环节的引导难题。
3）我（外部客座教授）在鹅现场直播上无法首播，必须等营运者登录后台修改信息
第三个设计准则：当销售业务需要分配角完成时，每个机能的位置/定位，除了考虑销售业务业务流程之外，还需要考虑配角分工（以此预测出会使用到该机能的配角），综合确认该机能应该放在哪一个配角处管理，即机能位置放到哪一端。 同时，不同供方的配角分工情形可能是不同的，因此如果预备将某敏感机能放置到服务器端管理，应该同时给供方提供更多对应权限管理机能。
小鹅通案例：
① 营运者创建时随意选择了结束时间，等客座教授预备首播时才发现“现场直播已结束，无法首播”，此时客座教授端无法修改结束时间，必须由供方的营运者登录后台修改后，客座教授再首播
② 小程序/APP：客座教授无法看到本场现场直播的数据情形，需要靠营运者在后台截图发给客座教授；客户端中提供更多了客座教授数据海报，可以提供更多基础数据情形，并且满足分享场景
小节总结：
对于平台类/场域类机能，SaaS必须先保证自己梳理清楚完备销售业务业务流程、配角分工、配角协同各个环节，才能将抽象化出来的销售业务用商品开发表达出来，让机能达到以下3点效果。
向供方提供更多灵活可“自定义”的平台类/场域类机能的同时，全销售业务业务流程的机能逻辑清晰明了在连接需方/服务器端的各个环节上，为供方提供更多清楚的说明与帮助在需方、服务器端使用的端口商品上，机能介面和使用路径符合实际使用者的期望最终才能将平台/场域的规则定义权掌握在自己手上，才能向直接和间接使用者提供更多既便捷简单又灵活丰富的商品机能。
第三步：现场直播中像小鹅通一样，有一些SaaS是“帮助B端做toC生意”，其核心销售业务机能看似是提供更多给B端，其实最终会交货给C端。对于这类机能的商品设计，除了考虑“B端目标”外，还要非常重视从“C端视点”出发思考。
期望和目的，而不深入C端的价值和新体验：
C端对这个机能会有什么心理和反应是否能达成商家使用这个机能的营运目的等1）我（C端使用者）过五关斩六将才进了现场直播间， 结果看着五花八门的东西迷失了方向
B端的营运需求是没有尽头的，最终很可能会搞出一堆花里胡哨却没什么效果的机能，并且还会加剧B端的错误营运思路。这一点在现场直播机能上体现的尤其明显。
现场直播与C端的碰触会被限量发行在一段时间内的，B端之前设置的各式各样的营运手段，会在一段时间内集中、轮番地呈现给C端使用者。因此，在现场直播下B端的营运行为是非常快速且紧凑的，C端使用者的情绪心理也会被不断冲击，在此情形下，如果机能因忽略C端心理而设计得过于粗糙或繁杂，价值传递的效果就会大打折扣，还可能让使用者产生抵触感，很容易导致使用者流失。
2）我（B端营运者）不知道C端会看到一个什么样的介面、会经过什么样的路径
SaaS的toC机能与纯toC商品不同：
纯toC商品：商品开发者可以清楚知道并控制商品的最后结果；SaaS的toC机能：商品开发者给B端在每个销售业务各个环节、每个场景上都提供更多了丰富的营运机能，B端根据自己的目的自由组合机能点，形成最终的toC机能和介面。因此，对于多个机能点需要在一个介面中展示时、需要在一个业务流程中依次出现时，纯toC商品很容易平衡考虑，而SaaS的toC机能则要繁杂许多，若商品开发者都没有考虑，或没有可视化给B端的话，B端营运者就无法知道“C端使用者在某个业务流程、某个介面中会走的路、会感受到的信息价值”，导致B端无法自我平衡营运行为和内容。
小鹅通案例：
① 当该现场直播有许多针对“使用者进入现场直播间”各个环节的机能，如付费售卖+现场直播预约+信息采集+购买前后私域引流+……，会导致引流各个环节的跳转多→门槛高→流失率增高。
②该现场直播有许多针对“促进分享裂变”场景的营运机能，如邀请达人榜+分享有礼+招募推广员，会导致B端营运没有核心目标或营运行为过多，对应的C端会看到太多信息+太多路径而迷茫。更不用说一个现场直播间介面上还要展示“引流、气氛互动、营销带货”等等场景的营运机能。
小节总结：
设计每一个toC机能，都应该从C端视点出发思考和设计，尤其着重C端的①场景和价值点、②机能使用路径与新体验；商品开发者需要梳理清楚C端在该销售业务机能下会遇到的所有机能、介面、路径、岔路口，不光是某个静态页面内多个机能怎样呈现，还有该机能完备业务流程的动态过程中多个机能怎样呈现。这样才能在设计toC机能时，意识到单个机能点对C端在整个销售业务下感受的影响；商品开发者观察到的全面的C端视点，应该通过B端对toC机能的管理介面，通过可视化等设计手段，将此种视角信息传递给B端营运者，让他们拥有C端视点，才能真正平衡最终的营运行为。四、设计准则总结图
责任编辑由 @B端编外商品 原创发布于人人都是商品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是商品经理平台仅提供更多信息存储空间服务项目。
