一句话总结

向第三方履约的缓慢过渡

亮点

• 我已启动将 TinyPilot 的履约环节转交给第三方服务商的流程。
• TinyPilot 的客户对价格的敏感度比我预期的要低。
• 我在 TinyPilot 的以旧换新项目上投入了大量资源，但不确定是否值得。

目标评分

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

将一款低销量产品的履约转交给新的第三方物流（3PL）服务商

• 结果：我们的 3PL 服务商已承担 Power Connector 订单的履约工作三周。
• 评分：A

过程中有一些细节需要打磨，但我们成功完成了首款产品的切换。

在 NERD Summit 2023 上演讲

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

这是自 2019 年以来首次线下回归 NERD Summit，感觉很棒。现场有很多精彩的演讲，茶歇时的交流也很有趣。

减轻履约团队的负担，使被动响应类工作占用时间低于 80%

• 结果：基本达成，但难以精确衡量。
• 评分：B

为了向 3PL 过渡，我们需要让本地团队腾出足够的时间，以便能额外生产出一周用量的设备。为此我们采取了多项减负措施，不过团队的工作时长也比平时有所增加。

TinyPilot 数据一览

将 TinyPilot 的外壳从塑料换成金属后，需求大幅增长。即便我提高了售价、几乎停掉了所有营销，销量仍在持续攀升。

我今年的目标是实现 10 万美元利润，但目前已经完成了 75%。照这个势头，在 4 月底之前就能达成全年的利润目标。

向 3PL 服务商过渡时遇到的小插曲

我当前的首要任务是将 TinyPilot 的履约工作转交给第三方物流（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 账户，因为我没有他们的管理员凭证；3PL 也无法关联到 TinyPilot 的 Shopify 店铺，因为他们没有我的 Shopify 管理员凭证。

我不想给 3PL 开放 TinyPilot Shopify 的完全管理权限，更不想把自己账户的密码交出去。

于是，我自己注册了一个 ShipStation 账户，并创建了一个权限受限的虚拟 Shopify 用户。然后，我反复尝试用这个虚拟账户将 TinyPilot 的 Shopify 账户与我测试用的 ShipStation 账户关联起来。

经过反复试错，我找出了关联 ShipStation 账户所需的最小 Shopify 权限集合。弄清楚后，我便在 TinyPilot 的 Shopify 中为 3PL 创建了一个仅具备必要权限的受限账户。

如果有同样在使用 Shopify 和 ShipStation 并遇到此问题的人看到这篇文章，从 Shopify 关联 ShipStation 所需的权限如下：

• 订单
  • 编辑订单
• 查看商品
• 客户
• 管理设置
• 管理和安装应用与渠道

我很惊讶 Shopify 与 3PL 的 ShipStation 账户对接会如此复杂。3PL 告诉我他们有几十个使用 Shopify 的客户，于是我问他们过去是怎么解决这个问题的。

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

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

过渡中的下一个波折来自一笔澳大利亚订单。澳大利亚是 TinyPilot 配送国家中运费最高的国家之一。在美国境内寄送一个 TinyPilot Power Connector 只需几美元，而寄到澳大利亚则要 50 美元。

3PL 告知，发这笔订单他们要花费 150 美元，而客户只支付了 50 美元运费。原来，TinyPilot 一直通过 Shopify 享受着 DHL 国际运费的折扣价，因为 Shopify 帮我们谈下了更优惠的费率。而 3PL 并没有与 DHL 达成折扣协议，所以他们寄往澳大利亚需要支付 150 美元的全价邮费。

如果由 3PL 按标准邮费寄出，我就得承担这 100 美元的差价。这笔订单会让我比没接到这笔订单还要多亏 50 美元。

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

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

3PL 经理说，他们的其他客户要么提供包邮，要么按国家设定统一的固定运费，而不考虑包裹的大小和重量。

像那样估算价格倒也不是不行，但总觉得不够严谨。我们永远是在猜测，难免会出现对客户运费少收或多收很多的情况。TinyPilot 现有的设置能让客户根据精确的运费选择物流商，我想保留这一点。

我从 ShipStation 的文档中看到它可以与 Shopify 共享运费费率，所以这件事似乎是可行的。3PL 说他们以前从未这样做过，但愿意一起研究。几个小时后，3PL 的经理打电话告诉我，从 ShipStation 这端是可行的，但我的 Shopify 套餐等级不支持该功能。

我查看了 Shopify 的功能介绍页，确认“第三方计算运费”仅在 Shopify 的 Advanced 套餐中提供：

这意味着 TinyPilot 要从每月 105 美元的套餐升级到高达每月 399 美元的套餐，这将使 Shopify 成为 TinyPilot 最昂贵的云服务。

当时我还和 3PL 经理通着电话，想清楚后便有些冲动地当场完成了升级。

我之前对运费问题大费周章，这时也不好意思再退缩。不过我特意选择了按月付费，以便日后可以反悔。

回过头看，我仍然认为 Shopify Advanced 套餐是值得的。我实在不想逐个国家去估算运费，并随着市场波动不断调整。而且，高阶套餐还能将信用卡手续费降低 0.2%。按 TinyPilot 去年的营收计算，手续费优惠大约能省下 2000 美元，多少能抵消一部分每年 4800 美元的套餐费用——虽然这个价格依然贵得离谱。

TinyPilot 的需求弹性如何？

TinyPilot 当前的瓶颈是产能。我们仍在内部组装设备，而订单的涌入速度几乎与团队的生产速度相当。

如果要将所有产品都转给 3PL，光是跟上订单还不够。我们至少需要为 3PL 的仓库备出一周用量的 Voyager 2a 库存。为了减缓销售速度，我尝试提高 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 以及整个 Google Cloud 感到失望。当收到 Google 通知说将在几个月后下线 Python 2.7 的 AppEngine 时，我觉得这会是个有趣的实验，看看如今的自己能以多快的速度重新实现这个服务。

我没有再用 Python，而是选择了 Go，因为我觉得用 Go 构建和维护 Web 应用更轻松。我本来还在考虑如何用 SQLite 和 Litestream 来设计数据库，直到意识到其实可以完全省掉持久化存储。

如果把所有人的配额都放在内存里，会有什么弊端呢？每当我部署新版本或重启服务器，所有人的当日配额都会重置，让他们在演示服务器上获得额外的请求次数。

每次重启给每个用户多赠送价值 0.60 美元的额外配额，其实无关紧要，尤其是我本来就打算很少重启服务器。

我用大约 6 个开发小时就重写了这个服务。我对自己还挺满意，因为记得当初花了两周时间。短短五年，我的速度就提升了 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 台这种小批量生产电子产品的经历。