ステーブルコイン告知を外部コールセンターが一次回答する事案図解｜更新の配送

支払手段を1つ足すときの検討は、一次回答を担うのが自社の従業員である前提で語られがちです。本記事で外すのはその前提だけです。利用者からの問い合わせに最初に答える人が、自社の従業員ではなく、自社が委託した外部のコールセンターのオペレーターであるとき、ステーブルコイン建ての支払いの選択肢を1つ足すと何が起きるか。ステーブルコインとは、法定通貨と価値が連動するよう設計されたデジタルな決済手段で、日本では資金決済法上の「電子決済手段」として整理されています（用語は用語集にまとめています）。

先に結論を書きます。論点は一次回答の品質ではありません。委託先のオペレーターは、自社の新人よりよほど訓練されていることが普通です。論点は更新の配送です。

事案：問い合わせ窓口を外部に委託している会社が、支払いの選択肢を1つ足す

以下は当サイトが検討用に組み立てた想定事案であり、実在の企業・案件ではありません。実在のコンタクトセンター事業者や、実際に起きた障害事例を扱うものでもありません。

①既存事業と既存ユーザー。 国内でBtoC向けのオンラインサービスを運営する事業会社を想定します。従業員は約90名。既存ユーザーは一般の消費者です。問い合わせ窓口（電話・メール・チャット）は以前から外部のコンタクトセンター事業者に委託しており、応対するオペレーターは受託会社の従業員です。自社が用意した応対マニュアルとFAQに沿って、自社の「サービス名」を名乗って応対しています。利用者から見れば、電話口の相手はそのサービスの人です。

②やろうとしていること。 既存の支払方法（クレジットカード・コード決済）に、ステーブルコイン建ての支払いという選択肢を1つ足すかを検討しています。既存の選択肢を減らす計画ではありません。選ばない利用者はこれまでどおりです。

③登録業者との役割分担。 受け取り・換金・精算は、登録を受けた事業者が提供する仕組みに載せる前提です。自社はコインを発行せず、他人のために預かる設計も取りません。自社に残るのは、選択肢を1つ出すこと、告知すること、そして最初の質問を、自社の従業員ではない人が受けることです。

④想定される告知・導線。 会員向けの案内メール、サイトとアプリ内のお知らせページ、決済選択画面のラベル、ヘルプセンターのFAQ、そして委託先のオペレーターが読む応対マニュアルとスクリプト、電話の自動音声の案内分岐。この6点が、開発とは別に用意しなければならない成果物です。このうち最後の2点だけが、自社の外に配送しなければ効かない成果物です。

論点①　一次回答の品質ではなく、更新の配送が論点になる

自社の従業員が電話を取っているなら、条件が1つ変わったとき、朝礼で伝えるか社内チャットに1行書けば当日から反映されます。委託先ではそうなりません。自社が書き換えるのはマニュアルであって、オペレーターの口ではないからです。

図: 条件変更がマニュアル改訂・研修を経て全シフトへ届くまでの工程（当サイト作成）

この工程が一度きりなら、単なる準備期間の話で終わります。実際にはそうなりません。対応する銘柄、手数料の説明、反映までの時間のいずれかが変わるたびに、同じ工程がもう一度回ります。しかも最初の1回は社内の関心が高いので回りますが、2回目以降は「軽微な変更だから」と工程が省略されがちです。省略された結果として起きるのは、画面には新しい条件が出ているのに、電話口では古い条件が読み上げられている状態です。

事務ガイドライン第三分冊「17 電子決済手段等取引業者関係」も、周知の手段として研修を明示しています。Ⅱ－２－２－１－２⑴②は、利用者に対する情報提供義務等について社内規則等を定め、役職員が当該社内規則等に基づき適切な取扱いを行うよう、社内研修等により周知徹底を図っているかを着眼点に挙げています。Ⅱ－２－２－８－２②ロも、苦情等対処に関し社内規則等に基づいて業務が運営されるよう、研修その他の方策（マニュアル等の配布を含む。）により社内に周知・徹底をする態勢を整備しているかとしています（いずれも2026年7月時点で公開されている原文を確認しました）。

これらは電子決済手段等取引業者に向けられた着眼点であって、自社に直接課される義務として書かれているものではありません。ただ、規則を定めることと、それが現場に行き渡ることは別の工程だという整理の仕方は、委託先が一次回答を担う自社の設計にそのまま使えます。

論点②　即答してよい範囲を、告知を出す前に三分岐で決める

次に決めるのは範囲です。問い合わせのうち「まだ反映されません」「返金してほしい」「どのくらいで届きますか」の3つは、性質が他と違います。答えの根拠が自社の中にないからです。開始日や対象サービスは自社が告知物として出しているので、オペレーターは記載どおりに読み上げれば済みます。一方この3つは、取引の状況を持っているのが取扱業者側です。

図: 委託先のオペレーターが受けた問い合わせの三分岐（当サイト作成）

三分岐にする理由は、二分岐にすると②が消えるからです。「自社で答えるか、業者に回すか」の二択にすると、表示の食い違いや既存の返金規定との切り分けといった、自社にしか判断できない類型がどちらにも収まらず、結局その場のオペレーターが引き取ります。

