快生活 - 生活常识大全

做到什么程度就可以拿出去卖了


  对SaaS产品来说,如何兼顾完善的产品功能与制作产品耗时之间的矛盾呢?SaaS到底做到什么程度才可以正式对外让用户使用呢?这对这个问题,笔者给出了自己的思考与解答。
  刚刚做完一个SaaS的重构,花了一年多的时间,因为新系统的功能必须要大于老系统才行,不然用户现在使用的功能怎么办呢,工作都没法开展了。
  但如果是一个全新的SaaS,肯定不能这么做,等系统做大做全了出去卖,且不说这漫长的时间内是否已被竞品捷足先登了,这也非常不符合MVP,万一跑偏了,这试错成本相当的大啊。
  但如果只做了一点功能就拿出去卖,客户会用吗?如何和竞品完善的功能PK呢?
  不得不思考这个问题:我谈谈我的想法,如有不当请指正。
  一、核心闭环已打通
  做一点功能就拿出去卖不是说随便做一点就行,至少要把核心的闭环打通。
  这个核心闭环怎么定?还是要根据目标用户的需求来。
  1. 定位目标用户的核心业务闭环
  我们在做之前都会对系统有个整体的规划,比如说我做基层医疗机构的诊疗SaaS,那诊前、诊中、诊后三大环节是一个完整的系统蓝图。
  核心闭环也就是说,把这里面用户最急需、使用频率最高的功能串联起来,各角色人员能通过系统完成任务的流转和协作。这也是每个SaaS自己的核心灵魂。
  比如我们的目标用户是卫生所、诊所,我们想要取代的是传统的写病历、开处方的his系统,所以我们的核心是诊中环节:
  像诊前环节:预约 → 登记 → 分诊,以及诊后环节:随访、用药提醒,下次就诊提醒等,是重要的组成部分,但不是核心。
  当然如果是做专门的预约系统和随访系统,在那个系统里,预约和随访就是主角了。所以系统定位不同,核心环节也是不同的。
  2. 做哪些功能支撑这闭环?
  我们上面其实只是初步确定了流程的闭环,但不是完整功能的闭环,我们都知道,在这流程背后,还需要一些辅助功能和基础数据的支撑。比如接诊患者时,需要有病人库的信息;开处方时,先要录入药品信息;收费时,价格也是要提前设置的。
  还有一些系统底层的功能,比如说诊所的入驻、管理,用户的账号、角色、权限等。
  如果需要员工在手机上操作,C端的功能也是闭环内的一部分,比如药师扫码盘点药品库存。
  完整的功能闭环一般是要考虑多个平台和多个终端的,比如说这样的:
  我们不妨先把涉及到的功能点都列出来,然后做减法,比如说运营平台的功能可以先不做,用户新增和管理先直接操作数据库。这样直到功能最简为止。
  二、非核心功能有替代方案
  如果用户用了我们的系统,那其他重要的功能怎么办呢?比如说有慢病的患者,医生会每隔一周询问下身体情况,他们当然希望能通过系统完成,直接通过微信和对方聊天,然后把随访的情况记录到系统里面,这样方便长期管理。
  但我们的功能还不支持,所以我们要先给他们想好解决方案,一般就是这2种。
  1. 沿用线下解决方案
  很多B端用户是传统行业刚步入信息化建设,之前都是采用的人工方式,不妨继续坚持一段时间,虽然麻烦一点。
  像上面的情况,医生可以打印出一张随访表,每次随访后把结果填写在表里,拍照传到病人库中留档。熟练电脑操作的,也可以用Excel来做。
  2. 打通其他系统
  有些用户规模比较大,本身就会用好几个系统,我们就要考虑是否可以和其他系统打通。
  比如说诊所有个专门的诊后回访系统,那我们是否可以直接通过接口拉取到结果,记到患者的档案里面呢?把缺失的功能这样给补上。
  不过这也要看对方的系统是否支持,以及我们打通的成本。
  还有个比自动获取实现简单的办法就是,对方系统把结果导出,我们这边支持导入。这样人工工作量也不大。
  可以说,核心闭环的打通和非核心功能能替代解决,这个SaaS已经具备了对外售卖的核心条件,但不要着急,下面的2点同样非常非常重要。一定要准备充分,不然可能一推出去就惨遭失败。
  三、用户体验要做好
  B端产品功能是最重要的,但仅靠功能打天下的年代已经过去了,用户对互联网产品越来越熟悉,不管是B端还是C端,他们都会进行很多横向的对比。
  用户体验就是产品的包装和细节,在功能相似的情况下,甚至略有不足的情况下,用户体验会是打败竞品的强有力武器。B端产品也在往精细化耕作发展。
  如果一个产品的用户体验不好,给人的第一印象就不好,让人觉得不用心、不专业,一旦用户形成了这样的想法,后面即使功能再叠加,也很难改变之前不好的印象。
  在开始售卖前,不妨多花点精力处理下这些方面:
  把页面布局改的美观清爽一点
  把报错的提示改的友好一点
  把开发的词句改成用户能看懂的语言
  把用户不关心的字段都隐藏掉
  给一些内置数据及参考案例
  完善帮助文档,建立随时反馈渠道
  四、推广循序渐进
  不要着急招大量的销售,大范围的开始推广。我们都知道,一个产品刚上线,不管之前测试用例有覆盖的多全面,测试人员有执行的多一丝不苟,上线后也经不住用户用,而且用户一多爆发的问题就越多。如果贸然推广,开发抗不住,用户评价还差,坏了口碑。
  就像很多C端产品一样,比如微信的视频号,前期会有个内测期,开放给少量的用户。我们也可以找几家意向用户,先试用起来,最好是比较典型的用户,这样他们提出的意见比较具有参考价值,谨防被一些不规范化和个性化带偏。
  这个试用用户的数量怎么定?首先明确意向用户不等于实际使用用户,可能我们邀请了10家来试用,真正用起来的就3家,这里面有很多原因,比如说没有时间培训;当前还在用其他系统;先等别的用户用了再说,等等。前期我们假设一下这个转化比例,估计不超过50%,后面再根据实际情况调整这个比例。
  其次,评估下我们的开发人员能应对几家实际使用用户的bug和功能优化,前期可能就是2-3家。
  那么先邀请5-6家来试用,等这一批差不多稳定了,再开始陆续邀请下一批的10家。差不多过这么2-3轮,系统就稳定多了,可以逐步扩大销售范围了。
  五、总结
  能从0到1的打磨一个Saas,看着他1.0版本的上线、内测、公测、推广,直到站稳脚,开拓后续的业务。这应该是很多产品经理的理想,但现实中这样的机会很少很少。
  这是我理解的SaaS第一步推广要做到的程度:核心闭环已打通,非核心功能有替代方案,用户体验还不错。
  实际验证时肯定还会有很多细节问题,欢迎有经验的朋友指正。
网站目录投稿:碧蓉