Google AppSheetを導入した企業様は84%の業務工数の改善、年間48000分以上の業務工数の削減を実現しています。効果や導入の流れをまとめた資料をご用意しています。
AppSheetの業務改善の課題と事例が分かる!AppSheet Magic導入資料はこちら
問い合わせは、いくらの受注につながった?AppSheetでリードと案件をつなぐ方法

「問い合わせは増えている。でも、その問い合わせが最終的にいくらの受注につながったのか分からない。」
そんな状態になっていませんか。
当社で提案しているのは、最初の流入元を追うことを必須にしない管理方法です。
例えば、YouTube、検索、広告のどれが最初のきっかけだったかを完全に特定するより、把握できる入り口と、その後の営業活動をつなぐことから始めます。
問い合わせから受注までを追うには、問い合わせ時にリードIDを発行し、案件化した後も同じIDを引き継ぎます。
さらに、どのフォーム・サービス・セミナーでリードになったかを記録すれば、入り口ごとの案件化率や受注金額を確認できます。
この記事では、当社で使っている仕組みと同じ構成のAppSheetアプリ・分析ダッシュボードをもとに、その考え方をご紹介していきます。
※件数・金額はダミーデータとなり、当社各サービスの実績を示すものではありません。 また、実演で集計している金額は受注金額です。会計上の売上を追う場合は、売上計上のデータまでつなぐ必要があります。
「どこから来たか」より「どの入り口でリードになったか」を管理する
お客様の行動の一例として、YouTubeを見てサービスページを確認し、後日検索や評判の確認をしてから問い合わせる流れがあるとします。
このような動きでは、問い合わせ直前の流入元だけを見ても、最初に関心を持ったきっかけまでは分かりません。
そこで当社では、分析の軸を「どの入り口でリードになったか」に置いています。
ここでいうリードとは、問い合わせや申し込みによって、相談内容や連絡先を把握できた見込み顧客の情報です。
| 管理する情報 | 具体例 | この記事の仕組みでの扱い |
|---|---|---|
| 流入元 | YouTube、検索、広告 | 分かる範囲で補助情報として残す |
| リード獲得の入り口 | 特定のLPのフォーム、サービス申し込み、セミナー | 受注まで追うための集計軸にする |
| リードID | L-001 | 問い合わせと案件・受注をつなぐ |
「流入元を追うのをやめる」という結論は、流入元データを捨てるという意味ではありません。
流入元が不明でも、問い合わせから受注までの管理を続けられるようにする、という考え方です。
今回、例として、AI開発セミナー・AMC・AppSheet Magic・SaaS載せ替えの4つを獲得経路として扱ったとします。
これらは検索や広告といった媒体名ではなく、リードが発生したサービスや申し込みの入り口です。
なお、入り口を識別するには、フォームごとに識別情報を保存する、登録時に選択するなどの仕組みが必要です。
共通フォームに何の記録も残していなければ、後から自動で特定できるわけではありません。
問い合わせ・案件・受注をリードIDでつなぐ

問い合わせ一覧と案件一覧が別々に存在していても、同じリードIDを持っていれば、どの問い合わせがどの案件に進んだかを確認できます。
次の流れで説明していきます。
- 問い合わせが発生したら、リードIDを発行する(例:L-001)。
- 案件化したときに、その案件へ「L-001」を引き継ぐ。
- 受注した後も、元のリードとのつながりを保つ。
- リードに記録された獲得経路ごとに、案件化・受注の結果を集計する。
氏名や会社名だけで照合するより、変わらない識別子を使ってつなぐ方が管理しやすくなります。
案件側にリードIDを残しておけば、受注後に「この案件はどの入り口で獲得したリードから生まれたのか」をたどれます。
AppSheetでテーブルを分ける場合の考え方
リード情報から案件登録へ進む際、裏側のリードIDがそのまま引き継がれていきます。
実装を補足すると、AppSheetには、別テーブルの行との関係を持たせるRef型の列があります。
参照列には参照先のキー値が保存されるため、リードと案件を関連づける設計に使えます。Google公式のテーブル間参照の説明で仕様を確認できます。
リードIDは、案件を識別するための案件IDとは役割が異なります。
1つのリードから複数案件が生まれる運用では、案件ごとに案件IDを持たせ、元のリードIDを参照させる設計が考えられます。(※これは設計上の補足です。)
AppSheetの実演で見る、リード登録から受注まで
1. リードを登録し、獲得経路を記録する


