AIの成果を読む前に、
Thriveという会社を知る。
企業背景と公式発表の要約2026年10月22日、ServiceNowは、ThriveによるTPSMとAIの活用成果として、一次解決率73%、解決までの時間63%短縮、顧客満足度99.2%を発表しました。[1]このニュースを読むうえで重要なのは、Thriveがどのような会社で、どのようにサービス提供の基盤を育ててきたかです。
予防的なIT運用を担う、成長型のMSP
Thriveは、2000年に米国マサチューセッツ州で創業したITサービス会社を起点とし、問題が起きてから修理するモデルに対して、予防的なマネージドサービスを志向してきました。[2]顧客向けの選定資料では、従業員50〜5,000名、規制・コンプライアンス要件があり、人手の限られたIT部門を持つ企業などを理想顧客としています。[3]
現在の成長路線を理解する節目が、2016年のM/C PartnersによるThrive NetworksとCorporate IT Solutionsの買収・統合です。ここから地域や専門性を広げる買収を重ねてきました。[4]2025年にはBerkshire Partnersと既存投資家Court Squareからの戦略的出資に合意したと発表し、その時点で2020年以来15件の買収を行ったと説明しています。[5]
ServiceNowの共通基盤が先にあり、AI活用が続く
| 時期 | 確認できる動き | 記事を読む視点 |
|---|---|---|
| 2016年 | Thrive NetworksとCorporate IT Solutionsを統合。[4] | 連続買収による成長の起点 |
| 遅くとも2021年 | 買収発表で、ServiceNowの自動化・セルフサービスを活用するNextGen Platformを説明。[6] | 買収先の顧客へ既存基盤を展開する構造 |
| 2023年 | 公式記事で、買収企業をThrive基盤へ移行する統合チームの活動を紹介。[7] | 統合を継続して行う組織的な能力 |
| 2025年 | 追加出資と、標準化・拡張性・自動化による成長方針を発表。[5] | 成長を支える基盤への継続投資 |
| 2026年10月 | TPSMとAIの活用成果を公表。[1] | 蓄積してきた基盤の上でのAI活用 |
2021年のHoward Tech Advisors買収発表では、既存のNextGen Platformを買収先の顧客へ広げる方針が示されています。[6]今回の発表は、ServiceNowを最近導入して一気にAI化した事例ではなく、以前からの基盤投資の延長として読む必要があります。
Numberが見る、
PMIの理想像。
Numberの視点PMI(買収後の統合)では、買収先を迎え入れた後、どのようにグループとしての価値を生み出すかが問われます。私たちがThriveの歩みに見るのは、共通基盤を育てながら買収を重ね、そこにサービスや自動化の改善を蓄積していく姿です。
買収先には、地域の顧客との関係、技術者の専門性、特定業種への理解があります。一方、受付や案件管理、対応状況の記録が会社ごとに異なれば、グループの人材やノウハウを共有するには時間がかかります。
共通の運営モデルがあれば、新しく加わった会社が、グループの対応体制やナレッジを使うための道筋を定めやすくなります。新しい改善を一度つくり、適用できる範囲へ横展開することも考えられます。AIは、その共通の業務と情報を活用して効果を広げる位置付けになります。
図:公開情報から着想したNumberのPMI設計モデルです。Thriveの実際の統合手順やKPI体系を示すものではありません。
これは、標準化がすべてのM&Aより先に完了していたという意味ではありません。M&Aと基盤整備を並行して進め、次の統合と改善に使える能力を蓄積する。その循環が、PMIの理想像の一つだと考えています。
どこを共通化し、どこを残すか。
その判断を、共通KPIで支える。
日本企業への適用についての考察日本のITサービス企業がこの事例から考えたいのは、共通化する業務と個別に対応する業務の境界です。すべてを一律に揃えると、顧客との契約や業界固有の要件を損なうおそれがあります。一方、例外をそのまま積み上げれば、統合後も各社が別々に動く状態が続きます。
| 領域 | 共通化する部分 | 個別に設定する部分 |
|---|---|---|
| 受付・案件管理 | 分類、ステータス、必須記録、引き継ぎ方法 | 顧客ごとの受付窓口や利用言語 |
| サービス水準 | 計測方法、報告項目、違反時の対応手順 | 契約上の目標時間、営業時間、優先条件 |
| 技術対応 | 標準手順、実行記録、承認・例外管理 | 顧客環境、規制要件、固有の承認者 |
| データ・権限 | 顧客・契約・構成情報の持ち方、権限管理の原則 | 参照可能な組織や担当者、契約上の制約 |
表はNumberによる設計例です。Thriveの実装を再現したものではありません。
同じ数値を、同じ意味で比較できるようにする
統合の効果を測るには、共通KPIが必要です。同じ一次解決率でも、何を分母にするか、別担当者への転送をどう扱うか、後日の再問い合わせをどう数えるかが違えば、会社間の比較はできません。
| KPI | 揃える定義 | 改善に使う観点 |
|---|---|---|
| 一次解決率 | 対象案件、一次接点の範囲、再問い合わせの観測期間 | 受付で使える情報・権限・手順が十分か |
| 解決までの時間 | 計測の起終点、営業時間、顧客回答待ちの扱い | 実作業と引き継ぎ・承認待ちを分けて見る |
| 再オープン率・顧客満足度 | 再オープンの条件、調査対象、回答率 | 速さの改善が品質低下につながっていないか |
| 標準手順の適用率・例外率 | 対象業務、例外理由の分類、記録方法 | 共通化すべき業務と、維持すべき個別対応を見極める |
共通化するのは、まず測定の物差しです。契約や案件の難易度が違えば、目標値まで一律にする必要はありません。サービス種別や顧客条件ごとに比較し、差が生じた理由を確認します。
その結果から、優れた対応を共通手順へ取り込む、根拠のある例外を維持する、不要な個別対応を減らす。共通KPIを、共通化と個別対応の境界を見直すために使うことが重要です。AIによる要約や振り分けも、改善する対象が定まっていれば、導入効果を捉えやすくなります。
自社で運用するために、
まず整えること。
1. 共通化と個別対応の境界を決める
各社・各拠点の受付、振り分け、承認、技術対応、報告の流れを並べます。契約・規制・顧客価値に由来する違いと、これまでの慣習による違いを整理します。共通化の責任者と、例外を認める条件・見直す時期も決めます。
2. 共通KPIとデータの定義を揃える
案件分類、状態、時刻、顧客・契約との関係を揃え、KPIの計算条件を文書化します。移行前の実績を把握し、移行後も同じ条件で比較できるようにします。顧客構成や案件難易度の差を見られる切り口も用意します。
3. 次の買収先にも使える統合手順をつくる
データ移行、アクセス権、教育、稼働判定、例外の引き継ぎを、再利用できる手順にします。共通モデルへ移した業務から、要約や振り分けなどAIの適用対象を選びます。人へ引き継ぐ条件を定め、時間・品質・保守工数を合わせて確認します。
Numberは、PMIで整えた共通基盤に改善を蓄積し、その成果を次の統合へつなげることに注目しています。Thriveの事例は、AIの成果を、その前に積み重ねてきた統合と標準化から読むことの重要性を示唆しています。
出典・参考情報
- ServiceNow:ThriveのTPSM・AI活用事例 ↗
- Thrive:About Thrive / Our Story ↗
- Thrive:Channel Battlecard(PDF) ↗
- M/C PartnersによるThrive Networks・Corporate IT Solutionsの買収・統合 ↗
- Berkshire Partners・Court Squareからの戦略的出資に関する発表 ↗
- Thrive:Howard Tech Advisors買収発表 ↗
- Thrive:統合チームのJeff Boardman氏紹介 ↗
企業背景と成果は各社の公開情報に基づきます。PMIの理想像、共通化の境界、KPI体系はNumberの考察・提案であり、Thriveがその通りに実装していると確認したものではありません。各投資の時期と今回の成果の因果関係を定量的に示す資料ではありません。製品名・商標は各権利者に帰属します。