Construir un portal de cliente

Build a public website for [BUSINESS NAME], a [TYPE OF SERVICE BUSINESS] that helps [WHO YOU SERVE] with [WHAT YOU DO].

Create a home page explaining the service and the next step, a services page, a page for one service, an about page, a contact page and a how the client portal works page. The portal page should explain that invited clients will be able to exchange documents, check progress and send messages in one private place.

Add a client login button in the header and on the portal page. For now it should open a clear message saying that client access is being added next. Do not create a fake login or a private area that is not protected.

The public contact form collects only [PUBLIC ENQUIRY FIELDS]. Put a clear note beside it telling people not to send confidential details or documents through this public form. Do not add a file upload to the public form.

Store my services as editable information with a private owner screen. Each service has a name, short description, full description, who it is for and whether it is currently offered. Add three example services clearly labelled for me to replace.

Design the site to feel [THREE ADJECTIVES] using [COLORS]. Make it easy to read on a phone. Use labelled placeholders saying [REAL BUSINESS PHOTO NEEDED]. Do not use stock photography and do not generate images of clients, staff, documents, offices or results from scratch. Editing my own real business photos is fine; only invented or generated scenes are the problem.

Do not add client accounts, documents, project records, messages or notifications in this step. When finished, tell me where I edit services and which words and images are still examples.

Add invite-only client accounts and the private access boundary for this portal.

Use the platform's built-in account system for login, logout and forgotten-password reset. I create each client in a private owner area and invite their approved email address. Do not allow open public sign-up. An invited account belongs to exactly one client area unless I explicitly assign it to more than one.

Create a private client home page that shows only that client's name and harmless test items for now. Add two invented test clients using [CLIENT A TEST EMAIL] and [CLIENT B TEST EMAIL]. Give each one a clearly labelled dummy note and dummy document reference containing no real client information.

Enforce access on the material itself, not only by hiding menu links. Before showing a client area, note, document reference or future download, check that the signed-in account belongs to that exact client. Client A must never receive client B's title, file name, status, message, contact detail or any hint that the material exists.

Add owner and staff access using [YOUR STAFF ACCESS RULE]. Only I can create clients, send invitations or change which account belongs to which client. A staff member sees only [ALL CLIENTS / ASSIGNED CLIENTS]. A client can never change their own client assignment or staff permissions.

Make private material unavailable when signed out. If someone pastes an address for material they cannot access, show a neutral not available message or return them to their own portal without revealing whose material it was.

Do not add real uploads, project tracking or messages yet. When finished, give me a plain-language test plan using the two test accounts, including the exact client-area and dummy-item addresses I should copy between them.

Add private document exchange to the client portal without weakening the access rules from step 2.

I can upload a document to one chosen client and optionally connect it to [PROJECT OR CASE TERM]. A client can upload a document only into their own client area. Every document shows a clear title, category, who uploaded it, when it was uploaded, which client and project it belongs to, its current version and [DOCUMENT STATUS NAMES].

Store documents in private storage. Opening or downloading a document must check the signed-in account and client assignment again at that moment. Do not expose a permanent public file address. A copied download address from client B must not work for client A or while signed out.

Accept only [ALLOWED FILE TYPES] up to [MAXIMUM FILE SIZE]. Reject unsupported or oversized files with a useful explanation. If the chosen storage setup cannot check uploaded files for malware, which means harmful files, stop and tell me plainly what separate protection or review I need before accepting real uploads. Do not claim a file is safe merely because it uploaded successfully.

Let either side upload a new version without silently erasing the earlier one. Show which version is current and keep the earlier history for [YOUR RETENTION RULE]. A client may remove their own unsubmitted upload, but cannot delete a document I shared or erase the activity history. I can archive a document without breaking the rest of the client record.

Notify the other side that a document is available using a generic email that links back to the portal. Do not attach the file and do not include its confidential contents in the email.

Test with one harmless file uploaded by client A, one harmless file I share with client B, one unsupported file and one oversized test file. Re-run the crossed-address test using both the document page and its download address.

Add client-facing progress tracking to the portal. Use the word [PROJECT / CASE / ENGAGEMENT / YOUR TERM] throughout.

In my owner area, I can create a piece of work for one client with a title, responsible staff member, start date, current client-facing status, last update, next step, target date when appropriate and whether the client owes an action. Use only these client-facing statuses: [YOUR STATUS NAMES AND PLAIN-LANGUAGE MEANINGS].

On the client side, show their active work first. Each item shows the current status, the latest client-facing update, what happens next, any action they need to take and when it was last updated. Connect the right shared documents to the right item.

Keep client-facing updates completely separate from private staff notes. Private notes, internal risk labels, staff discussion, other clients, private fees and draft decisions must never appear in the client view, search, notifications or copied addresses.

Keep a dated history of client-facing status changes so the client can understand progress. Do not delete an earlier update when the status changes. Let me correct a mistaken update while preserving that a correction was made.

Do not invent target dates or imply a guaranteed outcome. If no reliable date exists, show [YOUR NO-DATE WORDING] rather than guessing.

Test one active item and one completed item for each test client. Re-run the client A versus client B address test on the item page and on a connected document.

Add private portal messaging, notifications and an owner activity view.

Each message belongs to one client and, when relevant, one [PROJECT OR CASE TERM]. Clients can start a message and reply only inside their own client area. Staff can message only clients allowed by [YOUR STAFF ACCESS RULE]. Show sender, date, message, unread state and the related work item in a clear conversation.

If a message includes a file, send it through the protected document flow from step 3 rather than adding an ordinary public attachment. The same client check must protect the message, conversation and file every time they are opened.

Send notifications for [EVENTS THAT SHOULD NOTIFY, e.g. new message, new document, status change and action due]. Use in-app notifications and [EMAIL / NO EMAIL]. An email should say only that new portal activity is waiting, name [SAFE DETAILS ALLOWED IN EMAIL] and link to the login page. Do not copy the full message, confidential document name or sensitive status into email.

Prevent duplicate notifications when an action is retried. Do not send a notification to the person who performed the action. Let each person mark items read, and let clients control [OPTIONAL NOTIFICATION PREFERENCES] without turning off essential account or security messages.

Give me one owner view of unread client messages, documents awaiting review, client actions due and work items not updated since [STALE PERIOD]. Opening an item should take me to the correct client and preserve the full dated history.

Keep archived conversations and notification history according to [YOUR RETENTION RULE]. Do not let a client delete staff messages or erase the history.

Test a message, reply, document attachment, status notification and due-action reminder with both test clients. Then repeat every client A versus client B direct-address test from steps 2 through 4.