MOps・営業・サポート運用用語集

MOPS GLOSSARY
最終更新：2026年2月8日
このページの目的

本用語集は、広告・マーケ・インサイドセールス・営業・サポートをまたいで、共通の言葉で会話できる状態を作るためのものです。
用語の定義は、一般的な意味に加えて、当社の運用支援（MOps/RevOps支援）でそのまま使える形に整えています。
現場での失敗例と、次に何を決めればよいかもまとめています。

使い方
  • わからない言葉が出たら、このページで意味と注意点を確認
  • 社内で言葉の定義がズレていると感じたら、まずここに合わせる
  • 導入前なら「次の一手」を優先して、先に決めるべきことを整理する

MOps寄り（マーケ運用）

マーケティングオペレーション（Marketing Operations）

定義：MOps（Marketing Operations）と同じ意味で、マーケのKPI・計測・ツール・運用ルールを整えて改善を回す役割/活動。
Ops視点の一言：「施策」より「定義・計測・会議」を揃えると伸びます。
よくある失敗：施策が増えるほど、数字の解釈が崩れて改善できない。
次の一手：CV→MQL→SQLの定義とダッシュボードを固定し、週次で回す。（運用支援サービスへ）

MA（マーケティングオートメーション）

定義：見込み客にメール等を自動で届け、反応に応じて次の案内を変え、商談化を促す仕組み。
Ops視点の一言：MAは「導線・同意・引き渡し条件・体制」が揃わないと動きません。
よくある失敗：配信だけして終わり、商談化に繋がっていない。
次の一手：導線（CV）→同意→MQL/SQL→SLA→制作体制の順に固める。（運用支援サービスへ）

CV（Conversion／コンバージョン）

定義：目標となる行動（問い合わせ、資料請求、予約、購入など）。
Ops視点の一言：「CVが何か」を曖昧にすると、改善ができません。
よくある失敗：部署ごとにCVの意味が違い、成果が比較できない。
次の一手：CVの定義・計算式・データ元を1枚にまとめる。（計測設計ページへ）

LP（ランディングページ）

定義：広告や検索から来た人が最初に見る、申込に特化したページ。
Ops視点の一言：LPは「CVの取り方」とセットで考えます。
よくある失敗：LPを作ったのに計測がなく、改善できない。
次の一手：フォーム・計測・問い合わせ後の追客までを一気通貫で設計。（導線設計サービスへ）

フォーム

定義：問い合わせや資料請求などの入力欄。連絡先を取得する入口。
Ops視点の一言：フォーム項目が多いほどCVは落ちやすいです。
よくある失敗：必要以上に入力させて、機会損失が増える。
次の一手：必須項目を絞り、同意と配信停止もセットで整備。（フォーム最適化ページへ）

リード

定義：連絡先が分かる見込み客。追客できる対象。
Ops視点の一言：「数」より「質」を揃えないと、営業が疲弊します。
よくある失敗：リードを増やしたのに商談が増えない。
次の一手：MQL/SQLの条件とSLAを決める。（MQL/SQL設計サービスへ）

導線

定義：流入→ページ閲覧→CVまでの道筋。
Ops視点の一言：導線が曖昧だと、MAもCRMも活きません。
よくある失敗：CV地点が複数あり、どれが成果か不明。
次の一手：CVを固定し、チャネル別に計測できる状態にする。（導線設計サービスへ）

ファネル

定義：認知→興味→商談→受注など、段階で見た流れ。
Ops視点の一言：ファネルは「どこが落ちているか」を特定するための道具。
よくある失敗：受注だけ見て、途中の詰まりが分からない。
次の一手：段階ごとのKPI（例：MQL率、SQL率）を決める。（KPI設計ページへ）

チャネル

定義：集客の入口の種類（広告、SEO、SNS、紹介、イベントなど）。
Ops視点の一言：チャネル別に見ないと、勝ち筋が分かりません。
よくある失敗：全体だけ見て、効く施策に集中できない。
次の一手：UTMなどで流入元を揃え、チャネル別のレポートを固定。（計測設計ページへ）

