日本の大企業向けカスタマーサクセス実践ガイド：定例から障害報告書、予算サイクルまで

海外で書かれたカスタマーサクセスの教科書は、顧客が英語を読み、会議の場で意思決定し、価値が伝われば買ってくれることを前提にしています。日本の大企業では、そのどれもが当てはまるとは限りません。私は大阪から、サンフランシスコに本社のある会社の日本企業向けカスタマーサクセスを担当しています。この記事では、私が実際に気をつけていることを、仕事の流れに沿ってまとめました。

日本語で、文章に残す

日本のエンジニアは普段から英語のドキュメントを読んでいるので、つい英語だけでアカウントを回したくなります。問題はエンジニア以外の人たちです。導入を決めてくれた担当者は、上司、情シス、セキュリティ部門、購買部門に説明しなければなりませんが、その全員が日本語で仕事をしています。英語のメールを1通送るたびに、担当者に翻訳という宿題を出しているようなものです。

だから基本は日本語、それも文章です。会議の前日にアジェンダを送り、議事録はその日のうちに送ります。中身は決定事項、未決事項、担当者、期日の4つがあれば十分です。日本の会議では、その場ではっきり「はい」が出ることはあまりありません。合意が見えるのは、むしろ議事録の方です。内容が違っていれば、お客様が直してくれるからです。

定例を「出る価値のある会議」にする

大企業のアカウントは、たいてい週次か隔週の定例に落ち着きます。定例は関係の土台になる一方で、一番無駄にしやすい会議でもあります。読めば分かる進捗報告を30分聞くだけの定例は、どこにでもあります。

まず課題管理表を共有し、1行ごとに担当者と期日を1つずつ決めて、毎回冒頭で確認します。資料は前日までに送り、会議の時間は判断と質問に使います。お客様側の議題の時間も取ってください。こちらのロードマップの説明で枠を埋めてしまうと、お客様は課題を持ってこなくなります。技術的な課題が残っているなら、「持ち帰ります」で済ませず、答えられるエンジニアを同席させます。

頻度も状況に合わせて変えます。移行中は週次が妥当ですが、1年後も課題管理表が空のまま同じ枠を続けていると、だんだん誰も来なくなります。

転送されても通じるサクセスプラン

日本のサクセスプランには、読み手が2人います。一緒に作った担当者と、来年度の予算を承認する上司です。書くときは、後者に向けて書きます。

分量は1枚です。まず、お客様自身の言葉で目標を書きます（リリース頻度、障害件数、社内ですでに約束している公開日など）。続いてフェーズ、フェーズごとの双方の担当者、そしてこちらではなくお客様の会計年度に合わせた日程。日本語で書き、お客様が普段ドキュメントを置いている場所に置きます。それがExcelなら、Excelで構いません。

「機能Xを展開する」はベンダー側の目標なので、見出しには書きません。お客様の目標は、上司から求められている成果の方です。

日本語でのEBR（エグゼクティブ・ビジネス・レビュー）

日本企業とのEBRで、その場で何かが決まることはほとんどありません。決定は事前の根回しで済んでいて、レビューはそれを関係者の前で確認する場です。

準備もそれに合わせます。1週間前に担当者と資料を最初から最後まで確認し、役員の方から出そうな指摘を聞いておきます。担当者が上司の前で驚くような内容は外します。説明はスライドに書き込んでください。資料は会議のあとに転送され、その場にいなかった人が読みます。最後は、役員がその場で了承できる提案で締めます。次のフェーズや、半年後の合同レビューなどです。

アカウントの裏にいる人たちを整理する

製品を触るエンジニアは、アカウントのごく一部です。残りはだいたいこうなっています。

部門	関心事	こちらに求めるもの
事業部	ローンチ、売上、上司が注目している案件	事業部の言葉で語れる成果、日程に間に合う計画
情シス	社内標準、運用、取引先の管理	構成資料、SSO、ログ、サポート窓口の明確化
セキュリティ部門	リスク、監査、データの保管場所	チェックシートへの漏れのない回答、期限内の提出
購買部門	契約条件、取引先登録、予算枠	先方の形式に合った書類、または経由できる販売代理店

きっかけを作るのは事業部でも、使い続けられるかどうかを決めるのは情シス、ということはよくあります。聞いたこともない製品の承認を頼まれる前に、早めに情シスの方と顔を合わせておきましょう。

