となりの成長室

海外カスタマーサポートの問い合わせを、返信だけで終わらせない

海外顧客から英語で問い合わせが来る。翻訳して返す。必要なら担当者へ聞く。返信はできているのに、同じ質問が繰り返される、要望が製品へ戻らない、営業が顧客の困りごとを知らない。返信できることと、問い合わせを会社の材料にすることは別です。

海外カスタマーサポートでは、言語の違いだけに注目しすぎないようにします。問い合わせを、返信、要望、不具合、仕様確認、社内共有へ分けます。

翻訳返信から、社内の戻し先へ海外問い合わせの共有ルート問い合わせを、使い方、仕様、不具合、要望、商談材料へ分類します。
01使い方ヘルプやオンボーディングへ戻す
02仕様製品、営業、契約確認へ戻す
03不具合再現手順と環境を開発へ渡す
04要望・商談製品改善と営業資料へ分ける

この図で決めること返信後の戻し先を書けば、海外問い合わせは翻訳作業で終わらない。

問い合わせは、翻訳前に分類する

翻訳の前に、問い合わせの種類を分けます。分類があると、返信後に戻す先が決まります。

分類見ること戻す先
使い方質問どの機能、どの画面、どの手順で迷ったかヘルプ、オンボーディング
仕様確認対応範囲、制限、連携、契約条件製品、営業、契約確認
不具合疑い再現手順、環境、発生時刻、影響開発、運用、障害対応
要望顧客がしたい仕事、代替手段、頻度製品、CS、営業
商談材料導入前の不安、比較、社内説明営業、資料、FAQ

最初から「英語返信」として処理すると、言葉は整っても社内で使える情報が残りません。分類を先に決めると、必要な確認先も変わります。

返信メモには、社内へ戻す一行を入れる

返信が終わった問い合わせにも、社内へ戻す一行を残します。

問い合わせ分類と社内共有メモ 分類: 仕様確認と要望。 顧客のしたいこと: 複数拠点の利用状況をまとめて見たい。 返信: 現在できる範囲と代替手順を案内。 社内へ戻すこと: 同じ要望が3件以上出たら、管理画面の集計要望として製品会議へ持ち込む。 営業へ戻すこと: 導入前の説明資料に「複数拠点で見るときの前提」を追加する。

ここで大切なのは、すべてを製品改善にしないことです。ヘルプで直せるもの、営業資料で先に説明できるもの、仕様として検討するもの、不具合として対応するものを分けます。

個人情報と契約条件は、翻訳メモに広げない

海外問い合わせでは、時差や言語だけでなく、契約、個人情報、利用規約、越境データの扱いが関係することがあります。記事の表は分類の型であり、法的判断の代わりではありません。

含まれる可能性がある情報扱い
個人名、メール、ログ、画面、契約ID必要な人だけが見られる場所で扱う
契約範囲、返金、保証、SLA営業・法務・責任者へ戻す
障害や安全に関わる内容通常問い合わせと分け、緊急度を確認
顧客の未公開情報営業資料や公開記事へ転用しない

J-Net21は、問い合わせ対応の効率化では、対応内容の記録と蓄積、問い合わせ履歴の管理を第一歩として挙げています。また、クレーム対応では、商品・サービスに対するものとコミュニケーションに対するものを分け、相手の話を聴き理由を確認する流れが示されています。海外問い合わせでも、返信文の良し悪しだけでなく、何が起き、どこへ戻すかを残します。

顧客要望を改善へ残す方法は顧客の要望を、改善と次回提案に残す方法で、顧客の声を営業資料へ使う場合は顧客の声を次の営業資料に戻す方法で扱います。初回返信の時間軸は問い合わせの初回返信へつなげます。

参考資料

次の海外問い合わせでは、返信文を作る前に分類を一つ付けます。返信後に、ヘルプ、製品、営業、契約確認のどこへ戻すかを書けば、問い合わせは翻訳作業で終わりません。

まずは相談から

海外問い合わせを、返信後の社内共有まで使える形にしませんか。

問い合わせ分類、返信状況、要望、不具合、仕様確認、営業・製品への戻し先を一つの共有メモへ整理します。