ナーチャリング（育成）

定義：すぐ買わない人に継続的に情報を届け、将来の商談につなげる活動。
Ops視点の一言：育成は「営業に渡す条件」が決まって初めて設計できます。
よくある失敗：全員に同じメールを送り、反応が落ちる。
次の一手：セグメント条件とシナリオの最低本数を決める。（運用支援サービスへ）

MQL

定義：マーケが「営業に渡してよい」と判断した見込み客。
Ops視点の一言：MQLは“マーケの都合”で決めると破綻します。
よくある失敗：営業が「質が悪い」と言い、放置が増える。
次の一手：MQL条件とSQL条件を一緒に決め、SLAもセットで合意。（MQL/SQL設計サービスへ）

SLA

定義：対応期限や基準の約束（例：リード受領後24時間以内に初回連絡）。
Ops視点の一言：SLAは「放置をなくす仕組み」です。
よくある失敗：ルールがなく、追客が人任せになる。
次の一手：期限・担当・未対応時の通知ルールまで決める。（運用設計ページへ）

リードナーチャリング（Lead Nurturing）

定義：今すぐ買わない見込み客に情報提供を続け、将来の商談につなげる活動（育成）。
Ops視点の一言：ナーチャリングは「誰を」「どの条件で」育てるかが先です。
よくある失敗：全員に同じメールを送り、反応が落ちる。
次の一手：セグメント条件と、MQLへ上げる条件を決める。（運用支援サービスへ）

スコアリング（Scoring）

定義：見込み客の行動や属性に点数を付け、優先順位を決める仕組み。
Ops視点の一言：スコアは「営業が納得する条件」にしないと機能しません。
よくある失敗：マーケ都合の点数でMQLが増え、営業が不信になる。
次の一手：MQL条件とセットで、点数の根拠を合意。（MQL/SQL設計サービスへ）

アトリビューション分析

定義：受注や商談への貢献を、どの施策・接点が担ったか分析する考え方。
Ops視点の一言：アトリビューションは「評価のルール」なので、先に合意が必要です。
よくある失敗：部署ごとに手柄の定義が違い、意思決定が止まる。
次の一手：まずは単一ルール（例：ラストクリック）で固定し、後で精緻化。（計測設計ページへ）

シングルタッチアトリビューション（Single-touch）

定義：1つの接点に成果の貢献を100%割り当てる考え方（例：ラストクリック、ファーストタッチ）。
Ops視点の一言：運用が簡単で、まず全体を回すのに向きます。
よくある失敗：途中接点の価値が見えず、育成施策が過小評価される。
次の一手：まず固定ルールで走らせ、必要に応じてマルチタッチへ。（計測設計ページへ）

マルチタッチアトリビューション（Multi-touch）

定義：複数の接点に成果の貢献を分配して評価する考え方。
Ops視点の一言：精度は上がるが、定義・データ整備・合意コストが増えます。
よくある失敗：複雑すぎて誰も理解できず、意思決定が遅くなる。
次の一手：目的と対象範囲を絞って導入。（RevOps支援ページへ）

CPMQL（Cost Per MQL）

定義：MQLを1件獲得するのにかかったコスト（例：広告費÷MQL数）。
Ops視点の一言：MQL定義が揃っていないと、CPMQLは比較不能になります。
よくある失敗：MQL定義が変わり、過去と比較できない。
次の一手：MQL定義を固定し、変更ルール（承認者）を決める。（運用設計ページへ）

CAC（Customer Acquisition Cost／顧客獲得コスト）

定義：顧客を1社獲得するまでにかかったコスト。CPO（受注あたり）と混同されやすい。
Ops視点の一言：どこまで費用を含めるか（広告だけ/人件費含む）で数字が変わります。
よくある失敗：計算範囲が人によって違い、比較不能。
次の一手：CACの範囲（含める費用）を明文化。（KPI設計ページへ）

ROI（Return On Investment）

