고객 포털 프롬프트
이 고객 포털 프롬프트는 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.포털이 공급업체가 아니라 자사 제품처럼 보여야 할 때.
붙여넣기 전에 프롬프트에서 바꿀 것
고칠 만한 곳은 세 군데입니다. 필드 이름 — 팀이 실제로 쓰는 단어로 바꾸세요. 나중에 바꿔도 되지만 처음부터 우리 말로 시작하는 편이 편합니다. 단계 — 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
생성된 고객 포털의 모습
고객이 로그인하면 자기 대시보드로 바로 들어옵니다. 진행 중인 프로젝트와 진척도, 승인 대기 중인 산출물, 미결제 잔액, 공유된 파일이 보입니다. 다른 고객의 데이터는 아예 존재하지 않습니다. 내부 팀이 같은 포털을 열면 모든 계정을 한 번에 봅니다.
포털을 안전하게 지키는 세 문장
포털 프롬프트는 제작 요청인 동시에 권한 설계 문서이기도 합니다. 아래 세 가지 요청이 대부분을 해결합니다.
고객마다 자기 레코드로만 범위를 제한하세요
프롬프트의 한 문장이 모든 테이블과 뷰에 적용되는 역할 기반 권한이 됩니다.
감사 로그를 요청하세요
누가 무엇을 언제 바꿨는지 — 권한 변경과 고객 초대까지 남습니다.
고객이 보면 안 되는 필드를 지정하세요
내부 메모, 마진, 투입 시간은 명시적으로 적어 두면 내부 전용으로 유지됩니다.
프롬프트 이후에도 평범한 말로 계속 수정
프롬프트는 첫 메시지일 뿐 마지막이 아닙니다. "Signed off by" 열을 추가하거나 특정 필드를 고객에게 숨기는 것도 문장 하나면 되고, 모든 변경은 감사 로그에 남습니다. 온보딩은 사람이 함께합니다. 담당자가 첫 버전을 같이 만들고 수정 방법을 팀에 알려 주기 때문에, 포털이 한 사람만 아는 물건이 되지 않습니다. Free 요금제는 $0/월, 팀으로 쓰면 $99.99/월부터.
프롬프트에 대한 질문
프롬프트를 적힌 그대로 써야 하나요?
아닙니다. 출발점으로 쓰세요. 테이블 이름, 필드, 단계는 업무에 맞게 바꿔도 됩니다. 중요한 건 표현이 아니라 구조입니다.
한국어 페이지인데 프롬프트는 왜 영어인가요?
프롬프트는 빌더가 읽는 입력이라 결과를 일정하게 유지하려고 영어로 둡니다. 포털의 라벨, 필드, 콘텐츠는 원하는 언어로 하면 됩니다.
만들어진 포털이 마음에 들지 않으면요?
계속 대화하면 됩니다. 필드, 단계, 권한 변경을 한 문장으로 요청하면 반영되고, 모든 변경은 감사 로그에 기록됩니다.
고객이 정말 자기 데이터만 보나요?
네, 접근 규칙이 프롬프트에 남아 있는 한 그렇습니다. 권한은 역할 기반이며 고객 레코드 단위로 제한되므로, 각 로그인은 해당 고객에 연결된 행에만 접근합니다.