セキュリティチェックシートも忘れずに。たいていはExcelで、日本語で届きます。提出期限も、商談のスケジュールの一部と考えておきましょう。

エスカレーションと障害報告書

障害が起きると、数日以内に障害報告書を求められることがよくあります。担当者が社内の上層部に説明するための資料なので、ここでも読み手はその場にいなかった人です。

構成はこれで十分です。

件名: 【障害報告】<サービス名> <発生日>

1. 概要
2. 発生日時      開始・終了（JST）
3. 影響範囲      影響を受けた機能と利用者
4. 原因
5. 対応内容      時系列で
6. 再発防止策    実施内容と期日

お詫びは最初に、それも早めに伝えます。日本で「ご迷惑をおかけし申し訳ございません」と書くのは迷惑をかけたことへのお詫びであって、法的な責任を認める文言としては読まれません。ところが海外の法務チームはここを気にすることがあるので、その背景を英語で説明するのもブリッジ役の仕事です。お詫びのない報告書は、問題を軽く見ていると受け取られ、障害そのものより信頼を損ねます。

一番じっくり読まれるのは再発防止策です。エンジニアリングチームが実際に約束した対策だけを、期日付きで書きます。「監視を強化します」のような曖昧な一文は、質問と一緒に戻ってきます。

大阪はサンフランシスコより16〜17時間進んでいるので、報告書は本社チームが寝ている間に、そのメモをもとに書くことになりがちです。時刻はすべてJSTで統一しましょう。

更新は4月始まりの年度から逆算する

多くの大企業は4月始まりの会計年度で動いていて、翌年度の予算は秋から冬にかけて組まれます。一定額以上の支出には稟議も必要です。

更新の1か月前に増額の提案を持っていっても、その予算はもう半年前に確定しています。お客様の予算カレンダーから逆算しましょう。

オンボーディングの段階で、予算編成がいつ始まり、誰が稟議を書くのかを聞いておく。
その前に実際の数字を使ったレビューを行い、担当者が稟議に使える材料を渡す。
材料は日本語で、稟議書にそのまま使える形にする。
可能なら契約期間を会計年度に合わせ、更新がすでにある予算枠に乗るようにする。

従量課金なら、もうひとつ注意点があります。日本の予算は年に1度承認される固定額で、超えてしまうと、誰もやりたくない追加の承認が必要になります。だから利用量の計画もカスタマーサクセスの仕事です。お客様と一緒に見込みを立て、毎月推移を確認し、予算を超えそうなら早めに知らせます。

SIerやパートナーもアカウントの一員

日本の大企業の多くは、SIerと一緒にシステムを作っています。コードの大半を書いているのはSIerのエンジニアで、システムのこともお客様より詳しく、お客様との付き合いもこちらよりずっと長い、ということがよくあります。

SIerの頭越しに話を進めるのはやめましょう。定例に招き、お客様のエンジニアと同じくらい真剣にイネーブルメントを行い、SIerの方が強い部分は任せます。すでに契約のあるパートナー経由で購入したいというお客様もいて、そうすれば新たな取引先登録も要りません。

パートナーと組めば、1社ずつ回っていては出会えないチームにも届きます。2025年10月には、AWS Startup Loft Tokyoで行われたAWSジャパン、クラスメソッドとのハンズオンで、Vercelのセッションを担当しました。

日本語でのイネーブルメントとコミュニティ

英語のドキュメントは製品のことはカバーしてくれますが、日本のチームが英語では聞きにくい質問まではカバーしてくれません。イネーブルメントは日本語で、スライドよりハンズオン中心で行い、来年チームに加わる人のために録画しておきます。最後に「何か質問はありますか？」と聞いて沈黙を待つのはやめましょう。代わりにどうするかは、日本語教師の経験から学んだことに書きました。

残りはコミュニティが担ってくれます。日本のエンジニアは、どのベンダーよりもほかのエンジニアを信頼します。その信頼を積み上げてくれるのが、勉強会やミートアップ、ハッカソンです。私も東京のVercelミートアップに登壇し（CEOのGuillermo Rauchと一緒の回もありました）、Anthropic、Raycast、SupabaseとTokyo AI Hackathonを共同開催しました。一覧は登壇ページにあります。