協業相談と発注相談を分ける受付ページ｜提案の種類と検討段階に合う入力設計

見積依頼のフォームに、販売代理の打診や共同開発の提案が届く。営業担当が内容を読み直して別の部署へ転送し、提案者には発注案件と同じ追加資料を求めてしまう。法人向けサイトでは、問い合わせを一つに集めた結果、相談の目的が受付時点で分からなくなることがあります。

受付ページを整えるなら、まず「自社の商品・サービスを依頼したい人」と「自社と一緒に仕事を進めたい人」が、入口の説明で自分の用件を見つけられるようにします。そのうえで、協業の形態、検討段階、初回に必要な情報、通知先を一組にして決めます。

この記事は、法人の新規取引を増やしたい営業責任者とWeb担当者に向けた、受付ページの設計案です。提携先を選ぶ基準や契約内容は事業者が確認し、制作側はその受付方針を、ページの言葉と入力項目へ反映します。

入口の名前で、依頼と提案の向きを伝える

「法人のお客様」「パートナーの方」という二つの入口だけでは、新しく取引したい企業がどちらを選ぶか迷います。将来パートナーになりたい企業も、いまは商品を買いたい企業も、法人であることは同じだからです。会社の属性より、今回何を相談したいのかが分かる名前を考えます。

たとえば「商品・サービスの利用、見積りのご相談」と「販売連携・共同開発などのご提案」を並べる構成が考えられます。前者は自社へ仕事を依頼する入口、後者は自社と取り組みたいことを提案する入口です。実際に共同開発を受け付けていない会社なら、その言葉を例示に含めないようにします。

クロス・コミュニケーションの公開フォームでは、サービスに関する問い合わせと協業に関する問い合わせが分かれ、協業側には分野の選択と提案内容の欄があります。ジオコードの協業・パートナーシップ等のページでも、サービスに関する問い合わせには別のフォームを案内しています。自社の受付を考える際に参考になる、入口と用件の対応例です。クロス・コミュニケーションの協業窓口・ジオコードの協業等の窓口

入口を分けることと、フォームを二つのシステムで作ることは別です。一つのフォームで用件に応じて項目を変える方法も、別ページへ進ませる方法もあります。どちらを採るかは、確認する担当と必要な項目、運用できる仕組みに合わせて決めます。先に二つ作ってから、違いを考える必要はありません。

「協業」を、受け付ける提案の例で説明する

協業という言葉だけでは、販売代理、共同提案、技術連携、共同開発など、想定する関係が広すぎます。自社が現在受け付ける相談を営業や事業開発の担当者へ確認し、入口の近くに短い例を添えます。「当社の商品を販売したい」「自社の技術と組み合わせた企画を相談したい」など、相手が説明できる行動に置き換えると選びやすくなります。

STANDAGEの協業窓口は、共同事業、パートナーシップ、販売代理店・業務提携などを例として示しています。同じ掲載内容を自社へ転用するのではなく、広い言葉を具体的な相談例へ分けている点を参考にします。返信に関する条件も載っていますが、その条件は同社のものであり、自社の対応方針は担当者が決める必要があります。STANDAGEの協業窓口

「当社へ商品やサービスを売り込みたい」という提案を、協業と同じ窓口で受けるかも確認します。自社商品の販売を手伝いたい提案と、自社へ別の商品を販売したい提案は、文章では似ていても、確認する担当や資料が異なります。相手を責める案内ではなく、それぞれの用件を受け付ける場所を明確にすることが目的です。

すべての提案を受けない場合は、対象を広く見せる見出しを置いたまま、送信後にだけ対象外と伝える構成を避けます。受け付ける範囲や別の窓口を、入力前に案内します。受付範囲が未決定なら、Web担当者が独断で排除するのではなく、事業側へ確認する項目として残しましょう。

形態と検討段階を分けて、必要な情報を決める

ここからは、自社商品の販売連携と共同開発の提案を受け付ける、架空の企業を例にします。問い合わせを分類する目的は、提携の成否を自動判定することではありません。初回に何を読めばよいかと、誰が確認するかを、受付ページの設計へつなぐためです。

相談の形態	検討段階	初回に求める情報の例	最初に確認する担当の例
商品・サービスの発注相談	依頼条件を検討中	用途、依頼したい範囲、分かる条件	対象サービスの営業
商品・サービスの見積依頼	条件の一部が具体化	対象、数量等の条件、希望時期	見積りを担当する営業
販売連携の提案	具体的な案件は未定	扱いたい商品、得意な販売先、提案の概要	販売連携の担当
共同提案の相談	顧客の課題を把握	公開可能な課題、双方に想定する役割	関連事業の担当
共同開発の打診	アイデアを検討中	解決したいこと、提供できる技術、未定事項	事業開発の担当

この表は設計例です。実際の部署名や必要項目は、自社の担当者に合わせて変更します。会社名、担当者名、連絡先などの共通項目に加えて、相談を読み始めるために何が必要かを考えます。初回から会社案内、詳細仕様、事業計画をすべて必須にするという意味ではありません。

「販売連携」は形態、「案件は未定」は検討段階です。これらを一つの選択肢へ混ぜると、「共同開発だが案件は未定」のような人が選べなくなります。必要なら別々の質問にし、形態は相談先、段階は追加で求める情報を決める材料として使います。