定義：投資に対する利益の割合。何を「投資」「利益」とするかで数字が変わります。
Ops視点の一言：ROIは定義が曖昧だと議論が終わりません。
よくある失敗：広告ROIと事業ROIが混ざって揉める。
次の一手：計算式（分子/分母）とデータ元を合意。（KPI設計ページへ）

ABM（Account Based Marketing）

定義：特定の企業（アカウント）を狙い撃ちし、マーケと営業が連携して受注を取りに行く考え方。
Ops視点の一言：ABMは「対象企業リスト」と「営業連携」がないと空回りします。
よくある失敗：対象が曖昧で、施策が一般マーケと変わらない。
次の一手：ターゲットアカウントの定義と、担当・追い方を決める。（GTM設計ページへ）

ABR（Account Based Revenue）

定義：ABMをさらに広げ、受注だけでなく継続・アップセルまで含めてアカウント単位で収益を伸ばす考え方。
Ops視点の一言：ABRは営業とCSまで含むため、横断KPIが必須です。
よくある失敗：受注で止まり、継続・拡大が運用されない。
次の一手：アカウント単位のKPIと、引き継ぎルールを決める。（RevOps支援ページへ）

PLG（Product-Led Growth）

定義：プロダクトの体験（無料利用・トライアル等）を起点に成長させる考え方。SaaSでよく使われます。
Ops視点の一言：PLGは「プロダクトの利用データ」と「営業の介入条件」が鍵です。
よくある失敗：利用データが見えず、誰に営業すべきか決まらない。
次の一手：利用指標と、SQLに上げる条件を定義。（運用設計ページへ）

フィールドマーケター

定義：展示会・セミナー・共催イベントなど、現場接点の施策を担うマーケター。
Ops視点の一言：イベントは「後追い（追客）」設計がないと成果が落ちます。
よくある失敗：参加者リストが放置され、商談化しない。
次の一手：MQL条件とSLAを決め、参加後のシナリオを固定。（運用設計ページへ）

キャンペーンリクエストフォーム

定義：社内でキャンペーン（施策）を依頼・承認するための申請フォーム。
Ops視点の一言：運用が回っている会社ほど、依頼の入口を一本化しています。
よくある失敗：口頭依頼が増え、抜け漏れと優先順位の混乱が起きる。
次の一手：依頼項目（目的/KPI/期限/担当）を固定し、承認フローを決める。（運用設計ページへ）

マーケティングテクノロジースタック（MarTech Stack）

定義：マーケで使うツール群（広告、CRM、MA、分析、連携など）の組み合わせ。
Ops視点の一言：スタックが増えるほど「定義」「連携」「責任分界」が重要になります。
よくある失敗：ツールが増えたのに数字が揃わず、二重運用になる。
次の一手：データの元（どこが基準か）と連携範囲を決める。（運用設計ページへ）

iPaaS（Integration Platform as a Service）

定義：複数ツールをつなぐ連携基盤の総称（例：Zapier、Make等）。
Ops視点の一言：連携は便利ですが、壊れた時の責任者が必要です。
よくある失敗：連携が止まっても気づかず、数字が壊れる。
次の一手：連携一覧、監視、変更ルール（誰が直すか）を決める。（運用設計ページへ）

CDP（Customer Data Platform）

定義：顧客データを統合し、施策に使える形で整える仕組み/製品。CRMやMAと混同されやすい。
Ops視点の一言：CDPは「統合する目的（何に使うか）」がないと失敗します。
よくある失敗：データを集めたが、現場が使わず放置される。
次の一手：使うユースケース（セグメント/分析/配信）を先に決める。（運用支援サービスへ）

コンポーザビリティ（Composability）

定義：大きなツール1つに依存せず、必要な機能を組み合わせて柔軟に仕組みを作る考え方。
Ops視点の一言：柔軟な分、設計と運用（責任分界）が弱いと崩れます。
よくある失敗：連携が増えすぎて、誰も全体を把握できない。
次の一手：ガバナンス（変更ルール・責任者）と、連携の棚卸しを先に行う。（運用設計ページへ）

横断Ops（RevOps/SalesOps/CSOps）

RevOps（Revenue Operations／レベニューオペレーション）

