フォワーディングと物流の基盤を構築する

なぜ自社のフォワーディング基盤を作るのか

今村は横浜で6人のフォワーディングの事務所を回しています。貨物はきちんと動きます。動かないのは情報です。進捗は3つの船社のポータルにあり、書類は「RE: RE: FW:」という件名のメールの連なりの中にあり、毎日午後には同じ質問で電話が鳴ります。私のコンテナはどこですか。尋ねる権利は当然あり、自分で見る手段が無いだけの荷主から。

大手のフォワーディング製品は、それが仕える大手の値段をしています。Klivは代わりに、今村の大きさのシステムを構築します。彼女の貨物ファイル、彼女の進捗、彼女の書類の流れ、そして荷主がサインインするポータル。平易な文で記述され、自分のドメインの上でひとつのアプリとして動きます。午後の電話が止まるのは、貨物が速くなったからではありません。答えが、荷主自身が持つ画面の上にあるからです。

深圳から横浜まで、コンテナ1本

1件のFCL貨物を事務所ごしに追いかけて、誰が誰に電話しなくてよくなるかを見てください。

引き合いが見積になる

レート、サーチャージ、有効期限が見積のレコードに載ります。その日付を過ぎれば、見積は自分で失効します。先月のレートで、うっかり予約が入ることはありません。

予約確定

貨物ファイルが、コンテナ、本船、締切日とともに開きます。同じ分に、それは荷主のポータルに現れます。状態は、予約済み。

書類が集まる

顧客がパッキングリストを貨物にアップロードし、事務所が船荷証券とインボイスを添えます。ひとつの貨物、ひとつの書類一式、メールの発掘作業はゼロ。

出港 ― メールが自分を書く

進捗が切り替わり、事務所のテンプレートで到着予定を添えた通知が出ます。顧客はそれを社内に転送します。今村の机で、それを打った人はいません。

入港と通関

通関に時刻と通関の書類が付きます。どこかの段階で貨物が長く止まっていれば、明日の例外レポートがそれを言います。名指しで。

搬送完了、請求、入金

受領証がファイルに着地し、運賃の請求書が荷主の税務登録番号を印字して出て、支払いのリンクが、あなた自身のStripeアカウントの上で輪を閉じます。

どう組み上がるか

7:00の例外レポート。 定期実行のジョブが、事務所が開く前にすべての進行中の貨物を掃き、本当に手当てが要るものを机にメールします。通関で3日止まっている2件、到着予定が後ろへずれた本船が1隻、支払期日を過ぎた請求書が1通。静かな貨物は、静かなままです。

誰の貨物かを知っているエージェント。 荷主がポータルに「PO-4471はどこですか」と打つと、エージェントは自分の貨物の行から答えます。到着予定、直前の進捗、ひもづく書類。ほかの誰の行からでもありません。やり取りの記録はあなたのデータベースに残ります。役務の争いが、まさに証拠を置きたい場所です。

監査に耐える税。 請求先の、税を徴収する地域を登録すれば、運賃の請求書は請求の時点で正しく計算され、法人の取引先の税務登録番号がすべての書類に出ます。四半期末には、そのまま提出できる形のレポートが出ます。

フォワーディングの基盤は、たまたま顧客に向いている社内ツールです。平均的なものを借りるのではなく自分で作る、というより長い言い分はKlivの社内ツール向けページにあります。

机ごしに聞かれること