クライアントプロジェクトを請求する — Patter

このルーティンについて

プロジェクトの終わりは、楽な部分のはずだ。仕事は終わった。クライアントは満足している、あるいはまあ満足している。残るのは事務作業だけ。

それなのに、ここで止まってしまうことが多い。納品物を送っても返事が遅い、請求書は本来より1週間遅れる、ファイルは3か所に散らばる、フォローアップのメールは送りにくいからという理由で4日間下書きのままになる。

どれも避けられないことではない。ルーティンがないときに起きることだ。

クローズは、それ自体がプロジェクトの一つのフェーズだ。固有のステップがあり、決まった順番がある。承認の前に請求書を出さない。承認が届いたらすぐに請求書を出す。気まずさが先送りを上回ったときではなく、スケジュールどおりにフォローする。プロジェクトを頭の中で終わらせる前にファイルをアーカイブする——6か月後に何が何だったか思い出せなくなってからではなく。

きちんとやれば、クローズは1時間で終わる。ルーティンなしでやると、3週間かかって、余計な不安も一緒についてくる。

クライアントプロジェクトのクローズ

納品物を最終確認する手元を離れる前に。全体を見直すのではなく、見落としたら恥ずかしいことがないか最後に確認する。
最終納品物をクライアントに送る短い一文を添えて。何を送るか、何が必要か、いつまでに。明確に、余計な言葉なしに。
返答がなければフォローアップする合意した期間、または合意がなければ妥当な期間待つ。それから一度、直接フォローする。まだ返答がなければ @8。
承認を書面でもらうメールの返信で十分。「承認しました」と読み取れるものが必要。Slackのいいねではない。
請求書を発行する承認が届いたらすぐに。今日の後でではなく、今。待てば待つほど、入金も遅れる。
正確な情報で請求書を送るクライアント名、住所、プロジェクト番号、支払条件、支払期限。送る前に確認する。ここでのミスは、完全にこちらの責任による遅延を招く。
請求書が届いたか確認する特に、請求書が別の担当者や部署に届く大きな組織と仕事をしている場合は必ず。一度の確認で後の督促が大幅に減る。
未払いの場合はフォローアップする支払期日に、過ぎてからではなく。短く、事実だけ伝える。聞くことを謝らない。必要なら再び @8。
プロジェクトファイルをアーカイブするすべて一か所に、明確な名前で、2年後にも理解できる構造で。デスクトップではない。
預かっているクライアントの素材をバックアップするクライアントのファイルを持っている場合、複数の場所に保存されているか確認する。これは省略できない。
短いプロジェクトメモを書くうまくいったこと、そうでなかったこと、次回変えること。3文で十分。これは自分のためのもの。
システム上でプロジェクトを閉じる何を使っていても——完了としてマークする。ステータスを更新し、スレッドを閉じ、進行中のリストから外す。終わった仕事は現在の仕事の隣にあるべきではない。

自分流にアレンジ

ステップ3とステップ8のつながりは、多くのフリーランサーが嫌いな部分だ。フォローアップは、十分待って本当に苛立つまでは気まずく感じる——その頃にはさらに悪化している。ルーティンはそれを個人的なことではなく手順にする。追いかけているからではなく、次のステップだからフォローする。

承認が予想より長引いていて請求書が時間的に切迫している場合、提出済みの納品物に対して請求書を発行し、最終支払いは承認後という注記を添えることが妥当な場合もある。うまくいくかどうかは契約とクライアントによる。その状況になる前に知っておく価値がある。

ステップ11は積み重なるものだ。2年分の短いプロジェクトメモは思った以上に価値がある——パターンが見えてくる、スコープクリープが可視化される、収益性が高そうに見えたプロジェクトが、実際に何が起きたかを書き出すとそうでないことが多い。

クライアントとの正式な振り返りが必要なプロジェクトもある。ほとんどはそうではない。必要な場合は、ステップ5の前に追加する——その会話は請求書を送る前に行うべきで、後ではない。