1Approval
出張・トラベル

BTMが浸透しない理由と乗り換えの判断

出張管理システム(BTM)を導入したのに現場が使わない。その原因を5つに分け、乗り換えで直るものと直らないものに切り分けます。浸透度を測る唯一の指標、乗り換えを決める4つの基準、移行時に持ち出すべきデータ、そして「順序の問題」はBTMを変えても解決しない理由まで整理しました。

BTMが浸透しない理由と乗り換えの判断

BTM(出張管理システム)を導入したのに、気づくと半分の出張が従来どおり各自の予約サイトで手配されている。請求書は相変わらず何通も届き、経理の作業は減っていない。契約更新の時期が近づき、「このシステムが悪いのではないか」と乗り換えを検討し始める——これは珍しい話ではありません。

ただ、乗り換えれば直る原因と、乗り換えても直らない原因があります。 切り分けずに別のBTMへ移ると、移行コストだけ払って同じ場所に戻ります。本記事では、浸透度の測り方、原因の切り分け、乗り換えを決める基準、移行時に持ち出すべきものを順に整理します。

この記事の要点

  • 浸透度を測る指標は**利用率(BTM経由の手配件数 ÷ 全出張件数)**の1つだけでよい。アカウント発行数やログイン数では実態が見えない。
  • 目安は9割。AI Travelは定着した導入企業で手配の9割以上が自社経由になるとしており、BTMは全社で使われて初めて効果が出る。
  • 原因は5つに分けられ、そのうち乗り換えで直るのは3つだけ。残り2つはBTMを変えても再発する。
  • 乗り換えを決める基準は4つ。利用率が6か月で5割を超えないことが最初の分岐点。
  • 承認と手配が別々のシステムに分かれているという原因は、BTMの優劣ではなく順序の問題なので、乗り換えでは解決しない。

浸透度は「利用率」ひとつで測る

まず現状を数字にします。見るべきは1つだけです。

利用率 = BTM経由の手配件数 ÷ 全出張件数

分母の「全出張件数」は、出張申請の承認件数から数えるのが正確です。BTMの管理画面だけを見ていると、そもそもBTMを通らなかった手配が分母から落ちるため、利用率は常に高く見えます。

アカウント発行数やログイン率は使えません。アカウントを持っていて月に一度ログインするが、実際の予約は個人のサイトで済ませている、という状態を拾えないからです。

目安は9割

AI Travelは、定着した導入企業では出張手配の9割以上が同サービス経由になると公開しています。この水準が目安になります。

なぜ9割が必要かというと、BTMの価値が集約にあるからです。請求の一本化も、出張データの分析も、危機管理での所在把握も、全件が通って初めて成立します。7割が通っていても、残り3割のために立替精算の仕組みと個別の請求処理を残さなければならず、管理部門の作業はほとんど減りません。

利用率が5割を切っているなら、それは「使いにくい」ではなく「使われていない」状態です。

浸透しない5つの原因

1. 自分で予約したほうが早い

多機能なほど画面は複雑になります。どこを押せば手配できるか分からない、候補を絞るのに手数がかかる。出張者から見れば、使い慣れた予約サイトで3分で終わることに10分かけている状態です。

この判断は合理的なので、精神論では覆りません。

2. 承認と手配が別々になっている

申請と承認は既存のワークフロー(kintone、Microsoft 365、Teams、Google Workspace など)で回し、承認が降りたらBTMを開いて予約する。この構成だと、同じ内容を2回入力することになります。

さらに、承認を待っている間に席や部屋が埋まれば取り直しです。出張申請の手動再予約はなぜ多発するのかで扱ったとおり、これは担当者の注意力ではなく順序の問題です。

現場から見ると「二度手間のうえ、結局取り直しになる仕組み」なので、使わない理由が積み上がります。

3. 個人のポイント・マイルが貯まらない

会社のBTMで手配すると法人決済になり、個人のクレジットカードのポイントは付きません。マイルも会員番号を入れなければ貯まりません。

これは出張者にとって実損です。規程で「マイルは会社帰属」と定めていない会社では、BTMを使わないことに金銭的な動機があります。

4. 規程が曖昧で、システムが弾く理由を説明できない

