Client Portal

The Client Portal is the half of Client Delivery that your client sees. It is a separate application at /portal, or at your firm's own portal address, in your firm's name, logo and colour, with none of the internal product around it. A signed-in client lands on a portfolio home that covers every engagement they can open, or straight on the dashboard when there is only one. A sidebar on the left groups each engagement into Home, Work, Conversations, Governance, Files and People, with a count beside each item that is waiting on the client. Every page opens with its figures and a chart, then a register the client can search, filter and sort, and every action is a named endpoint rather than a general permission, so a surface a client must not reach cannot be reached by sending a different argument.

• A sidebar with six sections and waiting-on-you counts, a portfolio home across every engagement, and an engagement dashboard with progress, health and its history, the next milestone, deliverables by stage, requests by age, changes awaiting a decision, the latest status report, upcoming meetings and recent activity
• An analytics page over the last 30, 90 or 365 days or the whole engagement: deliverables accepted and time in review, request turnaround, milestones planned against actual, the cost and schedule effect of changes, health over time, and how quickly the firm answers threads
• Every module as a register with its own figures and chart, search, filters and sort that the browser remembers, and a detail drawer or page for each row, including the risks, issues and decisions the firm chose to show
• New thread for a client who can act: a title, a message and a kind, sent to the engagement team, who are told at once
• A notification bell in the top bar with an unread count and what changed since the client last looked, marked read after a moment open or at once with Mark all as read, checked every minute while the tab is in view
• A deliverable page with its review history (each issued version with its files, each client review round with its outcome, and the sign-offs from the client side with their comments) beside the three-decision sign-off
• Documents filtered by origin, type (including spreadsheet, document and presentation) and month, with a PDF or an image opening as a preview in place; several files sent at once with progress for each; Add to calendar on upcoming meetings
• Print or save as PDF from the dashboard and the analytics page, light and dark themes, and a language choice saved to the client's profile so it follows them to another device

• 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. Every figure on a dashboard, an analytics chart, a register and the bell is computed from the same rows, so none of them can count something the client could not open.
• A client contact can be scoped to particular workstreams, and every portal read honours that scope. A contact scoped to several workstreams cannot yet start a thread from the portal, because a new thread has to name one of them; the portal says so and asks them to contact the firm.
• Information barriers deny rather than label. A party excluded from an engagement is refused even holding a live, correctly scoped, unexpired grant, on the grant check, on signed downloads and on every surface that hangs off the engagement.
• A restricted guest reads everything shared but cannot act: no sign-off, approval, reply, new thread, answer or upload, and the portal offers them none of those controls. They can still read the bell and mark it read, because that changes only their own view.
• The review history never shows drafts, the firm's internal review gates or its reviewers' comments. What the client side wrote appears on its own sign-offs, in its own words.
• 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 people tab in Client Delivery, choose the access level, and choose whether the invitation covers the whole engagement or particular workstreams.
2. 2The contact accepts the invitation and arrives on the portfolio home, or on the engagement dashboard when they hold only one engagement. The sidebar shows what is waiting on them in each section.
3. 3Point them at the item 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 sign off a deliverable, open it, read the files and its review history, choose approve, approve with comments, or request changes, type your name, and submit. The decision reaches the firm immediately.
5. 5To raise something the firm has not asked about, open Threads, or the conversations block on the dashboard, and press New thread. Write a title and a message, choose its kind, and send it.
6. 6Ask the client to open the bell in the top bar to see what changed since their last visit, and to choose their own emails under Notification settings in the account menu, per engagement.

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. Of the risk register, a client sees only the risks, issues and decisions you mark visible to the client and not confidential; the rest of it, the working papers and the engagement economics stay private. The commercial summary is a separate, deliberately narrow surface the firm chooses to share.

Who is told when a client starts a new thread?

The thread is addressed to the engagement manager, or to the partner when there is no manager, who is told as a thread owner is told about a reply. It is a client-audience thread, never confidential, and it takes the firm's response target, so the response clock on the client's analytics page starts when the client asked.

What does the notification bell show, and when is it marked read?

The latest changes on the open engagement, such as a deliverable sent for review, a reply from the firm or a decided change, without the posts and sign-offs of the client's own side. It is marked read up to the newest item shown once the popover has stayed open for a moment, or at once with Mark all as read; anything that arrives later stays unread.

Can our clients reach the portal on our own domain?

Yes. In the client portal settings, give the portal a firm address under the Atlas domain, or connect a domain you own, such as portal.yourfirm.com, by adding the DNS records the settings screen shows. Clients who open the firm address see your name, colour and logo, and the main /portal address keeps working.

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

Withdraw their access from the access register on the engagement people tab. 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.

Why can a client read the engagement but not approve, reply or start a thread?

They hold restricted guest access, which reads everything shared but cannot act, and the portal shows them a note saying so. Invite them again as a guest from the engagement people tab; their access changes when they accept.