一句話總結

緩慢過渡到第三方物流

重點回顧

• 我已開始將 TinyPilot 的出貨作業轉移至第三方廠商。
• TinyPilot 顧客對價格的敏感度比我預期的還要低。
• 我投入了大量資源在 TinyPilot 的舊換新方案上，但不確定是否真的有回報。

目標評分

每個月月初，我都會訂下當月想完成的目標。以下是我的達成狀況：

將低銷量產品的出貨轉移至新的第三方物流（3PL）

• 結果：我們的第三方物流廠商已經承接 Power Connector 的出貨三週了。
• 評分：A

雖然還有一些細節需要磨合，但我們已成功轉移了第一項產品。

在 NERD Summit 2023 發表演說

• 結果：我完成了演講，自認表現不錯。
• 評分：A

自 2019 年以來首次實體重返 NERD Summit，感覺很棒。現場有許多精彩的演講，也有許多愉快的走廊閒聊。

減輕出貨團隊負擔，讓被動性工作佔比降至 80% 以下

• 結果：大致上成功，但難以精確衡量。
• 評分：B

為了轉移至第三方物流，我們需要讓在地團隊的工作量降到足以多生產一週份量的裝置。我們採取了幾項措施來減輕他們的負擔，不過他們實際工時還是比平常多。

TinyPilot 數據統計

將 TinyPilot 的外殼從塑膠改為金屬後，需求大幅增加。即使我調漲價格、幾乎把行銷降到零，銷量仍持續攀升。

我今年的目標是達到 10 萬美元的利潤，但我們已經完成了 75%。照這個速度，我們在四月底前就會達成全年 10 萬美元利潤的目標。

轉移至第三方物流廠商時的波折

我目前的首要任務是將 TinyPilot 的出貨作業轉移至第三方物流（3PL）廠商。3PL 的工作就是在倉庫中存放成品，並在收到訂單時負責揀貨、包裝與出貨。

為了啟動這個流程，我們先把銷量最低的產品交給 3PL，也就是 TinyPilot Power Connector。這是給自行組裝 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 使用者帳號。然後，我反覆嘗試用這個假帳號去連結 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 之所以能享有 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 去年的營收來算，手續費折扣大約能省下 2,000 美元，所以至少能補回一部分我每年花在這個貴得離譜的方案上的 4,800 美元。

TinyPilot 的需求彈性有多大？

TinyPilot 目前的瓶頸是製造產能。我們仍在內部組裝裝置，但訂單進來的速度，幾乎跟 TinyPilot 員工組裝的速度一樣快。

如果要把所有產品都轉移至 3PL，光是跟上訂單還不夠。我們需要多生產至少一週份量的 Voyager 2a 裝置，作為庫存送到 3PL 的倉庫。為了減緩銷售速度，我試著調漲了 TinyPilot 的價格，也因此得到了一些有趣的數據。

在經濟學中，產品的「彈性」代表消費者對價格的敏感度。Uber 搭車就是一個彈性很高的例子。如果車資便宜，你會為了方便而付錢，但如果價格漲了 10 倍，你大概就會改搭大眾運輸了。

那麼，TinyPilot 的顧客對價格有多敏感呢？

Voyager 2a USB-C

Voyager 2a PoE

反思

我的樣本數太小，還不足以做出強烈的結論，但數據顯示 TinyPilot 的顧客對價格的敏感度比我預期的還要低。PoE 機型的需求彈性似乎尤其低，即使我把價格調漲了 80 美元（17%），顧客的購買速度也大致維持不變。

我內心的資本家想繼續漲價以極大化利潤；我內心愛好者的那一面，則希望產品能讓一般使用者也負擔得起。

我最近重讀了當初撰寫關於打造第一個 TinyPilot 原型的部落格文章，注意到這一段：

接著，我看了市面上的商用 KVM over IP 解決方案。它們提供的功能類似 Dell 的 iDRAC，但……價格甚至更貴，每台要價 500 到 1000 美元。

現在，換我成了那個昂貴的商用 KVM over IP 解決方案了！

或許有點不理性，但我還是希望能提供一款讓 2020 年那個只想用簡單方式管理家用伺服器、又不想花大錢的自己也會想買的 TinyPilot 產品。

我認為在 TinyPilot 目前同時受限於供應和生產速度的情況下，較高的價格是合理的，但我希望未來能再次調降價格，並靠銷量來補回來。

舊換新是個蠢主意嗎？

每當 TinyPilot 推出新版硬體，顧客就會問能不能用舊裝置折抵換購最新機型。過去，我總是告訴他們我們沒有舊換新的流程，但可以提供新機型的優惠折扣。

今年，TinyPilot 最主要的瓶頸是 Raspberry Pi 的供應。因為這個原因，我想盡可能從有限的 Pi 供應中創造最大收益。

與其給顧客新機折扣，我靈機一動想到了舊換新方案。顧客把裝置寄回給我們，我們盡可能回收零件，將其改造成 Voyager 2a 後再寄回去。由於 TinyPilot 的每款產品都使用同一型號的 Raspberry Pi，這樣既能回饋忠實顧客，又不會消耗新的 Pi。

