Client Portal Prompt
This client portal prompt is written to be pasted straight into AgentUI — it spells out the tables, the fields, the client logins, the per-client access rule and the views, so the first version comes back as a working portal instead of a blank shell. Copy it as-is, or change the field names to match how you already talk about your clients.
The prompt stays in English — it is what the builder reads.
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.Why this client portal prompt works
Most prompts fail because they ask for "a client portal" and stop there. The one above names four tables, the fields inside them, two internal roles, the rule that a client only ever sees their own records, and three views — so nothing important is left to guess. If you want the full walkthrough of what happens after you paste it, read how building your own client portal works end to end. The short version: the prompt becomes a real shared database, real client logins and a portal your team can keep editing.
It names the tables
Clients, projects, deliverables, invoices — with the fields spelled out, not implied.
It states the access rule
"A client only ever sees their own records" is the single most important line in the prompt.
It asks for views, not screens
A client dashboard, an approvals view and an internal view — three jobs, three views.
It requests an audit log
So who changed what and when is recorded from day one, not bolted on later.
Four more client portal prompts to copy
Same structure, different business. Pick the one closest to yours, copy it, and edit the field names before you paste.
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.Use this if you run campaigns and need client sign-off on creative.
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.Use this if you chase documents and file returns for clients.
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.Use this if the hard part is getting a new client through their first 30 days.
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.Use this if the portal has to look like your product, not a vendor's.
What to change in the prompt before you paste it
Three things are worth editing. The fields: replace them with the words your team actually uses, because renaming later is easy but starting in your own language is easier. The stages: swap Draft / Awaiting client / Approved for whatever your process really calls them. The permissions: say out loud which fields a client must never see — margin, internal notes, hours logged — because anything you do not exclude may end up visible.
- maria.s renamed deliverables → matterstoday 10:04
- maria.s set internal_notes → staff onlytoday 10:05
- admin invited client haldentoday 10:11
What the generated client portal looks like
The client signs in and lands on their own dashboard: their active projects with progress, the deliverables waiting on their approval, their open balance, and the files shared with them. Everything belonging to your other clients is simply not there. Your team opens the same portal and sees every account at once.
The three lines that keep the portal safe
A portal prompt is a permissions document as much as a build request. These three requests do most of the work.
Scope every client to their own records
One sentence in the prompt becomes role-based access enforced on every table and view.
Ask for an audit log
Who changed what, when — including permission changes and client invitations.
Name the fields clients must not see
Internal notes, margin and hours stay staff-only when you list them explicitly.
After the prompt: keep editing in plain language
The prompt is the first message, not the last. Adding a "Signed off by" column or hiding a field from clients is another sentence, and every edit lands in the audit log. Onboarding is white-glove — a real person builds the first version with you and shows your team how to change it, so the portal never becomes the one thing only one person understands. Start on the Free plan at $0/mo, or bring the team in from $99.99/mo.
Questions about the prompt
Do I have to use the prompt exactly as written?
No. It is a starting point. Change the table names, the fields and the stages to match your process — the structure is what matters, not the wording.
Why is the prompt in English on the Spanish page?
The prompt is input for the builder, so it stays in English for consistent results. Your portal's labels, fields and content can be in any language you want.
What if the portal that comes back is not quite right?
You keep talking to it. Ask for a field, a stage or a permission change in one sentence and it updates, with every change written to the audit log.
Will clients really only see their own data?
Yes, as long as the access rule stays in the prompt. Access is role-based and scoped per client record, so each login only reaches the rows linked to that client.