コードを一行も書かずにクライアントポータルを作る方法

どんなフリーランサーや小さな制作会社も、いつしか第二の仕事を抱えることになります。クライアントに、今どうなっているかを伝えるという仕事です。

成果物を仕上げて、PDFをメールで送り、宛先を間違えてccに入れる。クライアントは古いスレッドに返信してくる。誰かが請求書はどこかと尋ねる。また別の誰かがウェブサイトはもうできたのかと尋ねる。月曜の朝、誰が何を尋ねて、それに自分が答えたかどうかを把握するためだけに、40分を費やすのです。

クライアントポータルがこれを解決します。クライアントがログインして、何が起きているかを — プロジェクトの状況、ファイル、請求書、メッセージを — あなたに尋ねることなく見られる、ひとつの場所です。かつての問題は、それを作るには開発者と6週間、そして20社以上のクライアントを抱える制作会社にしか割に合わない予算が必要だった、ということでした。

AIアプリビルダーがあれば、午後のあいだにコードを書かずにクライアントポータルを作ることができます。その方法を解説します。

クライアントポータルに本当に必要なもの

AIビルダーに何かを作るよう頼む前に、「クライアントポータル」が具体的に何を意味するのかを知っておくと役立ちます。その多くは、見た目よりもシンプルです。

核心において、クライアントポータルとは、次のものを備えた非公開のウェブサイトにすぎません。

ログイン — クライアントはそれぞれ自分のアカウントを持ち、自分のプロジェクトだけを見られる
プロジェクト状況ページ — 今どのフェーズにいて、何が終わり、次は何か
ファイルのセクション — 成果物、契約書、参考資料
メッセージのスレッド — 少なくとも、何もメールに埋もれて消えないようにするためのメモ欄

それだけです。それ以外のすべて（請求書、工数管理、フィードバックフォーム）は、あとから重ねていける付け足しです。まずこの4つから始めれば、あなたの月曜を食いつぶす「今どうなってる？」という質問の90%をカバーできます。

AIビルダーへの伝え方

AIで作るときにいちばんよくあるミスは、一度にあれもこれもと求めることです。「プロジェクト管理、請求、ファイル共有、チャットシステムを備えたクライアントポータルを作って」というのは、テストしづらく、直すのはもっと大変な、とりとめのない初稿を生み出します。

そうではなく、ひとつのユースケースとひとつのペルソナから始めましょう。たとえばこんなふうに。

「管理者としてログインしてプロジェクトを作成できるウェブアプリを作って。各プロジェクトには名前、ステータス（計画中／進行中／レビュー／完了）、メモ欄がある。クライアントをメールで招待でき、彼らはログインして自分のプロジェクトとそのステータス、メモだけを見られる。」

この説明は2段落に収まり、その日のうちに実際に使えるものを生み出します。明確なデータモデル（ステータスとメモを持つプロジェクト）、2つのユーザー役割（あなたとクライアント）、そしてひとつの重要な制約（クライアントは自分のデータだけを見る）を備えています。

それが動いたら、ファイルを追加します。それから、たぶんメッセージを。追加のひとつひとつが、別々の依頼です。

クライアントポータルで本当に重要な3つのこと

すべての機能が同じだけ重要なわけではありません。この3つが、クライアントが本当にポータルを使うか、それとも相変わらずメールしてくるかを決めます。

1. ログインは簡単でなければならない。

もしクライアントが、プロジェクトの状況を確認するために、3か月前に設定したパスワードを思い出さなければならないなら、彼らは代わりにメールしてきます。技術にうとい人たちにとっていちばんいい仕組みは、マジックリンクログインです。メールアドレスを入力すると、リンクが届き、それをクリックすると入れる。忘れるパスワードはありません。

AIビルダーにこう伝えましょう。「マジックリンクログインを使って — ユーザーがメールアドレスを入力すると、リンクが届き、それをクリックするとログインできる。」 最近のたいていのAIビルダーは、この一文でこれを組み上げられます。

2. ステータスはクリックしなくても見えなければならない。

クライアントがポータルを開いたとき、最初に目に入るものは、何か役に立つことを伝えるべきです。ナビゲーションメニューではなく。空っぽのダッシュボードでもなく。プロジェクトのステータスを、まさにそこに、はっきりとしたラベルとともに。

「ダッシュボードでは、各プロジェクトをカードとして表示し、プロジェクト名と現在のステータスを目立つように見せて。ステータスは色分けして。完了は緑、進行中は黄、レビューはオレンジ、計画中はグレー。」

3. ファイルのセクションは、ちゃんと使えなければならない。

クライアントに何かをダウンロードさせ、それを別の場所に再アップロードさせ、確認のメールを送らせるような「ファイル共有」は、メールよりも悪いものです。ビルダーに、プロジェクトにファイルをアップロードできて、クライアントがそれを直接ダウンロードできるようにしてもらいましょう。それ以上に凝ったものは要りません。

初日にやること

うまくいく、ちょうどこの順番です。

プロジェクト、ステータス、役割（管理者＋クライアント）を備えた基本のアプリを作る。
自分を管理者として追加し、ダミーのプロジェクトを1つ作り、ダミーのクライアントを1人追加する。
ダミーのクライアントとしてログインする（別のブラウザかシークレットモードを使う）。そのプロジェクトが見えるか？そのプロジェクトだけが見えるか？
マジックリンクログインを追加する。
まっさらなシークレットウィンドウから、ログインの一連の流れをテストする。
ファイルのアップロードを追加する。
本物のクライアントを1人、本物のプロジェクトを1つ追加し、試してもらう。

ステップ7は大切です。あと5つの機能を作る前に、それが現実の世界で機能するかどうかを確かめましょう。本物のクライアントは、何が分かりにくいかをすぐに教えてくれます — そしてそれは、ほとんどの場合、あなたが予想していたものではありません。

ポータルが、その価値以上に厄介になるとき

クライアントポータルが意味をなすのは、こんなときです。

同時に3〜4社以上のアクティブなクライアントを抱えている
クライアントが状況を尋ねる頻度が、実際に時間を奪うほど高い
「何か用意できたらメールします」よりもプロらしく見せたい

おそらく意味をなさないのは、同時に1社だけのクライアントしかいない、プロジェクトの周期が非常に短い（数週ではなく数日）、あるいはクライアントがすでに、お互いに使い慣れたツールを使っている、といった場合です。

判断の目安。もし「今どうなってる？」に答えるのに週1時間以上を費やしているなら、ポータルは、それを作る午後の時間に見合うだけの元を取ってくれます。

作ったあとに

クライアントポータルにおける本当のリスクは、技術ではありません — 定着です。何年もあなたにメールしてきたクライアントは、変える理由を与えない限り、相変わらずメールしてきます。初めてポータルを共有するときは、ただリンクを送るのではいけません。リンクを送り、通話で一緒にログインし、プロジェクトを確認するときに彼らが何を目にするのかを、まさにその場で見せてあげましょう。

一度ログインして役に立つものを目にしたクライアントは、また忘れずにログインしてくれます。何の文脈もなくリンクを受け取ったクライアントは、決してそれを開きません。

これが実際にどんな感じになるか気になるなら、まずいちばんシンプルなバージョンを作ってみてください — プロジェクトとステータスだけ。あとからいくらでも足せます。来月作るかもしれない完璧なバージョンよりも、今日仕上げられるバージョンのほうが価値があるのです。