受注見通しの次に、入金までの工程の見通しを置く
SMB向け事業の営業計画では、契約が決まるかに加え、決まった後に何がそろえば提供と請求へ進めるかを確認します。受注金額が計画に届いても、顧客の準備、提供側の枠、請求に必要な確認が止まれば、入金の見通しも動くためです。営業から提供、請求担当まで、同じ案件を工程ごとに追える形にします。
本稿は、SMBを顧客とするエンタープライズ企業の営業責任者・営業企画・事業開発担当者に向けた運用設計です。受注する可能性の予測や、営業施策の採算比較から一段先へ進み、受注後に何を誰へ渡すか、どの待機を解けば次へ進むかを扱います。
自社ノウハウの入金からの逆算、受入体制、次の行動の具体化を、部門間の工程管理へ展開した提案です。会計上の売上計上や個別契約の解釈を決めるものではなく、それぞれの担当が確認した条件を運用へ反映する方法を整理します。以下の日数は説明用の架空例です。
受注・開始・請求可能・請求・入金を別々に記録する
一つの「受注済み」欄では、契約後の停滞を区別できません。対象範囲が決まった、提供を始めた、請求の前提が満たされた、請求した、入金を確認した、という状態と日付を分けます。商材によって必要な状態は違うため、使わない工程を無理に増やす必要はありません。
請求できる状態は、営業が納品したと思う時点と一致するとは限りません。顧客による確認、必要書類、対象期間、発注番号など、自社と顧客が実際に必要としている前提を請求担当と確かめます。確認済みの条件と、確認相手がまだ分からない項目を分け、後者を標準条件で埋めないようにします。
一つの契約で複数回の提供や請求がある場合は、その対応を残します。契約全体の金額と、今回請求する部分を重ねて足さず、どの提供・請求・入金が対応するかを特定します。営業の受注指標と請求担当の管理単位が違っても、相互にたどれることが必要です。
| 工程 | 必要な情報 | 受取側の確認 |
|---|---|---|
| 受注から開始 | 合意範囲・顧客準備・希望日 | 提供側が準備と枠を確認 |
| 提供から請求準備 | 対象期間・作業と確認の状態 | 請求担当が不足条件を確認 |
| 請求準備から請求 | 今回の対象・必要書類・提出方法 | 請求の対象と提出先を確認 |
| 請求から入金確認 | 請求内容・合意条件・実際の処理 | 対応する請求と入金を照合 |
入金の希望時期から、確認すべき前提へさかのぼる
最初に確認するのは、入金の時期を誰が何に基づいて見込んでいるかです。そのうえで、請求に必要な状態、提供に使う期間、開始前の準備、顧客の判断へさかのぼります。固定の日数を機械的に引くより、どの条件が未確定なら予定を出せないかを特定します。
準備には依存関係があります。対象範囲が決まらないと担当を割り当てられない、顧客の情報が届かないと作業を始められない、確認担当が不在だと請求前の確認が終わらない、といった関係です。並行できる工程は分けつつ、前提が整うまで着手できない工程を同時に完了したものとして扱いません。
営業は顧客の判断と合意した範囲、提供側は受入枠と必要な準備、請求担当は請求の前提と提出方法を確認します。顧客側にも、利用、作業の確認、支払処理を担う役割があります。同じ人が兼務している場合も、何の確認が必要かは分けます。営業の入金目標だけを根拠に、開始や支払いを顧客へ迫る計画にはしません。
架空例：同じ受注でも、開始の15日遅れが入金を動かす
工程の違いを示す単純な架空例を考えます。契約後の準備20日、提供30日、提供後の確認と請求10日、請求から入金まで30日と仮定します。すべて暦日で、工程は重ならず順番に進み、締日や休日による調整は置かない計画モデルです。実際の請求条件や標準期間を表すものではありません。
この場合、契約を起点に準備完了は20日後、提供完了は50日後、請求は60日後、入金は90日後という計画になります。開始前の準備だけが15日延び、他の工程も同じだけ後ろへ動く条件なら、請求は75日後、入金は105日後です。受注日と受注額が変わらなくても、後工程の見通しは変わります。
実務では、開始の遅れがそのまま入金の遅れになるとは限りません。請求の条件や締日、部分提供の扱い、並行できる作業が違うためです。だからこそ、90日という合計をテンプレートにせず、動いた工程と、他の工程へ伝わる条件を残します。この例から金額や資金不足の大きさまで推定することもしません。
待機を、準備・提供・確認・請求後に分けて対応する
開始前の待機なら、顧客の必要情報、担当、作業時間と、提供側の受入枠を確認します。提供中の停滞なら、残る作業、変更された範囲、必要な承認を整理します。顧客の確認待ちなら、確認する対象と担当、判断材料が渡っているかを確かめます。同じ「遅延」でも、連絡先と必要な作業は異なります。
請求前提が整っていない状態と、請求後に予定の入金を確認できない状態も分けます。前者は不足する確認や提出物をそろえ、後者は請求担当が合意済みの条件、提出状況、顧客側の処理状況を確認します。営業だけで原因を未払いと断定したり、現場担当へ同じ催促を重ねたりしない運用が必要です。
予定を動かすときは、新しい日付とともに、動いた理由、影響する工程、双方の担当、次に確認する時点を更新します。支援範囲や提供方法を変えれば予定を維持できる場合もありますが、必要な価値や確認を省くなら別の合意が要ります。入金の予定を守るためだけに、完了していない作業を完了扱いにしません。
| 止まる場所 | 確認する内容 | 主に対応する役割 |
|---|---|---|
| 開始前 | 情報・担当・時間・受入枠 | 営業と導入担当が前提を調整 |
| 提供中 | 残る作業・変更範囲・承認 | 提供担当が工程と支援を修正 |
| 請求前 | 必要な確認・対象・提出物 | 提供と請求担当が不足を解消 |
| 請求後 | 提出状況・合意条件・処理状況 | 請求担当が事実を確認して連携 |
過去の計画を残し、引継ぎの問題を部門間で直す
最新の予定だけを見ると、何度ずれた案件かが分からなくなります。予測日、想定していた工程、根拠、未確認、予定日を保存し、実際に進んだ日付と照合します。過去の受注予測と同様に、現在の管理情報を直しても当時の計画は消さない形にします。
比較は、同じ開始条件や請求方法の案件群で行います。契約から入金までの経過だけでなく、準備待ち、提供中、確認待ち、請求後の経過を分けます。入金が済んだ案件だけの平均日数では、未入金のまま残る案件を表せません。観測日を決め、まだ次へ進んでいない案件数とその状態も併記します。
会議では、日数の長い担当を責めるより、営業時に確認できていなかった条件、受取先の不明、作業範囲の変更、提出方法の不一致を見つけます。営業・提供・請求の各責任者が、自部門の次の作業と、上流へ戻す修正を決めます。全部門が同じ入力を重ねるのでなく、必要な条件を引き継げる記録を作ることが目的です。
実務で迷う論点：前受け、顧客都合の延期、短い案件
前受けの取引でも工程管理は必要でしょうか。入金が提供より前にある場合も、実際の順序を残し、受け取ったことと提供を完了したことを分けて確認します。入金時期だけで顧客への約束が終わったとは扱いません。
顧客の都合で開始が延期された場合はどうするでしょうか。理由をそのまま一つの分類にせず、担当、情報、時期、必要性のどれが変わったかを確認します。見通しと支援枠を更新し、請求への影響は実際に合意した条件に沿って担当者が確認します。
短期間で契約から入金まで進む商材にも細かい表が要るでしょうか。全件に大きな表を作るより、標準の流れと例外条件を定めます。標準から外れた案件だけ不足する条件を確認し、件数が多いからと未確認を自動的に正常へ分類しないようにします。
