
監修者
リメディ株式会社 ディレクター
馬越 雄司 | MAGOSHI Yuji
神戸大学を卒業後、阪急阪神ホールディングスに新卒入社。経理事業部に配属となり、グループ企業5社を担当。担当企業の決算業務や税務、IFRS改正対応業務に従事。
その後リクルートに転職しキャリアアドバイザーとして、候補者様に徹底的に向き合いながら、20代から50代まで様々な業界・職種の方のキャリア支援に従事。結果として、新人賞をはじめ、顧客価値貢献・チーム貢献に関する複数の賞を受賞。
現在はディレクターとして、M&A業界、戦略・総合コンサルティングファーム、メガベンチャー企業に特化した転職サポートを行い、業界トップクラスの支援実績を誇る。
電話やメール、チャットで問い合わせに向き合ってきても、「問い合わせ対応」とだけ書けば、その仕事の難しさは伝わりません。担当した顧客や製品、判断したこと、周囲との連携、対応後の変化まで書くと、採用担当者が仕事ぶりを具体的に想像できます。
オペレーターやテクニカルサポート、SV・リーダー、隣接職から転職する方が押さえたいのは、経験の分け方、成果指標の選び方、募集要項との合わせ方、面接準備です。自分の実績として説明できる事実だけを残し、確認できない数値は入れません。
職務経歴書に、どこまで書けば仕事ぶりが伝わる?
応対した事実だけでなく、どう解決し、同じ問題をどう減らしたかまで書きます。企業の募集要項では、顧客対応に加えて品質管理、ナレッジ整備、教育、エスカレーション、業務改善も仕事に含まれています。
| 採用担当者が確かめたいこと | 職務経歴書に置く事実 | 結果を示す手掛かり |
|---|---|---|
| どんな顧客に対応したか | 顧客層、製品領域、チャネル、問い合わせの難しさ | 応答、解決、正確性を担当範囲とともに示す |
| どう問題を解いたか | 再現、原因の切り分け、回答、エスカレーション | 解決までの変化と手戻りを示す |
| 繰り返す問題をどう減らしたか | FAQ、ナレッジ、QA、業務フローの変更 | 自己解決、処理、品質の変化を示す |
| チームへ何を残したか | 教育、レビュー、負荷配分、他部署との連携 | 対応できる業務の広がりや運用の安定を示す |
一つの実績にすべてを詰め込む必要はありません。顧客対応で強みを示す実績と、再発防止やチーム改善を示す実績を分けると、個人の応対力と組織への貢献が混ざりません。
職務要約、職務経歴、自己PRはどう分ける?
職務要約は仕事の全体像、職務経歴は担当した事実、活かせる知識・技能は持ち運べる力、自己PRは応募先での使い道に分けます。同じ実績を各欄で繰り返すのではなく、欄ごとに採用担当者の疑問を一つ解消します。
| 欄 | カスタマーサポートで書く内容 | 重複を避けるポイント |
|---|---|---|
| 職務要約 | 製品・顧客、担当期間、チャネル、役割、得意な領域 | 細かな施策を並べず、経歴の輪郭を短く示す |
| 職務経歴 | チームでの役割、問い合わせの難しさ、自分の判断、改善、結果 | 職務要約で触れた強みを事実で裏付ける |
| 活かせる知識・技能 | 製品・業務知識、問題の切り分け、説明、QA、ナレッジ、教育 | ツール名だけで終えず、何に使ったかを添える |
| 自己PR | 応募先でも使える判断や改善の進め方 | 職務経歴のうち、募集要項に近い実績を一つ選ぶ |
ハローワークの案内とマイジョブ・カードの職務経歴入力では、職務内容や役割、身につけた知識・技能を具体化する前提が示されています。カスタマーサポートなら、単に「電話対応」とせず、相手の状況を聞き取り、原因を切り分け、回答や連携へ進めた経験に置き直してください。
職務要約を書いた後に、各語へ「それを証明する職務経歴はどこか」と問いを置くと、書類全体がつながります。裏付けがない強みは削るか、事実を確認してから職務経歴へ足します。
同じ会社で担当製品や役割が変わった場合は、異動や役割変更の前後を分けてください。所属名を細かく並べるより、問い合わせの難しさ、判断できる範囲、改善を任された範囲がどう広がったかを示すと、経験の積み上がりが伝わります。
問い合わせ対応を、4つの仕事に分けて書ける?
「問い合わせ解決」「品質と運用」「再発防止」「チームや他部署との連携」に分けます。業務名を並べる前に、どの場面で自分が判断し、どこから先を別の担当者へ渡したかを確かめてください。
問い合わせ解決では、どこまでが自分の仕事?
受け付けてから回答後の確認までのうち、自分で判断した工程を書きます。顧客の申告をそのまま転送したのか、環境や操作を確認して事象を再現したのか、仕様と不具合を切り分けたのかによって、伝わる専門性が変わります。
- 誰から、どのチャネルで相談を受けたか
- 再現に必要な情報をどう集めたか
- 自分で回答した範囲と、他部署へ渡した判断基準
- 回答後に利用者の解決をどう確認したか
厚生労働省編職業分類では、電話による問い合わせ対応と、インターネット・チャットによる応対は別区分です。職務経歴書でも「顧客対応」と一括りにせず、使ったチャネルと、そこで求められた判断を示しましょう。
品質と運用は、何を切り分ける?
速さ、正確さ、業務量への対応を分けます。応答を速めても誤回答や再処理が増えれば、改善とは言い切れません。繁忙時の配置、QAレビュー、エスカレーション条件、変更管理のうち、自分が担ったものを明記します。
再発防止は、どこまで書く?
問い合わせログから原因を見つけ、回答以外の仕組みを変えたところまで書きます。FAQや内部ナレッジを更新したなら、テーマを選んだ理由、内容を確認した相手、更新後に見た変化までたどります。
プロダクトへの改善提案も、「顧客の要望を伝えた」だけでは自分の仕事が見えません。発生条件、影響を受ける利用者、回避策の有無を整理し、企画や開発が判断できる情報にした過程を示してください。
チームへの貢献は、何で示す?
自分が不在でも、ほかの担当者が同じ基準で対応できるようにした事実で示します。研修資料を作っただけで終えず、レビューの方法、判断に迷う場面の共有、独り立ちを確かめる基準まで言葉にしましょう。
成果指標は何を選ぶ?
自分が変えた業務と同じ単位で測れる指標を選びます。個人の回答改善をチーム全体の成果で示したり、FAQの閲覧を顧客の自己解決と同じ意味で扱ったりすると、自分が変えた範囲が分かりません。
| 変えた業務 | 対応する指標 | 一緒に書く条件 | 避けたい見せ方 |
|---|---|---|---|
| 受付・応答 | 応答率、サービスレベル、一次応答時間 | チャネル、期間、担当範囲 | 速さだけで品質向上としない |
| 問題解決 | 解決時間、初回解決、エスカレーション | 問い合わせの難しさ、指標の定義 | 難しい案件を除いた比較にしない |
| 正確性 | 誤回答、手戻り、QA評価 | 評価基準、確認体制 | 苦情の減少だけで代用しない |
| 顧客負担 | 満足度、CES | 接点、設問、比較条件 | 条件の異なる値を並べない |
| 自己解決 | FAQ利用後の解決、問い合わせ抑制 | 対象テーマ、導線、自分が変えた範囲 | 閲覧を解決とみなさない |
| 標準化・教育 | 対応できる業務、研修到達、独り立ちまでの期間 | 対象チーム、確認基準 | 資料の作成量だけを成果にしない |
継続率や売上も自分の実績?
契約更新や追加提案を自分が直接担った場合に限って使います。サポート対応が顧客体験に影響していても、継続や売上を別部門が担う組織はあります。関わっただけの成果を、自分の達成として書かないでください。
チームの指標を使ってもよい?
チームの指標は、その変化に対して自分が担った仕事を切り出せる場合に使えます。「チームで初回解決を改善した」と書くだけでは、配置を変えたのか、回答をレビューしたのか、ナレッジを整えたのかが分かりません。
まず、チームで起きていた課題と、自分に任された範囲を分けます。そのうえで、提案、設計、実行、確認のどこを担い、ほかのメンバーや上司が何を決めたかを示してください。チーム全体の値を使う場合も、「自分がすべてを変えた」と読める書き方は避けます。
個人指標でも考え方は同じです。担当する問い合わせの難しさや勤務時間帯が変われば、単純には比べられません。比較条件がそろっているかを確認し、説明できない差は成果から外すほうが誠実です。
実績はどの順番なら伝わる?
対象、課題、判断、行動、結果、次の職場でも使えるやり方の順で書きます。この順番なら、施策名だけでなく「なぜその行動を選んだか」も伝わります。
- 対象:顧客層、製品・業務領域、チャネル、チームでの役割
- 課題:利用者が困っていたこと、運用上の詰まり、品質上の問題
- 判断:ログ、再現、顧客の声、QAから何を原因と考えたか
- 行動:回答、連携、FAQ、研修、フローのうち何を変えたか
- 結果:同じ条件で確かめられる変化
- 次にも使えるやり方:別の製品やチームでも生かせる判断や仕組み
数値が手元になければ、結果を作る必要はありません。「問い合わせ分類と更新担当を決め、回答の確認手順を統一した」のように、変えた仕組みと自分の役割を具体化します。その仕事を別の環境でも繰り返せると伝わる書き方を選びましょう。
数値がない実績は、何を結果にする?
数値を補わず、仕組みをどう変え、その変化を何で確かめたかを書きます。回答ルールの統一、引き継ぎ方法の変更、ナレッジの更新担当の明確化などは、数値がなくても自分の行動を説明できます。
| 書く順番 | 自分に確認する問い | 書かないこと |
|---|---|---|
| 課題 | どの場面で、誰が何に迷っていたか | 「非効率だった」など根拠のない評価 |
| 判断 | ログ、相談内容、レビュー結果から何を原因と見たか | 後から作ったもっともらしい理由 |
| 変更 | 回答、連携、手順、ナレッジのどこを変えたか | チームが行った施策を自分だけの仕事にすること |
| 確認 | 迷い、手戻り、再質問、レビュー時の指摘に変化があったか | 記録がない改善幅や割合 |
結果がまだ確認できていない施策は、「改善した」と言い切らず、実施したことと確認中のことを分けます。書類で強く見せることより、面接で経緯を正直に説明できることを優先してください。
過去の記録から、実績をどう探す?
問い合わせの履歴だけでなく、回答を変えた記録、レビューで受けた指摘、他部署へ渡した情報まで振り返ります。目立つ成果だけを思い出そうとすると、毎日の判断や改善が抜け落ちやすいためです。
- 問い合わせ分類やチケットの履歴から、繰り返し担当したテーマを探す
- QAレビューや上司のフィードバックから、回答を変えた理由を思い出す
- FAQや内部ナレッジの更新履歴から、自分が提案・確認した範囲を分ける
- エスカレーションの履歴から、他部署へ渡した判断材料を確かめる
- 研修や引き継ぎの記録から、誰が何をできるようになったかを整理する
社内の記録は、経験を思い出し、事実関係を確かめるために使います。顧客名、個人情報、公開前の製品情報などを職務経歴書へ写さず、製品領域や顧客層、問い合わせの種類に置き換えてください。社内資料そのものを持ち出す必要もありません。
一つの出来事を選んだら、相談を受けた時点、原因を切り分けた時点、回答または連携をした時点、その後を確かめた時点に分けます。時系列に置くと、自分が判断した場所と、他者に任せた場所が見つかります。
記憶が曖昧な数字は使わず、当時の評価基準や担当範囲を確認できるものだけを残しましょう。確認できない部分があっても、観察した課題、選んだ行動、残した仕組みを具体的に書けば、仕事の進め方は伝えられます。
「問い合わせ対応を担当」は、なぜ弱い?
対象も判断も結果も見えず、任せられる仕事を判断できないからです。抽象的な表現を見つけたら、対象、判断、変更点、確認結果の順に事実を足します。
| 曖昧な記載 | 確認する事実 | 書き直す方向 |
|---|---|---|
| 問い合わせ対応を担当 | 顧客、製品、チャネル、難しさ、自分で判断した範囲 | 切り分けから回答・連携までの役割を示す |
| FAQを作成 | 選んだテーマ、選定理由、確認者、更新手順、公開後の変化 | 作成物ではなく自己解決と更新の流れを示す |
| 顧客満足度を向上 | 対象接点、施策、設問、比較条件、自分が変えた範囲 | 施策と確かめられた反応のつながりを示す |
| 他部署と連携 | 渡した情報、相手部署、判断された内容、戻された結果 | 連携の目的と意思決定への貢献を示す |
| チームをマネジメント | 品質課題、配置、教育、レビュー、確認基準 | 管理行為ではなくチーム運用の変化を示す |
「コミュニケーション力」「顧客志向」「問題解決力」も、言葉だけでは仕事の証明になりません。相手がうまく説明できない状況をどう聞き取り、どの情報から原因を絞り、どんな言葉で回答したかを示せば、強みを実際の行動で伝えられます。
カスタマーサクセスやヘルプデスクとは、どこが違う?
カスタマーサポートは顧客からの問い合わせ、カスタマーサクセスは顧客の目標、社内ヘルプデスクは社内利用者の困りごとから仕事が始まります。部署名ではなく、支援を始めたきっかけと、自分が担った成果で分けてください。
| 職種 | 仕事が始まる場面 | 主な行動 | 職務経歴書で示す成果 |
|---|---|---|---|
| カスタマーサポート | 問い合わせ、障害、操作上の困りごと | 診断、回答、連携、FAQ、QA、VoC | 解決、正確性、顧客負担、自己解決、運用改善 |
| カスタマーサクセス | 顧客の導入計画、目標、利用状況 | オンボーディング、活用提案、定着支援 | 導入、活用、継続、拡張への直接的な貢献 |
| 社内ヘルプデスク | 社内利用者のIT課題 | 端末・アカウント対応、復旧、環境整備 | 社内業務の復旧、標準化、問い合わせ抑制 |
サポートとサクセスを兼務していても、問い合わせ解決とオンボーディングは別の仕事です。それぞれの成果を分け、応募先の役割に近い実績を残しましょう。応募時は、募集要項の仕事内容と自分の経験を照らしてください。
応募先の募集要項から、何を拾えばいい?
任される業務、必須経験、改善を求められる範囲に対応する事実を拾います。同じカスタマーサポートでも、個人の応対が中心の求人と、品質や教育、運用設計まで担う求人では、前に出す実績が異なります。
募集要項で見落としたくない違いは?
チャネルや製品知識だけでなく、品質管理、教育、仕組みづくりまで任されるかを見ます。次のように、募集要項の言葉と自分の経験を一つずつ対応させてください。
| 企業 | 採用情報から分かる仕事 | 経験を合わせるポイント |
|---|---|---|
| SmartHR | 主にチャットでの支援、KPI、品質、対応できる業務、エスカレーション、ナレッジ、変更管理 | 速さを上げた施策と、品質を保った仕組みを対にする。AIや自動化を使った場合は、対象業務、確認方法、回答品質への影響を分けて書く |
| マネーフォワード | チャット・メール・電話での支援、業務知識、ガイドやチャットボット、社内教育、サービス改善 | 顧客の申告から論点を見分けた経験か、未知の制度や製品仕様を学んで回答へ反映した過程を示す |
| スマレジ | 電話・メール・チャットの品質改善、FAQ、スタッフ教育、評価、運用設計 | SV・リーダーは、判断基準の統一、教育、レビュー、繁忙時の運用について、自分が設計・実行した範囲を明確にする |
AIや自動化の経験は、どう書き分ける?
使ったツールではなく、任せた工程、確認方法、例外時の判断、自分が変えた範囲を書きます。SmartHRとマネーフォワードの採用情報にはAI活用が含まれますが、導入した事実だけでは、回答品質をどう守ったかが見えません。
たとえば、問い合わせの分類、回答案の作成、ログの分析では、誤りを誰が確認したか、どの条件で人へ戻したか、更新後の回答をどう見直したかが論点です。自動化で処理が速くなった場合も、手戻りや誤回答が増えていないかを別に確かめます。
自分が利用者だったなら、設計者の成果まで引き受けず、運用の中で工夫したことを中心にします。設計や導入を担ったなら、対象業務を選んだ理由、関係者との調整、確認基準、運用へ定着させた手順を示しましょう。
すべての経験や指標を一枚に詰め込む必要はありません。応募先が次の担当者に任せたい仕事へ近い実績から選び、募集要項ごとに順番を変えます。
応募前に経験の選び方で迷ったら、実際の求人を見比べ、求められる業務と自分の事実を一つずつ対応させてください。面接対策まで見据え、口頭で判断理由を話せる実績だけを残すと、書類と受け答えがつながります。
経験別に、どの実績を前に出す?
オペレーター、テクニカルサポート、SV・リーダー、隣接職で、難しい判断をした場面が違います。全員が同じ「顧客対応力」を掲げるのではなく、自分の経験に合う仕事を選んでください。
| これまでの経験 | 前に出す仕事 | 確かめる成果 | 補いたい説明 |
|---|---|---|---|
| オペレーター | 状況把握、説明、難しい問い合わせの切り分け | 応答、解決、正確性、顧客負担 | 製品領域と自分で判断した範囲 |
| テクニカルサポート | 再現、ログ・仕様確認、開発連携 | 解決、手戻り、再発防止 | 非技術者へ伝えた方法 |
| SV・リーダー | QA、配置、教育、エスカレーション設計 | チーム品質、対応できる業務、運用の安定 | 自分の設計と共同成果の区別 |
| サクセス経験者 | 顧客理解、オンボーディング、利用課題の把握 | サポートに生かせる説明や連携 | 問い合わせ解決の経験との差 |
| 営業・接客経験者 | 顧客の意図把握、説明、関係者調整 | 誤解の解消、合意、継続的な改善 | 製品理解、切り分け、記録の経験 |
隣接職から応募するなら、職種名の近さより、仕事の進め方が次の職場でも使えるかを見ます。顧客の話を聞いた経験だけでなく、不足情報を集め、選択肢を判断し、記録を次の対応へ残した経験を探しましょう。
経験が隣接していても、書かない仕事はある?
応募先で使う場面を説明できない経験は、無理に前へ出しません。営業の売上、サクセスの契約更新、社内ヘルプデスクの端末管理は、カスタマーサポートと接点があっても、そのまま同じ仕事になるわけではありません。
残すなら、問い合わせの意図をつかむ、複雑な内容を相手に合わせて説明する、関係者が判断できる情報を渡す、といった共通する行動へ戻します。そのうえで、製品知識、外部顧客への応対、問題の切り分けなど、応募先で新たに補う点も書き出してください。
経験の不足を隠さず、共通する行動と未経験の範囲を分けたうえで、入社後に学ぶ内容と手順まで具体化してください。過去に新しい製品や制度を学んだ手順があれば、面接で話せるよう準備しておきましょう。
書類の実績を、面接でどう説明する?
判断した理由に加え、別の環境でも同じやり方を使える理由まで話せるようにします。数字だけを覚えるのではなく、前提条件、自分の役割、施策で起きた想定外の影響も確認しておきましょう。
| 書類に書いた内容 | 面接で説明すること | 準備する事実 |
|---|---|---|
| 解決時間の改善 | 遅れの原因と、品質を落とさないための判断 | 指標の定義、対象、比較条件、自分の役割 |
| FAQ・ナレッジ改善 | テーマを選んだ理由と、更新後の確認方法 | 問い合わせ分類、レビュー、導線の変更 |
| 開発・企画への連携 | なぜ連携が必要で、何を判断材料として渡したか | 発生条件、顧客への影響、回避策、決定内容 |
| 教育・QA | ばらつきの原因と、評価基準をどうそろえたか | 対象者、手順、レビュー方法、確認結果 |
志望動機も「顧客に寄り添いたい」だけで終えません。応募先が求める品質、ナレッジ、教育、業務改善のうち、次に担いたい仕事と自分の経験が重なるところを伝えます。
書類では個人の成果としたのに、面接で「チームが行ったので詳しく分からない」と答えると、自分の役割が曖昧になります。共同成果は、自分が提案したこと、実行したこと、ほかの人が判断したことに分けて説明してください。
提出前に、何を見直せばいい?
募集要項、自分が担った範囲、指標の定義、面接で話す内容が一致しているかを見直します。業務を広く見せるより、任された範囲で何を判断し、何を変えたかが明確な書類のほうが、応募先とのつながりを伝えられます。
- 職種名ではなく、問い合わせ解決から改善までの担当範囲が分かるか
- 応募先の募集要項に対応する実績を選べているか
- 数値の定義、対象、期間、自分が変えた範囲を説明できるか
- サクセス、営業、開発など他職種の成果を自分の成果にしていないか
- 面接で判断理由、連携、失敗や想定外の影響も説明できるか
最後に、最も強い実績を一つ選び、求人で任される仕事と一文でつないでください。その一文を支える事実が本文にそろっていれば、書類と面接の話がぶれにくくなります。
給与や働き方は職務経歴書に書く?
指定欄がない限り、給与や働き方は職務経歴書の中心に置きません。経験と能力を伝える書類なので、希望条件は応募手続きや面談の適切な場面で確認します。
希望年収は職務経歴書に書くべきですか?
指定欄がない限り、職務経歴書の中心には置きません。まずは担当業務、自分の役割、説明できる実績を示し、希望条件は応募手続きや面談で伝えます。
オファー条件を意識して書類を変えるべきですか?
条件をよく見せるために、実績を強めてはいけません。応募先が任せる役割に合う経験を選び、リーダー職なら個人対応よりQA、教育、運用設計の経験を前に出します。
リモート勤務の経験は強みになりますか?
勤務場所だけでは強みになりません。非対面での情報収集、記録、引き継ぎ、エスカレーションをどう進め、回答品質を保ったかまで説明できれば、業務経験として伝わります。
入社後の立ち上がりの早さはどう示せますか?
過去に製品知識や業務知識を学んだ手順を示します。学習資料、質問の整理、ロールプレイ、回答レビューをどう使い、任せられる仕事を広げたかを自分の事実で説明してください。

