博客

可复用的数字产品交付手册

一种可重复的流程,用于向多个客户交付数字产品,而无需每次都重建相同的架构。

摘要

大多数数字产品建议都假设是一次性发布,当你需要为多个客户运行同样的操作时,这种建议毫无用处。本文认为,产品不是策略——交付才是。你将学会标准化交付规格、自动化支付环节,并让支持和退款保持人工处理。文章还涵盖了如何在客户要求定制门户时提出异议、如何按产品类型定价,以及哪三个数字能真正证明流程有效。目标是建立一个可重复的系统,能在与客户的接触中存活下来,而不是一个巧妙的营销漏斗。到最后,你会确切地知道明天该做什么:编写规格。

大多数关于销售数字产品的建议都是为那些只做一次的人写的。选择一个平台,上传文件,添加电子邮件,然后称之为发布。当你必须为第二个客户、第三个客户运行同样的操作时,这些建议就失效了。你没有为每个人定制设置的奢侈;你有义务构建一些可重复的东西。产品本身很少是困难的部分。交付才是。而交付是一个系统问题,而不是创意问题。

根据 MVST 对数字产品商业模式的概述,数字产品市场预计到 2027 年将达到 8485 亿美元。我不知道这个数字有多精确,你也不知道。它的存在是为了让你觉得自己迟到了。忽略它。重要的是,这个市场足够大,客户不断向你寻求帮助,如果你把每次合作都当作独一无二的雪花,你会精疲力竭,无法享受工作。

数字产品建议中最大的谎言是什么?

最大的谎言是产品就是策略。你会听到很多关于寻找盈利利基、设计完美课程大纲,或在一键购买和订阅之间做出选择的建议。这些确实是决策,但对于需要为多个客户交付的人来说,它们位于实际瓶颈的上游。瓶颈是交接:从有人付钱到真正使用他们所购买的东西之间发生的事情。自动化系统可以将这个窗口从几小时缩短到几秒——更重要的是,它可以减少需要接触交易的人数。

因此,真正的策略不是爱上某个客户的产品,而是构建一个无需重新设计就能重新配置的交付架构。这与大多数数字产品建议训练的不同。这意味着你按产品类型思考,而不是按产品;按流程思考,而不是按功能。一旦你这样框定,下一个问题就很明显了。

难道每个客户不都不同吗?

部分不同,但没有他们想让你相信的那么不同。课程、模板包、软件许可和电子书有不同的文件、不同的价格和不同的客户。但它们也有共同的骨架:购买、接收、访问、支持。如果你从这个骨架开始,你可以在不重建骨骼的情况下调整细节。

下表是故意粗略的。它不是策略;它是在你开始设计之前对客户请求进行分类的一种方式。

客户情况真正重要的应该投入精力的地方
单个文件(电子书、PDF、模板包)即时、可恢复的下载文件存储、下载页面、简单的许可说明
带有模块或滴灌内容的课程访问控制、进度跟踪登录、交付计划、电子邮件提醒
软件或许可证密钥密钥生成与验证自动化密钥交付、清晰的支持路径
会员资格或订阅定期访问和计费支付集成、取消处理

如果客户无法告诉你他们属于哪一行,你不需要一个更好的平台。你需要一次更好的对话。

我应该为每个客户选择不同的平台吗?

不。如果你对此点头,让我帮你省去一年的痛苦。一个你熟知的默认平台,胜过每个项目都要重新学习的更灵活的平台。客户不在乎你使用哪个平台。他们在乎下载是否有效。选择一个主要的销售环境,了解其局限性,并围绕这些局限性设计交付架构。当客户要求默认设置无法做到的事情时,那就是讨论定制构建的时候——而不是之前。

这并不意味着你应该忽略客户现有的设置。这意味着你应该有自己的观点。如果客户说他们“已经在”某个平台上,并且它做事方式不同,你的工作是将他们的状况与你的默认设置进行比较,而不是为了他们重新发明轮子。可重复的流程是有默认值的流程。

如果客户已经有商店设置怎么办?

