Staff portals: the sibling that determines whether the client portal works

A client portal is the visible half. The staff portal is the half that decides whether the client portal gets used. If the team has to log into three systems to answer a question that arrives through the client portal, the portal becomes another inbox. The firms with the highest portal adoption built the staff side first. We have laid out the sequence and the trap most firms hit when they do it the other way.

Why most firms build the client side first, and regret it

The client side is what gets sold. It is the screenshot in the proposal, the demo the partner watches, the URL the client logs into. The board can see it. The client can see it. So the build starts there.

The staff portal is invisible. Nobody outside the firm asks for it. The internal portal that consultants and partners log into in the morning does not appear in the marketing email about the new client experience. It is not in the pitch deck. The temptation is to ship the client portal first and “add the back-office portal later when there is budget.”

This is the trap. The client portal is a window into the firm. If the team behind the window is still working out of Xero, LEAP, Xplan, SharePoint, Outlook and a shared drive, the window shows nothing useful. A client uploads a document. The team has to remember to log in to the portal to see it. They then have to download it, save it to the right matter folder, mark the request closed, and reply through the portal instead of email. Three of those steps are new behaviour for the team. None are new behaviour for the client.

Adoption follows the path of least friction, and the path of least friction for an accountant or a lawyer is the system they already had open. If the staff portal does not exist, the client portal becomes a place documents arrive and then quietly leave again, copied into the system the team actually uses. Within three months the partner is emailing again.

Building the staff side first inverts the problem. The team gets a single login that pulls together what they were already doing, faster. The client portal then lands as the public face of a system the team already lives in. The client uploads a document; the team sees it in the same view where they already track the matter. No extra step, no new tab, no new habit to learn under deadline pressure.

The five workflows the staff portal has to absorb before the client side ships

A useful staff portal is not a dashboard with five tiles linking out to the underlying systems. That is a bookmark page, and bookmark pages do not change anyone’s day. The portal has to absorb the workflows, not link to where they happen elsewhere.

The five we work through with every firm before the client side gets scoped:

The matter or client list, with status that reflects reality. Whatever the firm calls its core unit of work (jobs, matters, files, advice cases), the staff portal has to show every active one with a status the team trusts. The staff dashboard a professional services firm actually uses is not a screen that looks impressive; it is the one with status the partner can rely on. If the status is stale because it comes from a Monday CSV export, the team learns to ignore the portal and check the underlying system. The status has to read live from the database, not from a dashboard layer that drifts.

The task queue the team actually works from. Today, this week, blocked, waiting on client. Real work, in the order it has to happen, with owners. Most firms run this in someone’s head, in a Teams thread, or in a spreadsheet a senior associate maintains. Pulling the queue into the portal is the moment the portal stops feeling like overhead and starts saving time.

Document handling that ties to the record. A client uploads a document; it has to land against the right matter or client, with permissions set, version tracked, and an audit trail showing who touched it. The same applies to documents the team generates: tax returns, engagement letters, SOAs, court documents. The staff portal has to be the place this happens, not a link out to NetDocuments or SharePoint. If documents live somewhere else, the team works somewhere else.

Time recording without a context switch. Lawyers and accountants have to record time. If the time entry happens in a separate window, on a separate timer, against a matter list that has to be cross-referenced manually, the time gets recorded badly or late. The staff portal has to let someone start a timer or log time against the matter they are already looking at, in one or two clicks. The pattern we see when adoption stalls is rarely a UI complaint. It is a click-count problem. Time entry that takes eight clicks gets skipped; time entry that takes two gets done.

The integrations that already run the firm. Practice management (Xero Practice Manager, LEAP, Xplan), accounting (Xero, MYOB), document store (NetDocuments, SharePoint, FYI), CRM, platform statements from HUB24 or Netwealth where the firm is in wealth. The staff portal has to read from these and, where appropriate, write back. The team should not see the underlying systems most days. The portal is where the work happens; the integrations are the plumbing.

A staff portal that does three of these is a useful internal tool. A staff portal that does all five is the system the team starts their day in. The client portal then plugs into a working spine, not a half-built one.

What “single pane of glass” actually means in practice

The phrase appears in every portal RFP. It rarely survives the first design review. The trap is reading it as a UI ambition, a single screen with everything on it, when it is a data-model claim.

Single pane of glass means the records on the screen come from one source of truth. The phrase is about the data, not the layout. When an accountant looks at a client in the staff portal, the client name they see is the same string that appears on the invoice in Xero, the BAS workpaper in the document store, the engagement letter the client signed, and the matter card in XPM. If the underlying systems each carry their own version of the client record and the portal merges them at display time, the pane is glass and the data behind it is fog.

What this looks like in build:

• One client record with a stable internal ID. Every system the firm runs links to that ID, not to a free-text string of the client name.
• One matter or job record per piece of work. Time, documents, invoices, tasks, communications all carry the same matter ID.
• One activity log that captures every action across systems against the record. When the partner asks “what’s happened on this matter in the last week”, the answer is a single query, not five tabs.

This is what “database-first” means in portal terms. The database holds the canonical record. Every other system, the practice management tool, the accounting platform, the document store, the email integration, syncs to it or reads from it. Drift is an exception that gets logged, not a daily reality.

