SES営業の要員提案管理とは｜案件とエンジニアを別管理しない
SES営業の要員提案管理で最初に壊れやすいのは、案件表と要員表が別々に動いていることです。営業側では「この案件を取りたい」と見えていても、要員側では「今出せる人がいない」「この人は単価が合わない」「面談結果が戻っていない」という情報が別管理のまま残り、初動が遅れます。
特にSESでは、案件獲得と要員提案が一体です。案件を増やすだけでも、エンジニア情報を増やすだけでも足りず、誰に何をいつ提案したか、その結果どうだったかが戻らないと歩留まりが改善しません。
結論から言うと、SES営業の要員提案管理に必要なのは、案件台帳とエンジニア台帳を別々に整えることではなく、案件、候補エンジニア、提案日、面談予定、結果、次アクションが同じ文脈で返る状態です。詳細なスキルシートを厚くするより、提案履歴が返る営業管理の方が先に効きます。
本記事のポイント
- SESの要員提案管理では、案件要件とエンジニア情報を別台帳で持つほど、初動と歩留まりが悪くなりやすい。
- 管理すべき最小単位は、案件、候補エンジニア、提案日、結果、面談予定、次アクションのつながりである。
- 先に整えるべきは詳細スキルシートではなく、誰に何をいつ提案したかが戻る営業運用である。
この記事で扱うテーマ
関連キーワード
- SES 要員提案 管理
- SES エンジニア 提案 管理
- SES 案件 要員 管理
- SES CRM 要員管理
- SES 面談調整 管理
- SES 提案履歴 管理
このページで答える質問
- SES営業の要員提案管理では何を持つべき？
- 案件台帳と要員台帳はどうつなぐ？
- SESとSIerで提案管理はどう違う？
- スプレッドシート運用から何を先に移すべき？
SES営業の要員提案管理で最初に揃える単位
SESで営業管理を整えるとき、案件だけを見ると遅れます。案件要件、候補エンジニア、提案状況、面談予定、結果、空き時期が同時に動くため、見るべき単位は「案件」だけではなく「案件に対して誰をいつ提案したか」です。
ここは SES向けCRMの選び方 で触れたように、顧客、案件、要員、稼働、契約更新が分断しない設計が前提になります。その中でも要員提案管理は、受注前の歩留まりを左右する最前線です。
詳細なスキルシートを厚くしても、提案日や返答状況が追えなければ営業は改善しません。逆に、技術詳細が少し粗くても、提案結果と次アクションが返る運用になれば、案件との相性判断はかなり速くなります。
案件台帳とエンジニア台帳を分けると何が起きるか
別管理の問題は、情報の量ではなく往復の遅さです。案件側の更新と要員側の更新がつながらないと、提案済みなのか、面談待ちなのか、見送り理由は何かが見えず、同じ詰まりを繰り返します。
| 分断している情報 | 起こりやすい問題 | 要員提案管理でつなぐべきこと |
|---|---|---|
| 案件要件と候補者一覧 | 誰を出せるか判断するまでに時間がかかり、初動で負ける | 案件ごとに候補エンジニアと優先順位をひも付ける |
| 提案日と返答状況 | 提案済みかどうか分からず、追客も再提案も遅れる | 提案日、返答待ち、見送り理由、次回アクションを残す |
| 面談予定と営業メモ | 面談調整が担当者依存になり、歩留まり改善の材料が残らない | 面談日程、論点、フィードバックを活動履歴として返す |
| 空き時期と稼働中情報 | 今後出せる人が見えず、先回り提案ができない | 終了予定日、更新可否、次回提案候補をまとめて見る |
この往復を軽くするには、活動ログを残す最小実装 の発想が効きます。メール、会議メモ、面談結果が案件と要員の両方に返るだけで、歩留まりの見え方はかなり変わります。
SESとSIerで提案管理の重心はどう違うか
同じ提案営業でも、SESとSIerでは管理の重心が違います。SESは「誰をどの案件へ出すか」が中心で、SIerは「どの論点で案件を前に進めるか」が中心です。
| 比較軸 | SESで重い情報 | SIerで重い情報 |
|---|---|---|
| 提案の主語 | 候補エンジニア、単価、商流、面談可否 | 提案論点、体制案、見積、技術検証 |
| 歩留まりを左右する要素 | 要件適合、提案速度、面談調整、返答管理 | 課題把握、提案精度、意思決定者の整理 |
| 重要アラート | 提案未返答、面談未調整、空き要員、契約終了接近 | 見積停滞、提案差し戻し、仕様変更、進行摩擦 |
| 近い記事 | 本記事 | SIer向け営業管理の方法 |
この違いを意識せず同じ案件管理画面で済ませると、SES側は提案の往復が見えず、SIer側は提案論点が薄くなります。業態ごとに営業管理の主語を分ける方が実務では安定します。
要員提案管理を回す最小構成
最初から詳細スキルDBや大量の検索軸を作る必要はありません。先に整えるべきなのは、営業判断に直結する最小構成です。
- 案件名、顧客名、要件概要、単価帯、商流、返答期限を持つ。
- 候補エンジニアのIDまたは氏名、主要スキル、空き時期、希望条件を持つ。
- 誰をいつ提案したか、面談予定、結果、見送り理由、次アクションを持つ。
- 稼働中要員については、終了予定日と更新可否だけ先に営業管理へ返す。
スプレッドシート運用が長い会社は、脱スプレッドシート の考え方で、まず壊れない型を先に作る方が現実的です。案件と候補者を別ファイルで持ち続けるほど、提案履歴の往復は遅くなります。
Google環境中心なら、Google Workspaceで営業管理を行う方法 のように、Gmail、予定、メモから更新が返る導線にした方が面談調整と追客が止まりにくくなります。
よくある質問
詳細なスキルシートを整えれば歩留まりは上がりますか？
それだけでは上がりません。詳細情報より先に、誰をいつ提案し、どう返ってきたかが見える状態を作る方が改善に直結します。
要員管理と契約更新管理は別で考えるべきですか？
完全に別にはしない方がよいです。終了予定日と更新可否が見えていないと、次に出せる人の計画と先回り提案が組めません。
面談調整も営業管理の範囲に入りますか？
入ります。面談調整の遅れは歩留まりに直結するため、少なくとも予定日、担当、結果、次回アクションは営業側でも見える必要があります。
SIer向けの案件管理をそのまま流用できますか？
難しいことが多いです。SIerは提案論点が中心で、SESは候補エンジニアと提案履歴が中心なので、管理の主語を変える必要があります。