リード登録画面には、発生日、名前、メールアドレス、会社名、電話番号、相談内容などの項目があります。
その中で当社が重視しているのが、どの入り口でリードになったかを管理する項目です。
例えば、『AppSheet Magic』を選ぶと、獲得経路と獲得内容、媒体がデータとして入ります。
具体的には「AppSheet Magicから直接申し込み」「媒体はLP」といった情報です。
入り口を選択肢としてそろえておけば、後から経路別に集計しやすくなります。
2. リード情報を引き継いで案件化する


リードの詳細画面から「案件登録」を押すと、案件発生日などを確認し、商談情報を登録できます。
このとき、リードIDと登録済みの情報が引き継がれます。
問い合わせと案件をつなぐために大切なのは、この引き継ぎを日常の登録操作に組み込むことです。
担当者が案件を作るたびに、元の問い合わせを探して手作業で結びつける運用では、記録漏れが起きやすくなります。
3. 商談の進捗・見積もり・受注確度を残す


案件化した後は、問い合わせ受付、面談、打ち合わせ、見積もり提出といった進捗を記録します。
見積もり金額と受注確度も営業データとして管理しています。
例えば、受注確度をA=80%、B=50%、C=10%として、提案金額に対する見込みを管理することが可能です。これは自社の営業活動に合わせて設計できます。
受注確度を掛けた見込み金額は、確定した受注金額とは分けて扱います。
4. 受注・失注の結果と理由を記録する


