お客様の導入事例
Insperia:再現性のある提供に向けて整えた法人予約業務
中東の B2B 法人出張サービス企業が、より明確な業務管理を導入しました。すべての法人予約が、同じアカウントルール、同じエージェント手順、同じ承認ルートに沿って進みます。
- 中東
- B2B 法人出張
- 法人ワークフローの構築
- 2024 年に稼働
ケーススタディ
Insperia 導入事例の概要
Insperia は中東で法人出張サービスを提供し、B2B で事業を行っています。顧客は企業で、エージェントが企業に代わって出張を予約し、対応します。このプロジェクトは法人ワークフローの構築で、ウェブサイトの見た目ではなく、業務の組み立て方に焦点を当てたものでした。
目標は安定したサービスでした。法人アカウントにはより厳格な構造が、エージェントには個人ごとのやり方ではなく統一された予約の扱い方が、社内承認には全員が見える明確な順序が必要でした。
この構成はプラットフォーム概要上で動いています。同様の要件を持つチームは、たいてい出張管理のページとB2Bホールセラーのツールから始めます。
出発
エージェントごとに異なる対応
到着
再現性のある法人対応
- お客様
- Insperia
- 業種
- 法人出張サービス
- 地域
- 中東
- モデル
- B2B
- 範囲
- 法人ワークフローの構築
- 稼働
- 2024
技術スタック
REST APIPHPMySQL
出発点
日々の法人予約業務にあった三つの課題
Insperia は構築前に三つの課題を挙げていました。それらは同じ業務の三つの異なる工程、つまりアカウント、エージェントデスク、承認にあります。
アカウント対応
すべての法人アカウントを一か所で確認
複雑なアカウント対応が一つ目の課題でした。答えは構造です。誰がそのアカウントに属し、どのルールが適用され、各リクエストがどの段階にあるか。
アカウント情報がメールの受信箱や個々のエージェントの記憶の中にあると、予約のたびに探すところから始まります。一つのアカウント画面があれば、どのエージェントも予約に手を付ける前に関係者、ルール、未完了のリクエストを確認できます。連絡履歴やフォローアップは旅行業向けCRMで管理するのが自然です。
- アカウントの関係者と役割を一覧で
- 予約前にアカウントのルールが見える
- 未完了のリクエストと状況がひと目でわかる
- 出張手配担当社員の出張リクエストを送る
- 承認者予約確定前に承認する
- アカウント担当エージェントアカウントの出張を予約し対応する
- 承認
- 確定前に必須
- 承認する人
- アカウントに指定された承認者
- 対応メモ
- 一人のエージェントではなくアカウントに保存
- 航空券
CR-2041承認待ち - ホテル
CR-2038承認済み - レンタカー
CR-2035確定
説明用の画面です。構成の仕組みを示すもので、Insperia の実データではありません。
承認フロー
すべてのチェックポイントが順に並ぶ法人予約の承認ルート
あいまいな承認ルートが三つ目の課題でした。社内チェックポイントには明確な順序と可視性が必要でした。段階を選ぶと、誰が対応し、何を確認し、誰が追跡できるかがわかります。
- 対応する人
- 出張手配担当
- 確認すること
- リクエストに出張者、日程、アカウントが記載されている
- 追跡できる人
- 手配担当とアカウント担当エージェント
- 対応する人
- アカウント担当エージェント
- 確認すること
- リクエストがアカウントとそのルールに合っている
- 追跡できる人
- エージェントとチームリーダー
- 対応する人
- 指定の承認者
- 確認すること
- 何かを確定する前に出張が承認される
- 追跡できる人
- 承認者、手配担当、エージェント
- 対応する人
- アカウント担当エージェント
- 確認すること
- 承認済みのリクエストに沿って予約を確定する
- 追跡できる人
- リクエストの関係者全員
- 対応する人
- アカウント担当エージェント
- 確認すること
- 変更も同じルートを通る
- 追跡できる人
- リクエストの関係者全員
説明用のルートです。各段階は構成の原則を示しています。決まった順序、確定前のチェック、そして共有された一つのステータスです。
エージェント間の一貫性
どのエージェントが担当しても同じ手順書
エージェントごとの手順のばらつきが二つ目の課題でした。対応スタイルが違えば結果も違います。共通の手順の流れが、法人業務から個人差を取り除きます。
- 01法人アカウントを開くエージェント A
- 02アカウントのルールと対応メモを読むエージェント A
- 03ルールの範囲内で候補を用意するエージェント A
- 04承認に回して承認を待つエージェント A
- 05承認済みのリクエストに沿って確定するエージェント A
- 06予約をアカウントに記録するエージェント A
0 / 6エージェントを切り替えても、手順はまったく同じです。誰が担当しても、予約は同じ方法で処理されました。
新しいフローのおかげで、チームは法人予約をより一貫して実行できるようになりました。
成果
Insperia の法人デスクで変わったこと
Insperia は成果を数字ではなく業務上の言葉で報告しているため、このページには数字を載せていません。各成果は三つの課題のいずれかに対応しています。
- 実行品質対応する課題02
より一貫した提供
エージェントが同じ順序に従うため、誰が担当しても法人予約は同じように処理されます。
- 法人業務対応する課題01
より明確なアカウント対応
関係者、ルール、未完了のリクエストを、寄せ集めではなくアカウントから読み取れます。
- 社内ガバナンス対応する課題03
より良い承認フロー
チェックポイントは決まった順序で進み、その状況はリクエストの関係者に見えます。
構成を支える技術スタック
- L1
REST APIプラットフォームを他のシステムとつなぐ - L2
PHP予約とワークフローのロジックを動かす - L3
MySQLアカウント、予約、その履歴を保存する
PHPTRAVELS はセルフホスト型で、ソースコードは商用ライセンスのもとで提供されます。
法人出張チーム向けの関連情報
中東の B2B 法人出張サービス企業である Insperia が、PHPTRAVELS 上で法人予約のワークフローを構築し、2024 年に稼働させた経緯を紹介しています。この取り組みにより、アカウント対応にはより厳格な構造が、エージェントには予約を扱う共通のやり方が、社内承認には明確な順序がもたらされました。
三つです。構造と明確さが不足していた法人アカウントのワークフロー、エージェントごとの対応スタイルで変わる提供品質、そしてより明確な順序と可視性が必要だった社内承認のチェックポイントです。
チェックポイントが常に同じ順序で進み、状況が見えていれば、リクエストがどこにあるかを誰も尋ねる必要がなく、承認前に何かが確定することもありません。Insperia は成果の一つとして、より良い承認フローを挙げています。
いいえ。Insperia は成果を業務上の言葉で説明しています。より一貫した提供、より明確なアカウント対応、より良い承認フローです。このページでは、お客様が公表していない数字は追加していません。
プロジェクトは PHP と MySQL を使用し、他のシステムとの接続には REST API を使っています。PHPTRAVELS はセルフホスト型で、ソースコードは商用ライセンスのもとで提供されるため、企業は自社のルールに合わせてワークフローを調整できます。
はい。まずデモでアカウント、エージェントの手順、承認を確認し、その後料金ページで一括払いのプランを比較してください。貴社固有のワークフロー変更は、決定前にチームと範囲を詰めることができます。
