文章深入探讨如何剖析用户采购组织，理解B端用户的业务场景和决策路径，强调了通过沟通获取用户价值信息的重要性，并提出了基于用户故事的方法来捕捉不同角色的需求。
剖析用户采购组织
影响采购组织决策的因素
外部因素
运营手段：渠道、内容、活动、广告、服务
环境影响：经济、政策、技术、竞品
内部因素
个人影响：使用者使用反馈
组织关系：部门的关系以及权力的犬牙交错
其他因素
产品or服务选择、供应商选择、专业方案、合同条款、、优惠折扣、采购金额
用户的采购类型
新购：用户第一次购买产品，决策流程相对较长，而且采购比较谨慎
增购：用户在使用过程中业务发展较好，再次增加购买，流程较为简单
复购：用户服务周期即将到期，用户再次续费购买，流程简单
通过沟通获得用户的价值信息
用户为什么购买（降本增效）?
内因：业务中出现障碍，需要及时的解决，通过调研的形式发现市面上存在产品和解决方案可解决当前的问题，或公司内部有专家建议使用新的方式解决现在的业务问题。
外因：每年信息化部门有相当的预算完成公司的信息化程度，也可能在外部内容、活动等看到不错的解决方案，尝试引入到公司内部解决问题。
谁参与了决策？谁是主要的影响者？
用户的采购决策是谁参与了，
使用者：关注产品的使用、体验，问题的解决。
影响者：不参与沟通，但是意见非常重要，CTO、CIO、COO。
采购者：采购部门，每年固定预算，每一项控制合理区间。
决策者：拍板购买产品的人，小公司是老板，大公司是经理，小单子可能就是使用者。
传递者：内部传递信息的人，并不参与真正决策，比如：商务、秘书等用户。
采购的主要影响因素是什么?
外部环境：经济情况、供需情况、技术发展、竞争情况等会影响用户的购买决策。
采购组织：当年的目标,公司的战略规划，采购组织和采购流程等也会影响用户的决策。
人际关系：内部人际关系，专家意见，采购人的权利，以及商务关系也会影响产品在客户心目中的地位。
个人倾向：工作职位、个人喜好、个人动机以及购买方式等都会成为影响采购组织决策的重要影响因素。
用户做出购买决策的流程？用户如何做出购买决策?
注意事项
用户的决策流程很长，在每一个环节都要正确的传递产品和公司价值。
关注客户的环节流程，更要关注每个环节的主要影响人员。
通过运营手段，在各个环节促进用户进入到下一个环节。
深度理解用户的业务场景
为什么要分析业务场景、梳理业务需求？目的在于提升用户体验，助力解决业务问题。要永远记住，B端用户买产品买的都是场景的解决方案。
理解业务步骤
分行业：按照科技、互联网、制造业、农林牧渔等方式进行用户的行业划分
分类别：把企业按照政府单位、央企、国企、私企等方式进行划分
分公司：把公司按照头部、肩部、腰部、尾部等规模进行划分
理解方法之收集信息
基于第四节的内容，尽量多的收集行业的信息，抽取行业中有价值的信息。
阅读：大量阅读行业的信息，把信息内进行归类整理，特别设计业务角度的信息（不要看结论，都带有主观性）。
分类：把信息按照行业、类别、公司等级别进行分类，理解不同类型公司的业务相关信息。
提取：从中提取有价值的信息，辨别是材料中表述的事实，还是片面的观点，尽可能多的理解业务场景。
理解业务方法之调研
理解用户的业务步骤，必须理解用户的公司组织，只有到一线去，才能真正的理解用户。
行业专家
邀约行业的专家，快速通过他们构建起行业的第一因素。
梳理调研问题：从宏观到微观进行问题的梳理，结合自己阅读材料获得的信息，可以先讲述整个客户的流程。
邀约行业专家：在行业中比较知名或从事业务比较就的人员，通过脉脉、招募形式邀约、约谈最好是两个人一组对专家进行约谈，尽可能的补充并获取有价值的信息。
整理结论：按照专家的描述，画出内部业务流转的路线图，并记录客户关心的问题。
公司客户
可以按照自己的分类,调研不同的公司成员，深度理解公司的业务场景。
分类筛选：按照公司对用户的筛选规则，选择不同类型、规则的用户进行调研。
邀约客户：让客户成功、销售等对客户特别了解的人邀约客户，邀约一些工具使用较好的客户。
用户访谈：邀约用户之后，最好能够线下访谈或者跟着客户成功团队一起拜访用户，提升用户信息获取的效率。
信息收集：把用户的信息按照流程梳理，并提取公司的共性问题以及特殊问题，加强对行业的理解。
内部同事
和公司内部同事多沟通，了解其内部的多样信息，获取更多有价值的用户信息。
售前：售前专注于客户的解决方案，可以获得非常有价值的用户业务流程以及用户业务中的痛点和难点
销售：销售接触用户时间最长，对于用户的了解更透彻，特别是业务用户的需求点
实施：实施部门落地业务的场景，对于用户每个角色使用那个功能模块了解的更多
客户成功：用户真正的上线使用，深度理解客户的业务场景，包括业务的流转形式，以及每个阶段所需要的功能
注意事项
B端运营至少是半个业务专家和半个产品专家。
深入到业务中去，梳理用户的业务流程，最好产出用户的业务流程图。
对于业务中涉及的专业知识，必须在业余时间加强补充。
一句话定位就是：比业务更懂产品，比产品更懂业务。
理解业务方法之拆解
拆解用户业务路径中每个角色的触点，针对每个角色梳理有效的行为路径。
准确的、深入的理解B端用户
决策和使用路径
理解B端用户路径
拆分用户角色：基于行业区分、采购组织成员以及使用产品人员，把用户按照不同角色区分
梳理用户触点：按照用户的业务流程，画出用户的行为蓝图
观察用户行为：可以邀请部分用户，或与客户一起工作,看客户如何使用产品
调研用户利益点：根据调研情况，梳理各方使用产品的关注点,并输出用户关心内容
公司的常见角色以及关注点
梳理用户触点
注意细节
从用户业务的行为路径出发，按照用户角色进行划分
在角色中解决用户的业务问题，并标注主要的事项
也可以利用泳道图解决问题，不一定是按照这种方式
观察用户行为
POEMS观察法
POEMS观察法用于指导观察者在设计观察的时候，该观察什么、怎么记录并考虑后期的整理分析
People：被观察者、观察对象
Oobjects：观察看到的物体或产品，尤指与被观察者有关的物体或产品
Environments：观察内容所处的环境
Messages：观察过程中可能相关的信息
Services：观察中可能涉及的服务
选择用户
可招募现场的参与者，可以和选择合作企业，说明观察的目的和获取内容，并说明获得信息的用户，高度敏感行业只能去现场自行观察。
观察用户
记录用户操作产品的路径和方式，以及用户在使用中遇到的问题，并分析获取的内容，探究用户背后的逻辑。
记录事项
在记录期间不要分析发生了什么，观察用户对产品的操作并仔细操作操作的细节内容。
注意事项
尽可能全的观察每个环节中用户的行为
对于一些疑惑点，可以再次和用户沟通，进行用户调研
用户观察需要投入较多的资源，收获也是较大的
B端的观察根据用户的业务路径，可能一次性并不能完全观察，需要多次观察
用户调研
B端用户尽可能用访谈法进行用户研究
对于单个功能的建议可以使用调研问卷
一定是先用户访谈定性，然后再调研问卷定量研究
调研的目的是发现用户的痛点、难点和提升点，深度了解每个角色的用户
用户调研步骤
调研准备
按照用户的行为数据，拆解出用户的名单，按照调研目标的3倍准备名单，并准备访谈的问题，营造一种轻松的范围进行用户的调研。并把调研的背景、目的在公司内部同步，让帮忙邀约的同事知道这件事情的价值。
邀约调研
让公司的其他部门同事按照名单邀约，特别是销售同事、客户成功同事，大家共同维护一个邀约日历，避免日期的重复。尽量邀约线上的访谈，可以节省一部分的时间。
调研记录
在调研中记录访谈中有价值的信息，特别是征得用户同意后进行录音、录屏，方便会议结束之后对内容的梳理，重点关注用户的痛点、难点、希望解决的问题点等信息内容，在访谈中尽量以轻松的分为让用户进行调研。
报告输出
把统计到的用户数据，最后输出一份调研报告，把用户的问题归纳到类别内，可以更好的理解当前用户的行为和想法，帮助构建内容、用户运营等技巧。
注意事项
用户调研的过程中存在一些问题，需要逐渐的解决问题，理解用户。
在公司的分类下，对公司组织中的各类用户进行调研，丰富用户信息。
从人出发，解决理解用户深层次问题
围绕用户感受价值为核心，构建一切用户感受体系
以人为本的原因
虽然B端运营面向的是采购组织，采购组织中不能忽略个人因素的影响
虽然B端运营不能让所有人满意,但是必须让接触到的用户满意
只有触点用户的大多数人满意当前价值，才能产生更大的生命周期价值
用户分层
KA客户：定制化程度较高，内部的结构比较复杂，喜欢私有化系统，业务挑战度很高，喜欢有同行案例的客户，而且也看中商务关系。
头部客户：业务开始变的复杂，需要更多的业务系统帮助解决问题，关注系统稳定性、数据、权限互通的能力，更好的在业务中落地。
潜力客户：潜力客户是腰部客户中发展较好的用户，可以从业务发展、资方背景、创始团队背景判断，和腰部客户的诉求一致。
腰部客户：腰部客户的业务找到了核心商业模式，着重在发展业务，纵向或横向发展，可以利用专业的案例吸引这些客户。
长尾客户：长尾客户关注产品的价格，而且决策链路很多，更多的运营方式可以满足长尾用户的需求。
使用者、影响者以及决策者的关系
以人为本的三个重要点
用户画像：根据用户的共走目标，使用场景，使用频率，使用平台，使用时间，等构建用户画像。
业务场景：用户在什么情况下会使用产品，列举日常使用的场景。
用户痛点：在使用过程中用户存在的业务障碍点以及希望提升的内容。
用户故事之3C法则
卡片（card）：简短，必须解决故事的”谁(角色)”，”什么(行动）”和”为什么（好处)”。
交谈（conversation）：用户故事背后的细节，来源于跟客户或产品负责人的交流沟通。
确认（confirmation）：确认代表满意度条件，这些条件将用于确定故事是否满足意图以及更详细的要求。在B端中，必须要避免闭门造车。
用户故事之3W法则
用户（who）：与系统发生交互的成员，而不是团队。
行动（what）：用户应该采取什么样的主动行动，才能完成这样的功能。
好处（why）：这个功能客户给用户带来什么样子的价值。
一句话来说就是：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<带来哪些开发价值>。
例如：作为[经理]，我想[生成一份报告]，以便[我可以了解哪些部门需要更多的资源。
用户故事案例
对不同的功能，不同的用户群体，准备不同的用户故事。
市场部：使用聚合投放，节省工作时间，提高工作效率。
运营部：记录活动和素材的数据，迭代分析，提高活动成功率。
老板：用户全生命周期数据沉淀到系统，分析最优渠道，提高公司收益。
用户故事案例
用户故事在不断的迭代，随着产品的功能完善，用户需求也在变动。
用户故事在写完之后内部进行检验，迭代多次才能有效。
产品的用户故事，一定是基于对用户的调研，而不是根据产品功能的脑补。
没有回复内容