CS代行とは、電話・メール・チャットなどの顧客対応の全部または一部を外部事業者へ委託する方法です。FAQに沿った一次受付や注文・配送案内は任せやすい一方、返金・補償、重大な苦情、ブランド方針に関わる判断は自社に残す設計が基本です。導入前に委託範囲と運用ルールを決め、費用だけでなく応対品質、システム連携、個人データの管理体制まで比較します。
CS代行とは何か｜任せられる業務と自社に残す判断
CS代行は、顧客からの問い合わせ対応を外部事業者へ委託するサービスです。すべてを外注するのではなく、電話・メール・チャットなどの窓口業務、問い合わせ内容の確認、定型的な回答、担当部署への取り次ぎといった業務の一部だけを切り出して任せることもできます。
EC事業者であれば、注文状況や配送状況の案内、返品・交換の受付、キャンセルに関する一次対応、苦情の受付などが委託対象になり得ます。ただし、代行会社がどこまで注文情報を参照できるか、返金や注文変更を実行できるかは、契約とシステム権限によって異なります。
重要なのは、「問い合わせを受ける業務」と「会社として最終判断する業務」を分けることです。定型対応を外部化しても、例外時の判断基準や責任の所在まで外部へ移るわけではありません。
委託しやすい業務と自社判断を残しやすい業務
委託しやすいのは、FAQや手順書に沿って回答・受付できる業務です。たとえば、営業時間や送料、商品の基本仕様、注文の受付状況、配送状況の案内は、参照する情報と回答基準を整えれば代行会社が対応しやすくなります。返品・交換の申請を受け付け、必要情報をそろえて社内へ引き継ぐ業務も、条件を明確にすれば委託候補になります。
一方、次のような業務は自社の判断を残す設計になりやすい領域です。
- 返金額、補償額、無償交換の可否を決めること
- 規約や通常ルールから外れる例外対応
- 重大なクレームや事故、法的な申し出への最終回答
- 商品仕様の変更、販売停止、ブランド方針に関わる判断
- 顧客ごとの事情を踏まえた特別対応
切り分けの基準は、問い合わせの種類だけではありません。代行会社に判断権限を与えるか、その判断に必要な情報を誰が更新するか、最終責任を誰が負うかまで確認します。代行会社には受付・確認・定型回答を任せ、判断が必要になった時点で自社の担当者へ引き継ぐ形にすると、対応の速さと責任の所在を両立しやすくなります。
CS代行が向く状況と、先に社内設計を見直すべき状況
CS代行は、人手不足だけでなく、問い合わせ量の波や対応チャネルの増加によって社内対応が追いつかないときに検討しやすいサービスです。ただし、業務を外へ出せば自動的に品質が上がるわけではありません。問い合わせの性質と、自社の対応設計が整っているかを分けて判断します。
導入を検討しやすい課題
次のような課題がある場合は、CS代行の導入を検討しやすくなります。
- 問い合わせ件数が増え、営業・商品開発・出荷など本来の業務を圧迫している
- 電話、メール、チャットなどの窓口が増え、社内だけでは対応時間を広げにくい
- 繁忙期やセール期間だけ問い合わせが急増する
- 時間外や休日の一次受付を用意したい
- 担当者によって回答内容や案内の速さに差がある
繁忙期だけ増員する、時間外の一次受付だけを任せる、常時の定型問い合わせを委託するなど、委託範囲には複数の選択肢があります。問い合わせが少ない時期まで同じ体制を維持する必要がない場合は、繁忙期・時間帯・チャネルを限定したほうが、目的と費用を結び付けやすくなります。
複数チャネルで回答をそろえること自体が課題なら、単に人員を増やすだけでは解決しません。まず回答基準や情報の置き場所を整えたうえで、その運用を代行会社にも共有できるかを確認します。
委託前に対応設計を整えたほうがよいケース
次の状態で委託を急ぐと、社内の問題がそのまま委託先へ移り、回答品質が安定しないおそれがあります。
- 担当者ごとに回答や判断が異なる
- 商品、在庫、配送、返品の情報を社内でもすぐ確認できない
- FAQやテンプレートが古く、更新担当者も決まっていない
- 返金・交換・補償などの決裁者と連絡経路が決まっていない
- 過去の問い合わせ履歴が整理されておらず、同じ問題を繰り返している
この場合は、FAQ、回答テンプレート、対応履歴、例外時の判断基準、社内の連絡先を先に整えます。顧客への回答が遅い原因が人手不足ではなく、情報の分散や決裁の遅れである可能性もあるためです。
社内設計を整えても負荷が高い部分を特定できれば、委託範囲も明確になります。たとえば、定型的な問い合わせは代行会社、複雑な商品相談は社内、返品申請の受付は代行会社、返金の確定は自社というように分けられます。
委託開始前に決める対応範囲・エスカレーション・個人データの扱い
委託開始前に決めるのは、代行会社へ渡す業務の一覧だけではありません。どの情報を使って、どの基準で回答し、判断が必要な案件を誰へいつ引き継ぐかまで文書化します。これが曖昧なままだと、対応漏れや二重回答、顧客を待たせたままの案件が生じやすくなります。
対応範囲と回答ルールを具体化する
まず、次の項目を委託範囲として具体化します。
- 対応するチャネル（電話、メール、チャットなど）
- 受付時間、対応する曜日、時間外の扱い
- 対応言語と、各チャネルで受け付ける問い合わせの種類
- 一次回答だけを行うのか、受付・登録・処理まで行うのか
- 使用できるFAQ、テンプレート、商品情報、注文・配送情報
- 対応履歴を記録するシステムと、記録する項目
- 情報の更新担当者と、更新内容を代行会社へ伝える方法
ECの場合は、注文、決済、在庫、配送、返品の情報がどのシステムにあるかを整理します。代行会社が参照できる情報と、操作まで許可する情報は分けて考えます。たとえば配送状況の確認は許可しても、注文内容の変更や返金処理は自社だけに限定する設計が考えられます。
クレーム・返金・事故時のエスカレーションを設計する
クレーム、配送事故、個人情報に関する申出、返金・交換・補償などは、代行会社だけで確定しにくい案件です。あらかじめ、どの条件でエスカレーションするかを決めておきます。
最低限、次の事項を案件の種類ごとに定めます。
- 社内へ引き継ぐ条件
- 引き継ぎ先の部署・担当者と連絡手段
- 一次回答を行う範囲
- 社内確認後の確定回答を行う担当者
- 顧客へ返答する期限と、確認中であることを伝える方法
- 夜間や休日に緊急案件が発生した場合の連絡方法
たとえば、配送事故を受け付けた時点では、注文番号や配送状況を確認して受付完了を伝えます。補償や再発送の可否は社内の決裁者が判断し、確定した内容を顧客へ返します。このように一次回答と最終回答を分ければ、代行側が権限を超えて約束するリスクを抑えられます。
個人データを扱う委託先の監督と再委託の確認
顧客の氏名、住所、電話番号、メールアドレス、注文履歴、苦情内容などを代行会社が扱う場合、委託元は個人データの管理を委託先任せにできません。個人情報保護委員会のガイドラインでは、個人データの管理の中で安全管理措置と委託先の監督が整理されています。掲載ページには、令和8年6月の一部改正と、令和8年6月14日時点の条番号が示されています。詳細は個人情報の保護に関する法律についてのガイドライン（通則編）で確認できます。
委託先を選ぶ前に、少なくとも次の事項を確認します。
- 委託先が講じている安全管理措置
- 担当者の教育、守秘、退職・異動時のアクセス停止
- システムへのアクセス権限、認証、ログの管理
- データの保存場所、保存期間、削除・返却の方法
- 漏えい等が発生した場合の連絡と対応の手順
- 再委託の有無、再委託先を含む管理と報告の仕組み
個人情報保護委員会の公表資料は、委託元が事前に委託先の安全管理措置を確認し、委託先の取扱状況を把握できる内容を契約へ盛り込み、定期的な監査などで実施状況を確認する考え方を示しています。また、再委託で個人データを扱う場合も、再委託先を含めた監督が必要です。これらの確認事項は、委託先を監督してますか？にも整理されています。
法令上の具体的な対応は、取り扱うデータの種類や事業内容などによって変わり得ます。契約では、対象データ、利用目的、アクセス範囲、事故時の報告、再委託の条件を曖昧にしないことが重要です。
CS代行会社を比較するときの基準
委託先は、会社名や月額料金だけでなく、自社の業務要件を同じ条件で並べて比較します。「対応可能」という説明だけでは、実際にどの時間帯・権限・例外処理まで含むのか分からないためです。まず自社の問い合わせ件数、チャネル、受付時間、問い合わせの難易度、必要な社内判断を整理してから見積もりを依頼します。
対応体制と品質管理を比べる
比較では、次の項目を確認します。
- 電話、メール、チャットなどの対応チャネル
- 対応時間、休日対応、時間外の一次受付
- 対応言語、商材や業界に近い業務経験
- 研修の内容と、FAQ・商品情報の学習方法
- 回答内容のレビュー方法と品質不良時の改善手順
- 応対履歴やレポートの共有方法
- クレーム、返金、交換などのエスカレーション体制
- 繁忙期の増員や、担当者変更時の引き継ぎ方法
ブランド独自の言葉遣いや接客を重視する場合は、応対サンプルだけでなく、立ち上げ時にどのようにすり合わせるかも見ます。実際の問い合わせを想定したテストや、回答テンプレートの修正方法を確認すると、契約後の認識違いを減らせます。
システム連携と権限設計を確認する
EC運営では、問い合わせ管理だけでなく、受注管理、配送管理、CRMなどとの連携条件を確認します。連携方法がAPI、CSV、手動入力のどれなのかによって、反映速度、作業負担、入力ミスのリスクが変わるためです。
代行会社が確認・操作できる範囲も分けて確認します。たとえば、注文番号や配送状況の参照は許可する一方、注文変更、キャンセル、返金処理は自社承認後に限定するなど、業務ごとに権限を設定します。アカウントの共有を前提にせず、担当者単位のアカウント、操作ログ、退職・契約終了時のアクセス停止方法も確認します。
既存ツールと連携できることと、希望する業務を自動化できることは同じではありません。対象データ、更新方向、反映のタイミング、追加費用、障害時の代替運用まで確認して判断します。
費用は料金体系と運用変更費まで見る
費用は、月額、件数ごとの従量課金、初期費用だけで比較しません。次のような追加条件を見積もりに含めます。
- 電話・メール・チャットなどのチャネル追加
- 時間外、休日、繁忙期の増員
- 研修、FAQの作成・更新、応対品質のレビュー
- レポート作成や定例会議
- システム連携、アカウント発行、初期設定
- 返金・返品など例外処理の対応
- 対応件数や業務範囲を変更した場合の費用
問い合わせ件数だけでなく、1件あたりの難易度やエスカレーションの割合も見積もりの前提にします。同じ件数でも配送状況の案内が中心の場合と、商品相談や返品判断が多い場合では必要な体制が異なります。料金の安さだけでなく、必要な品質と自社担当者の確認負担を含めた総コストで比較することが大切です。
導入後は応答速度と解決品質を一緒に確認する
導入後は、返信の速さだけで成否を判断しません。速く答えていても、誤案内が多い、顧客が解決していない、同じ不満が繰り返されるといった状態なら、顧客体験は改善していないためです。
定例会では対応履歴を確認し、問い合わせの分類、回答内容、エスカレーション、再問い合わせの有無を見ます。代行会社だけに改善を任せず、商品情報や配送ルールを更新する自社側の責任も明確にします。
KPIは量・速さ・品質を組み合わせる
KPIは、量・速さ・品質を組み合わせて設定します。問い合わせ件数や対応完了件数は業務量、初回応答までの時間や解決までの時間は対応速度を示します。これらに加えて、次のような指標を確認すると、回答の中身を評価しやすくなります。
- 再問い合わせの割合と主な理由
- エスカレーションの件数・内容・引き継ぎの遅れ
- 回答の誤りやテンプレートからの逸脱
- 対応漏れ、二重対応、未完了案件の数
- 顧客の不満や低評価につながった問い合わせの傾向
速度だけを目標にすると、確認不足のまま回答するケースが増える可能性があります。初回応答の速さと、最終的に問題が解決したかを別の指標として見て、必要なら対象案件を抽出して内容を確認します。
問い合わせを商品・配送・案内の改善へ戻す
問い合わせは、顧客の不満を処理するだけでなく、商品や業務の問題を見つける情報源にもなります。問い合わせ内容を原因別に集計し、CS以外の担当部署へ戻す仕組みを作ります。
たとえば、商品説明への質問が繰り返されるなら商品ページの情報不足、配送日の問い合わせが多いなら納期表示や配送案内の分かりにくさが考えられます。返品理由が特定の商品に集中している場合は、仕様説明や梱包、品質の見直しにつながることもあります。
定例会では、件数の報告だけで終わらせず、「何が原因で」「どの部署が」「いつまでに」改善するかまで決めます。改善後に同じ問い合わせが減ったかを確認すれば、CS代行を単なる受付窓口ではなく、顧客体験を改善する運用へつなげられます。
まとめ
CS代行は、電話・メール・チャットの一次受付や定型案内、繁忙期の対応を外部化する方法です。返金・補償、重大な苦情、ブランド方針に関わる判断は自社に残し、業務ごとに権限と責任を分けると導入目的を明確にできます。
委託前に、対応範囲、回答基準、エスカレーション、システム権限、個人データの管理方法を決めます。委託先は費用だけでなく、対応体制、品質管理、既存ツールとの連携、再委託を含む情報管理まで同じ条件で比較します。導入後も応答速度と解決品質を確認し、問い合わせを商品・配送・案内の改善へ戻すことが、顧客体験を損なわない運用につながります。