When the consultant hands off to the forwarder, nothing should change for the SME

Most cross-border SME deals don’t fail at the contract. They fail at the handoff.

A consultancy lands the introduction. The SME signs a memorandum with a Vietnamese supplier. Everyone shakes hands. Then the deal moves to “execution” — and execution means a forwarder the SME has never met, in a workflow the consultant can no longer see, with documents the bank doesn’t have a copy of. Three weeks later, the supplier is asking why payment hasn’t moved, the consultant is asking why the SME stopped responding, and the SME is asking why nobody told them about the ¥120,000 demurrage charge.

This isn’t a logistics problem. It’s an information-architecture problem. And it’s the specific gap Forwarding PRO and Trade Cloud were built to close.

The handoff, traditionally

Here’s the chain that exists today, in nearly every consultancy-led SME deal:

1. Consultant uses CRM #1 to track the lead and the supplier introduction.
2. SME’s accounting team uses ERP #1 to set up the supplier as a vendor.
3. SME or consultant emails a forwarder for a quote. Forwarder uses CRM #2.
4. Quote comes back as a PDF attached to a reply email.
5. SME approves over email. Forwarder books the shipment in System #3.
6. Forwarder updates the SME on container status by email. (Consultant is CC’d “for visibility”.)
7. Bank or Standage handles payment in System #4. Forwarder doesn’t have access.
8. Documents arrive at customs. Customs broker uses System #5.

Eight systems. Three companies. One SME who has never seen most of them. Nobody can answer “where is this deal right now” without checking three inboxes.

The handoff, on Trade Cloud + Forwarding PRO

The replacement isn’t “one system” — that’s the wrong frame. It’s one shared project record, with role-scoped views into the same underlying data.

Concretely, for the same deal:

• Consultant opens a project on Trade Cloud for the SME’s Vietnam expansion. The project is the unit of work — supplier intro, KYC, commercial terms, milestones.
• The SME is invited into the project as the client. They see everything the consultant has shared, plus their own private notes.
• The forwarder quote request becomes a Forwarding PRO action on the same project record. Not a separate email thread. The supplier’s address, the agreed Incoterm, the cargo description — already populated from the project. The forwarder sees the request in their Forwarding PRO inbox and quotes back in the same record.
• Quote approval is a single click in the project. Consultant and SME both see the chosen rate, the chosen carrier, the chosen route. The forwarder gets booking confirmation. The SME’s accounting team gets a line item with no manual data entry.
• Container milestones publish back to the project automatically. Vessel ETD, ETA, customs cleared — each milestone visible to all three parties in real time.
• Payment release is conditional on those milestones. When the forwarder publishes “vessel departed”, Digital Safe releases the second installment to the supplier. The consultant doesn’t need to chase. The SME doesn’t need to remember.

What changes for each party

For the consultant. You stop being the email switchboard between SME, supplier, forwarder, and bank. You see the full project state on one screen, and your billing is tied to deliverables that are actually verifiable — not “we made the introduction, then it disappeared into someone else’s CRM”.

For the forwarder. Quote requests arrive with the upstream context already attached — you’re not asking the SME for the fifth time what Incoterm they agreed. Booking happens against a record you can see end-to-end, so demurrage surprises don’t catch the SME off guard.

For the SME. One workspace. One point of truth. Your accounting books a JPY line item that matches the project. Your customs broker waits — Standage handles the import declaration on the payment leg. You never have to forward an email to find out where your container is.

For the bank backing the consultancy. Project-level visibility into the cross-border pipeline it has historically had no way to see. The same record that proves the consultant added value also proves the SME used the bank’s credit line as intended.

Why we built it as two products, not one

Forwarding PRO and Trade Cloud are separate products by design. A forwarder doesn’t need a CRM for consulting projects. A consultancy doesn’t need a multi-leg rate management engine. Each side gets a tool optimized for its actual job — and the shared project record is the bridge between them, not the product itself.

This matters because most “integrated platforms” fail by trying to be everything. They become a worse CRM than the dedicated CRM, a worse rate engine than the dedicated rate engine, and the customer keeps the dedicated tools and ignores the platform. We’re building the opposite: best-in-class tools for each role, with shared data underneath.

Where the line is

We’re explicit about what stays outside this shared record. The SME’s commercial negotiation with the supplier is not on Trade Cloud — that’s a relationship the SME owns. The forwarder’s internal cost structure isn’t on Forwarding PRO either — that’s the forwarder’s margin. What’s shared is the operational state of the deal in flight: who is doing what, when, and what’s blocked.

That’s the unit of work that today falls through the cracks. That’s what we put on one screen.

If you run a consultancy moving Japanese SMEs cross-border, or a forwarder asked to quote on consultant-routed business, a 30-minute walkthrough will show you exactly what this looks like on a real project.

Related reading

• Trade Cloud — the project-operations layer for consultants and banks.
• Forwarding PRO — the quote and rate-management layer for forwarders and shippers.
• How a regional bank starts cross-border without launching a new product — the consortium logic above the handoff.

---

コンサルがフォワーダーに引き継ぐ瞬間、SMEには何も変わらない

SMEの越境取引の多くは、契約で失敗するのではありません。引き継ぎで失敗します。