定義：マーケ・営業・サクセスを横断して、数字の定義、仕事の流れ、データの持ち方を揃え、収益が伸びる状態を作る考え方/役割。
※当社では「マーケ〜営業〜サクセスを横断して、プロセス・データ・運用ルールを揃える考え方/役割」として扱います。
Ops視点の一言：RevOpsはツール導入ではなく「定義と運用」を揃えるのが本体です。
よくある失敗：部門ごとに指標が違い、会議で噛み合わず改善が進まない。
次の一手：KPI定義（計算式・データ元・責任者）と、MQL/SQL・SLAを合意。（RevOps支援ページへ）

Revenue Operations（レベニューオペレーション）

定義：収益に関わる部門横断の運用（プロセス・データ・会議体・責任分界）を整える活動。RevOpsと同義・近い文脈で使われます。
Ops視点の一言：名称より「何を揃えるか（定義・SLA・データ）」が重要です。
よくある失敗：役割名だけ作って、現場の運用が変わらない。
次の一手：会議で見るダッシュボードと、入力必須項目を固定する。（運用設計ページへ）

MOps（Marketing Operations／マーケティングオペレーション）

定義：マーケ活動が回るように、KPI定義、計測、ツール運用、プロセス、資料や型（テンプレ）を整える役割/活動。
Ops視点の一言：MOpsが強いほど、マーケが属人化せずに伸びます。
よくある失敗：施策は増えるが、計測と定義が追いつかず改善できない。
次の一手：CV→UTM/タグ→MQL定義→定例レビューの順で整備。（運用支援サービスへ）

Sales Ops（Sales Operations／セールスオペレーション）

定義：営業活動が回るように、案件管理、パイプライン、レポート、ルール、ツール運用を整える役割/活動。
Ops視点の一言：営業の“感触”を条件化し、予測精度を上げるのが重要です。
よくある失敗：CRM入力が形だけになり、会議で信用されない。
次の一手：案件ステージを事実で定義し、次アクションと期限を必須化。（運用設計ページへ）

CS Ops（Customer Success Operations／カスタマーサクセスオペレーション）

定義：カスタマーサクセスが回るように、更新・解約・利用状況などの指標と運用ルール、ツール整備を行う役割/活動。
Ops視点の一言：Successは「成果・継続」に直結するので、指標の定義が最優先です。
よくある失敗：担当の頑張りに依存し、解約の兆しに気づけない。
次の一手：リテンション指標とアラート条件、引き継ぎルールを決める。（運用設計ページへ）

サイロ（サイロ化）

定義：部門ごとに情報・定義・目標が分断され、全体最適の意思決定ができない状態。
Ops視点の一言：サイロの正体は「定義ズレ」と「責任分界不明」です。
よくある失敗：マーケはリード数、営業は受注、CSは解約…で会話が噛み合わない。
次の一手：共通KPIと、引き渡し条件（MQL/SQL）とSLAを合意。（RevOps支援ページへ）

ガバナンスモデル

定義：誰が何を決め、誰が実行し、誰が最終責任を持つかのルール（権限と意思決定の型）。
Ops視点の一言：ガバナンスが弱いと、設定や定義が増殖して崩れます。
よくある失敗：各部署が勝手に項目や指標を増やし、誰も全体を直せない。
次の一手：KPI/定義/変更の承認者（オーナー）を決め、変更手順を固定。（運用設計ページへ）

レベニューリーク（Revenue Leak）

定義：本来取れるはずの収益が、運用の穴で漏れている状態（放置、追客漏れ、更新漏れ等）。
Ops視点の一言：リークは「見える化」すると止められます。
よくある失敗：誰も追っていない案件や更新が放置され、失注・解約になる。
次の一手：SLAと未対応アラート、定例でのレビューを導入。（運用設計ページへ）

フォーキャスト（Forecast／売上予測）

定義：将来の受注や売上の見込みを予測すること。
Ops視点の一言：予測は主観ではなく「条件」で揃えると安定します。
よくある失敗：担当の感触でブレて会議が荒れる。
次の一手：見込の条件チェック（Yes/No）を決め、更新日も必須化。（会議の型ページへ）

