1. 最初に「サイトを見た人にしてほしいこと」を書く
会社の概要を確かめてもらう、見積りを依頼してもらう、希望日時を送ってもらう、注文を確定してもらう。この違いで、必要な仕組みも運用も変わります。「会社案内サイト一式」「予約機能付き」だけで発注範囲を決めず、利用者の行動を一文にします。
J-Net21の発注Q&Aは、PR・受発注・ネット販売などの目的によって構成が変わると説明し、担当者と自社で担う範囲を先に決めるよう案内しています。HPの役割のQ&Aも、伝える相手と必要な情報を整理し、運用費や継続更新を考えることを挙げています。
これを発注時の判断に使うため、以下では「掲載」「受付」「確定と業務連携」に分けます。この分け方と表はhirostaの提案で、公的資料が同じ分類を指定しているわけではありません。
2. 会社案内・受付・予約や受注の確定を分ける
会社案内にも問い合わせフォームを付けられます。ただし、フォームがあることと、予約や注文が確定することは別です。
| 作る範囲 | お客様ができること | 発注時に決めること |
|---|---|---|
| 情報の掲載 | 会社・サービス・連絡先を確認する | 掲載ページ、原稿・写真の分担、更新方法と担当 |
| 希望や依頼の受付 | 問い合わせ、希望日時、見積依頼を送る | 入力項目、保存先、通知先、受付後の確認と返答、確定前の案内 |
| 予約・受注の確定と業務連携 | 空き枠や条件に沿って手続きを終える | 枠・在庫・価格の管理、確定条件、変更・取消、重複防止、社内への引き継ぎ |
電話とWebで同じ枠を扱うなら、どこを空き枠の正本にするかを決めます。注文も、見積り依頼の送信で終えるのか、価格・納期を合意して受注確定にするのかで範囲が変わります。受付画面・自動返信・管理画面の文言も、その違いに合わせます。
決済が必要なら、支払方法、失敗時の扱い、取消・返金、入金と注文の対応まで別に確認します。個別の取引条件や必要な表示は、自社の責任者が専門家・利用サービスの窓口などに確認し、制作側だけで決めないようにします。
どの範囲から始めるかの判断
- 会社と対応内容を伝えることが目的なら、掲載を中心にする。 原稿・更新担当・問い合わせ先をそろえます。
- 案件ごとに価格や日程の相談が必要なら、受付と人による確定を候補にする。 確認待ちの一覧と返答担当も必要です。
- 枠や価格の条件が整理され、管理する担当がいるなら、確定までの仕組みを比較する。 既存サービスで対応できる範囲を確認してから、足りない連携や個別開発を検討します。
手動にすれば安全とは限りません。確認できる件数を超えるなら、受付範囲や担当体制も見直します。定員のある受付の詳細は申込フォームの定員管理、作り方の選択は既存サービスと個別自動化の比較へ進んでください。
3. 見積りの前に、初回の範囲と完了条件を一枚にする
機能名を並べるだけでなく、次を同じ資料に書きます。未決定の項目には、決める人と回答期限を付けます。
- 目的と対象。 誰が何を申し込み、サイトでどこまで終えるか。
- 初回に作るもの。 ページ、入力項目、受付結果の表示、管理する一覧、通知、引き継ぎ先。
- 今回含めないもの。 決済、顧客用ログイン、既存台帳との連携など。必要になったときの追加条件も残します。
- 運用の分担。 自社の受付・確定・訂正担当、制作側の保守範囲、外部サービス側の担当。
- 納品時の完了条件。 表示だけでなく、受付・保存・確認・返答まで、頼んだ工程がつながること。
例えば「希望日時を送ると受付完了が表示され、担当者が管理一覧から確認できる。お客様には、担当者からの返答で日程が確定すると伝える」なら、受付と確定の境目が伝わります。通知が届かなくても一覧から未対応を見つけられるか、送信を繰り返したときに二重対応しないかも、制作側と確認範囲を合わせます。
収集する情報は必要な項目に絞り、誰が閲覧できるか、保管・削除を誰が行うかを決めます。顧客の依頼内容を、公開ページや誰でも見られる一覧へ載せる設計にはしません。
4. 想定シナリオ：設備保守会社が点検依頼の受付から始める
以下は架空の設備保守会社の、未実施の想定シナリオです。訪問時間は設備の種類と作業員の予定を見て決めるため、最初は予約確定をサイトに任せない案を考えます。
初回は会社概要・サービス紹介・依頼フォームを作り、お客様は設備の種類、希望日、連絡先を送ります。受付完了画面と返信には「まだ訪問日は確定していません。担当者が確認してご連絡します」と表示する設計です。返信までの目安は、責任者が対応できる条件を決めてから掲載します。
管理画面のイメージは、受付番号・受付日時・希望日・担当者・状態・次の対応を並べた一覧です。
| 状態 | 担当者がすること | 次の状態に進める条件 |
|---|---|---|
| 未確認 | 依頼内容と同じ依頼の再送がないかを見る | 担当者が引き受ける |
| 日程調整中 | 作業員と顧客に日程を確認する | 双方の合意を記録する |
| 確定 | 決まった訪問日を管理し、変更が来たら再調整する | 対応完了を担当者が確認する |
| 取消・保留 | 理由と次の確認先を残す | 再開または終了を担当者が判断する |
フォームの再送だけで新しい訪問を確定したり、返事がない依頼を自動で取消にしたりはしない扱いにします。通知が不達の場合も、一覧の受付記録と連絡先を確かめ、別の連絡手段での対応を判断します。
オンライン決済、空き枠の自動確定、既存の作業台帳への自動登録は初回の対象外とします。将来、作業時間や空き枠の管理方法がそろったら、予約確定の仕組みを追加するか見直します。その際は電話受付との共有、変更・取消、重複時の扱いを確認し直します。
AIを使うなら、利用を認めた情報から要件の下書きや確認事項を整理する補助にとどめられます。顧客情報を外部AIへ送る前には利用条件と社内の許可を確認し、AIに空き枠・価格・受注の確定を任せる前提にはしません。
5. 費用と期間は、画面・連携・運用に分けて比べる
会社案内と予約・受発注のサイトを、ページ数だけで比べないようにします。同じ見た目でも、裏側の条件や連携で作業が変わるためです。見積りは次の内訳をそろえて比較します。
- 制作と準備： ページ制作、文章・写真、入力画面、管理画面、社内の条件整理。
- 連携と確認： 既存データの整理、台帳との接続、受付から確定までの動作確認、担当者への説明。
- 公開後の運用： サーバーや利用サービスの料金、情報更新、保守、障害時の連絡、追加変更。
既存の予約・受発注サービスへリンクする案、サイト内に組み込む案、個別開発する案では、利用条件・費用・管理の分担が異なります。製品ごとの現行仕様と、必要なプランや追加費用は発注時に提供元で確認します。この記事では相場や一律の完成日数は示していません。
期間も、デザインと制作だけでなく、社内の条件決定、素材準備、連携先の確認、動作確認、運用の説明を分けます。希望の公開日があるなら、遅れたときにどこまで公開できるかを先に相談します。必要な保護や確認を省いて公開を急ぐ範囲の縮め方は避けます。
原稿・写真の準備はHP制作の素材準備をご覧ください。
6. 納品確認は、お客様側と担当者側の両方で行う
発注時の完了条件に戻って、PC・スマホの表示とリンクに加え、頼んだ機能の流れを確認します。個人情報を使わない確認環境や送信先を制作側と相談し、実際の注文・予約や顧客への通知と混ざらない方法で行います。
- お客様は、送信できたか、次に何を待つか、予約・注文が確定したかを区別できるか。
- 担当者は、受け付けた記録と未対応を見つけ、変更・取消の履歴を追えるか。
- 入力不足、重複、不達、連携失敗が起きたとき、誰が確認し、どこから対応を再開するか。
- 公開後に情報や条件を変える人と方法、保守窓口、今回の対象外が明確か。
会社案内だけなら、発注していない予約機能の確認まで広げる必要はありません。今回頼んだ範囲を確認し、残る機能と追加する条件を別に記録します。
サイトの後ろで続く転記・確認・返答の整理は問い合わせ対応の支援、業務全体の見直しはAI業務改善ガイドをご覧ください。LINEで受け取った書類から請求書を作る事例は受付後の処理を考える参考ですが、予約サイトの制作実績を示すものではありません。開発・改修の相談範囲はシステム開発の案内、支援内容と料金はサービス案内にまとめています。範囲が決まっていなくても、困りごとからお問い合わせいただけます。