去年我帮朋友的养老院做了一次业务咨询和系统设计，他们原本已经有了4家连锁性质的养老院，但开设新院、连锁管理和市场推广方面的需求特别急迫，特别想用互联网化的思维重建系统，最终形成具备提供养老行业标准化服务体验的Saas系统。在这个过程中我也受到多方面的启发，本来想尽快写出来，结果一拖就是一年多，正好当下有些闲功夫，写出来和朋友们分享分享。
朋友请我帮他们做咨询和设计主要的诉求是这家养老院业务扩展迅猛，短短几年时间就已经开设了4家养老院，且后续将以每年2家的速度开设新院，而在这个过程中他们整理、总结和验证出了一整套养老服务的标准化流程和规范以及养老院内部管理体系，但如果是连锁式发展，这套养老行业的SOP(Standard Operation Procedure)又怎么能快速复制和更新到分布到各地的分院中呢？
如果借鉴酒店行业的连锁经营，当然是希望通过行业内的连锁管理IT系统实现对各分院的集约化管理，但是苦于养老行业的互联网化在发展初期并没有受到太多资本的关注，也没有可以影响整个行业，特别是Saas化的养老行业互联网化平台，所以只能从0基础起步自建养老业的平台。
这里说的养老平台是需要满足养老院自身服务运营的基本需求，而不是现在一些创业项目中只是涉及渠道化养老的互联网养老项目，目前国内的养老行业分布还是以养老院为主体，社区养老和居家养老为辅 ，而这里最难的是养老院的方式，因为入住养老院的老人，是社会急需帮助和关注的弱势群体。
这里需要说明的是按照国际划分标准老人的定义是65岁以上的人群，而他们的构成差异也比较大，有自主行为能力的老人，他们其实和普通人没有什么区别，他们的养老其实主要是以提供一些生活服务和医疗的便利性和一些社群的关照为主，这就是目前互联网渠道化养老项目的关注点。
而更需要社会关注和帮助是那些丧失自主生活能力的低能老人，他们需要的更加细致，深入和全面的社会服务和关注，需要制定老人全方位的生活照顾计划，这就是为什么需要强调养老服务过程的标准化的重要性原因了。
这家养老院前期就已经零零碎碎的搭建起了各式各样分散、独立的小系统，有服务订购系统，客户基本管理系统，老人能力评估，计费，人事，财务系统等，可以说“麻雀虽小，五脏俱全”。那我该从哪里入手呢？ 我怎么重新整合这些已经形成体系的分散系统，从而构建一套可以支持标准化服务体验的Saas化养老平台呢？
我们构建一个业务领域的IT系统首先要搞清楚该领域或者企业的运营核心是什么？从运营核心入手分析行业的流程和规范才能事半功倍的帮助企业快速解决业务瓶颈。一个服务型行业或者企业的运营核心无外乎是：
图中运营实体：建议书，要约，产品，服务，资源，在我看来是大部分的电商系统的核心运营实体，而客户首先和这些运营实体发生关系和连接的流程和功能就是我们需要重点优先考虑的。
在电商中客户是怎么和以上的运营实体发生连接的呢？ 目前普遍的产品销售和服务提供行业的电子商务化都是建立在销售理论中的：“客户请求2商户响应和满足”的模型下，x东，x宝如此，其他垂直行业电商也是如此。
所以C2C(Customer2Customer)的流程分析就是我们创业阶段电商优先关注的流程。我们如果从MVP产品的交付角度来说，能满足如下C2C的常见流程所需功能的系统基本也就具备开门接客的必要条件。我们总结常见的C2C流程如下：
他们分别是：
1. Request-to-answer（请求到响应）
2. Order-to-confirmation（订购到确认）
3. Usage-to-payment（使用到付款）
4. Request-to-change（请求到变更）
5. Termination-to-confirmation（终止到确认）
6. Problem-to-solution（问题到解决）
7. Complaint-to-solution（抱怨到解决）
以上7个流程涵盖了从客户发起，到最终得以响应或者解决的端到端过程，该过程是对客户体验影响最为深刻的流程，我们无论是新建电商还是已有电商都可以按照此流程重新检验自己产品在业务设计上是否完整，当然一个企业除了这7个C2C流程，还有诸多管理流程，例如：
但如果选择一个系统构建的优先级的话，一定是上面7个流程，因为它们直接关系着以客户为中心，以企业运营核心要素（建议书，要约，产品，服务，资源）为主体的架构思路。下面我们将分别谈谈这7个流程都是什么含义。
1. Request-to-answer（请求到响应）
我们知道现代的商业销售模型基本都是建立在请求到响应的核心模型下，是在客户发起请求到商家响应请求的过程，这里的请求是泛意的请求，并不是特指购买产品或者服务的请求，而是一种咨询、一种信息了解和一种客户需要。
在传统行业中，企业通过门店，客服中心等传统渠道接收这种咨询请求，而在互联网电商模式下，一次搜索，一次网页浏览，一次产品收藏等其实都是一种请求，客户的请求是显性或隐性的把自己的需要(need)告知给商家，而商家响应的是：匹配满足客户有意愿和购买能力的产品，最终将解决方案反馈给客户确认。
上图是一个High Level的请求到响应的流程图，您可以当一个宏观流程参考，具体行业细节流程上差异比较大，所以我们只能分析宏观流程。而图中的请求咨询、判断销售前景、匹配产品组合、提供销售建议、确认方案，是基本销售过程，具备一定的跨行业性和普世性，无论是服务、产品销售，2B、2C模式都有参考意义。
可能你会说这个流程看似在面对服务和2B市场的时候可以采用，但在产品销售和2C市场中也太复杂了吧？在某宝的购物体验中没有这么麻烦啊！对，确实作为客户的购物体验中确实也许没有这么复杂和麻烦，但作为商户来讲这些工作就一个也不能少，只是有些过程是自动化的，非人工的，是实时反馈的，所以客户的体验才如此简单和快速。但作为一个系统架构者如果也认为业务是如此简单，就太天真了。客户的体验简单和系统提供复杂的构造本身没有冲突，反而是通过系统的复杂构造才能提供客户的简单体验。“麻雀虽小五脏俱全”，系统也是如此。
由于篇幅所限我举一个快速消费品的购买流程，来说明无论是快速消费品还是复杂服务都需要该流程。“销售前景”这个概念一般我们常见的2B市场或者是复杂服务提供市场，例如：养老行业，一次老人家属的咨询，往往都需要养老院One By One的去分析和跟踪他们的签约前景。
在快速消费品行业也同样存在，我们要网购一把电动牙刷，通常会先搜索电动牙刷，再看品牌、看功能、看评论、再比较性价比，最后做出最后购买决定，这是站在用户角度的流程，如果我们换到商家的角度再看，绝不会把这些过程看成是自然行为，商家都想通过这个购买流程尽最大可能去影响客户的判断，比如：搜索的排序，功能有针对性体现，提供最适合消费者购买力的品牌等。你去看看某宝的App首页构成，你就知道了。
商家系统销售策略就是如何利益最大化的响应客户请求的策略，只是消费者没有感觉而已，那是后台数据的One By One的自动分析和跟踪，这是大数据的用武之地。目前大数据，机器学习发展的如火如荼，可以预见不远的将来类似养老这样的复杂业务也逐渐会采用人机交互的自动化实时分析方式替代，但这恰恰证明请求到响应的流程在销售行业中是如此的重要。
2. Order-to-confirmation（订购到确认）
订购到确认流程是我们最常见的电商流程，当消费者对商家提供的产品或者服务的解决方案感到满意，就会向商家发起订购，而从消费者发起订购开始后该消费者才能真正能称之为“客户”（欧盟相关法律对客户有严格定义和数据保护，商家不能随意使用和泄露客户资料），订购代表一种契约，买卖双方必须严格遵守该契约，当客户下了订单后，如卖方无法提供相应产品或服务的时候，卖方要承担相应赔偿责任也就是说卖方提供产品或服务的可行性和能力分析一定要在订单阶段以前展开。
关于我在网购中一次不愉快体验：我有一次双11在某宝的某品牌狗粮旗舰店上购买了几袋狗粮，价格是按照双11价格成交的，但在两周后的收货确认的过程中，发现狗粮包装破损，当然我拒收，退货，但这时商家客服人员却说他们只愿意退款，而不愿意换货，摆出一堆公司规定想说服我，因为我在双11购买的价格比平时便宜150元，所以如果采用退款，我再下订单的方式，我将每袋损失150元。当然最后我把什么是订购的理论和我的权益给客服人员做了一次扫盲后，最终他们答应可以给我以双11价格重新购买该狗粮的权利。
当然最后这些客服人员是忌惮于我这样的知识型客户投诉，还是他们真正明白了什么是交易，订购，客户权益的概念，不得而知，但至少说明某宝在订购流程的标准化上面还有很多提升空间，他们给了商家太多忽悠客户的空间，如果平台在订购流程中只发挥渠道作用，而不提供产品、服务质量控制，我想所谓的新电商也是空谈。
言归正传，在订购到确认流程中我还要重点解释的是订单，支付的关系和订单构成关系，先说说订单和支付关系，我们常见订单支付有三种模式，分别是预付费订单、后付费订单和使用后付费订单。
我们常见的电商是预付费订单，电商的80%都是这样的订单，因为目前最普及的电商模式还是产品销售模式，所以预支付产品费用到第三方平台，是对买卖双方最好的利益保障手段。另外有一些物流破损风险的产品可以选择收货后支付的方式，这种方式目前来看使用人群较少，因为在现在平台托管资金如此发达的今天，收货后再支付也没有提高消费者的权益保障，而且还增加了操作麻烦。而第三种支付方式，“使用后支付”是下一步服务业消费升级的重点方式，值得我们关注，在下一个流程中我将重点介绍。
订单构成关系，我们看到的订单按照商家提供的产品结构的不同，会拆分为：产品订单，服务订单和资源订单，也就是说这和我们平台、商家卖什么而决定，我们常见的是产品订单，我们在电商平台购买的都是产品（包括服务类产品），商家所售卖的产品是在他自身经营范围以内的满足人们使用和消费的满足人们某种需求的任何东西，包括有形和无形。
所以服务类产品也是产品，而对这些产品的购买请求就是产品订单，我们常见的购买一把电动牙刷，一台冰箱和一次美甲服务都是这类订单，而服务类产品还多一个服务提供的过程，这样就会分解出服务订单，注意这个服务是动词服务，而非名词服务，你可以理解为名词服务service是产品的构成，而动词服务serve，则是这个服务的提供过程。
所以当你购买了一次美甲服务后，看得见的电商订单是产品订单，而看不见的是serve订单，这个serve订单是管理服务人员如何按时，保证质量的方式向客户提供服务的过程。而资源订单是要满足该项服务过程，而提供的对于资源的调拨，使用和预占过程。例如：对于车辆，人员，道路等的占用和使用。 什么是产品、服务、资源在我的《互联网+下的新电商产品体系》一文中有详细解释，大家可以读读那篇文章。
小结：本来想用一章的篇幅写完这7个流程，可是前面铺垫有点多，所以写到前两个流程时发现已经4千多字了，要继续写下去，就已经不是简书了（怕读者没有耐心继续读下去），所以如果你们喜欢，多关注我的文章的话，我会在下一篇文章中继续写后5个流程Usage-to-payment（使用到付款），Request-to-change（请求到变更）， Termination-to-confirmation（终止到确认）， Problem-to-solution（问题到解决），Complaint-to-solution（抱怨到解决）。
这些流程，当然是宏观流程，是业务分析的方法论，并不是真正意义上的系统流程，这7个流程会根据企业的大小，核心运营实体（建议书，要约，产品，服务，资源）的复杂程度，企业管理方式等演化出更多的流程实例（系统流程）。如果我们分析业务流程没有方法论支撑，那我们看到需求永远是细节和枝叶，没有业务全貌和骨干，同样如果我们只知道这7个宏观业务流程而不具体业务，具体分析理解和实例化，也不可能解决电商实际发展过程中遇到的问题，而我写该文章的目的也是想为那些正在做互联网化发展的传统服务行业提供我的经验和见解，养老行业如此，其他有待我们关注的服务行业也一样。