そして、渡す先の書き方も決めておきます。「カスタマーサポート部へ」と部署名で書くと、渡された先で誰も一次回答者になりません。書くのは「誰が一次回答者か」です。渡す先が自社なら担当者の名前と代替者、取扱業者なら受付窓口の連絡先と受付時間まで書きます。

3行目の手数料が、この表でいちばん扱いにくい行です。概算を口頭で作ること自体が、自社が新しい説明を1つ増やす行為になるからです。ここでも事務ガイドラインが手がかりになります。Ⅱ－２－２－１－２⑶②は、利用者が当該電子決済手段等取引業者以外の者に対しても手数料等を支払う必要がある場合には、当該委託先に対するものも含めて手数料等の総額若しくはその上限額又はこれらの計算方法を説明しているかを着眼点に挙げ、同⑶④は、手数料等の実額ではなく上限額や計算方法のみを説明する場合には、利用者が実際に支払うこととなる手数料等の総額の見込み額又は計算例を併せて説明することとしているかとしています（2026年7月時点で公開されている原文を確認しました）。

つまり、説明の中身は業者側に用意されています。自社がオペレーターに渡すべきなのは概算を出す権限ではなく、そのまま読み上げてよい説明文の現物です。

渡す先の窓口は、告知文より先に現物で受け取る

表の3列目は、渡す先が実在しなければ機能しません。事務ガイドラインⅡ－２－２－８－２③ニは、受付窓口における対応の充実を図るとともに、利用者利便に配慮したアクセス時間・アクセス手段（例として、eメール、電話、手紙、FAX等の複数の手段）を設定する等、広く苦情等を受け付ける態勢を整備しているかとしたうえで、これら受付窓口、申出の方式等について広く公開するとともに、利用者の多様性に配慮しつつ分かりやすく周知する態勢を整備しているかを挙げています。

同じくⅡ－２－２－８－２③ヘは、業務の外部委託先が行う委託業務に関する苦情等について、電子決済手段等取引業者への直接の連絡体制を設けるなど、迅速かつ適切に対処するための態勢を整備しているかとし、Ⅱ－２－３－３－２⑪も、委託業務に関する苦情等について利用者から委託元である電子決済手段等取引業者への直接の連絡体制を設けるなど適切な苦情相談態勢が整備されているかを挙げています（いずれも2026年7月時点で公開されている原文を確認しました）。

いずれも業者側に向けられた着眼点です。ただ、委託先を挟んでも利用者から委託元への直接の連絡が確保されているか、という着眼の向きは、自社と委託先の関係を設計するときの見取り図になります。オペレーターが案内した先で会話が途切れないかどうかを、告知の前に実際に試しておくという意味です。

論点③　委託は「任せる」ことではない

最後が本記事の芯です。オペレーターが読み上げる文章は、自社が表示主体として出している告知物と同じものが口頭になっただけです。書いた人が受託会社の研修担当だとしても、その内容を決めているのは自社です。

だから、応対スクリプトは告知物と同じ版管理の対象に入れます。次の3つが同時に更新されないと、画面と口頭で条件が食い違います。

3行目だけ、書き換える主体と届ける主体が分かれています。この行の「委託先が全シフトへ展開する」という部分に締切を入れていない版管理は、運用開始後に必ずずれます。版数と改訂日をスクリプトの先頭に入れておくと、後から「電話口ではいつの版が読まれていたか」を取り出せます。

委託の範囲に、新しい種類の問い合わせが増える

もう1点だけ置いておきます。問い合わせ対応の委託には、個人情報の取扱いの委託が伴います。個人情報保護法は、個人データの取扱いの全部または一部を委託する場合について、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならないと定めています（第25条）。また、利用目的の達成に必要な範囲内で取扱いを委託することに伴って個人データが提供される場合、その提供を受ける者は第三者提供の制限における第三者に該当しないものとされています（第27条第5項第1号）。いずれも2026年7月時点で確認できる条文です。この事案で増えるのは委託先の数ではなく、既存の委託の範囲に新しい種類の問い合わせが加わることです。取扱いの範囲と監督の内容が現行のままでよいかを法務に確認する、という1行を工程に置いておけば足ります。

この事案から取り出せること

支払いの選択肢を1つ足すという判断は、決済の話に見えて、実際に発生するのは自社の外にいる人へ更新を届ける工程の設計です。自社の従業員が答えているなら、この工程は朝礼の数分に圧縮されていて、そもそも工程として認識されません。委託しているというだけで、同じ内容が日数を持ちます。

だから着手の順番も決まります。告知文より先に回答レンジ表を作り、全シフト反映までの日数を委託先から数字でもらい、そこから逆算して告知日を置いてください。逆にすると、告知の当日にいちばん多くの問い合わせが来て、いちばん多くのオペレーターが、古い版のスクリプトを読み上げます。オンチェーン金融そのものの位置づけを社内で揃える段階であればオンチェーン金融とは何かも使えます。

本記事の整理は2026年7月時点で確認できる法令および公表資料に基づくものです。制度と公表資料は更新が続くため、実際の検討にあたっては最新の資料と専門家の確認を前提にしてください。