猎云网注：本文转自安在（微信号：AnZer_SH）作者梁伟。他分享了自己所思考的一种打法以及该打法下应展开的做法，而对于SaaS来说，其实可能的打法有千万种，其具体做法自然也会有所不同。以下为文章原文：
1、之前写过一篇《杂谈：SaaS + 安全》（复制搜索，或关注Piz0n查看历史消息可见），限于篇幅没有展开，今天算作一个续篇。纯粹随笔，想到哪里写到哪里，可能会不够规整。
2、我文中所指都是多数情况或普世概念，而非特定行业、特定群体，如果老拿特殊群体说事儿的话，天儿都没法聊，更何况抬扛乎？！
3、我所思考的角度并非纯技术或纯商务角度，可能会引起部分人的不适。
1F SaaS 特性
SaaS 的特性网上一搜一大把，不再赘述。
但，SaaS 可想象的模式太多，所以很难概全，我觉得网上描述的那些特性，主要针对一些刚需SaaS 。
什么样的SaaS 是刚需？
之前我也发过一篇PPT描述我的观点。
有些传统IT架构中不可或缺的服务就是SaaS 的刚需，例如，邮件系统、知识管理、CRM …等等。
这些基本都是企业所必须的，对于大型企业来说，多以自建为主，但是中小型企业为了规避运维带来的烦恼，选择SaaS的概率会更大一些——这也是那些长尾。
另外，就是一些底层的XaaS 也是刚需。
例如很多PaaS和IaaS平台，其原因跟上面非常相近。
但PaaS 和IaaS 不是小公司能玩得起的，未来肯定只是少数掌握着“硬”资源和“硬”实力的厂商所垄断。
2F 安全SaaS特性
安全SaaS ，现在有一些定义为SECaaS，我其实没有太搞清楚SECaaS 所指之核心，所以我这里还是继续称为“安全SaaS”比较稳妥。
安全SaaS 就是指，现在安全厂商以SaaS交付模式为依托，所承载的那些安全能力，比如，基于云的Scanner、WAF ……等等。
安全SaaS 不是刚需，因为安全本身就不是刚需。所以安全上加上个SaaS 依旧改变不了这个事实。
之前聊天也有人跟我说过，安全都立法了还不刚需？——其实，立法这件事恰恰更能说明安全不是刚需。
非刚需是安全SaaS 区别于上面我所说SaaS 的最大特性。
但是，安全SaaS 有几个其他SaaS也有的特性——安全能力的出入口都统一了，安全产生的数据出入口也都统一了，安全的管理也都统一了…
这几个特性在其他SaaS里看起来不是什么，但结合上安全这块“非刚需”，这几个“统一”就很有的看了。
3F 垂直打法
有了两个特性做铺垫，打法其实就比较明朗了。
都说SaaS 是轻销售模式——这个不展开说了。其实安全SaaS 也是轻销售模式。
因为安全非刚需，所以很多需求都是来自顶层设计，而顶层设计的贯彻者多是大企业或集团公司总部有安全职责的部门。
所以，这种非刚需造就的顶层贯彻需求，以及上面说说的几个“统一”特性，就契合了一个安全SaaS 顶层作战计划——纵深垂直打法。
安全SaaS 绝对不适合一个个去死磕，即便你没磕过安全SaaS产品，传统安全产品总磕过吧？
而SaaS的价格特性就是低单价、高总价（因为群体大）、边界效应明显，所以安全SaaS 产品一个个客户去死磕，自寻死路。
以此可见，纵深垂直打法是目前安全SaaS 一条不错的出路。
但我认为，多数销售是不适合“吃透”一个行业的，虽然很多销售都会专注少数几个行业甚至几个客户，然后“吃死”，但并不代表他们能“吃透”。
吃透，是一种对行业及业务的深刻理解和思考，一般销售做不到（但我也见过几个做到的，但仍是少数）。而对售前等有技术基础的人员来说，却对此有着天然的优势。
所以，我所说的“轻销售”可能并不是大家一般所理解的“轻”，而是需要技术与销售能力的深度结合和再造，并非传统的销售套路。
关于纵深垂直大概就说这些，如果还没理解，再默念几个关键字——非刚需、顶层设计、“统一”的能力（不好意思，对此我也只能半遮半掩，不好说的更透了）。
4F 有些没必要谈的“话术”
SaaS 的本质是交付模式的改变。
一方面是用户体验有所不同，另一方面是收费模式的不同（其实这也算是另一种体验）。
但这些话，实在不适合在安全SaaS 产品的介绍中出现。
首先，安全不适合谈体验——毕竟，很多用户对传统安全产品尚无体验，在新交付模式下的安全的“体验”实在没什么价值。
其次，安全是一种难以量化的能力，为什么现在搞羊毛党的产品容易赚钱？因为他们有量化标准——减少业务损失XX万元。
但现在多数安全产品或服务，还是缺乏此类量化指标，这种时候谈价格优势或付费模式，缺乏对比依据，反而容易把SaaS交付模式拉回到与传统交付模式去对比，这样并不是什么好事。
另外，关于安全的体验，多说一句。
根本上来说，界面上的体验并不等于能力上的体验。
之前我做过很多售前工作，也有用户会跟我说谁谁家的界面漂亮、人机交互好，但是该扫的扫不出来，依然是然并卵。
所以，体验这种事，还是要分层次、分角度的去看，我这里所说的体验，明显不是界面问题。
5F “分赃”模式已死
安全SaaS因为要铺好大一片用户，所以很多人会建立类似传统渠道一样的合作伙伴来制定一种“分赃”模式，以促进产品推广。
但，这种模式仅限于外部竞争不多且不强的情况下使用，否则，其劣势远大于优势：
多竞品环境下，“分赃”模式直接导致价格战，这种价格战跟传统价格战没什么区别，但是会多一些参与者，而多出来的参与者可能把事情搞的更加混乱；
“分赃”模式其本意是促进野蛮生长，也就是说，在无竞争环境中，放血出来让大家野蛮生长，让我的SaaS产品到处生根。所以，一般分赃方不会去关注你的什么垂直纵深策略，而只是以“吸血”为主要目的。而在有竞争的环境下，这种模式本身就可能造成合作方有多种选择，而左右摇摆，甚至直接影响产品在当地的策略；
“分赃”模式只适合无策略打法。接上一条，可能有人会有疑问，为什么该模式只能野蛮生长？不能贯彻策略吗？在我看来，绝对无法贯彻！本来纵深垂直的打法就是上下冲突很多的一种打法，再加上分赃方多是来自外部合作方，贯彻策略上再出现理解上的差异，分分钟玩死自己。
所以，综上。在已经无法野蛮生长的今天，任何与此模式有关或类似打法，都会受挫——至于挫成什么样，需要观测的维度太多，不好评价。
6F 试用与服务
如果按照之前我所说的打法、说法、做法都贯彻了，还能走到这一步，应该说很有看头了——当然也不排除，只是商务关系造就的无意义的试用而已。
不过，到了这一步也来到了最危险的一步，毕竟，很多产品的最差体验就是来自试用。
这里，先从试用周期说起：我其实一直不喜欢长周期试用。
什么样的周期算长？超过10天，都算长了。
当然，我也能理解为什么当前普遍使用都是30天起步，甚至有90天试用的产品，反正大家都懂，就不多说了。
长周期的坏处很多：
话说的多，漏的就多。产品也一样，用的越长，毛病就越多，即便产品十全十美，用久了都会感觉到不爽。就跟男人结婚之后都想换老婆一样；
当然，有人可能会说，用户对产品的使用频度并不高。那就更惨了，人家都不经常用，你给那么长试用周期干嘛？
给用户廉价感，当然，这并不是一两家推行长周期试用就能造成的结果；
竞争信息泄露，这种问题很普遍，而且很多时候泄露并不是用户故意或竞争对手有意制造的，只能说，时间长了提供了太多机会；
而对于SaaS来说，可能还有更多的恶果（主要针对没有私有或混合硬件形态的SaaS）：
SaaS相对传统产品来说更透明，如果没有一个“粘着点”仅仅粘住用户的话，可能很快就忘了有这么个试用产品了；
SaaS因为没有具体硬件形态，所以一般是一个账号的形态存在，再加上长时间没人搭理的话，给用户感觉会比传统产品更廉价；
我能想到的好处也不是没有，但除了与对手在此项上扯平之外，实在也没什么更突出的地方了。
再说试用阶段的服务问题。
从原始的SaaS模式来看，服务是非常重要的一部分，从好听的方面来说，有着响应快、专家集中…等等优势，但从真实世界里发生的故事来看，SaaS作为“强服务、弱产品”形态的交付，在试用阶段如果仅仅让其以“产品”形式存在的话，本身就是一个不好的开头——这其实也是现在安全SaaS普遍存在的问题，当大家都强调SaaS中最后一个“S（Service）”的时候，缺失最多的恰恰也是这个“S”。
而另一方面，由于云的特性，很多试用用户使用的资源和正式的合同用户使用的资源是分开的。
而划分出来的试用资源往往是质量不高的非优质资源（例如，带宽比正式用户少、硬件比正式用户差等），一类资源的投入就代表了一个企业对此类资源上的用户的态度，那么，运维人员自然也不会对此类用户过分关注。运维人员所谈及的往往就是“付费用户优先”，虽然本质上没错，但如果以“纵深垂直打法”为前提的话，对试用用户的轻视所带来的恶果可能会更大——所以需要一个折中做法，就是从组织划分上，试用资源的维护和正式合同资源的维护应该是分开的：一组人负责试用用户，一组人负责正式用户，两组人可以不定期按需调换人员。
主要原因是，由于两组人面向的产品阶段不同，因此，用户的态度、问题和解决方式也不一样。
更为重要的一个层面则是，售前和售后的服务体系应该是不一样的，尤其是问题响应过程、以及问题处理的评价体系的差异，所以只有划分为两组人才能实现两套服务体系的独立存在。
7F 自我营销
安全SaaS 有望成为安全的一个入口——当然，其实我对此一直都有所怀疑。
但每次当出现安全事件的时候，其实就是各大SaaS平台的营销最佳机会，但大家能说的却都只有“我们的XX平台已添加此规则，请您尽快登录添加”。
其实我已经不知道这个时代对安全服务的定义是什么样的了，我只知道，在我还被称为服务工程师的时候的准则是——把事情做在前头，把话说在后头。
作为服务交付模式来说，不用过于刻意扭转什么样的印象而去刷存在感。
普遍情况下，用户的惊喜不是来自于“哦，你的规则也上来了？！”，而是来自于“啊？！这个是最新0-day的防护效果报告吗？”。
就好象，我现在不愿意去海底捞的最大原因就是——每当我聊的正high的时候冲上来个满面堆笑的小伙子问我需要什么服务——说实话，您要是没这个眼力件儿干脆老老实实的盯着我什么时候招手就好了，不要假装很懂我的样子。
8F 结尾
说这么多，其实也就是我所思考的一种打法以及该打法下应展开的做法，而对于SaaS来说，其实可能的打法有千万种，其具体做法自然也会有所不同。
但是我觉得有一点应该是不会变的——SaaS 本身因其作为强服务模式的存在，所以对交付方来说，其打法不再是局限于一个硬件盒子的雕琢，而更应注重负责业务各个层面的人员之间的衔接与串联，而自古以来，管好人就是最难的。
毕竟，每个人都有不同的想法。
销售希望尽快签单、售前可能还带点技术情怀、运维希望节省工作、后台则希望bug被巧妙的无视……这样，原来对一个硬件效果的简单考核就变成了跟全公司人的斗智斗勇。
