フリーランス向け提案パイプラインアプリ：ドラフトから受注／失注まで

提案が抜け落ちる理由

ほとんどのフリーランスが提案を失うのは、仕事の質が悪いからではなく、提案そのものが“見えなくなる”からです。

よくある混乱は見覚えがあるはずです：ドキュメントに草稿が残り、最終版PDFは別フォルダにあり、最後のクライアントのメッセージはメールやチャットに埋もれて、唯一の「ステータス」は自分の記憶だけ。クライアント対応に忙しいと、誰に見積りを出しているか、誰にもう一度促すべきかを忘れてしまいます。

提案は次のような場所に散らばります：

• 「Proposal v7 FINAL (2)」というGoogleドキュメント
• 件名がバラバラのメールスレッド
• フォローアップ日が書かれたスマホのメモ
• 文脈のないカレンダー通知
• 自分の頭の中（手遅れになるまで）

提案が抜け落ちる単純な理由はひとつ：次にするべきことが一か所で見えないこと。10秒で「次に何をする？どのクライアント？」に答えられなければ、フォローアップは遅れます。フォローアップの遅れは、クライアントが興味を持っていても失注につながります。

それがパイプラインの役割です。少数の明確なステータスで、各提案がどこにあり次に何をすべきかを示す。提案パイプラインアプリは派手な営業ツールではなく、スコアボードでありTo‑Doリストでもあります。

期待は現実的に。予測や細かいレポート、複雑なCRMを作る必要はありません。実際の作業に合う軽いツールで、「次の一手」が明らかになることが目的です。

例：火曜にウェブリデザインの見積りを送り、金曜にフォローすると自分に言い聞かせる。でも金曜は別の仕事で手が離せず、月曜には既に確認したか忘れている。1つの見える「クライアント待ち」ステージと明確な次回フォロー日があれば、その静かな失注を防げます。

軽量な提案パイプラインがやるべきこと

提案パイプラインアプリの目的はシンプル：提案をドラフトから受注または失注まで、できるだけ手間なく動かし続けることです。もし余計な事務作業が増えるなら、使わなくなります。

設計に入る前に、数か月後でも必要な情報だけを決めておきましょう。フォローアップ、収入の予測、何が売れているかを学ぶのに役立つ最小限の情報に絞ります。

実用的な最小項目：

• クライアント（個人または会社）と連絡手段
• サービス種別（例：サイト改修、モバイルアプリ、月次SEO）
• 見積り金額（またはレンジ）と想定開始日
• 次回フォローアップ日
• 現在のステータス（Draft、Sent、Negotiation、Won、Lostなど）

「終わり」の定義も決めておきましょう。Sentのまま放置しないために、停滞したものはリマインドを起動し、回答が来たら結果を記録し、エクスポートなしで簡単なレポートが見られるのが理想です。

最初はスコープを小さく。1ユーザー、1ワークスペース、シンプルなフィールドのほうが大きなシステムより役に立ちます。今週提案を3件送るなら（例：着地ページ＋コピー2件、レテイナー1件）、次回フォロー日と結果を強制するパイプラインで、どのサービスがよく受注するか、どこで時間を失っているかがすぐに分かります。

実際のワークフローに合ったステータスを選ぶ

ステータスは、理想のプロセスではなくあなたの一日の流れを反映して初めて役に立ちます。カードを前に進めるのが手間にならない程度に数を絞りましょう。

実用的なセット例：

• Drafting（下書き）
• Ready to send（送信準備）
• Sent（送信済み）
• Follow-up due（フォローアップ期限）
• Negotiating（交渉中）
• Won（受注）
• Lost（失注）

名前は短く、次に何をするかが分かるように。ステータスを見て次の行動が分からなければ、名前を変えてください。

次に、いくつかの簡単なルールを設定して、ゾンビ状態の提案を作らないようにします。

例えば：

• クライアント、サービス種別、合計金額、納期の見込みがないとSentに移せない。
• Negotiatingはクライアントが返信し、範囲・価格・条件が実際に変わっている場合に使う。
• Wonは明確な合図が必要：署名済みの合意、入金、または書面での「はい」。

フォローアップ日はもう一つの安全装置です。すべてのステータスにリマインダーが必要なわけではありませんが、SentやFollow-up dueには必須にすると良いでしょう。Negotiatingも次のアクションが自分にあるときは必要にできます。

