顧客ポータルの作り方:ファイル、進捗、請求書、権限
顧客ポータルは、事業者の顧客それぞれがログインして、自分の案件の進捗、共有されたファイル、未処理の依頼、請求書を確認できる非公開の領域です。作るには、顧客が最初の10秒で何を見る必要があるのかを定義し、顧客、案件、ファイルの関係をモデル化して、すべてのレコードがひとりの顧客に属するようにし、顧客が自分のレコードしか見られないことをサーバー側で強制し、アップロードされたファイルは非公開のストレージに保存します。機能の一覧は短くて構いません。権限を正しく設計することが重要です。
事業者が顧客ポータルを作る理由
ポータルは多くの場合、大量のメールのやり取り、共有フォルダ、「進捗はどうですか?」というメッセージの山を置き換えます。代理店、会計士、コンサルタント、建設業者、スタジオ、サービス業など、さまざまな事業者が使っています。良いポータルは次のことを実現します。
- 顧客が聞く前に、進捗の質問に答えておける。
- ファイルを1か所にまとめ、最新版が一目で分かる。
- 依頼に正式な置き場所を与え、メールに散らばらないようにする。
- 整理された事業者に見えるため、継続や紹介につながる。
顧客が1〜2社で、機微な情報がない場合は、共有ドキュメントやフォルダで十分かもしれません。多くの顧客がいる、繰り返しの仕事がある、あるいは顧客同士に見せるべきでない情報がある場合に、ポータルを作る価値があります。
顧客ポータルに必要なもの
| 部分 | 顧客に見えるもの | 事業者に見えるもの |
|---|---|---|
| ログイン | 自分のアカウント | すべての顧客とそのユーザー |
| 概要 | 現在の進捗、次のマイルストーン、顧客側で待っていること | すべての案件の進捗を一目で |
| ファイル | 顧客と共有されたドキュメントや成果物、顧客がアップロードしたもの | 顧客と案件ごとのすべてのファイル |
| 依頼 | 何かを頼むためのフォーム、過去の依頼の状況 | 担当を割り当てて回答するための依頼キュー |
| メッセージまたは更新 | 自分の案件の更新のタイムライン | 同じタイムラインに、顧客からは見えない社内メモを加えたもの |
| 請求書 | 支払うべき金額と支払い済みの金額、支払いリンク | 顧客をまたいだ請求の状況 |
| 承認 | デザイン、見積もり、成果物を承認する | 誰がいつ何を承認したか |
まずはログイン、概要、ファイル、依頼から始めてください。請求書、承認、メッセージのやり取りは、顧客が実際に必要としたときに追加します。
データ
典型的なポータルには、顧客(会社)、顧客ユーザー(ログインする人。1つの顧客に所属)、事業者側のメンバー、案件(1つの顧客に所属)、マイルストーンや進捗の更新、ファイル(案件に所属)、依頼、そして必要に応じて請求書があります。重要な設計ルールは、すべてのレコードが、ちょうど1つの顧客にたどれることです。そうすれば権限が分かりやすくなり、確認もしやすくなります。
権限
次の内容を書き出し、テストしてください。
- 顧客ユーザーは、自社に属する案件、ファイル、依頼、請求書だけを見られる。
- 社内メモは、顧客には決して表示されない。
- 社内のメンバーは、担当している顧客だけを見られる。小規模な事業者なら、すべての顧客を見られる。
- ファイルのリンクは非公開で期限付きにする。誰でも共有したり推測したりできる公開URLにしない。
- 顧客ユーザーを削除したら、そのアクセス権はすぐに無効になる。
チェックは必ずサーバー側で行ってください。すべての顧客のデータを読み込んでから、ブラウザ側で絞り込むポータルは、非公開とは言えません。
判断とトレードオフ
ログイン方式
顧客はあまりログインしないため、パスワードを忘れがちです。ポータルでは、マジックリンク(メールで届くサインイン用のリンク)や、顧客がすでに使っているアカウントでのシングルサインオンのほうが、パスワードよりうまくいくことが多いです。どの方式を選ぶにしても、顧客は自分の側から招待してください。誰でもアカウントを作って会社を選べるようにしてはいけません。選択肢の比較については、アプリにログインを追加する方法をご覧ください。
1つのポータルか、顧客ごとのポータルか
顧客ごとにサイトを分けるより、顧客リストを持つ1つのアプリのほうが保守が簡単です。それでも、同じアプリの中で、顧客ごとにロゴや案件名などのブランドを変えることはできます。
ファイル
アップロードをサーバーのディスクに保存するのではなく、適切なファイルストレージを使い、最大ファイルサイズを設定し、可能であればファイルの種類も制限してください。権限チェックに通ったユーザーにだけファイルを配信します。バージョンの扱いも決めてください。上書きにするか、履歴を残すか。
請求書と支払い
会計ツールの請求書を表示する、ポータルの中で簡単な請求書を作る、あるいはホスト型の支払いページにリンクする、という方法があります。本格的な請求システムを作るのは、それ自体が1つのプロジェクトになります。詳しくは請求書アプリの作り方をご覧ください。ポータルでは、請求書の状況と、ホスト型の決済ページへの「今すぐ支払う」リンクを表示するだけで、たいてい十分です。
連携
多くのポータルは、2か所を更新しなくて済むように、すでに使っているツール(案件管理ツール、CRM、会計ソフト)から進捗を取得します。連携は時間の節約になりますが、セットアップと保守の手間も増えます。チームがすでにCRMを使っているなら、同じデータの上にポータルを構築することを検討してください。
AIビルダーへの最初のプロンプト
Northlight(小さなWebデザイン代理店)のための顧客ポータルを作ってください。顧客は会社単位で、会社ごとに1人以上の顧客ユーザーがログインします。顧客ユーザーには、自社の案件だけが見えるようにしてください。案件ごとに、現在の進捗(発見、デザイン、構築、レビュー、公開)、日付付きの次のマイルストーン、両者がアップロードとダウンロードできるファイル領域(PDF、画像、ZIP、最大50 MB)、依頼フォーム(タイトル、詳細、優先度)と過去の依頼の一覧および状況、更新のタイムラインを表示してください。代理店のスタッフは、すべての顧客を見られる管理画面を使い、案件の進捗を変更し、更新を投稿し、顧客には見えない社内メモを追加し、依頼に回答できるようにしてください。すべてのアクセスルールはサーバー側で強制してください。データはデータベースに、ファイルは期限付きのダウンロードリンクを持つ非公開のファイルストレージに保存してください。今はログインのプレースホルダーで構いません。本物の認証は次に追加します。プロフェッショナルで clean なデザインにし、スマートフォンでも使えるようにしてください。
段階を追って作ってください。データと管理画面を先に、次に顧客向けの画面、次に本物のログイン、その後にファイル、最後に追加機能です。AIアプリビルダー向けのプロンプトの書き方に、さらなるパターンがあります。
構築の手順
- 顧客が最初に見る必要があるものを一覧にする。 そして、現在メールで何を問い合わせてくるのかを確認します。
- データを設計する。 すべてのレコードがひとりの顧客に属するようにします。
- 管理画面を作り、 実際の顧客1社分のデータを入力します。
- その顧客向けの画面を作る。
- 本物のログインを追加する。 招待は事業者側から行います。
- ファイルを追加する。 非公開のストレージに保存し、ダウンロード時に権限チェックを行います。
- 権限をテストする。 テスト用の顧客を2社作り、相手のデータを見るためにできることをすべて試してください。URLのIDを変える、ファイルのリンクを推測する、古い招待を使う、などです。
- 依頼とメール通知を追加する。
- 親しい顧客1〜2社でパイロット運用する。 まだメールで何を問い合わせてくるのかを聞いてください。
- そのフィードバックをもとに、請求書、承認、連携を追加する。
よくある間違い
- サーバーではなくブラウザ側で絞り込む。 最も深刻なポータルのバグです。すべての顧客のデータはダウンロードされていて、ただ隠されているだけです。
- 公開のファイルURL。 誰でも開ける共有リンクは、ポータルの意味を損ないます。
- 誰でも登録できる。 顧客は招待されるべきで、自分でアカウントを作り会社を選べてはいけません。
- リリース時に機能を詰め込みすぎる。 顧客が理解できないポータルは、メールの代わりには使われずに放置されます。
- 情報源が2つある。 進捗が案件管理ツールとポータルの両方にあると、どちらかが古くなります。1か所を正とするか、同期させてください。
- 退職時の処理を忘れる。 顧客の担当者が退職したら、そのアクセス権は必ず終了させる必要があります。
- 規制対象のデータを適切な保護なしに保存する。 健康、法律、金融の記録には、満たすべき法的要件がある場合があります。
費用とツール
運用コストは、ホスティング、データベース、ファイルストレージ(共有するファイルの量に応じて増えます)、そして招待や通知のためのメール配信サービスです。ホスト型のログインサービスや決済サービスを使う場合は、料金を各社のサイトで確認してください。座席ごとのポータルソフトと比べると、自作のポータルの費用は顧客数ではなく利用量に応じて増えていきます。
既製の製品のほうが適している場合
ポータル専用のソフトウェアや、会計・法務・業務管理ツールに組み込まれたポータル機能が適していることもあります。業界特有の要件がある場合(法的効力を持つ電子署名、規制された記録の保存、税務書類のやり取りなど)や、既存のツールにすでにポータルが含まれている場合です。それらの製品は、コンプライアンスとサポートをすでに解決しています。一方、自作が向いているのは、一般的なポータルがワークフローに合わない場合、自社のブランドとプロセスに正確に合わせたい場合、あるいは顧客ごと・座席ごとの料金体系がもはや合わなくなった場合です。
Mythexでの構築
Mythexでは、上のプロンプトのポータルを作れます。顧客向けの画面、管理画面、依頼、タイムラインを備え、アプリが必要とする時点で専用のPostgresデータベースとファイルストレージを追加します。顧客のログインは持ち込み型です。Mythexのアカウントは、アプリを作る人のためのものです。顧客向けの認証方式は自分で選び、エージェントが組み込みます。Mythexには電子署名や請求書の機能は組み込まれていません。そのため、これらは連携するか、自分で作る機能になります。APIキーはプロジェクトのシークレットとして保存し、公開前に、アプリ内のテスター機能で顧客側と管理側の操作を通して確認してください。
ドキュメントには顧客ポータルのユースケースがあり、ファイルストレージとログインの追加についても説明しています。出発点としては、代理店向けの顧客ポータルのテンプレートか、アプリのテンプレートの一覧をご覧ください。実際の顧客を招待する前に、AIで作ったアプリのセキュリティチェックリストで確認してください。
よくある質問
顧客ポータルとは何ですか?
顧客ポータルとは、事業者の顧客が作業の進捗を確認したり、ファイルをやり取りしたり、依頼を出したり、請求書を見たりできる、ログインが必要な非公開の領域です。すべてをメールで行う代わりに使います。各顧客が見られるのは自分の情報だけです。
顧客ポータルにはどんな機能が必要ですか?
安全なログイン、案件ごとの進捗の概要、ファイルの領域、依頼やメッセージを送る手段から始めてください。請求書、承認、電子署名、予約は、顧客が実際に必要とするなら後から追加できます。
自分で顧客ポータルを作っても安全ですか?
次のことを守れば安全です。各顧客が自分のレコードとファイルしか見られないことをサーバー側で強制し、適切なログインを使い、ファイルは非公開のストレージに保存し、別の顧客のデータを開こうとしてテストすることです。健康記録などの規制された情報には特別な注意が必要で、専門の製品を使うほうが適している場合もあります。
コードを書かずに顧客ポータルを作れますか?
はい、作れます。AIアプリビルダーやノーコードツールは、説明から顧客ポータルを作れます。ただし、誰に何が見えるかを正確に指定し、実際の顧客を招待する前にそのルールを入念にテストする必要があります。