Scott Brinker谈平台营销：自助式Martech的8个「P」

我在10月初的Martech Conference上做了一场题为「平台营销」的演讲。

我职业生涯中的大部分时间都在思考两个宏大的主题——市场营销和平台。然而，我花了一段时间才意识到，在软件平台（software platforms）上看到的模式与当今营销组织内部的Martech平权化所发生的事情是一样的。

这两者都致力于驾驭好系统组成部分在更广更深的生态系统中的能量。

几个月前，我写了一篇关于Martech 成熟度模型的文章，谈及了公司如何在营销中利用Martech三个阶段来取得发展的问题：

Assisted-Martech用于去中心化的有限的散点式解决方案

Embedded-集中的Martech /营销运营角色/团队

Absorbed-一个强有力的Martech中心，且分布广泛地被使用和采纳

在我最初的关于「成熟度」模型的文章中，我还明确指出了理论的第四阶段——「以Martech为主导」 ——AI将接管市场营销并为我们做一切。眼下，这不会很快发生，所以我在这里跳过。（如果Martech 最终在Gartner大肆炒作的周期中进入幻灭的低谷，我会欢呼雀跃，这样我们可以跳过对Martech 不切实际的幻想，而专注于现实和有待完成的实际工作。）

拥有专门做营销运营或营销技术角色或团队的公司，尤其是一些大型公司，通常将这种团队称为「卓越中心」（Center of Excellence），大多数这样的公司处于Martech成熟阶段。

从有限的（Limited）或分散（Scattered）的阶段转移到如上那种成熟Martech阶段相对简单——聘请优秀的营销技术人才，给他们明确的Martech管理工作职责，分配足够的Martech预算，便可以得到实实在在的embedded 模型的Martech功能。

但是，我们如何从embedded转变为absorbed第三阶段？答案并不是唾手可得的。

首先要问的问题可能是为什么从embedded模式转向absorbed模式的Martech ？这会带来什么好处？

Martech 成熟的下一阶段：大规模敏捷（Agility at Scale）

embedded模式和absorbed模式之间的主要区别在于，核心营销运营团队之外的营销人员能够在多大程度上能够自助适应与Martech相关的需求。

这是「授之以鱼」而不是「授之以渔」那句谚语的一种变体。相对于「替我做」，不如是「辅助我自己完成」。

瞧瞧，embedded模式的Martech 功能不可避免地会遇到的挑战，且与任何中心化（centralized）服务将面临的挑战类似：总是有更多的事情要做，每天花费数小时或全部资源都无法完成。

因此，当各种请求从整个组织涌入，中心化服务必须过滤掉请求（「抱歉，我们将无法这样做」）或将请求放入队列（「这是您的单号，我们将获得我们会尽快处理」）。

这种模式限制了整个组织对需求采取行动的速度。如上所示，对于中心化模型的服务，通常会在长长的队列（Queue）中等待新的相应。最后中心化模式的团队才会着手处理它，执行的过程效率通常比较高，毕竟这是他们这种类型团队的专长。但是，在「必须继续处理」队列中的下一个请求出现之前，他们通常无法对这个反馈进行太多的迭代。

这个想法的进一步解决，需要重新排进线性队伍中，然后再次等待，漫长的等待。

但是，当若能使整个组织中的人员能够自助式他们的更多想法时，排队等待就变得无关紧要了。他们可以直接从构思转到执行。而且，如果他们想迭代自己的执行过程，便可以立即这样做，且继续迭代的次数也可谓是「随心所欲」，只要他们认为这样做是有价值的事即可。

这种自助式功能还带来了一些其他好处：

带宽Bandwidth-由于不必与所有Martech相关的活动都通过核心集中的团队排着队依次进行，因此整个团队对Martech任务进行「并行处理」的能力将大大提高。Martech成为瓶颈的情况大大减少。

创新Creativity-将创意运用Martech不再仅限制在核心集中的团队构想出的创新中; 营销过程中的任何人都可以运用他们的想象力以新颖的方式利用Martech 。发现好创意好点子的最好方法是要进行大量而广泛的实践探索。

学习 Learning-在实干中学习。如果只有核心集体的团队在「搞」 Martech，那他们实际上是唯一可以从中学习的人。但是，营销人员与Martech 的合作越积极，学习到的就越广泛。

适应性Adaptivity-当embedded模式的Martech通过一个核心集中的团队提供执行效率和控制力时，absorbed模式通过鼓励营销组织中的每个人尝试新的想法和技术来提高适应性。不同的团队尝试使用不同的工具和策略，以更好地为他们自己的专业需求使用Martech。整个公司都将从营销创新更先进的引擎中受益。

平衡Martech的中心化和去中心化