一方で、選択肢を細かく増やすほどよいわけではありません。販売連携と共同提案を同じ担当が同じ情報で受けるなら、最初はまとめることもできます。担当や入力項目が変わらない区分を増やす前に、その選択が画面や受付後の扱いをどう変えるのかを確認します。

案件が決まっていない提案にも、書ける入口を用意する

協業の可能性を探っている人に、見積依頼と同じ「発注数量」「納期」「確定予算」を必須にすると、まだ答えられない項目が並びます。入力を埋めるための仮の数字が届いても、提案の理解には役立ちません。初回に決まっている必要があることと、相談の中で確認することを分けます。

案件未定の販売連携なら、どの商品に関心があるか、どのような顧客と接点があるか、何を話し合いたいかを短く書ける形が考えられます。共同開発なら、公開できる課題の概要と、自社が提供できる技術や経験から説明できるようにします。受け付ける側が判断に使わない情報は、念のためという理由だけで必須にしません。

記入欄の説明も「詳しく書いてください」だけにせず、「どの商品に関心があり、どのような販売先を想定しているか」など、その欄で知りたいことを示します。記入例を置く場合は、架空の説明例だと分かる内容にし、実在する顧客名や未公表案件の情報を入力するよう誘導しないようにします。

どちらの入口か判断できない人には、用件の概要を書いて確認を依頼できる場所を用意します。単に「その他」へ集める場合も、その内容を誰が読むかを決めます。後から種別を変えて引き継ぐ際に、提案者へ最初から入力し直してもらう必要がないかも確認します。自動分類で決められない相談が、通知先のないまま保存されることを防ぐためです。

資料の提出は、初回の要約と分けて案内する

協業の提案では、技術資料や顧客案件の詳細を持っている相手もいます。しかし、受付フォームの時点で、すべての資料を送ってもらう必要があるとは限りません。初回は公開可能な概要を受け、その後に必要な資料と送付方法を担当者が案内する構成も考えられます。

添付欄を設ける場合は、用途、任意か必須か、対応形式、容量の上限を入力前に示します。送付に適さない情報の扱いは、社内の情報管理や契約を確認する担当者と相談して、掲載できる案内へ整えます。Web制作側が「送信すれば秘密保持が成立する」などの条件を作ってはいけません。

資料を別の方法で受け取るなら、元の相談と照合する方法も決めます。同じ会社から複数の提案が来る場合に、会社名だけではどの相談の続きか分からないことがあります。受付番号や提案名など、導入している仕組みで照合できる情報を案内へ反映します。メールで送るのか、専用の共有先を使うのかも、実際の受領体制に合わせます。

詳細な実証計画や成果の見せ方は、受付フォーム一枚へ詰め込まず、別の説明として整えます。実証相手の募集内容を作る場合は、関連する実証事業ページの設計を参照してください。本記事の受付設計は、提案を最初に受け取る際の情報と案内を対象にしています。

完了画面と通知で、何を受け付けたかを残す

協業提案を送った直後に「ご注文ありがとうございます」と表示されたり、通知が通常の受注担当へだけ届いたりすれば、入口を分けた意味が薄れます。画面の選択肢だけでなく、受付内容の確認、完了画面、提案者への控え、社内通知まで、同じ相談種別が残るようにします。

完了画面では「販売連携のご提案を受け付けました」など、受け取った内容の種類を示せます。その先の確認方法や連絡方針は、自社が実際に行える範囲で書きます。提案の受領と、提携の承認や打ち合わせ日程の確定を同じ意味にしないことが大切です。回答の期限を約束できない場合、他社の表示から日数を借りて入れないようにします。

社内通知には、相談種別、検討段階、提案の概要が最初に分かる並びを用意します。フォームで聞いた項目が、通知では一つの長い自由文に埋もれていないかも確認します。販売連携と共同開発を別の担当へ通知するなら、選択肢と通知先の対応表を制作資料に残します。部署名を画面に出す必要がなくても、内部で対応が追えることは必要です。

担当が変わる際は、フォーム本体だけでなく通知先の設定も更新します。公開前の試験では、発注相談、案件未定の販売連携、共同開発の打診、分類が分からない相談を例に、決めた確認先へ届くかを試します。実際の窓口へ架空の提案を送るのではなく、事業者が認めたテスト環境と方法を使います。

相談の混在を、改修する項目へ置き換える

改修前には、過去の問い合わせから、追加説明や転送が必要になった場面を整理します。個々の提案の機密情報を制作会社へ渡す必要はありません。「販売したい」が自社商品を扱いたい意味なのか、自社へ別の商品を売りたい意味なのか判別できなかった、といった受付上の困り方を共有します。

その場面を、入口名の変更、相談例の追加、検討段階の選択、必須項目の見直し、通知先の変更へ対応させます。「協業フォームを追加する」という依頼だけで終えず、何が読み取れず、どの画面で補うのかを説明できると、改修範囲を決めやすくなります。

公開後は、相談種別を訂正した件数、担当への転送が必要だった件数、初回に追加で尋ねた内容などを、確認できる範囲で記録します。問い合わせ総数が増えたことだけを、提携が成立した成果とみなさないようにします。案件未定の相談を受け付ける方針なら、すぐ見積りにならなかったことだけで入口を失敗と判断する必要もありません。

最初に用意するのは、自社が受け付ける提案の例、形態と検討段階の表、初回に必要な情報、確認する担当です。この四つを基に、ページの言葉と受付後の表示をそろえましょう。取引条件を事業側で確認する作業と、伝わる画面を制作する作業を分担できます。