一句话总结

向第三方履约的缓慢过渡

亮点

• 我已开始将 TinyPilot 的履约工作过渡给第三方供应商。
• TinyPilot 客户对价格的敏感度低于我的预期。
• 我为 TinyPilot 的以旧换新投入了大量资源，不确定是否值得。

目标评分

每个月初，我都会公布当月想要完成的目标。以下是完成情况：

将一款低销量产品的履约过渡给新的 3PL(第三方物流)

• 结果：我们的 3PL 供应商已为 Power Connector 履行订单三周。
• 评分：A

虽然还有一些细节需要磨合，但我们已成功过渡了首款产品。

在 NERD Summit 2023 上演讲

• 结果：我完成了演讲，对表现感到满意。
• 评分：A

自 2019 年以来首次线下回归 NERD Summit，感觉很有趣。有很多精彩的演讲和愉快的走廊交流。

减轻履约团队的负担，使被动任务占用时间低于 80%

• 结果：基本成功，但难以量化。
• 评分：B

为了向 3PL 过渡，我们需要为本地团队腾出足够的工作量，让他们能够额外生产一周的设备。我们采取了多项措施来减轻他们的负担，不过他们的工作时间也比平时更长。

TinyPilot 数据

将 TinyPilot 的外壳从塑料换成金属后，需求大幅增长。即使我提高了价格并将营销投入降至接近零，销量仍在持续增长。

我今年的目标是实现 10 万美元利润，但我们已经完成了 75%。按此速度，我们将在 4 月底前实现 10 万美元的年利润。

向 3PL 供应商过渡中的波折

我的首要任务是将 TinyPilot 的履约工作过渡给 third-party logistics(第三方物流) (3PL) 供应商。3PL 的工作是将成品存放在其仓库中，并在收到订单时进行拣货、打包和发货。

为了启动这一流程，我们将销量最低的产品——TinyPilot Power Connector 交给了 3PL。它面向自行组装 TinyPilot 设备的用户，我们并未在网站上宣传，每月仅售出 20 至 30 件。

Power Connector 提供了一种低风险的方式，可以在将所有订单过渡给新 3PL 之前对其进行端到端测试。这次演练暴露了几个问题，因此我很庆幸我们从小范围测试开始。

“每个人都是直接把管理员密码给我们”

第一个挑战是将 TinyPilot 的订单系统与 3PL 的系统同步。TinyPilot 使用 Shopify，这是美国最受欢迎的电商平台之一。我们的 3PL 使用 Shipstation 来管理订单。Shipstation 相当流行，我也听过不少好评，所以我以为将 Shopify 与 Shipstation 集成会很简单。

我之前的 3PL也有类似的订单管理系统。要与之集成，我只需在 Shopify 中安装一个应用并粘贴 3PL 的访问密钥即可，非常简单。

当新的 3PL 发来将 Shipstation 与我的 Shopify 账户集成的说明时，他们建议我直接提供 Shopify 的根管理员凭据，或为他们新建一个管理员账户。

这不可能对吧。

我查看了Shipstation 的文档，却找不到关联这两个账户的方法。Shipstation 假定 Shopify 账户和 Shipstation 账户由同一个人拥有，而我们的情况并非如此。

Shipstation 的设计让我们陷入了僵局。我无法关联到 3PL 的 Shipstation 账户，因为我没有他们的 Shipstation 管理员凭据。3PL 也无法关联到 TinyPilot 的 Shopify 商店，因为他们没有我的 Shopify 管理员凭据。

我不想给 3PL 在 TinyPilot 的 Shopify 上的完全管理员权限，更不想把我自己账户的凭据交出去。

相反，我创建了自己的 Shipstation 账户和一个权限受限的虚拟 Shopify 用户账户。然后，我使用这个虚拟 Shopify 用户账户，反复尝试将 TinyPilot 的 Shopify 账户与我的测试 Shipstation 账户关联。

通过反复试错，我找出了 Shopify 用户账户关联 Shipstation 账户所需的最少权限。弄清楚后，我在 TinyPilot 的 Shopify 中为 3PL 创建了一个权限最小化的账户。