結果，舊換新的流程比我想像的還要複雜、耗工。

許多顧客日常工作都仰賴 TinyPilot，所以他們不想在還沒拿到替代品前就把裝置寄回。在這種情況下，我們會先賣給他們一台由整新零件組成的 Voyager 2a，等收到他們寄回的舊機後再部分退款。

還有一些顧客擁有多台 TinyPilot 裝置，而且每一台都必須保持上線。所以，我們會先寄一台整新機給他們，他們再寄回一台舊機，我們把那台改造成最新版本後寄回去，然後他們再寄下一台，就這樣重複，直到把他們所有的裝置都換完。有些顧客就這樣換了四台。

所有的舊換新都順利完成了，但比我預期的要費工得多。

很難衡量這個決定的利弊得失，因為好處是無形的——我們回饋了願意支持產品的忠實顧客。但舊換新的缺點卻非常具體：平均來說，處理一筆舊換新花的時間是一般銷售的 2 到 3 倍，而且我們幾乎是以成本價在做。

如果 TinyPilot 每筆一般銷售可獲利 300 到 400 美元，而每筆舊換新讓我們少做了約 2.5 筆銷售，那麼每筆舊換新就讓我們損失 750 到 1,000 美元。我們總共做了 22 筆舊換新，所以舊換新方案大約花了 19,000 美元的成本。

如果重來一次，我還是會提供舊換新，但會做這些調整：

• 不要大肆宣傳舊換新，但對於主動詢問的顧客仍提供協助。
• 為舊換新需求設立獨立的客服佇列，並先說明可能需要等候數週才會開始處理。

副業專案

用 Go 重寫 Zestful 微服務

早在 2018 年，當我推出 Zestful——我的食譜食材解析服務時，我想讓潛在客戶能用最低的門檻試用服務。其他服務都需要你建立帳號或輸入信用卡號，但我想在 Zestful 網站上提供一個無需任何手續的試用：

我需要讓試用版限制每位使用者每天只能解析 30 筆食材。超過之後，他們就必須訂閱付費方案。我決定打造一個試用伺服器，它的 API 介面與付費伺服器完全相同，差別只在於它會限制每人每天 30 筆食材的額度。

當時，我很喜歡 App Engine，也很討厭自己維護資料庫。我用 Python 2.7 的 App Engine 和 Google Cloud Datastore 寫了這個試用應用程式。

當有請求進來時，試用伺服器會在 Google Cloud Datastore 中查詢使用者的 IP 位址。如果該 IP 已經用完額度，伺服器就會拒絕請求，並回傳錯誤訊息請使用者訂閱付費方案。如果使用者還有額度，伺服器就會把請求轉發給付費的 Zestful 伺服器，然後扣除該 IP 一次額度。

自 2018 年以來，我已經不再那麼喜歡 App Engine 和 Google Cloud 了。當我收到 Google 通知說他們將在幾個月後關閉 Python 2.7 的 App Engine 時，我覺得這會是個有趣的實驗，看看現在的我能以多快的速度重做這個服務。

我沒用 Python，而是改用 Go，因為我覺得 Go 的網頁應用程式容易建構也好維護。我本來在思考要用 SQLite 和 Litestream 來設計資料庫，直到我意識到其實可以完全跳過持久化儲存。

如果我把所有人的額度都放在記憶體裡，會有什麼缺點呢？每當我部署新版本或重啟伺服器時，所有人的當日額度都會重置，讓他們能在試用伺服器上多獲得一些請求額度。

每次重啟就多給每位使用者價值 0.60 美元的額度，其實沒什麼大不了的，尤其是我本來就打算不常重啟伺服器。

我花了大約六個小時的開發時間重做了這個服務。我對自己感到很得意，因為我記得原版花了兩個禮拜。短短五年內，我的速度就提升了 10 倍！

接著，我回去查看了原版 App Engine 版本的提交紀錄，才發現其實當初只花了一天就做完了。

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 倍。

所以，我並沒有比五年前快上那麼多，但我很欣慰自己能發現跳過資料庫來簡化架構的新機會。我也很高興自己持續學習新技術，讓現在的我比過去擁有更多可用的解決方案。

總結

已完成事項

• 將一項產品轉移至第三方物流廠商。
• 在 NERD Summit 發表演說。
• 找到新的會計師，並完成了 2022 年報稅的大部分準備工作。

經驗教訓

• 在將關鍵業務轉交給新廠商之前，先進行小規模試驗。
  • 如果我當初試圖一次就把出貨作業全部交給第三方物流廠商，過程一定會非常混亂。
  • 從小規模試驗開始，讓我們得以淘汰不合適的第一家廠商，並與第二家廠商磨合掉許多細節問題。

下個月目標

• 將所有產品轉移至第三方物流廠商。
• 選定一家委外製造商來接手 TinyPilot 的裝置組裝，並開始轉移流程。
• 發布新版的 TinyPilot Pro。

徵求協助

如果你或你認識的人曾與委外製造商合作過硬體產品，我很想聊聊相關經驗。我特別想了解曾以 2,000 至 5,000 台／年的低產量規模，製作電子產品的經驗。