多数の企業が参加するBtoB商談イベントの運営側から、参加企業へのサービス申込がメール・FAX・郵送に分散している状態を解消したいというご相談を受け、参加企業専用の会員サイトを構築しました。各社に発行したIDでログインすると、会議室の貸切や備品レンタルといったサービスを申込フォームから依頼でき、受付担当者には申込と同時にメールで通知が届きます。要件を一度に固めるのではなく、運営側の負担が大きい申込種別から順に画面を追加していく進め方を取りました。
- 企業単位のIDにした理由
- 個人ごとのアカウントではなく参加企業ごとのIDにしました。イベント運営で追いたいのは「どの企業からの依頼か」であり、担当者の異動や交代でアカウントが使えなくなる事態も避けられます。個人を識別する必要が出てから分ければ足り、最初から個人単位にすると発行と回収の手間が申込件数に比例して増えます。
- 受付側が「見に行かない」流れにする
- 申込の送信と同時に受付担当者へメールで通知します。管理画面を用意しただけでは、担当者が定期的に確認しに行く運用になり、FAXや郵送を確認していた頃と取りこぼしのリスクが変わりません。窓口を集約する価値は、届いたことが受付側に伝わって初めて生まれます。
- 重複申込を運営が拾えるようにした背景
- 同じ企業から重複して届いた申込を管理画面で色分けして表示します。メールやFAXに分散していた頃は、同じ依頼が二重に届いても誰も気づけませんでした。窓口を一か所にまとめた効果は集計だけでなく、これまで見えなかった異常が検知できるようになる点にもあります。
- 全種別を作らず、負担の大きい順に公開
- 申込種別をすべて同時に作らず、運営側の処理の手間が大きいものから順に画面を追加しました。要件を一度に固めると、実際には年に数件しか来ない種別にも同じ開発費がかかります。使いながら次の優先順位を決める進め方にすることで、初期の投資を効果の大きい範囲に集中させています。
- 会議室と備品から窓口を開いた理由
- 会議室の貸切や備品レンタルという、申込から手配までの工数が大きい種別を先に画面にしました。件数だけで選ぶと、届く量は多くても受付側が数十秒で処理できる種別が上位に来ます。システム化で回収できるのは人手のかかる工程であり、優先順位は件数と処理の手間の両方で決める必要があります。
- 申込データが次の企画の材料になる
- 紙やメールで届いていた依頼が構造化されたデータとして蓄積されるため、種別ごとの集計や企業単位の一覧化が管理画面の操作だけで完結します。業務の効率化にとどまらず、どのサービスに需要が集中しているかを次回のイベント企画に持ち込めます。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
デジタル化の範囲を投資対効果で線引きする
業務の申込窓口をWebに集約する際、すべての申込種別を初期リリースに含めると、開発費と期間が膨らむ一方で、使われない画面も生まれます。まず申込の種類ごとに件数の多さと処理の手間を並べ、上位の数種類だけを最初の対象にする方法があります。残りは既存の手段で受け付け続けても事業は回るため、初期投資を抑えつつ、システム化の効果を早い段階で確認できます。効果が見えた後に追加投資を判断する方が、経営としても説明しやすい進め方です。
蓄積した申込データを次のサービス設計に使う
申込がデータとして揃うと、どのサービスに需要が集中し、どの企業が繰り返し利用しているかが見えるようになります。利用の多いサービスは事前予約制や有料オプションに発展させ、利用の少ないものは統廃合を検討する、といった判断が可能になります。単なる業務効率化の道具として終わらせず、参加企業の行動データからイベント自体の商品設計を見直す材料にするという視点を持つと、システム投資の回収先が広がります。
紙やFAXをいつ止めるかを先に決めておく
既存の受付手段を残したまま新しい窓口を開く進め方は安全ですが、止める条件を決めずに始めると両方を運用し続ける期間が延び、かえって受付側の負担が増えます。「対象の申込のうち一定割合がWeb経由になった時点で旧手段を締め切る」といった条件を、開発の着手前に運営側と合意しておく方法があります。あわせて、Webを使えない参加者が残る場合の例外の受け口を一つだけ決めておくと、締め切りの判断が現場の情に流されにくくなります。移行の完了もプロジェクトの成果物に含めて計画するのが要点です。
使った技術・扱った領域
- 会員ポータル
- 申込フォーム
- リアルタイム通知
関連するサービス
関連するインサイト
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP（実用最小限の製品）の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- シード期のMVPはどこまで作るかシード期の制約のもとで、管理画面・決済・権限・通知・設定をどこまで省けるかを機能ごとに判断します。省いてよいもの、省くと検証が壊れるもの、後で作り直す前提で割り切れるものを線引きします。
- プロダクトのKPI設計とダッシュボード — 見るべき指標を絞る北極星指標を起点に先行指標・遅行指標へ分解し、PMF前後のフェーズに応じて見るKPIを絞る考え方と、意思決定に使えるダッシュボードの設計、計測の信頼性、やりがちな失敗を整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開