Makuakeのリターン配送を自社で行うか、代行へ任せるか

発送件数より、「今の配送体制で最後まで処理できるか」を見る

Makuakeのリターン配送は、実行者が対応します。Makuakeは配送代行サービスも紹介していますが、代行を使っても実行者側の管理がなくなるわけではありません。

自社発送か代行かは、荷物の数だけではなく、次の4工程を今の体制で処理できるかで決めます。

自社発送を検討しやすいのは、既存の体制でMakuake分まで処理できるとき

普段からEC発送を行っており、Makuake分を追加しても通常業務へ無理なく組み込めるなら、自社発送を検討しやすくなります。

• 普段から注文データを使って発送している
• ピッキング・梱包を行う人員と場所がある
• 複数のリターン内容を間違えずに分けられる
• 送り状発行と運送会社への引き渡し手順がある
• 未着・誤配送・破損時に対応できる

この体制がすでにあるなら、Makuakeのためだけに別の発送工程を作る必要はありません。

配送代行を比較するのは、既存の発送体制だけでは処理しにくいとき

既存の発送体制だけではMakuake分を処理しにくい場合は、配送代行も比較します。発送体制がない場合だけでなく、出荷集中や特殊な配送条件がある場合も対象です。

• 社内に発送担当者がいない
• 梱包する場所を確保しにくい
• リターンの種類やセット構成が多い
• 冷蔵・冷凍、大型商品など通常発送と条件が違う
• 短期間に出荷作業が集中する

Makuakeは現在、提携する配送代行サービスを実行者向けに案内しています。

配送代行を使う場合も、どのサポーターへ何を送るかは実行者側で確定して渡します。

代行へ任せても、住所データの確定は実行者側で行う

Makuakeでは、発送準備に入る前に「住所ロック」を行います。住所ロック前は、サポーター自身がお届け先を変更できます。

そのため、CSVを先に渡して発送準備を進めると、その後の住所変更が反映されず誤配送につながる可能性があります。

配送代行を使う場合ほど、「最終データはどれか」を1つに決めてから出荷を開始します。

物理作業を外注しても、サポーター対応は実行者側に残る

Makuakeでは、リターンの管理と発送は各プロジェクト実行者が行う仕組みです。サポーターから配送に関する問い合わせが来た場合も、実行者が対応します。

配送完了後は、実行者向け管理画面で配送状況を「お届け完了」に更新する必要もあります。

全部を自社か、全部を外注かの二択にしなくていい

実務では、管理と物理作業を分けられます。

普段のEC倉庫が使えるなら、その倉庫へMakuake分も流す方法があります。倉庫がないなら、物理作業だけ代行へ任せる方法もあります。

自社でも代行でも処理できるなら、費用と通常業務への影響を比べる

自社でも代行でも対応できる場合は、追加で発生する費用と、通常業務への影響を比べて決めます。

自社の方が安くても通常業務が止まるなら、その影響まで含めて比較します。代行の方が高くても、短期間の出荷集中を吸収できるなら選ぶ理由があります。

自社発送か配送代行か｜5つだけ確認する

• 既存の発送体制でMakuake分まで処理できるか
• リターンの種類・同梱物・配送条件を間違えずに処理できるか
• 短期間に発送が集中しても通常業務へ影響しないか
• 未着・誤配送・破損時の対応まで社内で回せるか
• 自社と代行の両方が可能なら、追加費用と通常業務への影響はどちらが小さいか

すでに発送体制があり、この5点を処理できるなら自社発送を選びやすくなります。

発送工程を新しく作る必要があるなら、配送代行も含めて比較します。

結論｜発送作業ではなく、配送工程全体で決める

自社発送か代行かは、発送数だけで決めません。

住所データの確定から配送後の問い合わせまでを並べ、処理できる工程と、外へ出した方が負担の小さい工程を分けて決めます。