如果有和我一样在使用 Shopify 和 Shipstation 时遇到同样问题的人发现了这篇文章，从 Shopify 关联 Shipstation 所需的权限如下：

• Orders
  • Edit orders
• View products
• Customers
• Manage settings
• Manage and install apps and channels

我很惊讶将 Shopify 与 3PL 的 Shipstation 账户集成的过程如此复杂。3PL 告诉我他们有几十个 Shopify 客户，所以我问他们过去是如何解决这个流程的。

“每个人都是直接把管理员密码给我们，”3PL 的经理告诉我。她解释说，他们的大多数客户不太懂技术，所以把 Shopify 凭据交给负责履约的供应商并不觉得奇怪。

我们该花 150 美元来发这笔 50 美元的订单吗？

过渡中的下一个波折出现在我们收到一笔来自澳大利亚的订单时。澳大利亚的运费是 TinyPilot 所服务的所有国家中最高的之一。在美国境内寄送一个 TinyPilot Power Connector 只需几美元，但寄到澳大利亚则要 50 美元。

3PL 报告说他们寄送这笔订单要花 150 美元，但客户只付了 50 美元。原来，TinyPilot 一直在为 DHL 的国际运输支付折扣价，因为 Shopify 代表我们谈到了更优惠的费率。3PL 没有与 DHL 的折扣价，所以他们寄到澳大利亚的邮费需要支付 150 美元。

如果 3PL 按标准邮费购买，我就要承担 100 美元的差价。这笔订单会让我比根本没有这笔订单时还倒亏 50 美元。

单笔订单亏钱倒不是什么大事，但它暴露了一个更深层的问题。TinyPilot 客户在结账时看到的运费是基于 Shopify 的运费费率。我需要让客户看到的是我的 3PL 的运费费率。

我又问了一句：“你们的其他客户是怎么做的？”

3PL 的经理说，他们的其他客户要么提供包邮，要么按国家设定与包裹大小和重量无关的固定价格。

这样估算价格并非不可行，但感觉很草率。我们总是要靠猜，而且肯定会出现向客户少收或多收很多运费的情况。TinyPilot 现有的设置允许客户根据精确的运费选择快递商，我想保留这一点。

我从 Shipstation 的文档中看到它可以与 Shopify 共享运费费率，所以这似乎是可行的。3PL 说他们以前从未这样做过，但愿意尝试。几小时后，3PL 的经理打电话告诉我，从 Shipstation 这端是可行的，但我的 Shopify 计费套餐不支持。

我查看了 Shopify 的功能页面，确认“Third-party calculated shipping rates”仅在 Shopify 的 Advanced 套餐中提供：

这将使 TinyPilot 从 Shopify 的 105 美元/月档位升级到高达 399 美元/月的套餐，使 Shopify 成为 TinyPilot 最昂贵的云服务。

我还在和 3PL 经理通电话时就想明白了这一切，有点冲动地当场就升级了。

我之前对运费费率大做文章，所以当时不好意思再退缩。不过我特意选择了按月付费，以便日后可以反悔。

回过头看，我仍然认为 Shopify Advanced 套餐是值得的。我真的不想逐个国家去估算运费，并随着市场波动不断调整。而且我还能通过更高档位套餐降低 0.2% 的信用卡手续费来挽回一些成本。按 TinyPilot 去年的收入计算，手续费折扣大约能节省约 2000 美元的信用卡费用，所以在这项每年 4800 美元的离谱套餐上，我至少能收回一部分。

TinyPilot 的需求弹性如何？

TinyPilot 当前的瓶颈是制造产能。我们仍在内部组装设备，但订单的到来速度与 TinyPilot 员工组装设备的速度大致相当。

如果要将所有产品都过渡给 3PL，仅仅跟上订单是不够的。我们需要额外生产至少一周量的 Voyager 2a 设备，运送到 3PL 的仓库。为了放缓销售，我尝试提高 TinyPilot 的价格，这产生了一些有趣的数据。