我所说的自助式并不意味着放弃所有核心团队的责任，屈服于一个「无法无天」的「每个市场营销者都能自说自话」的混乱局。你必须提供基础结构和支持，以便你在实操层面捕获更广泛的营销组织带宽和创造力——而不会使信息熵损失掉比带更多参与者进入系统中的能量。

关于「核心中心化」与「去中心化」之间的平衡关系曾在「营销技术与运营的新规则」这篇文章中做了说明。

通常，你需要在差异性较低的技术基础架构上做好「中心化」，特别是在数据（即「记录系统」）层面，例如CRM，CMS，DAM，CDP。（凭经验判断，如果它是行业中通用流行的首字母缩写词，你应该将其中心化吗？可否称它为「首字母缩写词定律」呢？）

正如我在Martech主题演讲中所开的玩笑那样，Martech的去中心化并不意味着每个人都有自己的CRM——类似「奥普拉脱口秀」式的奖品大放送，人人有份。

但是在很多情况下，营销部门中的不同成员或团队可以从采用专业化的SaaS工具（或创造性地调整中心化类型的工具）中受益，从而以去中心化的方式自助满足营销过程中的特定需求，以适应差异很大的情形案例：

内容营销团队所用的可自行编辑日历的一个解决方案。

ABM「老虎小组（tiger team）」尝试做的一个发布者购买意向服务。

销售支持团队所使用的用来创建评估的一种交互式内容工具。

市场研究团队为参与者提供礼品卡发放的一项服务。

地推营销团队所需要的用于完成轻量级注册的一个系统。

产品营销团队所使用的一项移动视频录制和编辑工具。

本地营销团队在新兴市场中所测试的基于SMS技术的一套广告营销活动。

在Martech 领域的数千种应用程序中，许多应用程序对于这些特殊的案例是理想化的，这些用例已经超出了营销组织的边缘。

从人本位的角度来看，核心集中的营销运营团队必须为这些去中心化的活动建立全球法规还得做到有力执行。法规这个范围里包括例如GDPR这样限制数据隐私合规性的实际法律要求。此外，它还包括特定于公司的规定限令，这对保护品牌与业务运营的完整性来说，至关重要。

但是，你可能并不想限定得过于宽泛，以至于最终会阻碍本打算释放的那种散落各处的创造力。你希望采用去中心化的模式，以便有足够的空间进行有机发展，以便不同的团队在本地化任务的背景下了解哪些是有效抑或是无效的方法。

自助式Martech 的8P

为了进入Martech 成熟的Absorb阶段，并在营销业务的中心化和分散化之间取得适当的平衡，那你就需要一个可靠稳定的框架来最大程度上管理自助式的Martech。

想必你应该已经听说过营销理论上的「4P」：产品（product），价格（price），位置（position），促销（promotion）。它们是营销的基础，且并未被历史淘汰，与以往一样重要。

我提出了自助式MARTECH的「8P」。

诚然，这种缩写游戏玩得是原来市场营销理论「4P」玩剩下的。（嘿，不过如果营销的「4P」这么好用，那么自助式的Martech的「8P」肯定是好用的2倍啦，难道不是吗？这可是小学数学题！）但是，我要描述的八个因素实实在在是关于自助式Martech 企业组织应该具备的能力。

我将它们分为依照「技术」和「人员」展开的两个术语词组。

先来说说自助式Martech在技术层面上的4个因素

1. 平台-PLATFORMS，司空见惯的问题。首先，你需要真正开放的软件平台作为Martech技术栈的基础，为了给其他应用程序、数据源及其集成提供方便。这使你具有支持其他去中心化的Martech 工具的技术能力，同时又可以维护好整齐划一的中心化记录系统。

值得庆幸的是，Martech的三大趋势之一是，所有主要的营销云都走得比「old suite vs. best-of-breed dichotomy 」更快，从而做到了真正拥抱开放的平台生态系统。但是，并非所有整合都是平起平坐的。在评估平台选择时，请考虑app集成的4个层面：数据，工作流，UI / UX和统管。

2. 分割-Partitions（或模块化设计）。当多个自助式的人员在同一个平台上并行工作时，你会经常想将它们分割成各自独立的空间，以此做到在没有营销运营团队一直统调每个人活动时，不会有冲突发生。这是一种「沙盒」策略。

在 DXP/CMS 平台上，团队发布权限可能会被分配给网站上的不同域或目录，或者就单单分配到独立的跳转页面或博客文章。在营销自动化平台中，它可能意味着管理分割的订阅列表或工作流序列（但通常具有global rate限制约束）。使用 CDP，它可能意味着将新数据集链接到主客户记录，而不会覆盖核心字段（至少没有明确的审批流程情况下）。