The visible UI is downstream of this. If the data model is right, the screen can show whatever cut of it the team needs: by client, by matter, by partner, by week. If the data model is wrong, no UI rescues it. The team will still keep their own spreadsheet, their own tab, their own personal copy of the truth, because they have learned the portal cannot be trusted.

The trade-off is honest. Building this properly takes longer than building five tiles linked to the underlying systems. The five-tile version ships in two weeks and gets abandoned within months. The properly modelled version ships in six to ten weeks and survives into year three. The pattern we see is that the rebuild from the first shape into the second always costs more than the original would have if it had been done right the first time.

The integrations the staff portal needs to hide from the team

The staff portal earns its keep by hiding work, not by surfacing it. The team should not be aware of how many systems sit behind the portal. They should be aware of the workflow they are doing.

The integrations that have to disappear:

Practice management to portal. When a new matter or client opens in LEAP, Xplan, or XPM, it appears in the portal automatically. When status changes in the portal, it writes back to the source system if the firm wants the source to remain canonical, or the source system becomes a downstream view if the portal becomes canonical. Either choice is valid; the wrong one is leaving them out of sync.

Accounting to portal. Invoices, payments, trust receipts, time entries: visible against the matter or client in the portal without a manual export from Xero or MYOB. The integration runs continuously. If it breaks, an alert fires and a human investigates within hours. The team does not find out from a client.

Document store to portal. Documents attached to the matter or client appear in the portal regardless of whether they live in NetDocuments, SharePoint, or the firm’s own database. The team uploads, downloads, and previews from the portal. The underlying store is implementation detail.

Email to matter. Inbound and outbound emails associated with a matter route to the portal automatically. This one is hard to get right, because the email-to-matter routing has to be deliberate enough to handle mid-thread emails from third parties. We use a confirmation step: the integration suggests a matter, the team member confirms with one click. Less elegant than full automation; far fewer wrong-matter mistakes.

Identity and permissions. Single sign-on with Microsoft 365 or Google Workspace for staff, role-based permissions enforced at the database, audit trail on every record access. The team logs in once. The permission rules live in the database and run on the server, not in the UI layer where a curly URL could expose a record someone should not see.

The integrations are the work. We document this on the integrations service page because most firms underestimate how much of a staff-portal build is integration work and how little is UI. A rough rule on portal builds: the UI is the smaller share of the effort, the data model is larger, and the integrations are the largest bucket. Plan the budget that way and the project tends to land closer to scope.

When the integrations are right, the team forgets the underlying systems exist. That is the test. If the team is still opening Xero, LEAP, or Xplan to do their daily work three months after the portal ships, the integrations are not done.

A six-week sequence that ships the staff portal before the client portal

The sequence we run with most firms across accounting, legal and wealth when the brief is “we want a portal”:

Week one. Audit and data model. Map the workflows the team actually runs and the systems they touch. Identify the canonical source of truth for the client record, the matter record, the document, the time entry, the invoice. Decide which system stays canonical and which becomes a downstream view. Sketch the data model that will sit behind the portal; the sketch is not the final schema, it is the shape the build will iterate against.

Week two. Identity and the spine. Single sign-on wired up against Microsoft 365 or Google Workspace. The first integration: the practice management system to the portal database. A live read of the matter or client list, surfaced behind the SSO. No UI to speak of yet, just the spine. The team can log in and see their own matters. That is the first slice.

Weeks three to four. The first two workflows. Pick the two workflows that hurt most. For accounting firms it is usually the matter list with status plus the document handling. For law firms it is the matter list plus the task queue. For wealth practices it is the client list plus the platform statement view from HUB24 or Netwealth. The two get built into the portal. The integrations against the underlying systems run. The team starts using the portal for these two workflows.

Week five. Two more workflows and the activity log. Time recording in context, plus one of the remaining workflows depending on what hurts next. The activity log lights up: every action across every integration writes to the log, queryable from the portal. The “what happened on this matter” question becomes a single query.

Week six. Polish, audit trail, and the soft launch. Permission rules locked down. Audit trail tested against a representative compliance question. The team uses the portal as their primary tool for two weeks before any client side gets considered. If anyone is still opening Xero or LEAP for daily work, that workflow is not done; we go back and fix it before adding the client side.

Six weeks is the working assumption for a firm of ten to forty staff with a manageable integration surface. Bigger firms or messier integration surfaces stretch this to eight to twelve weeks. The shape stays the same: the spine first, the two highest-pain workflows, then the rest.

The client portal scopes after this is working. The client side is then a thin layer on top of a system the team already lives in. Documents the client uploads land in the team’s view automatically. Status the client sees comes from the same record the team updates. Messaging routes to the matter, not to a separate inbox. The client portal looks straightforward to ship because most of the work is already done.

Firms that try to compress the sequence by building both sides in parallel hit the same failure mode. The client portal ships looking polished, the staff portal ships half done, and the team falls back to the underlying systems. The client portal becomes the inbox the partner is no longer checking. Staff-first is the version that tends to survive the year-one review.

If a portal is on the roadmap and the team is wondering which side to build first, the answer is the side nobody asks for. Talk to us about the sequence that fits.