使用频率最高的功能串联起来，各角色人员能通过系统完成任务的流转和协作

刚刚做完一个SaaS的重构，花了一年多的时间，因为新系统的功能必须要大于老系统才行，不然用户现在使用的功能怎么办呢，工作都没法开展了。

但如果是一个全新的SaaS，肯定不能这么做，等系统做大做全了出去卖，且不说这漫长的时间内是否已被竞品捷足先登了，这也非常不符合MVP，万一跑偏了，这试错成本相当的大啊。

但如果只做了一点功能就拿出去卖，客户会用吗？如何和竞品完善的功能PK呢？

不得不思考这个问题：我谈谈我的想法，如有不当请指正。

一、核心闭环已打通

做一点功能就拿出去卖不是说随便做一点就行，至少要把核心的闭环打通。

这个核心闭环怎么定？还是要根据目标用户的需求来。

1. 定位目标用户的核心业务闭环

我们在做之前都会对系统有个整体的规划，比如说我做基层医疗机构的诊疗SaaS，那诊前、诊中、诊后三大环节是一个完整的系统蓝图。

核心闭环也就是说，把这里面用户最急需、使用频率最高的功能串联起来，各角色人员能通过系统完成任务的流转和协作。这也是每个SaaS自己的核心灵魂。

比如我们的目标用户是卫生所、诊所，我们想要取代的是传统的写病历、开处方的his系统，所以我们的核心是诊中环节：

像诊前环节：预约 → 登记 → 分诊，以及诊后环节：随访、用药提醒，下次就诊提醒等，是重要的组成部分，但不是核心。

当然如果是做专门的预约系统和随访系统，在那个系统里，预约和随访就是主角了。所以系统定位不同，核心环节也是不同的。

2. 做哪些功能支撑这闭环？

我们上面其实只是初步确定了流程的闭环，但不是完整功能的闭环，我们都知道，在这流程背后，还需要一些辅助功能和基础数据的支撑。比如接诊患者时，需要有病人库的信息；开处方时，先要录入药品信息；收费时，价格也是要提前设置的。

还有一些系统底层的功能，比如说诊所的入驻、管理，用户的账号、角色、权限等。

如果需要员工在手机上操作，C端的功能也是闭环内的一部分，比如药师扫码盘点药品库存。

完整的功能闭环一般是要考虑多个平台和多个终端的，比如说这样的：

我们不妨先把涉及到的功能点都列出来，然后做减法，比如说运营平台的功能可以先不做，用户新增和管理先直接操作数据库。这样直到功能最简为止。

二、非核心功能有替代方案

如果用户用了我们的系统，那其他重要的功能怎么办呢？比如说有慢病的患者，医生会每隔一周询问下身体情况，他们当然希望能通过系统完成，直接通过微信和对方聊天，然后把随访的情况记录到系统里面，这样方便长期管理。

但我们的功能还不支持，所以我们要先给他们想好解决方案，一般就是这2种。

1. 沿用线下解决方案

很多B端用户是传统行业刚步入信息化建设，之前都是采用的人工方式，不妨继续坚持一段时间，虽然麻烦一点。

像上面的情况，医生可以打印出一张随访表，每次随访后把结果填写在表里，拍照传到病人库中留档。熟练电脑操作的，也可以用Excel来做。

2. 打通其他系统

有些用户规模比较大，本身就会用好几个系统，我们就要考虑是否可以和其他系统打通。

比如说诊所有个专门的诊后回访系统，那我们是否可以直接通过接口拉取到结果，记到患者的档案里面呢？把缺失的功能这样给补上。

不过这也要看对方的系统是否支持，以及我们打通的成本。

还有个比自动获取实现简单的办法就是，对方系统把结果导出，我们这边支持导入。这样人工工作量也不大。

可以说，核心闭环的打通和非核心功能能替代解决，这个SaaS已经具备了对外售卖的核心条件，但不要着急，下面的2点同样非常非常重要。一定要准备充分，不然可能一推出去就惨遭失败。

三、用户体验要做好

B端产品功能是最重要的，但仅靠功能打天下的年代已经过去了，用户对互联网产品越来越熟悉，不管是B端还是C端，他们都会进行很多横向的对比。

用户体验就是产品的包装和细节，在功能相似的情况下，甚至略有不足的情况下，用户体验会是打败竞品的强有力武器。B端产品也在往精细化耕作发展。