受注したら、案件のステータスを変更し、受注金額、受注・失注日、理由を残します。
受注理由を残しておくことで、後からAIで分析したり、今後の提案に生かしたすることが可能になります。
結果の件数だけでなく、なぜ選ばれたのかを振り返れる記録があると、次の改善につながります。
実務上の補足として、理由には顧客から確認できた内容と、担当者の推測を区別して残すと、分析時に混同しにくくなります。
案件化率が高くても、受注につながるとは限らない
ダッシュボードでは、獲得経路ごとに下記を確認しています。
獲得リード数
案件化リード数
案件転換率
受注件数
受注金額
受注率
特に分けて見たいのが、案件化したリードに対する受注率と、獲得したリード全体に対する受注率です。
以下はデモデータを整理したものです。1リードにつき1案件・1受注として読める例になっています。
| 指標 | AppSheet Magic | SaaS載せ替え |
|---|---|---|
| 獲得リード数 | 12件 | 12件 |
| 案件化リード数 | 12件 | 2件 |
| 案件化率 | 100% | 16.7% |
| 受注件数 | 2件 | 2件 |
| 案件化リードに対する受注率 | 16.7% | 100% |
| 獲得リード全体に対する受注率 | 16.7% | 16.7% |
計算は下記の通りです。
案件化率=案件化リード数÷獲得リード数
案件化リードに対する受注率=受注件数÷案件化リード数
獲得リード全体に対する受注率=受注件数÷獲得リード数
AppSheet Magicは、獲得した12件がすべて案件になっています。しかし、受注は2件です。
この数字から、案件化までの手順や、その後の提案内容を確認する必要がみえてきます。
一方、SaaS載せ替えは、12件のうち案件になったのは2件ですが、その2件が受注しています。
なぜ案件化したリードは受注につながったのかを考えることで、次に確認すべき点が見えてきます。
ただし、この例では両方とも受注は2件で、獲得リード全体に対する受注率も同じです。
案件化後の受注率だけで、どちらが優れた経路かは決められません。受注金額や商談状況も合わせて判断します。
ファネルの各段階を図やレポートで確認したい場合は、Looker StudioとAppSheetを使ったファネル分析も参考になります。
集計するときは、分母と対象期間をそろえる
ここからは運用上の補足です。複数案件を持つリードがある場合、受注案件数をリード数で割ると、リードの受注率とは異なる指標になります。
「受注したリードの割合」を見たいなら、受注に至ったリードIDを重複なく数えます。
また、今月獲得したリードと、過去のリードから今月受注した案件を混ぜると、転換率を読み違える原因になります。獲得月ごとのリードの結果を見るのか、受注月ごとの金額を見るのかを決めておきます。
まだ商談中の案件が多い経路は、結果が確定していません。
2件中2件の受注も、今後同じ率で受注できるという証拠ではありません。
件数、経過期間、対応中の案件を一緒に確認してください。分母が0件の場合は、率を0%と断定せず「対象なし」などで表示します。
AIダッシュボードを作る前に、判断したいことを決める
分析ダッシュボードはAIを使って作っていきます。
当社が挙げるポイントは、「いい感じで作って」と頼むのではなく、自分たちが知りたいゴールを伝え、その判断に必要なデータを渡すことです。
今回なら、判断したいのは「どの入り口で獲得した問い合わせが、いくらの受注につながったか」です。
そのために、次の情報をつなぎます。
| データ | 判断に使う情報 |
|---|---|
| リード | リードID、発生日、獲得経路 |
| 案件 | 案件ID、元のリードID、案件発生日、進捗 |
| 営業見込み | 見積もり金額、受注確度 |
| 受注・失注 | 結果、確定金額、結果の日付、理由 |
リードIDが欠けていれば、見た目の整ったダッシュボードができても、元の問い合わせと受注はつながりません。
AIへの依頼は、例えば「獲得経路別に、リード数、案件化したリード数、受注したリード数、受注金額を表示したい。案件化率と受注率は分母を明記し、対応中の案件も確認したい」と具体化できます。
よくある質問
流入元が分からない問い合わせでも分析できますか?
リードが発生した入り口とリードIDが記録され、案件・受注までつながっていれば、入り口別の受注結果を分析できます。
ただし、最初の認知にYouTubeや広告がどれだけ貢献したかは、この仕組みだけでは分かりません。
この仕組みで売上まで分かりますか?
今回ご紹介したのは問い合わせから受注件数・受注金額までのつながりになります。
会計上の売上や入金まで追いたい場合は、案件IDなどを使って売上計上・入金の記録も関連づけます。
受注、売上、入金はそれぞれ別の指標として管理します。
リードIDを入れれば、受注率は自動で正しくなりますか?
リードIDはデータをつなぐ土台です。
正しく比較するには、何を案件化と呼ぶか、リード数と案件数をどう数えるか、どの期間を集計するかもそろえる必要があります。
AppSheetとAIは、このアプリではどう使い分けていますか?
AppSheetでリード登録、案件管理、受注・失注の記録を行い、そのデータを分析するダッシュボードをAIで作っています。
データを記録する仕組みと、判断するために見せる画面を組み合わせた実例です。
まずは、問い合わせと案件がつながっているかを確認しましょう
問い合わせの成果が見えないときは、今ある問い合わせ一覧と案件一覧を見比べてください。
案件から元の問い合わせをたどれるか、リードが生まれた入り口を確認できるか、受注金額までつながっているか。この3点を確かめると、整えるべき箇所が見えてきます。
当社では、業務基盤の構築をサポートしています。
データが別々でつなぎ方が分からない場合や、何を判断できるようにするかから整理したい場合は、AI・AppSheetによる業務アプリ開発の相談をご利用ください。
出典・補足
- AppSheetの参照機能:Google公式ヘルプ「テーブル間の参照」(2026年10月7日確認)。
- 動画内の数字はすべてデモデータです。複数案件の数え方、集計期間、売上・入金との区別、理由の記録方法は、誤読を防ぐための編集上の補足です。









