顧客ポータルのプロンプト
この顧客ポータル用プロンプトは、AgentUIにそのまま貼り付けて使えるように書かれています。テーブル、フィールド、顧客ログイン、顧客ごとのアクセス権のルール、画面構成まで明記しているので、最初の出力が空の枠ではなく動くポータルとして返ってきます。そのままコピーしても、フィールド名を普段お使いの言い方に変えてもかまいません。
プロンプトは英語のままです。ビルダーが読むのはこの文章です。
Build a client portal for my company.
Create a shared database with four tables: clients (company name, primary contact name, contact email, phone, account status, onboarding date), projects (linked to a client, project name, stage, owner on my team, start date, target date, percent complete), deliverables (linked to a project, title, description, due date, file attachment, approval status of Draft / Awaiting client / Approved / Changes requested, signed off by, signed off at) and invoices (linked to a client, invoice number, amount, issue date, due date, paid status, payment date).
Give each client their own login. A logged-in client must only ever see the projects, deliverables, invoices and files where the client record is theirs — never another client's records, and never internal-only fields such as the team owner or internal notes. Give my team two internal roles: staff, who can read and edit everything, and admin, who can additionally invite clients and change permissions.
Build three views. A client dashboard showing their active projects with progress, deliverables awaiting their approval, and their open balance. A deliverables view where the client can open a file, approve it or request changes, and leave a comment. An internal view for my team showing every client, every project stage and every overdue invoice.
Record who changed what and when in an audit log. Email the client when a new deliverable is waiting on their approval.この顧客ポータル用プロンプトが機能する理由
多くのプロンプトは「顧客ポータルを作って」で終わってしまうため、うまくいきません。上のプロンプトは、4つのテーブル、その中のフィールド、社内の2つのロール、顧客は自分のレコードしか見られないというルール、そして3つの画面を明示しています。重要な部分を推測に任せていません。貼り付けたあとの流れを最初から確認したい方は、自社の顧客ポータルを作る流れの全体像をご覧ください。要点はこうです。プロンプトが実際の共有データベースになり、実際の顧客ログインが用意され、チームがあとから編集し続けられるポータルになります。
テーブルを名指しする
顧客、プロジェクト、成果物、請求書——フィールドまで書き出し、暗黙に任せません。
アクセス権のルールを明記する
「顧客は自分のレコードしか見られない」がプロンプトで最も重要な一文です。
画面ではなく用途別のビューを頼む
顧客用ダッシュボード、承認用ビュー、社内用ビュー——役割3つ、ビュー3つ。
監査ログを要求する
誰がいつ何を変えたかを初日から記録し、後付けにしません。
コピーして使える顧客ポータル用プロンプト、さらに4つ
構造は同じで、業種が違います。自社に近いものを選び、コピーして、貼り付ける前にフィールド名だけ直してください。
Build a client portal for my agency.
Create tables for clients (company, main contact, retainer amount, contract end date), campaigns (linked to a client, channel, monthly budget, status), assets (linked to a campaign, file, version, approval status of Awaiting client / Approved / Changes requested) and monthly reports (linked to a client, month, spend, results summary, published flag).
Each client logs in and sees only their own campaigns, assets and published reports. Hide internal fields — margin, hours logged and internal notes — from the client role entirely. My team gets a staff role that can edit everything and an admin role that can invite clients.
Build a client dashboard with campaigns in flight, assets waiting on their approval and the latest published report. Let the client approve an asset or request changes with a comment. Keep an audit log of every approval and every permission change.キャンペーンを運用し、クリエイティブの顧客承認が必要な場合に。
Build a client portal for my accounting firm.
Create tables for clients (business name, entity type, tax ID reference, fiscal year end, assigned accountant), document requests (linked to a client, document name, period, due date, status of Requested / Uploaded / Reviewed / Rejected, uploaded file), filings (linked to a client, filing type, period, due date, status, filed date) and invoices (linked to a client, number, amount, due date, paid status).
Each client signs in and sees only their own document requests, filings and invoices. Clients can upload a requested document and see what is still outstanding, but cannot see another client's records or our internal review notes.
Build a client checklist view showing what we still need from them and by when, a filings status view, and an internal view for my team showing every outstanding request across all clients sorted by due date. Log who uploaded, reviewed or rejected each document and when.書類を集め、顧客の申告を代行している場合に。
Build a client onboarding portal.
Create tables for clients (company, primary contact, contact email, signed date, assigned onboarding manager), onboarding steps (linked to a client, step name, order, owner of Client or Us, status of Not started / In progress / Blocked / Done, due date, completed date), intake answers (linked to a client, question, answer, answered at) and onboarding documents (linked to a client, document name, file, status).
Each new client logs in and sees a progress tracker of their own onboarding steps only — what is done, what is theirs to complete next, and what we owe them. Let them fill in the intake form, upload documents and mark their own steps complete. They cannot see other clients or our internal owner notes.
Build an internal view showing every client in onboarding, which step they are stuck on and how many days they have been there. Log every status change with who made it and when.新規顧客の最初の30日をやり切るのが大変な場合に。
Build a white-label client portal that carries my company's branding, not a vendor's.
Use my logo, my brand colours and my company name across the sign-in screen, the navigation and every email the portal sends.
Create tables for clients (company, primary contact, contact email, plan, account manager), work items (linked to a client, title, stage, owner, due date), shared files (linked to a client, file, uploaded by, shared date) and messages (linked to a client, sender, body, sent at).
Each client logs in to a branded portal and sees only their own work items, files and message thread. My team gets staff and admin roles; admins can invite clients and change branding. Build a client dashboard with work in progress, files shared with them and their message thread, plus an internal view of every client account. Keep an audit log of who changed what and when.ポータルを自社製品として見せたい場合に。
貼り付ける前にプロンプトで直しておくところ
直す価値があるのは3か所です。フィールド名——チームが実際に使っている言葉に置き換えてください。あとから変更もできますが、最初から自社の言葉で始めるほうが楽です。ステータス——Draft / Awaiting client / Approved を、自社の工程での呼び方に差し替えます。権限——顧客に絶対に見せない項目(原価率、社内メモ、工数)を明記してください。除外しなかったものは表示される可能性があります。
- maria.s renamed deliverables → matterstoday 10:04
- maria.s set internal_notes → staff onlytoday 10:05
- admin invited client haldentoday 10:11
生成される顧客ポータルの中身
顧客がログインすると、自分専用のダッシュボードが開きます。進行中のプロジェクトと進捗、承認待ちの成果物、未払い残高、共有されたファイル。ほかの顧客のデータはそもそも存在しません。自社チームが同じポータルを開けば、全アカウントを一覧できます。
ポータルを安全に保つ3つの一文
ポータルのプロンプトは、構築の依頼であると同時に権限設計の文書でもあります。次の3つの指定でほとんどが決まります。
顧客ごとに自分のレコードだけに限定する
プロンプトの一文が、全テーブル・全ビューに適用されるロールベースの権限になります。
監査ログを依頼する
誰がいつ何を変えたか——権限変更や顧客の招待も含めて残ります。
顧客に見せない項目を名指しする
社内メモ、原価率、工数は、明示して列挙すれば社内限定のままになります。
プロンプトのあとも、ふつうの言葉で編集を続けられます
プロンプトは最初のメッセージであって、最後ではありません。「Signed off by」列を足すのも、顧客から特定の項目を隠すのも、もう一文書くだけ。変更はすべて監査ログに残ります。導入は人が伴走します。担当者が最初のバージョンを一緒に作り、変更のしかたをチームに引き継ぐので、ポータルが「一人しか分からないもの」になりません。Freeプランは$0/月、チームで使うなら$99.99/月から。
プロンプトについてのよくある質問
プロンプトは書かれたとおりに使わないといけませんか?
いいえ。出発点として使ってください。テーブル名、フィールド、ステータスは自社の進め方に合わせて変えて問題ありません。重要なのは文言ではなく構造です。
日本語のページなのに、なぜプロンプトは英語ですか?
プロンプトはビルダーへの入力なので、結果を安定させるために英語のままにしています。ポータル側のラベル・フィールド・コンテンツは好きな言語で構いません。
戻ってきたポータルが思いどおりでない場合は?
そのまま対話を続けてください。フィールド、ステータス、権限の変更を一文で頼めば更新され、変更はすべて監査ログに記録されます。
顧客は本当に自分のデータしか見られませんか?
はい。アクセス権のルールをプロンプトに残していれば大丈夫です。権限はロールベースで、顧客レコード単位に絞られるため、各ログインはその顧客に紐づく行にしか到達しません。