在经济学中，产品的“弹性”表示消费者对价格的敏感程度。优步打车就是一个富有弹性的产品的例子。如果车费便宜，你会为便利付费，但如果价格上涨 10 倍，你可能会改乘公共交通。

那么，TinyPilot 客户对价格有多敏感呢？

Voyager 2a USB-C

Voyager 2a PoE

反思

我的样本太小，无法得出任何有力的结论，但数据表明 TinyPilot 客户对价格的敏感度低于我的预期。对 PoE 型号的需求似乎尤其缺乏弹性，即使我将价格提高了 80 美元（17%），客户的购买频率也大致相同。

我内心的资本家想继续提价以最大化利润。内心的爱好者则想让产品对普通用户保持亲民。

我最近重读了自己关于创建首个 TinyPilot 原型的博客文章，注意到这样一段话：

接下来，我看了商用的 KVM over IP 解决方案。它们提供与戴尔 iDRAC 类似的功能，但……它们甚至更贵，每台价格在 500 到 1000 美元之间。

现在我成了昂贵的商用 KVM over IP 解决方案！

或许有些不理性，但我希望 TinyPilot 能有一款让 2020 年那个只想用简单方式管理家庭实验室、又不想花太多钱的自己也会心动的产品。

我认为在 TinyPilot 目前在供应和生产速度都受限的情况下，较高的价格是合理的，但我希望最终能再次降价，并通过销量来弥补。

以旧换新是个馊主意吗？

每当 TinyPilot 发布新的硬件版本时，客户都会问是否可以用旧设备以旧换新换取最新型号。过去，我告诉他们我们没有以旧换新的流程，但会对新版本提供慷慨的折扣。

今年，TinyPilot 的主要瓶颈是树莓派的供应。因此，我正试图从有限的树莓派供应中最大化 TinyPilot 的收益。

我没有向客户提供新设备的折扣，而是想出了一个绝妙的主意：提供以旧换新。客户将设备寄给我们，我们尽可能回收零件将其改造成 Voyager 2a，然后再寄回。每款 TinyPilot 产品都使用同一型号的树莓派，因此我们可以在不消耗新树莓派的情况下回馈忠实客户。

事实证明，以旧换新的流程比我预期的更复杂、更耗人力。

许多客户日常工作都依赖 TinyPilot，所以他们不想在没有替代品的情况下寄回设备。在这些情况下，我们先向他们出售一台由翻新零件制成的 Voyager 2a，然后在收到他们的以旧换新设备后给予部分退款。

还有一些客户拥有多台 TinyPilot 设备，需要所有设备都保持在线。因此，我们会先给他们寄一台翻新设备，他们寄回一台旧设备，我们将其改造成最新版本再寄回给他们，然后他们再寄下一台设备，如此重复，直到我们替换完他们的所有设备。有些客户有四台设备，我们就是这样逐一替换的。

所有以旧换新都顺利完成，但比我预期的工作量大得多。

很难权衡这个决定的利弊，因为好处是无形的——我们在回馈坚持支持我们、愿意支持产品的客户。而以旧换新的弊端却非常实在。以旧换新平均比正常销售多花 2 到 3 倍的时间，而且我们基本是按成本价操作的。

如果 TinyPilot 每笔标准销售的利润为 300 至 400 美元，而每笔以旧换新会占用约 2.5 笔销售的机会，那么每笔以旧换新的成本就是 750 至 1000 美元。我们总共做了 22 笔以旧换新，因此以旧换新项目的成本约为 1.9 万美元。

如果重来一次，我仍然会提供以旧换新，但会做以下调整：

• 不要广泛宣传以旧换新，而是与主动询问的客户合作。
• 为以旧换新请求使用单独的支持队列，并设定预期，即每个客户在我们开始处理其流程前可能需要等待几周。

业余项目

用 Go 重写一个 Zestful 微服务

早在 2018 年，当我推出 Zestful（我的食谱配料解析服务）时，我想为潜在客户提供一种低门槛的试用方式。其他服务要求你创建账户或输入信用卡，而我想在 Zestful 网站上提供无门槛演示：