BTMに宿泊費の上限を設定すると、超える予約は止まります。ところが規程側が「原則◯◯円」程度の書き方だと、現場は「例外のはずだ」と考え、止められた理由に納得しません。

規程が曖昧なままシステムだけ厳格にすると、システムが悪者になります。

5. 変更・キャンセルのサポートが遅い

出張は直前に変わります。前日の便変更に当日まで返事が来ない経験を一度すると、次から自分で予約するようになります。

乗り換えで直るもの、直らないもの

ここが本題です。5つの原因を切り分けます。

原因乗り換えで直るか
1. 自分で予約したほうが早い直る — 操作性はサービスごとに大きく違う
5. サポートが遅い直る — 有人サポートの範囲と対応時間は契約条件そのもの
手配できる在庫が足りない直る — 提携先が違えば選択肢が変わる
2. 承認と手配が分かれている直らない — どのBTMでも承認は自社のワークフローに残る
3. 個人のポイント・マイル直らない — 規程の問題
4. 規程が曖昧直らない — 規程の問題

2から4は、BTMを替えても同じ形で再発します。 乗り換え先の営業資料には書かれていない部分なので、検討時に見落とされがちです。

とくに2は厄介です。BTM各社は「申請・承認から精算まで一気通貫」と説明しますが、実際には既存の承認ワークフローを捨てて、BTMの承認機能に寄せるという意味であることが多い。稟議のルートや金額分岐を作り込んでいる会社ほど、それはできません。結果として、承認は既存のまま、手配だけBTM、という構成に落ち着きます。

乗り換えを判断する4つの基準

基準1:利用率が6か月で5割を超えたか

導入から半年は立ち上がりの期間です。この間に5割を超えないなら、運用の工夫で覆る見込みは薄いと判断してよいでしょう。逆に7割まで来ているなら、残りは原因を潰す作業で届きます。

基準2:原因が「直る側」にあるか

上の表で、自社の主な原因が直る側に2つ以上あるなら乗り換えの効果が見込めます。直らない側だけなら、乗り換えても費用と手間が増えるだけです。

基準3:契約の残存期間と違約金

年間契約の途中解約で違約金が発生するかを確認します。残り3か月なら、待ってから動くほうが安く済みます。

基準4:移行にかかる作業量

見落とされやすい部分です。少なくとも次が必要になります。

  • 利用者マスタと部署構成の再登録
  • 規程(宿泊費上限、クラス制限、承認ルート)の再設定
  • 会計・経費精算システムとの連携の作り直し
  • 出張者への説明と再教育

再教育は最も重いところです。 一度「使いにくい」と判断されたシステムを入れ替えると、現場は二度目の学習に消極的になります。乗り換えは一度きりのつもりで臨むべきです。

乗り換えるときに持ち出すもの

解約前に、次のデータを手元に落としておきます。解約後は取り出せなくなります。

  • 手配履歴(日付・行き先・金額・利用者)— 次のサービスの見積もり条件になり、削減効果の比較基準にもなる
  • 請求明細— 会計処理の照合に使う
  • 規程の設定内容— 宿泊費上限や承認ルートの設定をそのまま移せる
  • 利用者マスタ— 部署構成込みで出力しておく

手配履歴は特に重要です。これが無いと、次のサービスで「本当に安くなったのか」を検証できません。出張1件の工数は何分かで扱ったとおり、効果は工数と金額の両面で測る必要があります。

よくある質問(FAQ)

利用率は何で数えればいいですか?

BTM経由の手配件数を、出張申請の承認件数で割ります。BTMの管理画面の数字だけを見ると、BTMを通らなかった手配が分母から落ちるため、実際より高く出ます。

利用率が低いのは、周知不足が原因ではないですか?

周知は最初の1〜2か月の話です。半年経っても5割を切っているなら、周知ではなく構造に原因があります。本記事の5つの原因のどれかに当てはまるはずです。

乗り換えずに改善できる原因はありますか?

規程の明確化(原因3・4)は、システムを変えずに着手できます。マイルの帰属と宿泊費上限を規程に明記するだけで、現場の納得感は変わります。出張規程の作り方を参照してください。