3. 许可-permissioning（或管理）。多人工作在一个共同平台上，设置精细权限与访问准入是很重要的。谁可以在中央数据库中添加，查看，编辑或删除不同的记录（甚至这些记录中的特定字段）？谁可以在参与系统中触发不同的动作？谁可以批准工作流程中的不同决策？

最有安全性的做法是将某人执行其工作所必需的「最小特权」设为权限。在某些情况下，这也可能意味着类似于即时访问，即仅在为了完成特定任务有需要时才在有限的时间内授予该人员权限许可。这种技术统管并不是要保护自己免受违规行为者的侵害（当然了，希望这种情况少发生为好），而是要防止疏忽马虎造成的意外灾难。这种权限监管可以确保自助式整个环境的安全。

4. 感知-perception（或监视）。我承认，我主要是想找到一个以「p」开头的词。所以我借助「感知」这个词义来说说「监视」。在自助式的环境中，大多数由Martech推动的活动都将不经过人们明确要求而被允许触发，「开始执行」的决定权被分散了是一件好事。

但是，对于营销运营团队来说，监视那些正被Martech驱动的活动（即使已经开始运行）也很重要，要能检测（「感知」）异常模式或误入歧途的信号。通用基础的平台应提供一些「可见性」参考，包括仪表板和查账跟踪。

这是甚至在类似Workato工作流管理或类似Quick Base或OutSystems那种轻代码应用程序开发之类的情况下也要考虑使用标准化平台的原因。个人拥有在这些自助式的平台上构建自己渴求之物的自由，而中心化平台为所有平台提供了内置的透明性（transparency）。

您可能希望使用独立的监测工具来补充基于平台的监管，例如Blissfully或Torii这样的SaaS操作软件，Pagerduty 这样的网站和应用程序监视软件以及如Decibel Insigh这样的CX监视软件。您还应该与IT和网络安全团队保持紧密的合作，以进行更广泛的监查和威胁检测。

但是技术因素只是自助式Martech 等式的一半...

自助式Martech涉及到人的4个「P」

5. 权限许可-Permission（或赋权）。这是与我们上面讨论到的「权限管理（Permissioning）」不同的概念，之前说的是准入控制的技术原理。而这次我们说的是「管理层积极鼓励员工使用自助式Martech」。所以Permission就是为员工赋权。

它为整个组织的人们提供了尝试体验Martech 功能的权限许可，拥抱这其中要反复试验试错的发现过程。这帮助员工们灵活地将时间和预算分配给基于Martech技术的内容创意。一线营销员工在合理的范围内被赋予权力对该技术的使用做出判断。

6. 能力储备-Preparation（或启用）。当然，仅仅拥有做事的权限许可是不够的，还需要教一线营销人员在使用该项技术的能力技能上做好准备。这种能力储备首先来自对如何使用Martech这类文档的学习和培训，这既包括中心化的营销运营团队所采用的具体平台，也包括更广泛意义上的数字营销技能学习（例如HTML，SEO，数据分析，入门级的编程等）。

但是，良好的能力储备不仅限于单向的、被动的学习，还包括通过建立内部Wiki来参加Martech的「Office hours」活动，在公司的「Science fairs」上展示各自的工作状态，来鼓励营销人员彼此分享经验和见解。接触其他「点对点」的学习方法，抓住行业聚会交锋的机会，也可以与公司之外的同侪联系，交流想法，获得新的观点（Ahem，Martech）。

7. 原则-Principles（或确保）。「能力越大，责任越大。」既然选择了授权整个组织得以使用自助式的MARTECH ，那么建立明确的边界和范围就非常重要，也能引导大家应用该项技术时做出正确的决策。这包括与数据隐私合规范（即「未经明确同意不得导入联系人数据」）和品牌标准（即不得使用个人调色板和字体偏好创建新logo）相关的非黑即白的规则。

但是，比起详细的规则清单（那种写出十好几条，正常人难以真正记住的规则清单）更有价值的是正定义着品牌文化真正精神内核的原则。HubSpot的客户代码（Customer Code）就是一个很好的例子。这些原则使去中心化的团队可以在无数种特定情况下做出优质的决策，在一些特定情况下维护品牌的理念和声誉。

8. 激情-passion。创造前途无量的自助式Martech 生态系统的最后一个要素是激情。中心化市场运营团队必须热衷于授权组织中的其他成员使用Martech 并进行大胆试验。他们一定要做Martech 指导员，而不是Martech 审判官。

高级别的管理人员必须热衷于推动这种去中心化的转变—并致力于把时不时就很坎坷的学习经历和探索新想法时逃不开的失败实验来给大家分享一下，来宽心打气。

最后的最后，组织中的营销人员必须热衷于获得这些由Martech驱动的新技能，并大步迈出自己的舒适券。毕竟技术变革的速度比组织（Martech的法则）可快得多了，唯一的制衡力量来自于对自己学习更新那一以贯之的强烈需求。