我需要演示版将每个用户限制为每天 30 次解析。超过后，他们就必须注册付费套餐。我决定构建一个演示服务器，其 API 接口与付费服务器完全相同，只是将用户限制为每天 30 种配料。

当时，我喜欢 AppEngine，讨厌自己维护数据库。我用 Python 2.7 AppEngine 和 Google Cloud Datastore 编写了演示应用。

当请求到来时，演示服务器会在 Google Cloud Datastore 中查找用户的 IP 地址。如果该 IP 已用完配额，服务器会拒绝请求并返回错误，提示用户注册付费套餐。如果用户仍有剩余配额，服务器会将请求转发到付费的 Zestful 服务器，然后扣除与客户端 IP 地址关联的一个配额单位。

自 2018 年以来，我已经不再喜欢 AppEngine 和谷歌云。当我收到谷歌通知，称他们将在几个月内关闭 Python 2.7 的 AppEngine 时，我觉得这会是一个有趣的实验，看看今天我能以多快的速度重新实现这个服务。

我没有使用 Python，而是使用了 Go，因为我觉得 Go 的 Web 应用易于构建和维护。我开始考虑如何使用 SQLite 和 Litestream 来设计数据库，直到我意识到完全可以跳过持久化数据存储。

如果我把所有人的配额都保存在内存中，会有什么缺点呢？每当我部署新版本或重启服务器时，所有人的配额都会在当天重置，让他们在演示服务器上获得更多请求。

每次重启给每个用户额外 0.60 美元的配额并不是什么大事，尤其是我计划很少重启服务器。

我用大约六个开发小时重写了该服务。我对自己印象深刻，因为我记得原来花了两周时间。短短五年，我就实现了 10 倍的提速！

然后，我回去查看了原版 AppEngine 版本的提交历史，才意识到我实际上只用了一天就实现了它。

Mon Apr 30 00:51:48 2018 -0400  Adding badges to README (#7)
Mon Apr 30 00:51:40 2018 -0400  Adding changes to make prod API work (#6)
Mon Apr 30 00:43:55 2018 -0400  Adding support for parser config model (#5)
Sun Apr 29 23:51:03 2018 -0400  Adding deployment to Travis (#4)
Sun Apr 29 23:41:42 2018 -0400  Adding rate limiter (#3)
Sun Apr 29 18:18:37 2018 -0400  Adding coveralls.yml (#2)
Sun Apr 29 18:14:46 2018 -0400  Merge pull request #1 from mtlynch/parser-proxy
Sun Apr 29 18:11:16 2018 -0400  Fixing response handler
Sun Apr 29 17:52:28 2018 -0400  Fixing HTTP handler
Sun Apr 29 17:40:02 2018 -0400  Adding in ParserProxy and tests
Sun Apr 29 11:20:11 2018 -0400  Initial commit

诚然，从提交记录来看，那是一场从周日早上一直持续到周一凌晨 1 点的马拉松式编程，原版可能花了大约 14 个开发小时。这样算来，提速更像是 2.3 倍。

所以，我并没有比五年前快那么多，但我为自己能够发现通过跳过数据库来简化方案的新机会而感到自豪。我也很高兴自己在持续学习新技术，因此比过去拥有了更多的解决方案。

收尾

完成了什么？

• 将一款产品过渡给了 3PL 供应商。
• 在 NERD Summit 上演讲。
• 找到了新的会计师，并为 2022 年的报税做了大部分准备工作。

经验教训

• 在将关键业务过渡给新供应商之前，先进行小范围试验。
  • 如果我试图一次性将履约工作交给 3PL 供应商，那将会非常混乱。
  • 从小范围试验开始，让我们得以淘汰第一个不合适的供应商，并与第二家供应商磨合掉各种问题。

下月目标

• 将所有产品过渡给我们的 3PL 供应商。
• 选择一家代工厂来接管 TinyPilot 的设备组装，并开始过渡流程。
• 发布 TinyPilot Pro 的新版本。

求助

如果你或你认识的人曾与代工厂合作过硬件产品，我很想聊聊这方面的经验。我特别想了解以每年 2000 至 5000 台这种低产量生产电子产品的情况。