比較表をつくると、候補の3製品すべてに「旅程作成」「見積管理」「顧客管理」の欄で丸がつく。どれを選んでも同じに見えたのに、導入して半年後、ある会社では現場が毎日使い、別の会社では元のExcelに戻っていた。旅行業界でSaaSを選んだ経験のある方なら、こうした話に心当たりがあるかもしれません。
この差を生んでいるのは、機能の有無ではなく、その機能が「現場の業務がどう回るか」をどこまで踏まえて設計されているかです。本記事では、これを運用知見と呼び、それが製品のどこに表れるのか、そして選定の場でどう見極めればよいかを示します。
この記事の要点
- 業界特化SaaSの導入後の差は、機能の有無ではなく、設計に反映された運用知見から生まれます。
- 運用知見が製品に表れる4つの場所と、機能比較表ではそれが見えない理由を整理しています。
- デモや商談の場で、運用知見の有無を確かめるための5つの質問をそのまま使えます。
目次
機能比較表で差が見えない理由
運用知見とは何か：機能との違い
運用知見が表れる4つの場所
機能は追いつかれ、知見は追いつかれにくい
選定の場で運用知見を見極める5つの質問
まとめ：比べるべきは業務の回り方
機能比較表では、SaaSの差が見えない
SaaSの選定で機能比較表が使われるのは、候補を絞り込むには有効だからです。ただ、業界特化SaaS同士の比較では、表の上の差が小さくなりやすく、導入後に効いてくる差はほとんど表に現れません。
理由の1つ目は、機能名が同じでも、その中身の前提が違うことです。「旅程作成」と書かれていても、1日ごとの行程を自由に書くための機能なのか、ホテルや体験の情報を組み合わせて旅程を組み立てる機能なのかで、現場での使い方はまったく変わります。比較表はこの違いを、同じ1つの丸で表してしまいます。
2つ目は、比較表が「あるかないか」しか測れないことです。旅行会社の現場で問題になるのは、見積を作れるかどうかではなく、旅程を変えたときに見積も直る流れになっているか、手配の状況を誰が見ても分かるか、といった業務の回り方です。これは一覧表の1行では表せません。
3つ目は、汎用ツールとの比較で起こるすれ違いです。SalesforceやHubSpot、kintoneのような汎用ツールは、設定次第でほとんどの機能を実現できます。柔軟さは大きな長所ですが、裏を返せば、業務の回し方を設計する責任が導入する側に残るということでもあります。比較表では、汎用ツールにも業界特化SaaSにも同じように丸がつきます。
運用知見とは何か
運用知見とは、ある業界の業務が実際にどの順番で進み、どこで止まり、どんな例外が起きるのかについての知識です。機能が「何ができるか」を決めるのに対し、運用知見は「現場でどう回るか」を決めます。
旅行会社の業務で言えば、問い合わせを受け、旅程の案を作り、見積を出し、変更を受け、手配を確定させ、当日を迎えるという流れがあります。この流れの中で、どの情報を先に入れると後が楽になるのか、どの場面で変更が集中するのか、誰が誰に確認を待っているのか。こうした知識は、マニュアルにはなかなか書かれず、現場で業務を回してきた人の中に蓄積されています。
たとえば、旅程の案は確定までに何度も書き換えられます。顧客に送った版、社内で検討中の版、手配先に伝えた版が並んだとき、どれが最新で誰がどれを見たのかが分からなくなると、手配の取り違えが起きます。運用知見のある設計は、こうした場面が起きることを前提に情報の持ち方を決めています。この前提がない設計では、機能としては同じ「旅程作成」でも、担当者がファイル名に日付を付けて版を管理する運用に戻っていきます。
業界特化SaaSの価値は、この運用知見が、画面や機能の設計に前もって組み込まれている点にあります。導入した会社は、自分たちで業務設計をゼロから行わなくても、業界で無理なく回る流れに乗ることができます。
機能は「何ができるか」を、運用知見は「現場でどう回るか」を決めます。
運用知見が表れる4つの場所
運用知見は、機能一覧の中ではなく、製品の細部に表れます。選定時に注目すべき場所は次の4つです。
場所1：入力の順番と初期値
画面の項目が、現場で情報が手に入る順に並んでいるかどうかです。たとえば問い合わせの段階では、人数と日程は分かっていても、宿泊先はまだ決まっていません。それなのに宿泊先を入れないと先に進めない画面では、担当者は仮の値を入れるか、別のメモに書いておくことになります。入力の順番が業務の順番と合っているかは、毎日の使い心地を大きく左右します。
場所2：例外の扱い
旅行の業務は、予定どおりに進まないことのほうが多い仕事です。到着が1日遅れる、参加人数が1名減る、手配先から代替案が届く。こうした変更やキャンセルをどう記録し、関係する情報にどう反映させるかは、機能表にはまず載りません。しかし現場の負担の多くは、この例外処理に集中しています。
場所3：情報と情報のつながり
旅程、見積、手配といった情報が、それぞれ独立して存在するのか、互いに連動しているのかです。旅程を変えたら見積も自動で変わる設計であれば、担当者が二つの書類を見比べて直す作業はなくなります。TRAVESENSが旅程と見積を自動で連動させているのは、変更のたびに転記と確認が発生するという、旅行会社の現場で繰り返し起きている負担を前提にした設計です。
場所4：蓄積のされ方
一度入力した情報が、次の案件で使える形で残るかどうかです。ホテルやレストラン、体験の情報を案件ごとに毎回書き直すのか、データベースとして登録して検索・再利用できるのかで、1年後の業務量は大きく変わります。使えば使うほど楽になる設計かどうかは、導入直後のデモではもっとも見落とされやすい点です。
機能は追いつかれ、知見は追いつかれにくい
SaaSの機能は、時間がたつほど製品間の差が縮まっていきます。ある製品が便利な機能を出せば、他の製品も同じような機能を追加できるからです。開発の手段が増えたいま、機能を作ること自体の難しさは以前より下がっています。
一方で、運用知見は簡単には真似できません。どの場面で現場が止まり、どの順番なら無理なく回るのかを知るには、その業務を実際に経験するか、多くの現場を深く観察する必要があるからです。機能の数ではなく、設計の前提にどれだけの現場が反映されているかが、製品の差として残ります。
TRAVESENSの場合、開発元のTOKIはインバウンドのラグジュアリートラベルを手がける旅行会社で、自社の業務課題を解くために作った社内ツールが原型です。そのうえで旅行会社30社以上へのヒアリングを経てプロダクト化し、コンサルティング出身のメンバーが業務改善の知見を設計に反映しています。
ただし、運用知見が製品に組み込まれていることは、どの会社にも合うことを意味しません。組み込まれた業務の流れが自社のやり方と大きく異なる場合、その流れに合わせるか、柔軟に設計できる汎用ツールを選ぶかの判断が必要になります。業務が定型的で、見積なら見積だけを効率化できれば十分という会社であれば、単機能のツールで足りることもあります。
選定の場で運用知見を見極める5つの質問
運用知見は資料からは読み取りにくいため、デモや商談の場で確かめるのが確実です。機能の説明を聞くだけでなく、自社の過去の案件を1件持ち込み、次の5つを質問してみてください。
「この案件で到着日が1日ずれたら、どの画面のどこを直しますか」：例外処理の手数と、情報の連動を確かめる質問です
「この画面の項目は、なぜこの順番に並んでいるのですか」：入力の順番が業務の流れから設計されているかが分かります
「導入した会社が、最初の1か月でつまずきやすいのはどこですか」：現場への定着を見てきた経験があるかが表れます
「私たちの業務なら、使わなくてよい機能はどれですか」：機能を売るのではなく、業務に合わせて提案できるかを確かめます
「1年使うと、この中に何がたまっていますか」：蓄積と再利用の設計を確かめる質問です
答えの内容だけでなく、答え方にも注目してください。機能の名前で答えが返ってくるのか、「その場面では、多くの会社がこう回しています」と業務の言葉で返ってくるのか。後者であれば、その製品と提供元には運用知見が蓄積されていると判断する材料になります。
まとめ：比べるべきは、機能の数ではなく業務の回り方
業界特化SaaSを選ぶとき、機能比較表は入口として役に立ちます。しかし、導入後に現場で使われ続けるかどうかを決めるのは、表に載らない設計の細部です。入力の順番、例外の扱い、情報のつながり、蓄積のされ方。そこに業界の運用知見がどれだけ反映されているかが、半年後、1年後の差になります。
次にSaaSのデモを受ける機会があれば、機能を順に見せてもらうのではなく、自社の過去の案件を1件持ち込んで、変更が入った場面を再現してもらってください。その数十分で、比較表を何枚つくるよりも多くのことが分かるはずです。
変更が入った場面で、比べる。
旅程を変えると見積も連動して変わる流れを、デモでご確認いただけます。自社の過去の案件に近いシナリオで、例外が起きたときの手数を確かめてください。
まずは、実際の画面でご体験ください
無料デモを申し込む