複数種類の依頼を一つの窓口へ
問い合わせ、取材、証明書、資料依頼を入口で分け、担当部署へ渡す例です。
製造業の依頼受付ポータルを見る
問い合わせフォームは、送信できれば完成ではありません。件数が少なく、受信メールから担当者がすぐ返信できるなら、フォーム作成ツールで十分な場合が多いでしょう。受付判定、担当者、権限、履歴が必要な場合も、まず候補のフォームツールやCRMの設定・標準連携で対応できるかを確認します。必要な業務連携まで満たせない場合に、設定見直し、CRM追加、別ツールへの変更、部分開発や個別開発を比較します。
このページでは、フォーム作成ツール(SaaS)と自社開発フォームを、費用、入力負担、受付後の運用、外部連携、セキュリティ、移行の順に比較します。
先に結論:フォームの作り方は受付後の業務で決まります
項目と通知先が単純で、受信後はメール対応で完結する場合。
フォームはツールを使い、案件化・担当割り当てはCRMなどで行う場合。
候補ツールやCRMの設定・標準連携では、必要な受付判定、権限、履歴、業務連携を満たせない場合。
送信自体に問題がなくても、受付後の担当や対応状況が見えないと返信が遅れます。まず、フォームの機能不足と、受付後の運用上の問題を分けて確認します。
候補のフォームツールやCRMに、担当者管理、権限、履歴、条件分岐などの機能がある場合は、設定変更やCRM追加で対応できることがあります。個別開発は、標準機能・標準連携で必要な受付判定、権限、履歴、業務連携を満たせない場合に比較します。
比較表には、作成期間と費用だけでなく、受付後の担当管理、連携、個人情報、公開後の保守も含めています。現在困っている工程に関係する行から確認してください。
| 観点 | フォーム作成ツール(SaaS) | カスタムフォーム(自社仕様開発) |
|---|---|---|
| 立ち上げ速度 | 早い。当日から使い始められることも多い | 要件確認・設計・テストが必要で、利用開始までに一定の期間がかかる |
| 入力画面の改善 | テンプレートや入力支援、エラー表示などの基本機能が用意されていることが多い | 導線、入力補助、エラー表示などを、自社の利用者や業務内容に合わせて設計できる |
| 受付後の運用 | サービスが提供する通知・管理機能の範囲で運用する。担当割り当てや詳細な履歴管理には、上位機能や別サービスが必要な場合がある | 担当者、対応状況、履歴、回答期限などを、自社用の管理画面にまとめて設計できる |
| 連携(API/CSV) | APIやCSVが提供されていれば連携できるが、利用できる項目や処理はサービスの仕様に限られる | 既存のCRM・SFA・基幹システム・MAなどに合わせて連携方法を設計できる。連携先の仕様変更時には改修が必要 |
| スパム・不正対策 | reCAPTCHAなどが標準搭載されていることが多い。設定できる条件や確認できるログはサービスごとに異なる | レート制限、IPアドレス・ユーザーエージェントの確認、拒否リスト、重複判定などを状況に合わせて実装できる。継続的な保守も必要 |
| 個人情報・監査対応 | データはサービス提供者の管理環境に保存されるのが一般的。委託先、保存期間、ログ、権限などの確認が必要 | 保存先、保存期間、ログ、権限を自社の方針に合わせて設計できる一方、運用と保守の責任も自社側に生じる |
| 総コスト | 初期費用を抑えやすいが、利用件数、上位プラン、追加連携によって月額費用が増える場合がある | 初期開発費と保守費が必要。日々の作業時間や既存サービスの利用料を含めて総額を比較する必要がある |
問い合わせフォームに関するご相談では、入力項目や自動返信文の調整よりも、 「送信後の対応状況を管理できない」という課題が多く見られます。 受付後の担当者、進捗、回答期限が明確になると、同じ問い合わせ件数でも対応にかかる負担は変わります。
フォームツールでも、通知先の分岐やラベル付けなどで対応できる場合があります。 ただし、担当者の割り当て、対応履歴、重複問い合わせの確認、社内向け一覧画面まで必要になると、標準機能だけでは対応できないことがあります。 これらの機能が必要な場合は、フォーム単体ではなく、受付から回答までを管理する小規模な業務システムとして検討した方が適切なことがあります。
画面例:内容、担当部署、状態、回答期限を同じ一覧に表示すると、受信メールを開かなくても優先して確認する案件が分かります。
状態名や分類の決め方は、問い合わせ管理向けのステータス・タグ設計例で具体的に紹介しています。
問い合わせ数を増やしたい場合は、受付後の管理とは分けて、入力開始から送信完了までを確認します。ツールか自社開発かにかかわらず、項目を増やすほど回答の判断材料は増えますが、利用者の負担も増えます。
回答時期、必要な情報、所要時間、添付できる形式を入力前に案内します。
初回対応に不要な質問は後へ回し、エラーは該当項目の近くに具体的に表示します。
受付番号、返信の目安、追加資料の送り方、緊急時の連絡先を完了画面とメールで案内します。
| 指標 | 分かること | 次に確認する点 |
|---|---|---|
| 表示回数 | フォームが表示された回数 | 流入ページ、ボタン文言、同一利用者による複数表示 |
| 入力開始率 | 入力を始めた利用者数 ÷ フォームを表示した利用者数 | 項目数、説明、個人情報の扱い、スマートフォン表示 |
| 送信完了率 | 送信した利用者数 ÷ 入力を始めた利用者数 | エラー発生箇所、入力時間、添付容量、確認画面 |
| 有効問い合わせ率 | 営業・対応につながる内容の割合 | 項目の選択肢、対象条件の説明、スパム判定 |
比較時は、集計期間、利用者の数え方、重複送信やスパムを除外する条件を固定します。表示回数と利用者数は同じ指標ではありません。
どの項目をフォームで聞き、どれを初回連絡へ回すかは、BtoBフォームの入力項目チューニング例で、送信後の営業確認画面とあわせて確認できます。
「CRMに入れたい」「MAに渡したい」「スプレッドシートに残したい」といった要望はよくあります。 ただし、連携方式だけでなく、その後の運用も確認する必要があります。誰が、いつ、どの段階まで対応するのかが決まっていなければ、どの方式を選んでも確認作業が残ります。
| 方式 | 利点 | 注意点 | 向いている状況 |
|---|---|---|---|
| メール運用 | 最小構成で始められる | 対応履歴・担当者・重複問い合わせの管理が難しく、重要な内容を見落とす可能性がある | 件数が少なく、単発返信で終わる |
| CSV連携 | 多くのツールが対応しており、導入のハードルが低い | CSVの出力・取込作業が残る。担当者変更時には作業手順の引き継ぎが必要 | 週次・月次のバッチで十分で、即時性が不要 |
| API連携 | 対応するAPIやWebhookで定型処理を自動化できる | 反映頻度・遅延・利用制限は、サービスと連携方式により異なる。仕様変更・レート制限・障害時の再送も確認する | すぐ案件化したい/返信の目安時間が決まっている |
| 社内管理画面+システム連携 | 社内では管理画面で対応状況を確認し、バックグラウンドでCRMなどへ連携できる | 初期設計と開発が必要。要件が定まれば、担当者や履歴を共通の画面で管理できる | 担当割り・履歴・複数部署の関与がある |
API連携では、正常時の処理だけでなく、連携に失敗した場合の対応も必要です。 たとえば、CRM側の一時的な障害、通信のタイムアウト、同一問い合わせの重複送信などが考えられます。 受付側に未送信データの再送、重複判定、エラー記録の仕組みがなければ、担当者による確認や修正が必要になります。
問い合わせフォームは、インターネット上に公開される受付窓口です。対策が不十分な場合、スパム投稿だけでなく、 短時間の大量送信や自動返信機能を悪用したメール送信などにより、対応件数や送信費用が増えることがあります。 過度に複雑な対策を導入するのではなく、必要な対策を決め、継続して確認することが重要です。
フォームツールには基本的なセキュリティ対策が用意されていることが多い一方、例外処理、ログの保存内容、データの保存期間、権限設定はサービスの仕様によって異なります。 個人情報や取引情報を扱う場合は、保存先、保存期間、閲覧権限、削除方法を確認する必要があります。カスタム開発ではこれらを自社の方針に合わせて設計できますが、脆弱性対策、ログ監視、バックアップなどを継続する保守体制も必要です。
「まずはフォームツールで開始し、問い合わせ件数や運用要件が増えた段階でカスタム開発へ移行する」という方法もあります。 移行時には、入力項目、過去履歴、自動返信、計測方法などの確認が必要です。事前に移行条件を決めておくと、公開直前に多数の修正が必要になる事態を避けられます。
| 確認項目 | 発生する問題 | 事前に決めておくこと |
|---|---|---|
| 項目設計の不一致 | ツール側の項目名やデータ形式をそのまま移せず、変換作業が必要になる | 移行後に必要な項目とデータ形式を決め、受付時点の項目を確認する |
| 履歴の扱い | 過去の問い合わせ履歴を新しい管理画面から参照できない | 検索に必要な項目(送信者・日時・問い合わせ内容など)を先に決める |
| 自動返信の重複・不整合 | 旧フォームと新フォームの送信処理が重なり、異なる文面や二重の自動返信が送られる | 役割を分ける(受付確認/担当返信/完了通知) |
| スパム増加 | 公開直後にスパム投稿が増え、必要な問い合わせの確認に時間がかかる | 公開前にレート制限・重複判定・CAPTCHAを実装しておく |
| 計測の断絶 | コンバージョン(CV)計測が途切れ、移行前後の比較ができなくなる | 送信完了、入力エラー、離脱など、継続して計測する指標を移行前に決める |
移行では、入力画面だけを差し替えるのではなく、 案件、対応履歴、担当者、回答期限をどの単位で管理するかを先に決めることが重要です。 管理単位が決まると、既存ツールに残す機能と、カスタム開発へ移す機能を判断できます。
フォーム単体ではなく、受付後の対応まで含めて確認します。次の項目を順に確認すれば、設定変更で対応できる部分と、追加の仕組みが必要な部分を分けやすくなります。
カスタム開発を検討するときは、入力フォームだけでなく、送信後に担当者が使う一覧と詳細画面まで確認すると必要な範囲が分かります。以下は、製造業や葬祭業など、さまざまな場面で使われる受付フォームと管理画面の活用例です。リンク先は業種別ページの先頭ですが、各ページ内の画面モックでは、受付内容が社内でどのように使われるかを確認できます。
問い合わせ、取材、証明書、資料依頼を入口で分け、担当部署へ渡す例です。
製造業の依頼受付ポータルを見る利用者には必要な質問だけを出し、社内には回答の要点をまとめて表示する例です。
葬祭業の事前ヒアリング画面を見る営業と技術部門が関わる相談を、回答期限と履歴付きで扱う例です。
製造業の技術相談管理を見る個人情報の保存先、広告表示、送信件数、データ出力、サービス終了時の移行方法を確認できれば選択肢になります。業務利用では、権限、ログ、サポート、利用規約も確認します。
少なければ必ず良いわけではありません。初回対応の可否を判断する項目は残し、担当者が後から毎回聞いている項目と、利用者が答えにくい項目を分けて見直します。
候補ツールにAPI、Webhook、CSV出力などがあれば検討できます。項目対応だけでなく、重複時の扱い、送信失敗時の再送、連携ログも決めます。
候補のフォームツールやCRMの設定・標準連携では、必要な受付判定、権限、履歴、業務連携を満たせない場合に個別開発を検討します。設定見直し、CRM追加、別ツールへの変更、部分開発も同じ条件で比較します。
「フォームはあるのに対応が追いつかない」「部署をまたぐと担当が曖昧になる」「重複やスパムに埋もれてしまう」など、現在の問い合わせ受付から回答までの流れを確認し、入力画面だけでなく、担当者の割り当て、対応状況、履歴管理を含めた改善をご提案します。 フォームツールの設定変更で対応できる部分と、カスタム開発が適している部分を確認したうえで、必要な方法をご案内します。