複数のBTMを併用するのは現実的ですか?

勧めません。集約が価値の中心なので、分けると請求もデータも分断され、導入前に戻ります。国内と海外で分けている会社はありますが、その場合も請求と精算の集約先は1つに寄せてください。

乗り換え先はどう選べばいいですか?

自社で起きた原因を、そのまま確認項目にします。操作性が原因なら実際の画面で手配してみる、サポートが原因なら深夜・休日の対応範囲を契約条件として確認する、という形です。BTM13社の比較で比較の6つの視点を整理しています。

乗り換える前に:承認側でつなぐという選択

原因が「2. 承認と手配が分かれている」だけなら、BTMを替える必要はありません。

1Approvalは、いま使っている承認ワークフロー(kintone、Microsoft 365、Teams、Google Workspace)の上で、承認が降りた時点で手配まで完了させる仕組みです。承認ルートの設計をやり直す必要がなく、二重入力も、承認待ちの間の取り直しも構造的に起きません。

費用は法人一括請求にまとまり、手配データは経費データとして生成されて会計・経費精算システムへ連携できます。立替と証憑回収が発生しないため、出張旅費の統制で扱った「手配を個人任せにしない」状態にそのまま近づきます。

利用率が上がらない理由が順序にあるなら、順序を直すほうが安く、早く、そして再発しません。

まとめ

BTMが浸透しないとき、最初にやるべきは利用率を数えることです。目安は9割、5割を切っているなら構造に原因があります。

そのうえで原因を5つに切り分け、乗り換えで直る側にあるかを確認してください。 操作性・サポート・在庫が原因なら乗り換える価値があります。承認との分断や規程の曖昧さが原因なら、乗り換えても同じ場所に戻ります。

そして乗り換えは一度きりのつもりで臨んでください。二度目の入れ替えには、現場はついてきません。

主な参照先

※各サービスの条件は2026年9月時点で確認した公開情報です。最新の情報は公式サイトでご確認ください。

監修

伏見 匡矩

伏見 匡矩

株式会社エイチ 代表取締役社長

  • 国内旅行業務取扱管理者

株式会社エイチ代表取締役社長。出張手配・会場手配の実務を起点に、申請・承認から購買実行までを一体で扱う1Approvalを立ち上げ、事業責任者としてプロダクト設計に携わる。国内旅行業務取扱管理者。出張手配の実務とBTM各社の比較検証を踏まえ、承認・予約・精算をつなぐ設計を扱っている。

経歴・運営者情報を見る

この記事のテーマ

あわせて読みたい

海外BTM・経費管理7社比較|Navanと日本の差

Navan・Perk(旧TravelPerk)・Expensify・Brex・Ramp・Egencia・Spotnanaの7サービスを、出張予約・経費精算・法人カードの統合度と料金で比較。海外では1プラットフォームに統合されAIエージェント化が進む一方、日本企業がそのまま使えない4つの理由まで整理します。

AI Travelとは?特徴・料金・評判を解説

出張管理システム「AI Travel」の提供元・公開されている実績・できること・料金の考え方を整理しました。交通と宿泊を1画面で予約する仕組み、生成AIを使うTravel Intelligence Agent、法人一括請求の範囲、他のBTMと比べた強みと導入前に確認したいポイント、向いている企業までを実務目線でまとめます。

BTOL(ビートル)とは?料金・評判を他社と比較

南海国際旅行が提供する出張手配システムBTOL(ビートル)の機能、6つの特長、公開されている料金情報、e-出張との違い、レビューサイトでの評価状況に加え、性格の近いJTBビズバンス・日本旅行 出張なび・HIS BTM Portalの3サービスとの比較と導入前の確認ポイントを整理しました。

海外の自律型ソーシング6選|買い先を選び直す仕組み

Fairmarkit・Keelvar・Arkestro・Globality・Pactum・Levelpathの6サービスを、何を自動化するか・得意なスペンド・連携先ERPの軸で比較。「購買申請を横取りして買い先を選び直す」という海外で確立した型と、それを日本の購買実務にどう翻訳するかを解説します。

出張手配・経費精算のお役立ち記事をすべて見る

※記載されている会社名・製品名は各社の商標または登録商標です。