MarTech 的真实故事：避免这五个供应商选择陷阱

购买营销技术可能会带来压力。 您选择的影响将在您的企业中产生反响，并且转换成本可能会变得令人望而却步。 然而，似乎很难提前知道您是否选择了正确的解决方案。

这里有一个坏消息/好消息。 在 Real Story Group 为技术买家提供二十多年的建议后，我们看到许多企业成为严重陷阱的受害者，但另一方面，这些往往是可预测的，因此是可以预防的。 以下是我的前五个技术选择陷阱，以及一些避免它们的建议。

陷阱#1：创建一维选拔团队

IT 和营销孤岛之间的传统鸿沟——或者更普遍地说是 IT 和业务团队——经常被漫画家讽刺，或者被拿来开玩笑。

您可能会认识到这种现象：营销部门有预算并在没有充分咨询 IT 的情况下选择工具，或者 IT 仅负责寻找合适的供应商并且没有充分涉及营销利益相关者，或者营销团队只是拒绝参与。

根据我的经验，最好的技术选择团队是跨部门的。 根据您组织的规模和您采购的技术类型，该团队可能包括：

• 营销产品负责人/经理
• 专案经理
• 业务分析师
• 数据分析师
• 开发人员/集成工程师
• 企业和解决方案架构师
• 系统/安全专家
• 内容策略师
• 采购/采购专员
• 其他需要的职能代表：例如，法律/合规、销售、客户服务等

有时，营销与 IT 之间的鸿沟被夸大了。 真正的问题同样经常是单个业务部门的任务是为整个企业选择一个系统，并假设他们的选择将适用于所有人。 “如果它适用于我们，它应该适用于其他所有人。”

这可能源于在整个企业更广泛地将现有投资应用于特定解决方案的理性愿望。 但是，如果不同的业务部门不首先参与供应商选择，那么解决方案本身满足其需求的机会就会急剧下降。

那里的关键词是native 。 有了充足的时间和金钱，您就可以滥用软件来让它做许多从未打算做的事情。 但这对所有相关人员来说都是痛苦的。 如果您希望在整个企业范围内扩展试点项目，最好从一开始就让有代表性的业务部门参与进来。

陷阱#2：受制于电子表格

电子表格可以成为产品选择的有用工具——只要您明智地使用它们。 过度依赖一长串功能列表可能会导致您走上错误的道路。 这通常发生在两个地方：RFP 和供应商评分。

在 RFP 中，试图用一长串所需特性和属性来挑战供应商是很诱人的。 这是一个秘密：供应商以前已经看到了您的所有要求，我向您保证，他们有非常有吸引力的答案。

您的某一行可能会说“提供 REST API”。 几乎每个供应商都会选中该框。 他们不敢不。 据他们所知，RESTful API 支持可能是一项关键要求，甚至在他们满足您之前就将其淘汰。 这个过程可能不会告诉您的是，他们的 REST API 已被改装到平台中，并且没有公开一些关键服务。 因此，将您的 Excel 清单保留在最基本的要素中（例如首选的 IaaS 环境）。 然后，如果您想了解供应商的真正不同之处，请不要问：“是吗？ ”而是“你好吗？” 根据我的经验，供应商往往在如何而不是什么方面存在更多差异。

将清单项目保持在最低限度的另一个原因是，您希望专注于更敏捷、更具设计思维的方法，该方法以以人为中心、可测试的场景为中心。

许多选拔团队还使用电子表格进行决策：通过对标准应用权重、对投标人的表现进行评分，然后将数学相加来衡量和筛选入围者。 一些政府采购需要这种方法。 但是，您应该尝试更加灵活。

一方面，选择团队成员会从最喜欢的竞争中脱颖而出，他们经常在输入分数之前对方程式进行逆向工程，以使他们的首选供应商获得较高的总分。 这似乎是偷偷摸摸的，但它也表明需要发现和讨论为什么成员对特定供应商具有“直觉”本能。