コンサル会社が紹介を取り付ける。SMEがベトナムのサプライヤーと覚書を結ぶ。握手する。そして案件は「実行」フェーズに入る — 実行とは、SMEが会ったこともないフォワーダー、コンサルがもう見られないワークフロー、銀行がコピーを持っていない書類、を意味する。3週間後、サプライヤーは「なぜ送金が動いていない？」と聞き、コンサルは「なぜSMEから返事が来ない？」と聞き、SMEは「なぜ12万円のデマレージが発生したと誰も教えてくれなかった？」と聞いている。

これは物流の問題ではありません。情報アーキテクチャの問題です。そしてForwarding PROとTrade Cloudが埋めるために作られた、まさにそのギャップです。

従来の引き継ぎ

今日、ほぼすべてのコンサル主導のSME案件に存在するチェーン：

1. コンサルはCRM #1でリードとサプライヤー紹介を追跡。
2. SMEの経理チームはERP #1でサプライヤーを仕入先として登録。
3. SMEまたはコンサルがフォワーダーに見積をメール。フォワーダーはCRM #2を使用。
4. 見積が返信メールにPDF添付で戻ってくる。
5. SMEがメールで承認。フォワーダーがシステム#3で出荷予約。
6. フォワーダーがコンテナ状況をメールで更新（コンサルは”参考まで”でCC）。
7. 銀行またはSTANDAGEがシステム#4で決済処理。フォワーダーはアクセス権なし。
8. 書類が通関に到着。通関業者はシステム#5を使用。

8つのシステム。3つの会社。そのほとんどを見たことがないSMEが1社。「この案件は今どこ？」と聞かれて、3つの受信箱を確認しない限り誰も答えられない。

Trade Cloud + Forwarding PRO 上の引き継ぎ

置き換えは「1つのシステム」ではありません — それは間違ったフレーミング。1つの共有プロジェクトレコード、同じ基礎データへの役割別のビュー。

同じ案件で、具体的に：

• コンサルがTrade Cloudでプロジェクトを開設。SMEのベトナム展開がプロジェクト単位 — サプライヤー紹介、KYC、商業条件、マイルストーン。
• SMEがクライアントとしてプロジェクトに招待される。コンサルが共有したものすべて、加えて自社のプライベートメモを見られる。
• フォワーダー見積依頼は、同じプロジェクトレコード上のForwarding PROアクションとして発生。別のメールスレッドではない。サプライヤー住所、合意済みInco条件、貨物内容 — すべてプロジェクトから自動入力済み。フォワーダーは自社のForwarding PRO受信箱で依頼を見て、同じレコード上で見積を返す。
• 見積承認はプロジェクト内のワンクリック。コンサルもSMEも、選ばれた運賃、キャリア、ルートを見られる。フォワーダーはブッキング確定通知を受け取る。SMEの経理は手入力なしで明細を取得。
• コンテナマイルストーンが自動でプロジェクトに反映。ETD、ETA、通関完了 — 各マイルストーンが3者全員にリアルタイムで可視。
• 決済リリースがこれらのマイルストーンに連動。フォワーダーが「本船出港」を公開すると、Digital Safeがサプライヤーへの第2分割金をリリース。コンサルが催促する必要なし。SMEが覚えておく必要なし。

各プレイヤーにとって何が変わるか

コンサルにとって。SME、サプライヤー、フォワーダー、銀行の間のメール交換台でなくなる。1画面で案件状態を全部見られて、課金は実際に検証可能なデリバラブルに紐付く — 「紹介はしました、その後は誰かのCRMに消えました」ではなくなる。

フォワーダーにとって。見積依頼が上流コンテキスト付きで到着 — SMEに「Incoは何でしたっけ」と5回聞かなくていい。エンドツーエンドで見えるレコードに対してブッキングするので、デマレージのサプライズでSMEを困らせない。

SMEにとって。1つのワークスペース。1つの真実の起点。経理はプロジェクトと一致する円明細を計上。通関業者は待機 — 決済レグの輸入申告はSTANDAGEが処理。コンテナがどこにあるか調べるためにメールを転送する必要がない。

コンサル会社を支える銀行にとって。これまで見る術がなかった越境パイプラインを、プロジェクトレベルで可視化。コンサルの付加価値を証明する同じレコードが、SMEが銀行の与信を意図通り使ったことも証明する。

なぜ2つのプロダクトなのか、1つではなく

Forwarding PROとTrade Cloudは、意図的に別プロダクトです。フォワーダーはコンサルプロジェクト用のCRMを必要としない。コンサル会社は多レグの運賃管理エンジンを必要としない。各サイドが、実際の仕事に最適化されたツールを得て — 共有プロジェクトレコードはその間の橋であり、プロダクト自体ではない。

これが重要なのは、ほとんどの「統合プラットフォーム」が”何でもやろう”として失敗するから。専用CRMより劣るCRM、専用運賃エンジンより劣る運賃エンジンになり、顧客は専用ツールを使い続けてプラットフォームを無視する。当社はその逆を作っています：各役割に最高クラスのツール、その下に共有データ。

境界線はどこか

共有レコードの外に何が残るかを明示します。SMEとサプライヤーの商業交渉はTrade Cloud上にない — それはSMEの関係。フォワーダーの内部コスト構造もForwarding PRO上にない — それはフォワーダーのマージン。共有するのは、進行中の案件の運用状態：誰が、いつ、何をしているか、何が止まっているか。

それが今日、隙間に落ちている作業単位。それを1画面に乗せます。

日本のSMEを越境させているコンサル会社の方、またはコンサル経由案件の見積を頼まれているフォワーダーの方は、30分のウォークスルーで実際のプロジェクト上の見え方をお見せします。