那么你的规格就变了。你不需要从头设计;你是在审计现有的流程。和他们一起走一遍这四个问题:客户得到什么、何时得到、如何得到,以及失败时会发生什么。大多数现有设置都败在最后一个问题上。没有人对“下载链接已过期”有后备方案。这是你增加价值而不需要拆掉他们整个商店的机会。

人们倾向于把现有设置视为神圣不可侵犯。抵制这种诱惑。现有商店只是一个起点。如果交付路径是手动的,客户每天花一个小时手动发送文件,他们付钱给你是为了解决这个问题。你无法通过增加更多步骤来解决。你要通过将交接移至支付时刻来解决。

我如何知道一个流程实际上是可重复的?

把它写下来。如果你不能在十分钟内向承包商解释这个流程,那么你拥有的不是流程,而是习惯。一个可重复的流程能够在客户中途改变主意的情况下存活,也能在你状态不佳的情况下存活。

测试很简单:你能把规格交给别人并获得相同的输出吗?在代理机构的环境中,这就是零工和服务之间的区别。服务有明确的边界,而边界正是让你在不用增加压力的情况下扩展的东西。如果流程依赖于你在场,那么它不是可重复的,只是可靠的。

我应该首先标准化什么?

从你真正可以复制的东西开始:交付规格。这是一份一页的文档,为你销售的每种产品类型定义客户收到什么、何时收到、如何访问,以及如何获得帮助。听起来很无聊。确实无聊。这正是它能起作用的原因。

在你选择平台之前,先编写规格。然后每个客户都成为同一模板的变体。“客户得到什么?一份 PDF 和一个下载链接。何时?立即。他们如何访问?通过一个只有他们能访问的页面。如果出问题怎么办?一个工单表单。”现在你知道要构建什么了,你可以把规格交给开发人员、承包商,或未来的自己。我在 为每个客户提供交付规格 中写了更多关于将其转化为可重用工件的内容,但你现在需要的版本就是上面的四个问题。

什么实际上需要自动化?

自动化支付环节。交易一结算,客户就应该收到文件、链接、许可证密钥或解锁电子邮件。在这条路径中不应该有人工介入。自动化指南喜欢承诺这将“将交付时间从几小时缩短到几秒”,这听起来像是一本技术手册,但在这种情况下,技术确实做到了。客户不想被打动;他们想要的是他们所购买的东西。

然而,不要自动化整个客户关系。你可以自动化交接,然后让对话保持人性化。这种区别与守旧无关。它关乎避免出现每个支持请求都得到自动回复而无法回答问题的情况,因为客户不想为人工付费。正确的顺序是:让交接隐形,然后让人可以找到。

什么应该保持手动?

支持、退款和判断。这些任务看起来可以自动化,但绝对不应该自动化,至少在你看到几十笔真实交易之前不应该。埋藏在自动化流程中的退款政策是对知道如何利用它的客户的礼物。收到自动回复的投诉感觉像一堵墙。

这是论点中逆势的部分:在一个告诉你自动化一切的世界里,你的竞争优势是触手可及。购买后的一小时是建立或摧毁信任的地方,一个人在这一小时内能做的比任何电子邮件序列都多。如果你想把这件事交给软件,在这样做之前,请阅读 购买后的一小时

客户说“让我卖起来就行”——我该从哪里开始?

当客户给你这句话时,忍住直接进入设计的冲动。问三个问题:你在卖什么,你想如何交付,购买后应该发生什么?如果他们无法回答,就不要为他们选择平台,直到他们能回答。

拿一个典型的例子:一个客户有一组给手工艺人的 SVG 文件。他们想卖掉它们,但对交付一无所知。你不需要会员门户、移动应用或滴灌活动。你需要一个结账页面、一个下载链接,以及一个小页面,说明购买者可以用这些文件做什么。构建它,然后用真实购买进行测试。就这样。

每个客户的顺序都是一样的:定义产品类型,选择最简单的履行路径,绘制购买后体验,并添加一个指标来告诉你路径是否有效。对于简单的产品,你可以在一天内完成所有这些。平台是细节。

如果客户想要定制门户、会员网站和移动应用怎么办?