这种方法的另一个问题是一些利益相关者的判断比其他人的判断更重要，或者更重要。 营销人员应评估可用性； 架构师应该评估堆栈对齐； 等等。 根据我的经验，对比供应商成为一种权衡取舍的练习，而数学方法通常会成为阻碍。

可以肯定的是，您仍然需要一个结构化的评估过程，但在涉及到人时更多地依赖定性因素，并确保对解决方案和供应商进行 360 度全方位的了解。

陷阱#3：未能测试提议的解决方案

不试用就购买软件通常与购买汽车相比是不利的。 “你会买一辆不先试驾的汽车吗？”

事实上，技术选择团队通常认为他们必须根据书面提案和不可避免的精简、通用演示做出决定。 害怕在信息不完整的情况下做出错误的选择会造成巨大的压力。 买家开始怀疑，并从一开始就建立了一个冲突的过程。 （正如尤达大师所建议的那样，“恐惧导致愤怒。愤怒导致仇恨。仇恨导致痛苦。”你不应该受苦……）如果你要进行一项重大的营销技术投资，你应该在在提交解决方案之前，至少有两名决赛选手在有限的时间内针对重要的使用场景。

在最好的情况下，这个烘焙阶段变成了一个合作搜索，以了解特定工具如何适合您的环境。 在最坏的情况下，它会在为期一周的冲刺压力下发现与外部供应商合作的困难。 换句话说，它将类似于一个真正的实现，之后您可以以更大的知识和信心签订合同。

陷阱#4：将过多的注意力集中在平台上——而对供应商的关注不够

测试平台很重要，但通常您与获胜供应商的关系会对您的长期成功产生同样大的影响。 很难量化有效的关系，所以这里再次使用电子表格会让你失望。 请记住，您与软件销售团队的关系会像秋天的玫瑰花瓣一样飘忽不定，而您与供应商的服务和支持人员的关系将持续一年。 做出相应的判断。

所有公司都有个性。 软件公司（和开源项目）具有很强的个性。 一个供应商可能擅长核心软件工程，而另一个则专注于客户驱动的功能开发。 一家供应商推广了一个庞大而活跃的咨询部门； 另一个主要通过本地系统集成商工作。 （认识到企业“匹配”对功能越来越重要，我们花了更多时间在 RSG 供应商评估中了解供应商趋势。）没有理想的模型 - 最好的供应商是最适合您的供应商。

也就是说，我会敦促您特别关注围绕任何平台的客户和开发人员社区。 它是长寿的最佳预测指标，即使供应商投资可能会起起伏伏。

陷阱#5：默认现任者

在营销技术不断扩展的世界中，我希望您可以在堆栈中实现某种程度的简单性。 但是您不应该为了自身的利益而追求供应商或平台整合。 当然，您的现有供应商会提出其他建议，并声称您已经购买的解决方案可以填补您的空白（可能是真的），或者他们销售的不同产品会更好地集成（通常是不真实的）。

例如，从现有的 Web CMS 供应商处获得 CDP 可能会给您带来好处，但您更有可能会在等式中失去业务价值。 通过收购将多个平台拼凑在一起的多元化营销技术套件供应商通常没有技术连贯性来支持其吸引人的营销故事。 在许多情况下，它们实际上具有更高的风险。

因此，可以肯定的是，将您的现有供应商列入他们碰巧提供的任何新平台的长名单，但要让他们在我在本文前面概述的相同的、基于测试的选择过程中得到证明。 最重要的是，确保您维护一个可组合的堆栈，以实现灵活的、以客户为中心的功能。

祝你好运！ 请让我知道结果如何。

MarTech 上的 Real Story 是通过 MarTech 和 Real Story Group 之间的合作关系呈现的，Real Story Group 是一个与供应商无关的研究和咨询组织，可帮助企业做出更好的营销技术堆栈和平台选择决策。

本文中表达的观点是客座作者的观点，不一定是 MarTech。 工作人员作者在这里列出。