インサイドセールス（Inside Sales）

定義：電話やオンラインで見込み客に接触し、商談化（アポ化）につなげる役割。
Ops視点の一言：ISの成果は「引き渡し条件」と「対応速度」で大きく変わります。
よくある失敗：温度の低いリードが来て疲弊し、放置が増える。
次の一手：MQL/SQL定義とSLA（例：24時間以内対応）を合意。（運用設計ページへ）

SFA（Sales Force Automation）

定義：営業活動を仕組み化する機能/仕組み（案件・活動・タスク・予測などを管理）。CRMの中に含まれることが多い。
Ops視点の一言：SFAは「入力を増やす」のではなく「会議の判断を速くする」ために使います。
よくある失敗：入力負担だけ増えて使われない。
次の一手：入力項目を最小化し、会議で使うダッシュボードを固定。（運用設計ページへ）

Enablement（イネーブルメント）

定義：現場が成果を再現できるように、教育・資料・型（テンプレ/プレイブック）・運用ルールを整える活動。
※当社では「現場が再現性高く動けるように、教育・資料・型（プレイブック）・運用を整える活動」として扱います。
Ops視点の一言：Enablementは「研修」だけではなく、日々の運用に組み込んで定着させるのが重要です。
よくある失敗：資料だけ作って終わり、現場が使わずに形骸化する。
次の一手：使う場（定例会・商談前・引き継ぎ）を決め、テンプレと必須入力をセットで導入。（運用設計ページへ）

Revenue Enablement（レベニューイネーブルメント）

定義：収益に関わる部門（マーケ/営業/CS）を横断して、共通言語・型・運用ルールを整え、成果を出し続ける状態を作る活動。
※当社では「収益に関わる部門（マーケ/営業/CS）を横断し、型と運用で成果を出すEnablement」として扱います。
Ops視点の一言：部門をまたぐため、定義（MQL/SQL等）と責任分界（SLA）がないと崩れます。
よくある失敗：部門最適で動き、受け渡しが詰まって“レベニューリーク”が起きる。
次の一手：受け渡し条件とSLAを決め、週次で詰まり箇所をレビューする。（運用支援ページへ）

プレイブック（Playbook）

定義：現場が迷わず同じ動きができるようにした手順書（判断基準・例文・流れをセット化）。
Ops視点の一言：プレイブックは「更新される仕組み」がないと死にます。
よくある失敗：作って終わりで古くなり、誰も見ない。
次の一手：定例で改善し、最新版の置き場と更新責任者を決める。（運用設計ページへ）

リテンション（Retention／継続率）

定義：契約や利用が継続する割合。解約率（Churn）とセットで語られることが多い。
Ops視点の一言：リテンションは売上の安定に直結し、改善の優先度が高い指標です。
よくある失敗：解約理由が記録されず、改善できない。
次の一手：解約理由の分類と、更新前アラートの運用を作る。（CS支援ページへ）

Customer Success（カスタマーサクセス）

定義：契約後にお客様が成果を出せるよう支援し、継続・アップセルにつなげる活動/組織。問い合わせ対応（サポート）とは目的が違います。
Ops視点の一言：Successは「活用状況・継続・解約理由」を数字で見ないと改善できません。
よくある失敗：対応はしているが、継続率や解約理由が記録されず、再発を防げない。
次の一手：リテンション指標と解約理由の分類、更新前アラートの運用を作る。（CS支援ページへ）

Customer Support（カスタマーサポート）

定義：問い合わせ対応を行い、対応漏れ・返信遅れ・二重対応を防ぎながら、履歴を残して品質を揃える活動/組織。
Ops視点の一言：Supportは「チケット化（担当・期限・状況）」ができると一気に安定します。
よくある失敗：メール箱運用で誰が対応中か分からず、漏れや重複が起きる。
次の一手：チケット管理（Freshdesk等）か、CRM一体管理（Service Hub/Service Cloud）かを決める。（サポート支援サービスへ）
補足：「CS」は会社によって「カスタマーサポート（Support）」と「カスタマーサクセス（Success）」の両方の意味で使われます。本ページでは、問い合わせ対応を指す場合はSupport、継続・活用支援を指す場合はSuccessとして区別します。