短いシナリオ：月曜に見積りを送り、木曜まで返事がなければFollow-up dueに出る。クライアントが「ブログを外して価格を下げて」と言えばNegotiatingに移し、次のフォローアップを翌日に設定する。これだけで勢いを保てます。

データ設計：Clients、Proposals、Services、Activity

提案パイプラインアプリはデータ次第で生きるか死ぬかが決まります。構造が緩すぎると入力を飛ばし、厳しすぎると使わなくなります。信頼できる小さなレコードセットから始め、痛みが出たら詳細を追加しましょう。

まずは4つのコアオブジェクト：Clients、Proposals、Services、Activities。

コアテーブル（と保持する内容）

最初のバージョンはシンプルに：

• Clients：名前、担当者、メール、メモ（オプションで会社規模）
• Proposals：タイトル、client_id、service_type（または services）、金額、ステータス、送信日、次回フォローアップ日、結果理由
• Services：名前（例：「Website refresh」「SEO audit」）、オプションでデフォルト価格レンジ
• Activities：proposal_id、タイプ（メモ、リマインダー、通話、メール）、タイムスタンプ、詳細

Proposalsのnext_follow_up_dateは未来の自分への保険です。outcome_reasonはWonやLostにしたときに重要で、「価格が高かった」と「タイミングが合わなかった」では対策が変わります。

1提案＝1サービスか、複数サービスか

1提案につき1つのサービス種別が最速で、パッケージ販売に向きます。複数サービスを許すとバンドルに柔軟ですが複雑さが増します。ProposalServicesのような結合テーブルが必要になり、集計も難しくなります。

妥当な妥協は、最初は1サービスで始め、実際に混合提案が多くなったら複数化することです。

Activitiesはメールを掘らずに履歴を残す軽い手段です。提案送信後に「v2送信、納期について質問あり」と短く残しておくだけで状況が一目で分かります。

画面設計：ボード、リスト、詳細、レポート

答えが明確な画面だけあれば十分です。目標はスピード：開いて、注意が必要なものが見えたら1つ更新して閉じること。

パイプラインボード（日次ビュー）

ここが日常の居場所になります。各カラムはステータス。カードには次の情報だけを載せましょう：

• クライアント名
• 提案金額（または月額想定）
• 次回フォローアップ日
• サービスタグ

カード上のクイックアクションはレイアウトより重要です。カードや小さな詳細パネルからステータス変更、フォローアップ日設定、メモ追加、Won/Lostのマークが長いフォームなしでできるべきです。

提案リスト（検索とキャッチアップ）

ボードは流れを見るのに優れますが、リストは探し物に便利です。ステータス、クライアント、サービス種別、フォローアップ期限などで絞り込めるテーブルスタイルのリストを用意しましょう。忙しい週の「キャッチアップ」ビューになります。

詳細ページ（素早く編集できることが最優先）

ProposalページとClientページの2つがあれば十分です。

Proposalページはタイムライン（メモ、ステータス変更、次回フォロー）と価値やサービス種別などの主要フィールド。Clientページは連絡先情報、現在の提案、最近のアクティビティを置きます。

フォローアップ日を変えるのに30秒かかると更新されなくなります。ワンアクションで編集できる設計を優先してください。

シンプルなレポート（ワン画面）

最初は1つの軽いレポートで十分：サービス別の成約率と平均クローズ日数。これで「何をもっと売るべきか」と「どこで足止めされているか」が分かります。

ゼロから使える状態まで作る

使える提案パイプラインは“フルCRM”ではありません。何がアクティブで、どこが詰まっていて、今日何をフォローすべきかが一目で分かる場所です。

当日中に使える最初のバージョンを作る

データモデルといくつかのダミーレコードでフローをテストします。クライアント1つ、提案2つ、サービス種別2つ（例：「Website refresh」「Ongoing SEO」）を作りましょう。

まずボード（ステータス別カラム）と提案詳細フォームの2画面を作ります。ボードで日次スキャン、フォームで正確な更新をするイメージです。

進め方の例：

