Panalk.

01 / 背景

問題

成長する配送ビジネスは、通常、スプレッドシート、チャット グループ、大量のメッセージ、ドライバーの電話を使用して実行されます。注文はある場所にあり、価格は別の場所にあり、顧客は更新を要求する必要があります。不足しているソフトウェアを構築することは第 2 のビジネスです。多くのオペレーターはそれを受け入れることができず、依然として最初のオペレーターを実行します。

Panalk は、オペレーターの背後にあるインフラストラクチャです。配送会社にはならず、オペレーターのブランドや顧客関係も引き継ぎません。オペレーターには、作業用にすでに構築されたシステムが提供されます。

02 / 対象

誰のためのものなのか

その日を運営するオペレーター、その日に情報を送信するショップ、そして最新情報を待っている顧客は、3 つの異なる質問を持つ 3 人の異なるユーザーです。オペレーターには制御が必要です。ショップには信頼できる配送ルートが必要です。顧客は荷物がどこにあるのか、そしてどのように助けを求めるのかを知る必要があります。

各企業は独自の顧客と記録を保持しています。ソフトウェアは共有されます。ビジネスの境界はありません。

03 / 制約

ビルドを形作った制約

実際のテナント境界のない物流プラットフォームでは、多忙な日にデータ侵害が待ち構えています。各画面で会社 ID で行をフィルタリングするだけでは十分ではありません。ロールが間違っている場合、顧客リンクがコピーされた場合、またはリクエストが API を通過した場合には、境界を維持する必要があります。

また、プラットフォームは 5 つの言語で動作し、顧客の資金を保持せずに支払いを記録し、人と車両の間の引き継ぎを処理し、顧客にアカウントを作成させずに役立つページを提供する必要がありました。

04 / 構築

私たちが築いたもの

ビルドは 1 画面ではなく、丸 1 日をカバーします。

• 注文、価格設定、配車、ドライバー、車両、支店、支払い、配達証明、顧客最新情報を表示するオペレーター ダッシュボード。
• 割り当てられた区間のドライバー サーフェスと引き継ぎ記録。
• 顧客ポータルと署名された配信リンクにより、受信者はジャーニーをたどって助けを求めることができます。
• プラン、請求、サポート、役割、権限、ショップやその他のシステムの API。
• 5 つの言語と、インターフェイスだけでなくデータベース境界にも適用されるテナント モデル。

05 / 判断

難しい部分

面白い作品はほとんど見られなかった。 ID とテナントの分離は一致する必要がありました。顧客リンクは、それ自体の配信のみを明らかにする必要がありました。支払いイベントは、Panalk がウォレットであるかのように装うことなく記録する必要がありました。失敗したハンドオーバーには、一般的なエラーではなく、有用な状態が必要でした。

2026 年 10 月 27 日からのテスト数は証拠の一部です: 676 件の API テストと 280 件のアイデンティティ テスト。この数字が役立つのは、テスト数が製品の機能であるためではなく、労力がどこに費やされたかを示すためです。

06 / 結果

ライブとは

Panalk は panalk.xyz でライブ中です。公開されている製品説明は、システムに対するオペレータの見解です。その背後にある作業は、毎日同意する必要がある少数の可動部分を備えたプラットフォームです。