这是你需要诚实的地方,即使这会让你失去这笔生意。定制门户构建起来昂贵,维护起来痛苦。要求定制的客户通常并不需要它;他们需要一个让自己感觉专业的借口。你的工作是将“想要”转化为“需要”。

可重复的架构在失效之前一直有效。如果产品确实需要具有进度跟踪的会员系统,那就将其构建为具有自己的交付规格的单独产品类型。但如果客户因为不好意思卖 PDF 而要求开发移动应用,提醒他们,当下载是即时的且内容很好时,没有客户会抱怨 PDF。在你重新发明轮子之前,要提出反对意见。

那定价呢?

定价值得拥有自己的流程,你不应该让一个客户奇怪的打折习惯污染你的交付架构。但你的交付规格实际上塑造了定价对话。如果你知道客户得到什么、何时得到,以及后备方案是什么,你就可以自信地定价——并且你可以向客户解释价格,而无需编造关于“品牌资产”的故事。

在不同客户之间保持定价合理的最简单方法是,将价格与产品类型挂钩,而不是与客户的热情挂钩。单个文件模板包与完整课程有不同的价格区间,而你的规格让这种比较自然。如需深入了解,请参阅 数字产品利润最大化定价

那流量和营销呢?

这是大多数建议退化为“在社交媒体上发帖并祈祷”的地方。你可以做得更好,把营销当作另一个可重复的系统:一个解释结果的产品描述,一个样品或预告,以及一个在发布前收集电子邮件地址的简单方法。你不需要病毒式漏斗。你需要一个可预测的漏斗。

陷阱在于,让每个客户的“品牌声音”证明一个全新营销流程的合理性。你可以在不改变步骤的情况下调整语气。步骤是:展示问题,展示解决方案,展示证明,要求购买。这对电子书、课程和一组 SVG 文件都适用。它不戏剧化,而且它能在客户不知道自己品牌听起来如何的情况下存活。

我如何向客户展示这一点而不听起来像个顾问?

不要把流程当作流程来呈现。把它呈现为他们将得到的东西:一个自动将产品交给客户的店面,一个不占用客户周末的支持路径,以及一个不需要开发人员的发布。如果你以“交付规格”开头,你会失去他们。如果你以“你的客户会立即得到他们支付的东西”开头,你就不会。

额外好处是,可重复的流程给了你可辩护的范围。当客户要求规格之外的东西时,你可以说“那是一个单独的产品类型”,而不是“那是很多额外工作”。第二种说法听起来像借口。第一种听起来像专业边界。两者都说不;其中一个能保持关系完好。

如果客户还没有产品怎么办?

那么你就不是在做一个交付项目,而是在做一个产品开发项目。在开始之前要明确区别。说“我会为你建立一个课程”很诱人,但如果客户无法告诉你购买者得到的结果,你就是在为不存在的内容构建平台。

在这种情况下,第一步仍然是规格——但规格描述的是产品,而不仅仅是交付。谁是购买者?他们有什么问题?购买后他们能做什么?一旦这些答案存在,交付架构就与任何其他产品类型相同。不要让产品的缺失成为过度复杂化交付的借口。

我应该衡量什么?

衡量交接。具体来说,衡量从付款到客户获得有用东西之间的时间、购买与成功下载的比率,以及退款请求的比例。这三个数字告诉你交付系统是否健康。不要被页面浏览量、展示次数或“参与度”分散注意力,除非你拿钱是为了制作没人读的报告。

当交接时间持续很短时,你会发现退款减少,支持工单不再那么奇怪。那不是一堆统计数据;那只是人们得到他们支付的东西时发生的情况。你不需要仪表盘。你需要关注交接。

你明天应该做的一件事是什么?

编写交付规格。不是明天——是今天下午。拿你接下来最可能销售的产品类型,打开一个空白文档,回答四个问题:什么、何时、如何,以及如果出问题怎么办。这一个工件比任何新平台功能都更有价值。

数字产品建议中的其他一切大多是噪音。市场很大,炒作很响,工具每个季度都在换名字。能存活下来的,是一个将“客户 X 想卖东西”变成你已经深思熟虑的可重复答案的流程。一旦构建了它,你就不再出售你的时间。你开始出售系统。

Sources (5)