• モデル：Client、Proposal、ServiceType、Activity
• UI：ボードビュー＋提案詳細フォーム（ステータス、金額、送信日、次回フォロー）
• ルール：主要フィールドがない場合はステータス移動をブロック（例：Sentには送信日が必要）
• リマインダー：フォローアップ期限に通知（オプションでSentになったときにも）
• ダッシュボード：ステータス別カウントとサービス別の成約率チャート

「進めないとダメ」チェックを追加する

これがアプリを信頼できるものにします。

例：ドラフトからSentにドラッグした時、クライアントメールや金額がなければ止める。こうした小さな摩擦がデータの散らかりを防ぎます。

デフォルトルールの例：すべてのオープンな提案には次回フォローアップ日が必要。なければボード上で警告を出します。

「使える」定義の簡単な目安：

• 提案を60秒以内に追加できる
• 今日フォローすべき相手が一目で分かる
• ステータス変更が一貫している（半端な送信がない）
• サービス別の成約率が見える
• 既に管理できている案件ではリマインダーが静かに動く

うるさくないステータス駆動のリマインダー

リマインダーはパイプライン上の明確な瞬間に紐づけると効果的です。アプリが現在のステータスを知っていれば、案件が古くなりそうなときだけ促せます。

トリガーは少なくて良いです。実用的な設定例：

• 提案がSentになったとき、フォローアップ日を必須にする
• フォローアップ日に1回リマインドする
• SentのままX日返答がなければ自動でフォロータスクを作る

リマインダーの文面は短く、アクション指向に：

• "{Client} にフォローアップ：{Proposal} — 簡単な確認"
• "{Client} / {Proposal} — 承認前の変更有無確認"
• "{Client} / {Proposal} — 納期と開始日の確認"

ノイズにならないようにガードレールを入れます：提案につき1日1回まで、スヌーズは1日・3日・次週などを用意。

各リマインダーの結果も記録しましょう：完了、スヌーズ（いつまで）、スキップ、送信済み。これで実際に何が起きたか追えます。

例："Website refresh - Acme Co"を月曜にSentにし、木曜フォローに設定。木曜朝に1回リマインドが来て金曜にスヌーズ。金曜にフォローしてリマインダーを完了にすると、"X日後に返答なし"のタイマーはリセットされます。

サービス別の成約率を追い、数字を活かす

提案パイプラインが有益なのは、次に何をするかを決められるときです。一番簡単なのはサービス種別ごとの成約率を追うことです。"ウェブリデザイン"と"月次保守"は別ビジネスのように振る舞うことが多いです。

まず結果の一貫性を保ちます：

• Wonは明確な“はい”を意味する（署名、入金、確認済み開始日）
• Lostはもはや追わない状態（断られた、競合に決まった、 inactive enough）

ルールを一つ決めて守らないと数字が意味を失います。

失注理由は短く一貫して残します：

• 価格
• タイミング
• スコープ不一致
• 無応答
• 競合に決定

次に、実際に使う期間（過去30日や90日など）でサービス別の成約率を計算します。12件送って3件受注なら25%、6件送って4件受注なら67%です。完璧である必要はなく、一貫性があれば十分です。

クローズ日数も追いましょう。SentからWon/Lostまでの日数を測ると、"SEO監査は5〜10日で決まりやすいが、フルサイト再構築は30〜45日かかる"といった学びが得られ、フォロー頻度や収入予測に影響します。

数字を活かす単純なルールを作ります。成約率が低く、クローズに時間がかかるサービスはスコープを絞るか事前の絞り込みを強める。成約率が高いなら保護して、うまくいっている要素を再利用しつつ慎重に値上げする。

提案CRMを作るときのよくある落とし穴

ツールを使えなくする最速の方法は、分かりにくくすること。フリーランスは良い意図で始めても、信頼できないツールを作ってしまいがちです。

ひとつの落とし穴は、意味がほぼ同じステータスを増やすこと。"Sent"、"Submitted"、"Delivered"、"In review"の違いを一文で説明できないなら、たぶん1つで足ります。

もう一つはSentを墓場にしてしまうこと。フォローアップ日を必須にしないと、フォローすべき項目が見えない山になります。簡単なルールで多くは防げます：Sentの提案には必ず次のアクションを登録する。

他のミス：

• 提案と一般的なリードを混ぜてしまい、パイプラインがランダムな受信箱になる
• Lost理由を記録しないため同じミスを繰り返す
• 早期に自動化しすぎて、リマインダーの調整に時間を取られて提案を出す時間が減る

