準確的訂票費用和結構化的時間段邏輯使阿爾哈姆的平臺轉變為一個可預測的服務生態系統。
透過 Shipturtle 的訂票架構，市場現在已準備好在印尼提供數千個供應商管理的時段。
印尼服務預訂市場背後的基礎設施
簡而言之（太長了；沒時間看）
• 創辦人 Arham 經營一個印尼的多供應商服務市場，客戶在線支付預訂費用，其餘金額則以現金支付給當地供應商。
• 佣金計算出現問題，因為平台將訂房費用視為完整產品價格。
• 供應商電子郵件、客戶確認、時間槽和預訂日期缺少關鍵數據
• Shipturtle 修正了佣金邏輯，重新調整了稅務規則，並為電子郵件和 WhatsApp 送貨結構化了預訂屬性。
• 團隊要求一個面向供應商的界面，以發布可用時間槽，並提供企業 API 接口以支持更深入的工作流程。
一位將島嶼活動轉變為統一市場的創始人
當阿爾哈姆首次構想為印尼的旅遊和活動提供者建立一個市場時，他想要的不僅僅是一個旅遊網站。他希望建立一個系統，可以將獨立運營商聚集在一起。潛水教練、當地導遊、船隻操作員、ATV 擁有者、徒步專家，所有人都可以通過一個中央體驗提供可預訂的服務。
但這個模型有一個許多創辦人低估的變化。
客戶不會在線上支付全額。這個市場僅收取了訂金，剩餘的付款則是在當面進行的。
對於客戶來說，這個流程需要感覺自然。
對於供應商來說，這必須非常明確。
對於這個平台，它需要是和諧的。
相反地，裂縫很快就出現了。
• 佣金與實際的預訂費用不符
• 電子郵件缺少時間段和供應商聯絡資訊
• 供應商們在理解他們正在履行的預訂方面感到困難
• Shopify的結構將服務視為產品，並消除了預訂的背景。
Arham 並不是在處理設計問題。
他正在處理一個數據架構問題。
為什麼服務預訂市場會在缺乏上下文的情況下崩潰
電子商務平台以產品、價格和數量為考量。
服務預訂市場是以時間為考量的。
一個合適的訂票系統必須包含：
• 日期
• 時段
• 供應商名稱
• 訂票費用
• 應支付的現金金額
• 客戶的聯絡資訊
• 服務地點
• 會話持續時間
沒有這個，確認會顯得空洞，供應商只能猜測客戶實際預訂了什麼。
在 Arham 的早期設置中，Shopify 將早上 7 點的潛水課程和中午 12:30 的潛水課程視為相同的 SKU。
對於 Shopify 來說，這些是相同的。
對於現實世界而言，它們是完全不同的事件。
這個不匹配解釋了為什麼：
• 供應商的電子郵件中沒有時間區間
• 客戶確認缺乏必要的細節
• WhatsApp 通知看起來不完整
• 賣方經常需要致電客戶以確認時間安排。
這不是工作流程的問題。
這是一個結構性的問題。
當佣金邏輯與支付模型對峙時
Arham的預期付款流程很簡單。
• 客戶在線支付訂金
• 提供者以現金收取剩餘款項
• 市場賺取固定的佣金百分比
• 稅金僅適用於訂房費用
但 Shipturtle 直接從 Shopify 繼承了訂單，並記錄了全額價格。這引發了一連串的反應。
系統錯誤地：
• 根據完整服務價值計算佣金
• 佣金內已包含稅金
• 同步了錯誤的總數到通知中
• 在某些情況下，佣金重複收取
• 顯示與 Shopify 結帳不相符的值
市場感覺不穩定且難以信任。
Arham 不需要新功能。
他需要在邏輯的根本上進行修正。
重建基礎：合理的訂票費用
Shipturtle 將一切重構以符合實際的商業模式。
佣金邏輯重新調整
• 佣金只適用於訂房費用
• 全部服務價格不包含在付款中
• 稅款正確計算
• Shopify 總計和 Shipturtle 總計現在匹配
• 不再有奇怪的錯誤匹配或重複扣款
可訪問的預訂屬性
• 時間時段現在被存儲為預訂屬性
• 預訂日期已清楚地傳遞到電子郵件模板中
• 廠商儀表板顯示完整的預訂上下文
• 客戶確認最終感覺完整
供應商通知重建完成
如果 Shopify Flow 錯過一個觸發，Shipturtle 為以下內容準備備用資料：
• 供應商名稱
• 供應商電話
• 預訂時間
• 預訂日期
• 客戶資訊
• 預訂費用和應付現金
該系統現在使用現實世界服務交付的語言，而不是SKU邏輯。
缺失的連結：供應商時間格發佈
在對話中，一個主要的需求浮現出來。
供應商需要一種方式來發布可用性。
一個簡單的日曆式界面，讓他們可以設置：
• 日期
• 時段
• 容量
• 星期幾模式
• 持續時間規則
• 封鎖的日期
沒有這個，Arham 必須手動配置可用性或依賴靜態庫存。
他問 Shipturtle 是否能創建類似於全球服務平台的東西。一個供應商可以登錄、打開日曆，並精確控制他們何時可以接受預訂的面板。
這成為了可擴展性方面最大的路線圖項目。
一個市場無法在靜態可用性下擴展。
它需要動態的、供應商驅動的時間區段。
轉捩點：當預訂郵件終於承載意義時
當阿爾哈姆看到一封包含完整上下文的測試電子郵件時，一切都發生了變化。
它顯示了：
• 預訂日期
• 精確的時段（例如，早上7:00）
• 提供者名稱
• 訂金
• 剩餘餘額
• 客戶詳細資訊
第一次，供應商們確切知道他們需要交付什麼。
客戶不再重複問相同的問題了。
這個平台並不感覺像是將不相連的工作流程拼湊在一起。
它感覺就像一個真正的訂房引擎。
Shipturtle 作為服務市場背後的基礎設施
即使客戶從未見過它，Shipturtle 現在驅動著 Arham 平台的每一個重要組件。
Shipturtle 現在處理的事項
• 修正訂票費用佣金邏輯
• 準確的稅務流動
• 時段與日期對應
• 供應商電子郵件和WhatsApp通知屬性
• 日曆準備好的數據架構
• 企業 API 存取
• 多提供者服務同步
• 面向供應商的時間槽發布路線圖
• 專屬的上線支援
Shipturtle 不是客戶互動的介面。
它是確保整個生態系統可靠運作的無聲基礎設施。
84%
在東南亞，未成功的服務預約中，有{{count}}%是因為確認中缺少時間段或提供者的詳細信息。
最終轉型：一個為擴展而設的市場
Arham 的印尼服務市場現在運作如下：
• 清除訂票費用
• 精確的佣金計算
• 完成確認
• 供應商的清晰度和責任感
• 客戶信任
• 時間區塊邏輯準備擴展
• 針對未來工作流程的企業級支持
最初是一個將島嶼活動線上化的簡單想法，已經演變成一個有組織的訂票生態系統。
一個建立在清晰、簡潔邏輯和尊重服務實際運作方式的數據基礎上的生態系統。
Arham 不只是修復了一個破損的工作流程。
他創建了一個可預測且可擴展的系統，準備好處理印尼成千上萬的訂單。
隨著 Arham 準備擴大供應商的可用性、動態時間槽發布和更深層次的服務自動化，下一步是建立一個跨平台的統一排程引擎。
預約演示今天與我們一起構建一個不會崩潰的服務市場。
常見問題解答（FAQ）
- 為什麼服務預訂市場需要結構化的預訂屬性？
因為日期、時間區間、供應商詳細資訊和預訂費用必須一致地被捕捉和傳遞，以便用於確認、支付和通知。 - 乾淨的訂房費用邏輯如何改善支付？
這確保佣金僅適用於訂單費用，防止 Shopify 與市場後端之間的收費膨脹或總額不匹配。 - 為什麼供應商通知最初缺少時間槽？
Shopify 將服務視為產品，並未儲存預訂上下文，導致電子郵件和 WhatsApp 訊息錯過了關鍵的服務屬性。 - 供應商現在可以在他們的儀表板中查看完整的預訂詳細信息嗎？
是的。供應商會收到預訂日期、時間段、聯繫信息和費用明細，以便他們確切知道應提供什麼服務。 - 如果 Shopify Flow 無法觸發通知，可能會發生以下幾種情況：
1. **無法執行動作**：相關的自動化任務可能不會被執行，例如發送電子郵件或訊息。
2. **錯誤與異常**：系統可能會記錄錯誤，但不會通知用戶，這可能導致在某些情況下未能執行必要的操作。
3. **影響業務流程**：如果某些重要的通知未被發送，可能會影響業務運作與客戶關係。
為了解決這個問題，建議定期檢查流程、設定備用通知方式，並監控任何可能的錯誤記錄。
Shipturtle 準備了備選屬性，以確保供應商和客戶的電子郵件始終包含必要的預訂詳細信息。 - 為什麼供應商驅動的時段發布對於擴展非常重要？
市場無法在靜態可用性下成長。供應商必須能夠發布和管理自己的動態時間槽，以防止排程衝突。 - 這個系統是否支持帶有完整預訂內容的 WhatsApp 通知？
是的。時間、日期、供應商和費用屬性現在已經清楚地傳遞到 WhatsApp 模板中，以便提供明確且可行的更新。 - 企業 API 的訪問如何幫助這個市場？
它實現了更深入的工作流程自動化、先進的排程和定制化集成，這對於高容量服務生態系統是至關重要的。
關於作者
Kali
Working at Shipturtle shows how easily complex ideas can be turned into simple and engaging visuals. It reflects an ability to understand how digital products function and explain them in a way that anyone can grasp without feeling overwhelmed.
This experience also highlights strong problem-solving and clarity in thinking. It shows a talent for taking complicated concepts, breaking them down, and presenting them through clean visuals and clear writing. This makes information easier for people to understand, whether they’re new to tech or already familiar with it.