Client Portal

The Client Portal is the half of Client Delivery that your client sees. It is a separate application at /portal with the firm brand on it, no sidebar, no workspace switcher and no command palette, because a client who can see the shape of the internal product can also see how much of it is being withheld. A client contact signs in, lands on the engagements they hold a seat on, and works through twelve surfaces: what the firm needs from them, what they owe, what has been delivered, and what they have been asked to decide. Everything they can do is a named action rather than a general permission, so a surface they must not reach cannot be reached by sending a different argument.

• One address per surface, so an email can link to the exact page it is about rather than to a list somebody has to search
• Twelve surfaces behind one tab rail: an overview, the actions assigned to that person, milestones and their progress, the information the firm needs, deliverables, the document library, meetings, threads, issued status reports, change requests, who is on the engagement from both sides, and the notification switches
• Sign-off on a deliverable with three decisions, not one: approve, approve with comments, or request changes, each recorded against a typed name
• Information requests answered in place: submit a response, attach a file against a specific item, or mark a request not applicable with a written reason
• A document library the client can both read and add to, including sending a document nobody asked for
• Minutes approved by the client, and threads they can read and reply to without an email round trip
• Notification preferences the client sets themselves, per engagement, rather than asking the firm to change them
• Every download served through a signed, expiring link rather than a public address

• A client sees a status report only when all three of these are true: the firm has issued it, it is addressed to the client, and it is not marked confidential. A report still in draft, or marked confidential, is invisible in the portal no matter who asks for it.
• A client contact can be scoped to particular workstreams. Every portal read honours that scope, so the deliverables, information requests, meetings and threads all narrow to what that person was admitted to. A grant with no scope sees the whole engagement, which is what a grant means unless somebody narrows it.
• Information barriers deny rather than label. A party excluded from an engagement is refused even holding a live, correctly scoped, unexpired grant, and the refusal is applied on the grant check, on signed downloads and on every surface that hangs off the engagement.
• A deliverable the client is not scoped to and a deliverable that does not exist return the same answer, deliberately. Distinguishing them would reveal which identifiers exist on an engagement the client is only partly admitted to.
• There is no general update route anywhere in the portal. Each thing a client may do is its own endpoint, so the surface cannot be widened by changing an argument.
• Sign-off is a contractual acceptance, not a comment. It requires a typed name, and the decision is recorded against that name on the deliverable.

1. 1Invite the client contact from the engagement in Client Delivery, and choose whether the grant covers the whole engagement or particular workstreams.
2. 2The contact accepts the invitation and arrives at /portal, which lists the engagements they hold a seat on and takes them straight through when there is only one.
3. 3Point them at the tab that matches the job. Use "What we need from you" for outstanding information requests, "Deliverables" for anything awaiting sign-off, and "Actions" for work assigned to them by name.
4. 4To answer an information request, open it, attach a file against the item it belongs to, and submit. If the request does not apply, mark it not applicable and write the reason, which the firm reads on their own request screen.
5. 5To sign off a deliverable, open it from the Deliverables tab, choose approve, approve with comments, or request changes, type your name, and submit. The decision reaches the firm immediately and the deliverable leaves client review.
6. 6Ask the client to set their own notification preferences on the Settings tab, per engagement, so the firm is not fielding requests to turn messages on and off.

Why can the client not see a status report we published?

Check three things in this order. The report must be issued rather than in draft, it must be addressed to the client rather than internal, and it must not be marked confidential. All three are required, and the most common cause is a report that was written and never issued.

Why is a deliverable missing from the client list?

Either the deliverable is not marked for the client audience, or the contact is scoped to workstreams that do not include it. Open the grant on the engagement and check its workstream scope first, because an unscoped grant sees everything and a scoped one sees only what it was admitted to.

Can a client see our internal working papers, our margin, or the risk register?

No. The portal serves only rows marked for the client audience, and the internal register, the working papers and the engagement economics are not among them. The commercial summary is a separate, deliberately narrow surface the firm chooses to share.

What is the difference between approving with comments and requesting changes?

Approving with comments accepts the deliverable and records the comment alongside the acceptance, so the work is signed off and the remark is on the record. Requesting changes does not accept it: the deliverable returns to the firm for another version.

How long does a document download link stay valid?

Downloads are served through a signed link that expires. Once it has expired the client opens the document again from the portal, which issues a new one. A link forwarded to somebody outside the engagement will not work after it expires, and it was never a public address.

How do we cut off access when a client contact leaves?

Revoke their grant on the engagement. The portal reads the grant on every request rather than trusting a session, so access stops at the next request rather than when a token happens to expire.

Can a client upload something we did not ask for?

Yes. The document library accepts an unsolicited upload as well as a file attached to a specific information request item. Both arrive in the firm-side document list, and both are recorded against the contact who sent them.

Does a failure in one tab take the whole portal down for the client?

No. The error boundary sits inside the engagement, so a failure reads as one tab being unavailable while the engagement name, the branding and the other eleven tabs stay on screen and navigable.