リマインダーは地味で具体的に。通常はフォローアップ日1件で十分。詳細なルールは1か月の実データを見てから追加しましょう。

もし短期間で同じ理由（例："タイミングが長すぎる"）で3件失注したら、小さな第一フェーズを提案するなどの改善を検討しましょう。ステータスを増やすより優先度が高いはずです。

信頼できるものにするための簡単チェックリスト

提案パイプラインを信頼できる唯一の情報源にする前に、何もが宙に浮いておらず次の一手が明確になっていることを確認してください。

パイプラインビューを開いて30秒以内に今日の優先事項が分かることが理想です。複数の提案を開かないと次のステップが分からないなら、重要なフィールドを隠している設計です。

チェックリスト：

• すべてのオープンな提案に明確なステータスと次回フォローアップ日が表示される。次のステップがなければクローズする。
• 「今日」ビューに今できるアクションが表示される（フォロー、送信、修正など）。ただのストレスリストではないこと。
• WonまたはLostにしたときに最終金額と短い理由を記録する。
• サービス別の成約率が最近の期間（30〜90日）で見える。
• リマインダーはスヌーズ可能で、同じ提案に同一日に重複して来ない。

簡単なストレステストをやってみてください。異なるサービスで3つのサンプル提案を作り、ステータスを移動し、リマインダーを起動してみる。5分で壊せるなら、忙しい週に必ず壊れます。

例：ある週の提案（そこから学べること）

月曜に提案を5件送ったとします。3件はウェブリデザイン、2件は月次サポート。すべてはDraftから始まり、メール送信でSentに移ります。

水曜にはステータスが物語を語ります：

• 2件のリデザインがViewedに（クライアントがドキュメントを開いた）
• 1件のリデザインはまだSent（開封なし）
• 1件のレテイナーがNegotiatingに（作業時間調整の依頼）
• 1件のレテイナーがWonに（契約締結）

リマインダーが手を貸してくれます。"閲覧済みだが2日返答なし"というルールが、金曜朝に2件のリデザインリードへフォローを促します。"送信済みだが3日未閲覧"ルールは静かな案件をキャッチして、短いメッセージで再送して次の手順を明確にします。

現実はもっと曖昧です。あるクライアントが日曜に "忙しかった、ごめん" と返信して翌月開始を希望する場合、Sentのまま放置せずOn Holdに移します。交渉は継続しますが、リマインダーは毎日鳴らないようにします。

週末にはサービス別の成約率が明瞭になります：サポートは1/2受注、リデザインは0/3。翌週はリデザインのスコープを2段階に絞り、フィードバックの簡単な締め切りを設けることにします。

次のステップ：小さく出して改善する

最速で価値を出す方法は、毎日実際に開く最小限のバージョンを出すことです。テンプレートや複雑な自動化、初日からの多くのチャートは不要。今日送ったもの、待っているもの、次にすることを伝えられれば十分です。

ステータスはそれぞれ「今何を期待するか」を答えられるように設定してください。ステータスを一文で説明できないなら、それがワークを遅くします。

今週やるべき3つのアクション：

• 5〜7個のステータスを設定する（例：Draft、Sent、Follow-up due、Negotiating、Won、Lost）
• 数秒でステータスを移動できるボードビューを作る
• 本当に重要なケースだけにリマインダーをオンにする（Follow-up due、次のアクションが自分にあるNegotiatingなど）

基本ループが自然に回り始めたら改善を1つずつ追加します。優先順はリマインダー（案件が落ちないように）、レポーティング（学ぶため）、テンプレート（時間節約）の順です。一度に全部追加すると、何が効果的で何がノイズか分からなくなります。

重いコーディングをしたくなければ、AppMaster (appmaster.io) のようなツールでデータベース（clients、proposals、services）をモデル化し、UIとステータスルールを構築して反復するのが現実的です。

アップグレードは小さく、測定可能に。1週間後に：フォローが速くなったか、返信を見落とす数が減ったかを確認。1か月後に：どのサービスがよく受注するか、どれを改善するべきかを判断します。

最初のバージョンは個人的な道具として扱ってください。新しい提案をログするのに30秒以上かかるなら、フィールドや画面を簡素化してから他を追加してください。使うのが楽になれば、データは信頼できるものになります。