運送会社向け顧客ポータル

輸送チームは、ETA、POD、請求書のコピーを求める繰り返しの電話やメールに対応します。顧客には、アクティブな積載、出荷履歴、未処理のリクエストを確認できる単一の場所がありません。

ポータル データが TMS エクスポートから手動で再構築されると、顧客には古いステータスが表示され、内部チームはセルフサービスに対する信頼を失います。

このブループリントは、スプレッドシートを複製する代わりに、TMS およびドキュメント ストアから運用上の真実を読み取るポータルをターゲットとしています。

配送業者のユーザーは、事業者のネットワーク全体ではなく、自分のアカウント、レーン、サービス レベルに関するフィルタリングされた可視性を必要としています。

顧客サービスとディスパッチには、例外キュー、承認パス、顧客の変更内容の監査を含む内部ビューが必要です。

財務部門は、クローズされた出荷にリンクされた請求書パックへの読み取り専用アクセスを必要とする場合があります。

顧客は、TMS または統合フィードから取得したマイルストーン タイムラインを使用して、アクティブな出荷と完了した出荷を検索して掘り下げます。

ドキュメント ワークフローは、POD の取得、通関パック、およびウイルス スキャンと保持ルールを使用した出荷指示書のアップロードをカバーします。

サービス リクエストは、ピックアップの変更、保留フラグ、または見積依頼をキャプチャし、SLA タイマーを使用して適切なキューにルーティングします。

企業の配送業者向けの SSO によるアカウントとユーザーの管理はオプションです。

マップヒント、マイルストーンテーブル、関連ドキュメントを組み合わせた出荷ワークスペース。

テンプレートを使用して CS の受信トレイをリクエストし、承認されたら TMS の書き戻しをリクエストします。

主要なイベントに関する電子メールおよびポータル内アラートの通知設定。

TMS は出荷記録システムのままです。ポータルは、API または制御されたファイル ドロップを通じて、負荷、停止、ステータス、および料金を消費します。

ドキュメント ストレージには、POD 画像、BOL、署名付き URL 付きのカスタム PDF が保存されます。 ERP は、出荷が完了したときに請求書トリガーを受け取る場合があります。

電子メールの取り込みは、API を使用しないパートナーを補うことができます。検証キューは、認証されていないアップロードが顧客ビューに入るのを防ぎます。

顧客向けの出荷ビューを内部 TMS 識別子から分離し、顧客が認識する外部参照をマップします。

マイルストーン イベントは、紛争解決のためにソース システムのタイムスタンプと冪等である必要があります。

リクエスト オブジェクトには、ステータス、所有者、SLA、および荷物が分割されたときに孤立することなく 1 つまたは複数の出荷へのリンクが必要です。

フェーズ 1: パイロット アカウント セグメントの読み取り専用追跡とドキュメント。

フェーズ 2: CS の承認と選択的な TMS ライトバックを伴うサービス リクエスト。

フェーズ 3: 通知、SSO、および拡張されたアカウント階層。

フェーズ 4: ポータルの導入と偏向されたコンタクト量に関する分析。クライアントの結果として宣伝されるものではなく、正直に測定されます。