CRO（Conversion Rate Optimization／コンバージョンレート最適化）

定義：WebサイトやLPで、訪問者が問い合わせ・資料請求などのCVに至る割合（CVR）を上げる改善活動。
Ops視点の一言：CROはデザインだけでなく、計測・仮説・検証の運用が揃って初めて伸びます。
よくある失敗：見た目の改善だけで、CVRが上がらない。
次の一手：CV定義→計測→仮説→A/Bテスト→勝ちパターン化。（CRO支援ページへ）

CRO（Chief Revenue Officer／最高レベニュー責任者）

定義：マーケ、営業、カスタマーサクセスなど、収益に関わる組織を横断して統括する経営幹部の役職。
Ops視点の一言：CROは「収益全体最適」の責任者なので、KPI定義の統一が最優先です。
よくある失敗：部門ごとに指標がズレて、同じ会議で噛み合わない。
次の一手：共通KPI（MQL/SQL/受注/継続）とSLAを決める。（RevOps支援ページへ）

CMO（Chief Marketing Officer／最高マーケティング責任者）

定義：マーケ領域（認知・獲得・育成など）を統括し、売上成長に向けたマーケ戦略と実行をリードする責任者。
Ops視点の一言：CMOは「マーケKPIの定義」を揃えないと、広告・LP・MAがバラバラに最適化されます。
よくある失敗：部門内の指標が多すぎて、重要な改善が進まない。
次の一手：CV→MQL→SQLの共通KPIと、週次で見るダッシュボードを固定。（MOps支援ページへ）

GTM戦略（Go-To-Market Strategy）

定義：誰に、何を、どの売り方で届け、どうやって収益化するかを決める「市場への出し方」の設計。マーケ・営業・CSの役割分担も含みます。
Ops視点の一言：GTMは“戦略”だけで終わると失敗しやすく、KPIと運用（会議・SLA）に落とすのが肝です。
よくある失敗：理想の戦略はあるが、現場のKPIや引き渡し条件が決まらず実行できない。
次の一手：CV→MQL→SQL→受注→継続の指標と責任分界（SLA）を決め、定例で回す。（運用支援サービスへ）

CRM

定義：お客さん情報と商談の進捗を管理する台帳。
Ops視点の一言：CRMは「入力」より「会議で使う」から定着します。
よくある失敗：高機能CRMを入れたが使われず、二重管理になる。
次の一手：案件ステージ・必須項目・会議KPIを先に定義。（導入前チェックページへ）

案件

定義：商談・取引の単位。顧客に対して提案が進んでいるまとまり。
Ops視点の一言：案件の作成タイミングが曖昧だと数字が壊れます。
よくある失敗：案件が作られず、パイプラインが信用できない。
次の一手：いつ案件を作るか、必須項目を決める。（運用設計ページへ）

商談

定義：受注に向けた話し合いの段階。
Ops視点の一言：「商談」の定義が会社によって違うことが多いです。
よくある失敗：商談数が増えたのに受注が増えない。
次の一手：SQLの条件（営業が追う基準）を固定。（MQL/SQL設計サービスへ）

案件ステージ

定義：商談の段階（例：初回接触→提案→見積→契約）。
Ops視点の一言：「前向き」など主観語は避け、事実で定義します。
よくある失敗：担当ごとにステージが違い、予測が外れる。
次の一手：ステージを“やったこと”で定義する。（運用設計ページへ）

失注理由

定義：受注できなかった理由の分類。
Ops視点の一言：失注理由が揃うと改善が早くなります。
よくある失敗：「その他」ばかりで学びが残らない。
次の一手：選択肢を整理し、必須入力にする。（運用設計ページへ）

見込（受注見込）

