受注してから、回せないと気づく
見積を出すときに手が空いているかを確かめていない。取れてから、誰も入れられないことが分かる。
追いかけるのは「受注できるか」ではなく、
「受けて回せるか」です。
だから中心に置いたのは案件です。このエディションでは商談を案件と呼びます。 画面の言葉が変わるだけでなく、見積・受注・納品・保守更新までを1本の案件で追えます。
受託の粗利は、取れたかどうかより誰をいつ入れたかで決まります。 稼働をメンバー×週の表で持っているので、見積を出す前に着手できる時期を確かめられます。 前倒しできる案件と、断るべき案件が分かります。
保守契約は受注のあとに続く売上です。案件に契約終了日を入れておけば、その60日前に更新準備のタスクを作ります。
この考え方について読む →Problems
見積を出すときに手が空いているかを確かめていない。取れてから、誰も入れられないことが分かる。
稼働の見通しがPMの頭の中にしかない。前倒しできる案件も、断るべき案件も判断できない。
検収、請求、保守契約の更新。受注の熱が引いた後の工程が、誰の担当でもなくなっている。
The screens
メンバー×週で、割り当て人日とキャパを並べます。いつ誰が空くかを、感覚ではなく数字で見られます。
キックオフ・制作・レビュー・納品の工程を案件ごとに持ちます。滞留日数と期限、想定と実績の人日が同じ行に出ます。
下書き、送付済み、承認のステータスで管理します。明細は数量×単価で積み上げ、数量に人日を入れれば人日×単価の見積になります。
商談ではなく「案件」で呼びます。アプローチから見積までのステージごとに、金額と件数が出ます。
Project engine
受託開発版を作ると、案件まわりの自動化が最初からONになっています。 見積の段階に入った案件にタスクを作り、止まった案件を拾い、受注したら契約書・発注書の回収タスクを作ります。 保守契約の更新準備まで含めて、1日1回の処理として走ります。
自動化が作るのはタスク・通知・下書きと、売上予測の更新です。顧客へのメールは、送る相手と文面を自分で決めてONにした自動化だけが送ります。 担当者が中身を見て、直してから動かします。
AI
知りたいことのために、集計を組み立てる必要はありません。 話すとおりに聞けば、案件・稼働・顧客と、添付した資料を探して答えます。
今週の空き、期限が近い案件、止まっている案件。 どれも表を作らずに、その場で確認できます。
頼めば、コンタクトやタスクの登録もします。 AIが顧客にメールを送ることはありません。
Mobile

Permissions
顧客・会社・案件のそれぞれについて、見える範囲を「全体・チーム・自分」から選べます。 協力会社のメンバーを入れる場合も、担当者になっている案件と、その見積だけに絞れます。エクスポートの可否は別に設定できます。 下は設定例です。
顧客・会社・案件は変更履歴が残るので、誰がいつ何を変更したかを後から追えます。