フリーランスのための自己管理SFA/CRM/ERPをNotionで構築中
この記事は、Notion Community Advent Calendar 2022の12/20担当の記事です。
前日はkabewallさんのNotionAPIを使って参考文献を抽出するという記事でした。NotionAPIは色々できていいですよね。僕も活用しています。
軽く自己紹介
アドベントカレンダーから来る人も多いと思うので、軽く自己紹介させてください。
私は現在フリーランス・一人社長として、動画制作と軽めのWeb開発を仕事としています。
動画は企業VPなどが中心ですが、頼まれごとであれば基本何でも請けているので、広告やイベント配信などを手伝うこともあります。
一方で軽めのWeb開発ですが、基本的なホームページ制作ではないけれど、システム要素が入り、そこまで大規模じゃない案件、みたいなのに携わります。よくあるのが、お問い合わせフォームを作ってほしいとか、既存のCMSじゃできないことをちょっとカスタマイズしてほしい、とかですね。
案件管理はフリーランスの肝
フリーランスや経営を経験した人はわかると思いますが、案件は生命線です。案件があって、初めて納品があり、お金を頂けるわけですので、この管理は大変重要ですね。毎月出社していればお金が入ってくるサラリーマンとは違うところです。
私の案件管理という言葉の定義
案件管理という言葉は多くの企業やフリーランスの方も使う言葉だと思いますが、これはコンテキストに応じて意味合いが異なってくると考えています。
営業側面的な案件管理
例えばですが、私の場合「動画制作やってるんですよね？ ちょっと相談したい話があるんだけど、いいですか？」という引き合いの場合と、「○月○日にあるイベントで流したい映像を発注したいです。他には2社問い合わせています。予算は◯十万円です。間に合いますか」みたいな引き合いの場合、どちらが受注に近いか、つまり受注確度が高いか、ですね。当然後者の方になります。
営業案件を管理する的な意味でいうと「この案件は受注が近い、この案件は微妙かも…」といった、営業上の温度感を管理することが大切ですよね。
こういった管理には、SFA（Sales Force Automation）というツールを使うのが一般的かと思います。
制作側面的な案件管理
一方で、制作の立場の方から見た案件管理という言葉は、例えば「A社の案件は納期が◯日で、B社の案件が×日ですね。デザイナーさんはA社の案件にアサイン中だから、B社の案件がちょっとタイトだな…」といったように、複数の案件で自分やチームのタスク量を管理し、無事に期日通り納品に繋げることが案件管理になってくるかと思います。
こういった管理にも、一般的にはBacklogやAsana、会社によってはGoogle Workspaceなどを使っているところが多いと思います。
フリーランスなら、この両方をまとめてやっちゃいたい
これは私がフリーランスだからというわけではないのですが（実際、会社勤めしていた時にも思ってたこと）、営業的な案件管理と、制作的な案件管理を一気通貫で管理したいなと思っていました。
ただ、先ほど言ったように、SFAツールは基本的には企業組織で使うもの、BacklogもAsanaも基本的には有料ツールで、チームワークで使う物なので、フリーランスで基本一人で案件管理する私には向かない物でした。
自分でツールを開発しようかと思ったこともあったのですが、そんな時に出会ったのがNotionでした。
それでは、現時点で私がNotionでどのように案件管理しているか、ご紹介しましょう。
営業管理のスタートは、人、場所、企業である
まずは営業管理です。営業のスタートは、いかに見込み顧客の連絡先を握るかに限ると考えています。
もちろん、その連絡先を握るには色々なやり方があるのですが、それはNotionの使い方とは異なりますので、また別の機会に。
まず最初は獲得した連絡先をどのように管理するかです。
私のNotionは、ほぼ全てデータベースであり、ドキュメント的利用はわずかしかありません。
まず、営業に必要な情報リソースは「企業・拠点・担当者」というデータベースに集約しています。
企業データベースに登録している情報
では、企業データベースには何を登録しているのでしょうか。プロパティを中心に見ていきましょう。
名前 企業の名称です。通常の企業であれば「株式会社・有限会社・合同会社」などの企業区分が入ります。個人事業主の方の屋号であれば、これらが入りませんので、特に「株式会社」などと名称がなければ、この組織は個人事業や任意団体だな、ということがわかります。また、屋号のない個人事業主の方は「フリーランス：◯◯太郎」のように、個人名称の前に「フリーランス：」という接頭詞をつけるルールにしています。
Realted to Personnel 後述する担当者とのリレーションです。英語版時代に作ったので、このような名称になっています。ここに人の名前が並んでいると、この企業に所属する社員の方で、名刺交換したことがある人が並ぶことになります。
Related to Project 後述する案件とのリレーションです。これも英語版時代に作ったのでこのような名称に。ここには、この企業と取引した、あるはするかもしれない案件が並びます。
Related to 拠点 これも後述する拠点とのリレーションです。企業によっては、本社以外に支社や支店、工場などの拠点を持つ場合があります。〇〇社の人と名刺交換したけど、一人は東京本社で、一人は大阪支社の人、みたいな場合に備えて用意してあります。
Related to 継続案件 これは以前作っていたデータベース、継続案件とのリレーションですが、現在はNotionの利用見直しにより、使用していません。
種別 これは、この企業が、私にとって、その組織がどういう立ち位置なのかを示す種別です。以下の内容になっています。
クライアント 顧客です。見込み顧客の段階でつけることが多いです。
クライアント（代理店） 顧客ですが、この顧客の上流にさらにクライアントが存在する場合につけます。
クライアント（直） 直接私と取引をしてくれるクライアントのことです。
クライアント（エンド） 代理店の上流に存在し、最終的なエンドクライアントを指します。5種類あるクライアントの中で、請求書のやり取りが発生しないタイプのクライアントです。
ディストリビューター いわゆる商社系と言えばいいのでしょうか。二次請け、三次請けになる場合の、中間に入る企業のことです。
派遣会社 以前お世話になっていた派遣会社から、派遣のお仕事を紹介してもらったりすることもあるので、つけています。ただ、現在では、派遣の仕事はしていないので、あまり重要な区分ではありません。
協業パートナー こちらからお仕事をお出しする先の会社・組織です。いわゆる外注先となります。
派遣先 派遣社員時代にお世話になっていた派遣先です。個人的に連絡先を教えていただいた場合などにつけています。
派遣先の協業先 派遣社員時代に、他の企業の社員さんとお仕事をした場合などに個人的に連絡先を教えていただいた場合などにつけています。
就職活動先 以前会社員をしていたときに、転職活動をしたことがありますが、その時に面接官の方が名刺を出してくださる場合がありました。この時の名刺はこの区分にしています。
支援組織 商工会議所や中小企業支援組織です。通常はお金のやり取りが発生せず、こちらのビジネスを支援してくださる組織になります。
URL その企業の公式ホームページです。ググればわかるのですが、今後自分の組織が大きくなって、他のメンバーが会社のことを調べるようなことになっても、その手間を省くために、今のうちから入力しています。
廃業・解散・吸収合併 ラベル名の通り、廃業や解散、吸収合併などで、組織そのものが存在しなくなったケースです。実際にそういう会社さんがあるので、このフラグを追加しました。
スキル 担当者のレコードに存在するプロパティを、ロールアップで引っ張っています。詳しくは担当者のところで紹介します。
フリガナ フリガナです。手で入力しています
事故 何らかのトラブルがあり、取引停止にしたところです。
口座 営業用語で「口座を開く」という言葉があります。初めてその企業と取引することを言うのですが、つまり既存取引があるところを「口座がある」既存取引がないところを「口座がない」と言います。従って、選択項目は以下のとおりです。
未開 まだ口座が開いてない企業です。見込み顧客という扱いになります。
営業中 口座未開ですが、現在積極的に営業活動をしている企業です。
開済 口座が開いた企業です。既に取引があるという意味です。
当月末締め 企業ごとの支払いサイトを管理するためのフラグです。文字通り、当月の月末で締める企業はここにチェックが入ります。
当月特別日締め 末締めではなく、20日などの特定の日に締める企業です。その日にちの数字を入力します。
払い月 支払い月を数値で入力します。翌月なら1、翌々月なら2です。
末日払い 末日に払われる場合は、ここにチェックです。
特別払い日 末日ではなく、特定の日に支払われる場合はここに数値で入力します。10日なら、10です。
法人番号 2015年から施行された法人番号を入力するところです。実は、Notionに法人番号を入力するアプリを作ったので、興味ある方には販売いたします。
弊 #Notion の企業マスタには「法人番号」プロパティがあるのですが、手で入力するのは大変なので、放置してました。この度API同士を繋げて、ボタンぽちぽちで入力できるようにしましたので、披露します。重複する企業名もあるので、全自動というわけにはいかないのですが、だいぶ楽になりました。 pic.twitter.com/gtBpdW2GVJ
— Kohki SHIKATA📺動画制作＆軽いWeb開発 (@kohki) November 12, 2022
外注 この企業に発注した、または発注予定の注文です。外注データベースとのリレーションです。
ディストリビューター この企業が商流の中間に入っている案件を表示します。案件データベースとのリレーションです。
顧客ランク いわゆる顧客ランクです。現在は手動設定ですが、いずれは自動的に算出するアルゴリズムを書いて、自動化したいですね。項目は「★★★／★★／★」の3種類です。
拠点データベースに登録している情報
名前 拠点の名称です。必ず、社名＋拠点名という入力ルールにしています。当然「本社」や「大阪支社」という拠点名は、複数の企業に存在するので、その拠点を「ユニーク」に扱うための名前空間が必要となるからです。本社しか存在しない場合は、その企業名＋本社という名称にしています。
Related to 担当者 後述する担当者とのリレーションです。
企業 この拠点が所属する企業です
郵便番号 郵便番号です。
都道府県 都道府県です。
市区町村 市区町村です。
町名・番地 町名・番地です。
建物名 建物名です。
電話番号 その拠点の代表電話番号です。
FAX番号 その拠点のFAX番号です。
事故 企業データベースの事故プロパティをロールアップしています。
廃業解散買収等 企業データベースの当該プロパティをロールアップしています。
種別 企業データベースの種別をロールアップしています。
商談 商談データベースとのリレーションです。この拠点との商談があった場合に、ここに一覧が表示されます。
担当者データベースに登録している情報
企業 企業データとのリレーションです。この担当者（社員）の方が所属している企業となります。
Related to 商談 商談データベースとのリレーションです。この担当者の方と商談した履歴がここに並びます。
Related to 案件 案件データベースとのリレーションです。この担当者の方が担当の案件が並びます。
Related to 継続案件 継続案件データベースとのリレーションです。現在は使用していません。
フリガナ 担当者の方のフリガナです。
メールアドレス 担当者の方のメールアドレスです。
名刺 スキャンした名刺を貼り付けています。
所属拠点 拠点データベースとのリレーションです。異動などで拠点が変わった場合は、ここも変更することになります。
職種 この方がどういう職種やポジションなのかを説明する項目です。フリーランスの方との名刺交換も多いので、一般的な企業の職種以外の項目も多数設定しています。
役員
企画
マーケティング
営業
広報
制作
編集
技術
総務
人事
管理
経営企画
総務経理
人材エージェント
演者
運営
記者
セラピスト・カウンセラー
コンサルタント
専門コンサルタント
戦略コンサルタント
販売
士業
研究
教育
飲食
宗教
その他
部署 たとえば「営業部」であるとか「業務２課」といった、その企業で設定されている、その方の所属する部署のことです。
肩書 肩書です。その方の名刺に記載されているものをそのまま記載します。
携帯電話 携帯電話の電話番号です。
個人業務用電話 デスクの内線直通番号がある場合です。
部署直通電話 その方の部署に直通する電話番号がある場合です。
部署FAX その方の部署に直通するFAX番号がある場合です。
名刺交換日 その方と名刺交換した日付です。
マーケティング対象外 ここでいうマーケティングとは、こちらの事業を積極的に紹介したり、営業をかける対象か否か、ということです。何らかの理由で積極的にアプローチする対象から外したい場合、ここにチェックを入れます。（クレームをもらった等）
退職済み 文字通り、退職済みのフラグです。
故人 ご逝去された方の場合
廃業・解散・吸収合併等 企業データベースの当該フラグをロールアップしています。
都道府県 この方が所属されている拠点の都道府県です。住所録のためにロールアップしています。
市区町村 この方が所属されている拠点の市区町村です。住所録ためにロールアップしています。
町名・番地 この方が所属されている拠点の町名・番地です。住所録のためにロールアップしています。
スキル 協業パートナーの方専用のプロパティです。お願いしたい案件に必要なスキルでフィルタリングするためのものです。
ブランディング ジャンルを問わないトータルブランディングができる方
印刷会社 印刷をお願いできる会社様
DTP DTP案件をお願いできるデザイナー様
3D 3Dアニメーションやモデリングをお願いできる方
動画制作 動画制作全般をお願いできる方
動画編集 動画編集をお願いできる方
サウンドエンジニア 音の編集やMAをお願いできる方
ビデオグラファー 動画撮影をお願いできる方
フォトグラファー スチール撮影をお願いできる方
イラストレーター イラスト制作をお願いできる方
ビジネスマンガ 広告系のマンガをお願いできる方
Webディレクター Webディレクションをお願いできる方
Webデザイン Webデザインをお願いできる方
マークアップ HTML/CSSのマークアップをお願いできる方
Web広告運用 Webの広告運用をお願いできる方
フロントエンド フロントエンドの構築をお願いできる方
バックエンド バックエンドの構築をお願いできる方
インフラ インフラの構築をお願いできる方
システム開発 システム開発をトータルでお願いできる方
ゲーム開発 ゲーム開発をお願いできる方
営業代行 営業代行をお願いできる方
ライター ライティングをお願いできる方
ビジネスサポート 業務代行をお願いできる方
事故 企業データベースの事故フラグのロールアップです
企業種別 企業データベースの種別のロールアップです
企業名 企業名のロールアップです
いよいよ案件データベースを見てみる
さあ、ここまでで、ようやく営業側面的な案件管理ができるところまでやってきました。
ここからは、実際に案件の引き合いが来た時の ために、案件データベースの中身を見ていきたいと思います。
クライアント クライアント名を表示する関数です。リレーションがあるので、それを表示してもいいのですが、後述する案件をネストする「親案件・子案件」があるので、子案件の場合、その親を表示させるために使っています。関数のコードは下記の通りです。
prop("親案件クライアント") ? prop("親案件クライアント") : prop("Client")Client クライアント（企業）名を表示するリレーションです。
親案件クライアント 後述する親案件が存在する場合のクライアント名です。ロールアップしています。
担当者 この案件の担当者です。担当者データベースとのリレーションです。
案件種別 案件の性質によって、項目を分けています。
単発 受注して納品するシンプルな受託です。
継続 準委任であったり、複数月にわたって契約するタイプの案件です。
セミナーシリーズ 報酬が発生するセミナーで、複数回にわたって開催されるタイプのセミナーです。
セミナー 報酬が発生する単発のセミナーです。
インセンティブ 紹介料など、特に手を動かしたり拘束が発生せずに収入が入るタイプ。
Status 案件のフェーズです。
ニーズの確認 案件がありそうかどうか、顧客に確認している段階です。
気軽な相談 クライアントから相談があったものの、案件の具合性はまだないという状態。
見積提出済 見積書を提出した状態（概算含む）この時点で、案件はある程度具体性があると判断します。
比較検討中 他者との比較俎上に乗っている段階です。この時点で、案件の具体性はかなり高いと考えます。
決裁者確認中 既に競合に勝ち、最後は役員や部長クラスの判子待ちという段階です。
受注 見事受注に至った状態です
制作中 受注し、実際に制作フェーズに入った段階。
納品済み 納品完了の状態です
保留 案件自体が受注前に保留になっている場合
お見送り こちらから案件をお断りした場合
失注 クライアントの判断で、受注に至らなかった場合
代理店失注 代理店が間に入っている案件で、代理店の判断で受注に至らなかった場合
稼働報酬額 時給ベースの案件等で、総案件の総稼動額を計算する関数です。コードは以下の通り
prop("設定単価") ? (prop("設定単価") * dateBetween(end(prop("拘束日時")), start(prop("拘束日時")), "minutes") / 60) : (prop("子案件総金額") ? toNumber(prop("子案件総金額")) : prop("金額"))金額 単発案件等の報酬金額です。
子案件総金額 子案件がぶら下がっている場合に、その金額の総和を出すロールアップです。
収入タイプ 報酬の特性について区分しています。
業務委託：制作 単発で終わる制作案件
業務委託：長期 長期にわたって契約がある案件
インセンティブ 事務作業以外、手を動かす必要がない案件
温度感 案件のフェーズとは違い、私への発注のクライアントや担当者による熱意です。「安いところならどこでもいい」なのか「ぜひあなたにお願いしたい」なのかでは、受注への確度が全く違うため、この指標は営業上でとても大切です。「高・中・低」の３区分で判断しています。
初回接触日 最初にこの案件の引き合い相談が来た日付です。受注までのリードタイムを図る上でも重要です。
引き合いタイプ 引き合いの背景について区分します。特に新規案件の場合は、どういう経緯で引き合いに至ったのかが重要なため、新規案件の時に重要なプロパティです。
アウトバウンド こちらから積極的に営業活動をかけた成果による引き合い獲得。当社では現状行なっていませんが、テレアポ、お問合せフォーム営業、飛び込みなどがこれにあたります。
インバウンド 当社ホームページや電話でのお客様側からのお問い合わせやお申し込みなど。
リピート 既存顧客からの再発注（以前はLTVという名前でしたが、自分以外は分かりにくいので変えました）
紹介 誰かからの紹介によって得た引き合い
イベント 商談会や展示会などで得た引き合い
遭遇 偶然出会ったり名刺交換した場で発生した引き合い
公募 案件紹介サイトや、支援組織のメーリングリストなどで得た引き合い
チャネル いわゆる営業チャネルというものです。どのチャネルから来た引き合いなのかを分析するために設定しています。
お問い合わせ 当社のホームページお問い合わせフォームからの引き合いについて
紹介 誰かからの紹介
MEBIC ML 当社が所属しているメビックという支援組織のメーリングリストから
ココナラ クラウドソーシング、ココナラからの問い合わせや発注
UPFLOW クラウドソーシング、UPFLOWからの問い合わせや発注
イベント 展示会や商談会などで発生した引き合い
求人媒体 求人媒体を見てアウトバウンドした場合
過去勤務先 過去の会社員経験から得た人脈を通じて
パートナー募集 外注先募集などに応募した場合
Indeed Indeedに掲載の業務委託先に応募した場合
既存掘り起こし 口座は開いているものの、長期間発注が無かった取引先へアプローチした場合
再チャレンジ 過去、口座開きに失敗したものの、再チャレンジした場合
受注確定日 初回接触日から受注に至った期間、つまり受注リードタイムを計算するために必要なプロパティです。
失注・不対応確定日 受注確定日の逆です。失注リードタイムや、音信不通になった案件の不対応判断のための指標です。
営業リードタイム 先述の営業リードタイムを算出するための関数です。コードは以下の通り。
dateBetween(prop("受注確定日"), prop("初回接触日"), "days")リードタイム（月） 失注・不対応確定の場合のリードタイムです。コードは以下の通り。
dateBetween(prop("失注・不対応確定日"), prop("初回接触日"), "months")納品日 受注した場合、納品予定日、または納品した実際の日付を入力します。
制作期間 受注確定日から起算し、納品までにかかった期間です。コードは以下の通り。
(dateBetween(prop("納品日"), prop("受注確定日"), "months") > 0) ? (format(dateBetween(prop("納品日"), prop("受注確定日"), "months")) + "か月") : ""支払いサイト その案件の支払いサイトを、企業データベースからロールアップしていますが、現在は未使用です。今後使用の予定。
制作時間 作業データベースと連携し、この案件の制作にかかった時間を算出します。ロールアップです。
作業記録 この案件に紐づく作業レコードです。制作時間と原価算出のために連携させているリレーションです。
利益率 この案件に紐づく外注レコードから算出し、売上に対する粗利（売上ー外注費用総額）の割合を表示します。外注がなければ当然ここは100%の表示です。コードは以下の通り。
round(divide(subtract(prop("売上総額"), toNumber(prop("外注費総額"))), prop("売上総額")) * 100) / 100原価 かかった作業時間から算出し、原価を表示します。私の時給は、6250円をベースにしています。コードは以下の通り。
round(prop("作業時間") * 6250)営業利益 受注額から外注費、原価を引いた計算です。コードは以下の通り。
subtract(prop("粗利"), prop("原価"))外注費 外注があった場合の、費用の総額を算出します。ロールアップです。
外注 外注データベースとのリレーションです。
設定単価 時給ベースの案件で、拘束時間から売上を算出するための単価設定です。単発案件では未入力。
今月入金 支払いサイト関連のプロパティから算出し、今月の入金対象かどうかを判断するための関数です。コードは以下の通り。
formatDate(prop("支払い予定日"), "MY") == formatDate(now(), "MY")開始日 長期案件の場合の契約開始日をロールアップ
終了日 長期案件の場合の契約終了日をロールアップ
開始日(日付) 契約期間を算出するための関数です。コードは以下の通り。
start(prop("開始日"))終了日(日付) 契約期間を算出するための関数です。コードは以下の通り。
end(prop("終了日"))当月末締め 請求区分を確認するためのロールアップです。
当月末締め(リンク) 請求区分を別のデータベースで参照するための関数です。コードは以下の通り。
prop("当月末締め")当月特別日締め 末日締めでない場合のロールアップです。
当月特別日締め(リンク) 末日締めでない場合、別のデータベースで参照するための関数です。コードは以下の通り。
prop("当月特別日締め")払い月 払い月のロールアップです。
払い月(リンク) 払い月を別のデータベースで参照するための関数です。コードは以下の通り。
prop("払い月")末日払い 末日払いの場合のロールアップです
末日払い(リンク) 末日払いを別のデータベースで参照するための関数です。コードは以下の通り。
prop("末日払い")特別日払い 末日払いでない場合のロールアップです
特別日払い(リンク) 特別日払いを別のデータベースで参照するための関数です。
prop("特別払い日")稼動状況 セミナーシリーズの場合、現在そのシリーズが稼動状況下にあるかどうかを判定する関数です。コードは以下の通り。
(prop("案件種別") == "セミナーシリーズ") ? (contains(prop("稼働状況(リンク)"), "受注") ? "稼働中" : "契約終了") : ""稼動状況(リンク) 上記関数を表示するためのロールアップです
請求 請求データベースのリレーションです。長期案件なので、着手金や中間金など、請求書が複数に渡る場合、ここには複数件数表示されます。
金額(総額) 複数の子案件が存在する場合、それの総額を算出します。コードは以下の通り。
(prop("金額") > 0) ? prop("金額") : toNumber(prop("子案件総金額"))売上総額 単発案件の時は、報酬金額を、子案件が存在する場合はその総額を条件によって判定し、表示します。コードは以下の通り。
prop("金額") ? prop("金額") : prop("金額(総額)")再始動時期 案件ステータスが保留になっている場合、再始動する時期がいつ頃かを設定します。
Related to 商談 商談データベースとのリレーションです。この案件で行なった商談が全てここに並びます。
Related to Tasks タスクデータベースとのリレーションです。この案件で行なったタスクが全てここに並びます。
営業的側面から、Notionを使って、SFA利用する
さて、ここまでの情報が適切に設定できていれば、営業的側面からの案件管理はスタートできるでしょう。
別途営業というページを作り、そこにカンバン表示でSFAとして利用します。
スクショはこちら。
横軸がStatus、縦軸を温度感にしています。基本的に、左下に案件カードがたくさん出来、そこから温度感とステータスが進行するにつれ、右上に移動していくというような状況です。常に、真ん中から右上の案件ほど、手厚く対応する必要がある、という感じですね。
受注時には、妻と共有しているLINEグループに通知が入る
このNotionは、PipedreamというiPaaS（ZapierやMakeと同じようなやつ）と連携しています。
案件が受注ステータスに切り替わった場合、1時間以内に、Pipedreamが発動し、妻と私とLINE APIが入っているグループチャットに、受注通知が流れます。
制作的側面からもNotionを使って案件管理する
既に各プロパティを紹介したところで、受注後に関わる情報もあったので、既に想像がついている方もいらっしゃると思います。
特にStatusは受注後の設定もあるので、それを見越した設計になっているのですが、受注後も案件はそのまま利用します。
ここでは、受注後の案件がどのように管理されるか見てみましょう。
今月は割と忙しく無かったのでこんな感じですが、忙しい時は、案件がもっと並びますね。
商談管理をNotionで行う
さて、話は営業面へと戻りますが、商談管理はみなさんどのようにしていますか？ 営業の心理学として、接触回数が多いほど受注には有利という話がありますね。当然、獲りたい案件や確度の高い案件ほど、回数の多い接触（直接会うだけではなく、メールや電話も含む）が必要です。
当社のNotionでは、対面商談、オンライン商談、メール、電話全てを「商談」としていて、それを商談データベースにまとめています。
当然、商談データベースは、案件が具体化してくると案件レコードに紐づきます。商談の経緯をデータベースに書いておけば、その案件の背景を思い起こすのにも使えます。チームワークであれば、製作陣が営業チームがどのような商談をして受注に至ったかもわかるわけですね。
商談は不対応確定するまでは、1週間以上間を空けずに連絡を入れたいもの。そこで、こちらが連絡待ちの状態になる場合は、1週間後に【予】という接頭詞をつけ、こちらから状況確認をする予定の商談レコードを入れておきます。
ちなみに、ここでいう力不足架電ヒアリング、というのは、失注して時間が経ってしまったクライアントに、再度連絡を入れるアクティビティのことです。
失注になった経緯や背景を教えてもらうことを口実に連絡をとります。力不足というのは、平たく言えば「なんで発注してくれんかったん？」っていうことですが、ここはビジネスですので、大人な言い回しをします。「前回はご発注に至らなかったわけですが、私共が努力不足だった点、力不足だった点について、おうかがいできないでしょうか？」と言い回すわけですね。
もちろん、失注に至った経緯や背景は営業上とても大切な情報ですが、時間が経って、新たにニーズがないか探るチャンスでもあります。そういう場合は「時間も経ち、こちらも新たな実績や新しいサービスなども出来ましたので、一度ご紹介の機会を作っていただけませんでしょうか？」というトークスクリプトができます。
実際、このアクティビティとトークスクリプトで、一度失注したものの、別の案件を発注いただいたこともあるので、力不足ヒアリングは、かなり有効な営業手段だと思います。
納品したら、案件を振り返ろう
多くの組織で出来てるようで出来ていない、案件単位の振り返りを実施しています。これもNotionがあればこそで、Notionでなければ、あるいは高価なERPパッケージじゃないと出来ないことだと思います。
案件の赤黒判定とは
その案件を受注したら、売上は当然報酬額となります。
一方で、その案件には、協業パートナーさんに外注しないといけない作業があったりもします。つまり外注費が発生するわけです。
また、自分の給料もそこから払わないといけません。私は現在自分の給与を時給6,250円に設定していますが、この金額×かかった時間や拘束時間で算出すると、それが原価となります。
既に営業関連のプロパティで紹介しましたが、以下の考えでいます。
売上 → 案件の報酬
粗利 → 売上ー外注費の総額
原価 → 作業にかかった時間×自分の設定時給
営業利益 → 粗利ー原価
これを算出するために、別途経費と作業記録というデータベースを作っています。
経費データベースを見てみる
営業系や案件データベースに比べれば、プロパティの数は少ないです。
種別 経費の種別です。種類は以下の通り。
写真撮影／動画撮影／音声収録／イラスト作成／デザインカンプ作成／交通費／宿泊費／イベント参加費／接待交際費／素材購入
対象案件 その経費が、特定の案件に紐づく場合において、案件レコードとリレーションを貼ります。営業目的やマーケティング目的の場合は空欄です。
支払い期日 契約時に定めた支払いの期日
発注先 発注先が企業レコードに存在する場合、リレーションを貼ります。交通機関などの場合は空欄。
発注日 発注した日です。
納品日 納品された日です。
見積書 見積書をいただいた場合には、ここに格納します。
金額 発注金額です。税込です。
担当者 担当者レコードに担当者がいる場合、設定します。
対象マーケ 別途設定しているマーケティングというデータベースとのリレーションです。特定のマーケティングアクティビティに紐づく経費の場合、そこに設定します。
作業記録データベースを見てみる
さて、経費の次は作業時間です。自分が案件に対して費やした時間を記録していきます。
私は以前Togglという作業工数を管理するサービスを使っていたのですが、Notionを使い始めてから、こちらに移管しました。
Togglと違って自分が１から作っていかなければいけないのですが、Togglを使っていたおかげで、作らないといけない設定項目などが割とイメージしやすかったですね。
かかった時間 後述のプロパティ「作業時間」から、算出した時間数です。小数点第１位までに丸める計算を関数で行っています。コードは以下の通り。
round(toNumber(dateBetween(end(prop("作業時間")), start(prop("作業時間")), "minutes") / 60) * 100) / 100クライアント 作業が紐づいている案件のクライアント名をロールアップで引っ張っています。
作業時間 作業にかかった時間です。開始時刻と終了時刻を入力するだけで、前述の「かかった時間」プロパティに算出されるようにしています。
作業種別 作業の種別です。案件ごとに、どのような作業区分に時間がかかっているかの分析をするために設定しています。
マーケティング 営業に繋げるための活動に費やした時間。対象はマーケティング経費
営業活動 案件獲得のために、特定の顧客とやり取りした時間。対象は営業経費。
企画立案 案件の企画を立案するために必要とした時間。原則、企画立案費用として見積もり項目に立てた分に対する時間。対象は原価。
進行管理 案件の進行管理に必要とした時間。実際に制作として手を動かし、成果物生産のために要した時間ではないが、案件納品のためには必要な作業の工数。対象は原価。
制作 デザインや編集、撮影など。案件納品のために必要な成果物生産のための時間。対象は原価。
制作：システム組み込み 制作の中での細分化項目。今後、もう少し増える予定
有償セミナー 収入が発生するセミナーを実施した時間。対象は原価
総務 請求書作成などのバックオフィス業務。収入を産まない業務の時間。対象はバックオフィス原価。
案件 その作業が紐づく案件レコードとのリレーション。他のデータベースで利用するため、関数で表示。
案件 その作業が紐づく案件レコードとのリレーションです。
タスク その作業が紐づくタスクとのリレーション。そのタスクが実際にかかった時間を算出するためのリレーションです。
案件(継承) タスクと紐づけた時に、そのタスクが特定の案件と紐づいている場合にロールアップで表示します。この場合は、案件プロパティーに入力する必要は特になし。
今月 別のビューで、今月の作業実績を表示させるための関数。コードは以下の通り。
formatDate(prop("作業時間"), "YM") == formatDate(now(), "YM")今週 別のビューで、今週の作業実績を表示させるための関数。コードは以下の通り。
formatDate(prop("作業時間"), "W") == formatDate(now(), "W")さあ、損益計算をしよう！
さて、ここまで経費と作業時間が入力できたら、先述の粗利と営業利益が算出できるわけですね。
以下は、損益というページを作り、それぞれ損益分析のビューを作っています。
2021年も2022年も案件少ないし、今年は赤字やんけ… と思われるかもしれませんが、ここには出ていない案件もあるのでご心配なく（笑）
これで、案件ごとに赤字だったか黒字だったかがわかるようになっているわけですね。
あの案件、いつ入金するんだっけ？
さて、フリーランスや経営の経験がある人は、入金にヤキモキしますよね。会社員の人にはなかなか想像できないと思いますが…
そもそも、案件によって、その報酬が支払われるのは異なります。
一般的には、毎月末日で締めて請求書発行、翌月の末日までに銀行振込という、当月末締め、翌月末払いというのが一般的かと思います。
ただ、会社によっては、当月末締め、翌々月10日払いとか、当月20日締め、翌月10日払いなど、イレギュラーもあります。
つまり、案件によって、入金日が異なります。
また、案件によっては着手金だったり中間金といった、請求を複数回に分ける案件もあります（長期案件にありがちですね）
そこで、うちのNotionでは請求というデータベースを作り、案件ごとに請求を管理しています。
このように、請求日と入金予定日を設定し、入金タイミングがいつになるかを関数で判断しています。
もっとも、本当は請求日だけ入力すれば、各企業の締め日、払い日プロパティから算出して自動的に入金予定日を表示させたかったのですが、今の所プロパティの準備ができているだけで、機能実装には至っていません… 余裕ができたらやりたいです。
ちなみに、こちらは別のビューで、今月と来月の入金が把握できるようになっています。これは妻たっての希望の機能だったので、妻と共有しているビューになります。
まとめ：営業活動から納品後の振り返りまで、Notionで一気通貫に分析しています。
いかがだったでしょうか。これがフリーランスで一人社長のNotionのSFA/CRM/ERP的な利用です。正直、やりたいことの1/3程度しかできていないのですが、もっと機能実装して、日々の業務を効率化し、見えなかった成果をどんどんどんどん見える化していきたいですね。
ここで紹介してないビューもたくさんあるので、折に触れて別の機会にご紹介していきたいと思います。
最後に：こんなNotionの使い方を自社でやってみたい方、お問い合わせください
このNotionの活用方法は、私がWeb制作会社に勤めていた頃やりたかった機能です。当時はNotionはまだなく、Togglやスプレッドシート、boardという営業と請求書管理のシステムを横断して手作業でやっていました。
今、当時の会社でこの仕組みを導入できていたら、もっと違った働き方や、会社への貢献もあったと思います。特にTogglでの工数管理はインパクトがったので、それ以上のインパクトが出せたかもしれません。
今自分の口惜しい点としては、これを1人でやっていることです。妻というオブザーバーがいるので、2人で共有はしていますが、データを入力するのは基本自分一人。自分の振り返りだけです。
ところが、これが組織になり、案件の数も増えると、組織へのインパクトも異なると思います。
この仕組みを導入されたい組織の方は、ご相談に応じますし、内容によってはNotionの設計・実装・外部API連携・API作成などの製造やコンサルティングも行えますので、当社のホームページよりお問い合わせください。
明日のNotion Community Advent Calendar 2022は、弘松リク / gaz,Inc.さんの、「社内のnotion改築について書きます！」です。
頂いたサポートはクリエイター活動の主に機材費・出張費に充てます！ より良い作品アウトプットのためにご協力よろしくお願いします！