インドネシアのサービス予約マーケットプレイスの背後にあるインフラストラクチャ

島でのアクティビティを統一されたマーケットプレイスに変えた創業者

アルハムがインドネシアのツアー・アクティビティ提供者のためのマーケットプレイスを構築することを最初に思い描いたとき、彼は単なる観光サイト以上のものを望んでいました。彼は独立したオペレーターを結びつけるシステムを求めていました。ダイビングインストラクター、地元のガイド、ボートオペレーター、ATVの所有者、トレッキング専門家など、すべてが中央の体験を通じて予約可能なサービスを提供しています。

しかし、このモデルには多くの創業者が過小評価するようなひねりがありました。
顧客はオンラインで全額を支払うことはありませんでした。マーケットプレイスは予約手数料のみを徴収し、残りの支払いは対面で行われました。

顧客にとって、このフローは自然に感じられる必要がありました。
ベンダーには、それが非常に明確である必要がありました。
プラットフォームには、調和が必要でした。

その代わり、亀裂がすぐに現れました。
• 手数料が実際の予約料金と一致しませんでした。
• メールには時間帯やベンダーの連絡先が欠けていました。
• ベンダーは、自分たちがどの予約を履行しているのかを理解するのに苦労しました。
• Shopifyの構造はサービスを製品のように扱い、予約の文脈を消しました。

アルハムはデザインの問題を扱っていませんでした。
彼はデータアーキテクチャの問題に対処していました。

なぜサービス予約マーケットプレイスは文脈なしではうまくいかないのか

Eコマースプラットフォームは、商品、価格、数量の観点で考えます。
サービス予約マーケットプレイスは時間を基準に考えます。

適切な予約システムには以下が必要です：
• 日付
• 時間枠
• プロバイダー名
• 予約手数料
• 現金で支払うべき金額
• 顧客の連絡先情報
• サービスの場所
• セッションの_duration_

これがないと、確認が空虚に感じられ、プロバイダーは顧客が実際に何を予約したのかを推測することになります。

アールハムの初期設定では、Shopifyは午前7時のダイビングセッションと午後12時30分のダイビングセッションを同じSKUとして扱っていました。
Shopify にとって、これらは同じものでした。
現実の世界では、それらは全く異なる出来事です。

この不一致は次の理由を説明しています：
・ベンダーのメールには時間枠がありませんでした。
• 顧客の確認には重要な詳細が欠けていました。
• WhatsAppの通知が不完全に見えました
• ベンダーはしばしば顧客にタイミングを確認するために電話をかける必要がありました。

それはワークフローの問題ではありませんでした。
それは構造的なものでした。

コミッションロジックが支払いモデルと戦うとき

アルハムの意図した支払いフローはシンプルでした。
• 顧客はオンラインで予約手数料を支払います。
• 提供者は残りの支払いを現金で受け取ります
• マーケットプレイスは固定の手数料パーセンテージを得ます。
• 税金は予約手数料のみに適用されます。

しかし、ShipturtleはShopifyから直接注文を引き継ぎ、そこで満額が記録されました。これが連鎖反応を引き起こしました。

システムが誤って:
• フルサービスの価値に基づいた手数料を計算しました。
• 手数料の中に税金を含める
• 通知に誤った合計を同期しました。
• 場合によっては二重で手数料が請求されることがあります。
• Shopifyのチェックアウトと比較して不一致の値を表示しました。

マーケットプレイスは一貫性がなく、信頼しにくいと感じました。

アルハムは新しい機能を必要としていませんでした。
彼は論理の根本に修正が必要でした。

転機：予約メールがついに意味を持つようになった時

アルハムが完全な文脈を持ったテストメールを見たとき、すべてが変わった。

表示されました：
• 予約日
• 正確なスロット（例えば、午前7時）
• プロバイダー名
• 予約手数料
• 残りの残高
• 顧客の詳細

初めて、ベンダーたちは自分たちが提供しなければならないものを正確に把握していました。
顧客は繰り返しの質問をしなくなりました。
そのプラットフォームは、つながりのないワークフローが縫い合わされているようには感じられませんでした。

まるで本物の予約エンジンのようでした。

サービスマーケットプレイスの背後にあるインフラストラクチャーとしてのShipturtle

顧客はそれを見ることはないが、Shipturtleは今やArhamのプラットフォームのすべての重要なコンポーネントを支えています。

シップタートルが現在取り扱っているもの

• 予約手数料のコミッションロジックを修正する
• 正確な税フロー
• 時間帯と日付のマッピング
• ベンダーのメールとWhatsApp通知属性
• カレンダー対応データアーキテクチャ
• エンタープライズAPIアクセス
• マルチプロバイダーサービスの同期
• ベンダー向けの時間帯公開のロードマップ
• 専用のオンボーディングサポート

Shipturtleは顧客が対話するインターフェースではありません。
それは、全体のエコシステムが信頼性を持って機能することを保証する沈黙のインフラストラクチャーです。

最終変革: スケールのために構築されたマーケットプレイス

アルハムのインドネシアのサービスマーケットプレイスは現在、以下のように運営されています：
• 予約手数料をクリアする
• 正確な手数料計算
• 確認を完了する
• ベンダーの明確さと責任感
• 顧客の信頼
• 時間枠ロジックがスケーリングの準備完了
• 未来のワークフローに対するエンタープライズレベルのサポート

島のアクティビティをオンラインで提供するというシンプルなアイデアから始まったものが、構造化された予約エコシステムへと進化しました。
明確さ、清潔なロジック、そしてサービスが実際にどのように機能するかを尊重したデータ基盤に基づいたエコシステム。

アルハムは壊れたワークフローを修正しただけではありません。
彼は、インドネシア全土で何千件もの予約に対応できる、予測可能でスケーラブルなシステムを構築しました。

アルハムがベンダーの可用性を拡大し、ダイナミックな時間枠の公開やより深いサービスの自動化を進める中、次のステップはプラットフォーム全体で統合されたスケジューリングエンジンを構築することです。
デモを予約する私たちと一緒に、成長しながらも壊れないサービスマーケットプレイスを設計しましょう。