定義：将来の受注予測。
Ops視点の一言：見込は“感触”ではなく“条件”で揃えます。
よくある失敗：担当の主観でブレて会議が荒れる。
次の一手：見込の判断条件（Yes/No）を定義。（会議の型ページへ）

ToDo（タスク）

定義：次にやる作業。誰がいつまでに何をするか。
Ops視点の一言：ToDoが空欄の案件は進みません。
よくある失敗：メモだけ残って実行が止まる。
次の一手：次アクションと期限を必須にする。（運用設計ページへ）

SQL

定義：営業が「商談として追う」と判断した見込み客。
Ops視点の一言：SQLは営業の生産性に直結します。
よくある失敗：SQLの定義がなく、営業の対応がブレる。
次の一手：SQL条件とSLAを合意し、未対応を可視化。（運用設計ページへ）

ダッシュボード

定義：重要な数字をまとめて表示する画面。
Ops視点の一言：会議で見る数字が決まると入力が揃います。
よくある失敗：指標が多すぎて誰も見なくなる。
次の一手：会議で使うKPIを3〜5個に絞る。（会議の型ページへ）

KPI

定義：目標の達成度を測る数字（商談化率、受注率など）。
Ops視点の一言：KPIの定義が揃わないと、改善が進みません。
よくある失敗：部署ごとに定義が違い、議論が噛み合わない。
次の一手：定義/計算式/データ元/責任者を1枚にする。（KPI設計ページへ）

定例MTG

定義：週次/月次で数字を見て、課題と次アクションを決める会議。
Ops視点の一言：定例がないと、ツールは必ず形骸化します。
よくある失敗：入力が続かずデータが古くなる。
次の一手：会議アジェンダと更新ルールを固定。（会議の型ページへ）

外部支援（運用支援）

定義：社外に設定変更・改善・相談などを継続して手伝ってもらうこと。
Ops視点の一言：社内管理者がいないなら外部支援が必要です。
よくある失敗：支援が単発で終わり、運用が止まる。
次の一手：月額で改善まで回せる範囲を定義する。（運用支援サービスへ）

名寄せ（データクレンジング）

定義：同じ会社/人が重複登録されるのをまとめること。関連して、不要データの削除・表記揺れ修正などの作業を「データクレンジング」と呼びます。
Ops視点の一言：名寄せ不足は「二重連絡」など致命傷になります。
よくある失敗：同じ顧客が別IDでカウントされ、数字が壊れる。
次の一手：名寄せルールと責任者を決め、定期的に整備。（データ整備支援へ）

顧客台帳

定義：顧客情報をまとめた一覧（CRMの役割を分かりやすく言ったもの）。
Ops視点の一言：「どれが元の情報か」を決めると混乱が減ります。
よくある失敗：複数ツールに同じ情報がありズレる。
次の一手：元データの管理場所を1つ決める。（導入前チェックページへ）

一般IT・データ

計測

定義：どの施策が成果に効いたかを数字で追えるようにすること。
Ops視点の一言：計測がない改善は、勘になりやすいです。
よくある失敗：CVは増えたが、原因が分からない。
次の一手：UTM・タグ・CV定義をセットで整備。（計測設計ページへ）

タグ

定義：サイトに入れる計測用の部品。アクセスやCVを記録する。
Ops視点の一言：タグ変更は計測断絶の原因になりやすいです。
よくある失敗：サイト改修で計測が止まり気付かない。
次の一手：タグ管理の担当と変更ルールを決める。（計測運用ページへ）

UTM

定義：URLに付ける目印。どの広告・投稿から来たかを判別する。
Ops視点の一言：UTMが揃うとチャネル別分析が一気に楽になります。
よくある失敗：UTMがバラバラで流入元が不明。
次の一手：UTM命名規則を作り、徹底する。（計測設計ページへ）

BI

定義：複数データをまとめて見える化する分析ツールの総称。
Ops視点の一言：BIは“定義が揃ってから”が鉄則です。
よくある失敗：綺麗なグラフだが意味が合っていない。
次の一手：KPI定義とデータ元を確定してから着手。（KPI設計ページへ）

ERP

定義：会計・受発注など基幹業務のシステム。
Ops視点の一言：ERP連携が増えると、CRM要件が一段重くなります。
よくある失敗：連携が後から必要になり作り直し。
次の一手：将来の連携要件を早めに洗い出す。（導入前チェックページへ）

準委任

定義：成果物納品ではなく、一定時間・一定範囲の業務支援を行う契約。
Ops視点の一言：範囲と役割分担を最初に決めないと揉めます。
よくある失敗：「どこまでやるか」が曖昧で期待がズレる。
次の一手：担当外業務と成果物を明文化。（運用支援サービスへ）

製品名（混同しやすい固有名詞）

Salesforce

概要：高機能CRMの代表。権限・承認・連携など複雑運用に強い。
注意：運用設計と管理者（社内or外部）がないと形骸化しやすい。
推奨の目安：部署/拠点/承認/連携が増える見込みが高い会社向け。
一次情報：Salesforce公式：Sales Cloud（営業支援CRM）

HubSpot

概要：CRMとマーケ機能を同じ画面で運用しやすい製品群。
注意：製品（Hub）ごとに契約が分かれる場合がある。
推奨の目安：マーケ〜営業の一体運用を早く回したい会社向け。
一次情報：HubSpot公式：製品一覧（Hubの構成）
HubSpot公式：ヘルプセンター（日本語）

Freshworks

概要：CRMやサポートなどを製品として提供する会社名。
注意：「会社名」と「製品名」を混同しない（例：Freshworks≠Freshsales）。
推奨の目安：まず軽量に導入し、運用を短期で立ち上げたい会社向け。

Freshsales

概要：FreshworksのCRM製品。顧客・商談の管理に使う。
注意：「Freshworks（会社名）」と「Freshsales（製品名）」は別。
推奨の目安：複雑な統制よりも、現場の定着速度を優先したいフェーズ向け。
一次情報：Freshsales公式：CRM API / Docs（参考）

Freshdesk

概要：Freshworksの問い合わせ管理（チケット管理）製品。対応漏れ・二重対応を減らす。
推奨の目安：問い合わせ対応の見える化を最短で整えたい会社向け。
一次情報：Freshdesk公式：サポートチケットとは

Marketing Hub

概要：HubSpotのマーケ機能の製品名（メール、フォーム、育成など）。
注意：契約範囲はプランで異なるため契約前に確認。
一次情報：HubSpot公式：Marketing Hub（マーケティング）

Service Hub

概要：HubSpotのサポート機能の製品名（チケット管理など）。
注意：HubSpotの導入＝自動付帯ではない場合があるため契約前に確認。
一次情報：HubSpot公式：Service Hub（導入支援）

Service Cloud

概要：Salesforceのサポート機能の製品名（問い合わせ管理など）。
注意：Salesforceの導入＝自動付帯ではないため契約前に確認。
一次情報：Salesforce公式：Service Cloud（カスタマーサービス）
免責：製品の料金・プラン・付帯機能は改定される場合があります。契約前に各社の公式サイトで最新情報をご確認ください。

これを書いた著者

小長谷直登のイメージ
株式会社ユニバーサルマーケティング代表取締役｜ビジネスアナリスト
小長谷直登
1984年神奈川県足柄上郡生まれ。
広告・マーケ・インサイドセールス・営業・サポートを横断して、KPI定義・計測・運用ルール（MOps/RevOps）の整理と改善設計を支援しています。

WEBマーケティングとシステム開発で66社のビジネスを支援。SEOに強い会員サイトの構築を得意とし、新規会員獲得と既存顧客のLTV改善に寄与。

stripeを使った月額課金システムやキントーンやsalesforceとの連携。実績として動画配信サイト、ポイントシステム構築、フリマサイト、旅行予約サイト、オンラインサロン、モノのサブスクなど一般消費者向けのサービス設計とサイト設計を得意としています。
2025年7月　AIパスポート取得済

本コンテンツはコンテンツ制作ポリシーにそって、当社が独自の基準に基づき制作しています。
>>コンテンツ制作ポリシー