Client portals for consultancies: what clients should see, and what they shouldn’t

Every engagement generates the same small questions from the client side. Where are we? Can you resend the latest deck? Is the invoice for phase one the right amount? Who do we send the signed letter to? Each one is reasonable, each one takes someone on your team ten minutes, and together they fill a meaningful part of a project manager’s week.

A client portal can absorb most of them. It can also, if it is set up carelessly, show a client the internal note that said their CFO was the problem, or a draft finding nobody had reviewed. For a consultancy, where the relationship is the product, the second risk matters as much as the first benefit.

This post covers what a consultancy’s clients should see in a portal, what they should not, the grey areas worth deciding per engagement, and how to evaluate a portal before you commit to one.

What a portal is for, in a consultancy

Five jobs, in roughly the order clients value them.

1. Status. Where the engagement stands against its milestones, without waiting for the weekly email.
2. Documents. The deliverables and working files you have chosen to share, in one place rather than scattered across email threads.
3. Decisions and signatures. Proposals, engagement letters, change orders and estimates that need a yes.
4. Money. Invoices, what has been paid, what is due, and a way to pay.
5. Requests. A way to raise a question or send you a file that does not depend on finding the right person’s inbox.

If a portal does these five well, clients use it. If it only does documents, it becomes a file share with a login, and clients go back to email.

What clients should see

• Engagement status and milestones. Phase names, dates and whether each is done. This is the single most-asked question in any engagement.
• Deliverables you have published. Final versions, deliberately shared. Not the working folder.
• Anything awaiting their decision. Proposals to sign, estimates to accept, change orders to approve, with the version they are approving.
• Their invoices. Paid, due and overdue, with a PDF and a way to pay.
• Their own requests. What they asked, who replied and what happened.
• A place to send you files. Data extracts and source documents arrive in the portal rather than in a personal inbox.

What clients should not see

• Internal notes and discussion. Including the candid ones about stakeholders, politics and risk. These are the most damaging thing a portal can leak, and the most common.
• Draft findings before review. A preliminary number shared early becomes the number the client remembers.
• Cost rates, margin and internal budget burn. On a fixed-fee engagement, how many hours you have spent is your business, not the client’s.
• Staffing debates. Who might be moved off the engagement, who is over-allocated, who is being considered for the next phase.
• Your pipeline. That a follow-on proposal is being drafted, or how likely the partner thinks it is.
• Anything about another client. Including names in a shared document template, a mis-filed file, or a contact list that spans accounts.

The safest design shows a client nothing by default and exposes each item deliberately. A portal that shows everything unless someone remembers to hide it will eventually show the wrong thing.

The grey areas

Some decisions depend on the engagement. Make them at kickoff, write them down, and set the portal up accordingly.

Hours on time-and-materials work. On a time-and-materials engagement, the client is paying for the hours, so showing them is often fair and builds trust. On a fixed fee, showing hours invites a negotiation about effort that the fee was meant to remove.

Task-level detail. Some clients want to see every task; most want milestones. Task lists invite micromanagement and expose internal sequencing. Milestones with progress are usually enough.

Working drafts. For co-created work, sharing drafts may be the point. For diagnostic work, it rarely is.

Who at the client sees invoices. The sponsor who bought the engagement and the accounts payable team who pay for it often need different views.

Design principles that prevent the common failures

Show the same record, not a copy. A portal that receives an export of your project data goes stale the day after it is synced. A portal that shows the same record your team works on, with the internal parts removed, is current without anyone updating it.

One client, one view. A client contact should only ever reach their own account’s projects, documents and invoices, and a request for anyone else’s should be refused by the system, not by a careful setting.

Control who gets in. Invite contacts by name. If self-registration is allowed, require email verification and approval. Remove access when a client contact leaves their company, which is the step most firms forget.

Do not price people out. If each client user costs a licence, firms invite one contact per client, and everyone else goes back to email.

Put your name on it. The portal is part of the client experience you are selling. It should carry your brand, not your software vendor’s.

Questions to ask a portal vendor

• Is the portal showing our live records, or a synced copy?
• How is an internal note kept out of the portal? Show me one written next to a client reply.
• What does a client see by default when we create a new project?
• Can clients sign proposals and pay invoices inside the portal?
• How do we remove a client contact’s access, and what happens to what they uploaded?
• Do client users cost anything?
• Can the portal carry our logo and colours, and on whose web address?

These sit alongside the wider checklist in how to run a consultancy on one system, and the same visibility logic applies to the AI tools you give staff, covered in what to ask about AI permissions.

How Cyril approaches it

The Cyril client portal is a portal in your name, with your logo and colour and no Cyril branding, where a client sees their own projects, tickets, invoices and the documents you share, and nothing else. It works on a phone as well as on a desk. Your own web address for the portal is planned, not available today.

It is not a copy of your data. A client follows the same project your team runs in Projects, read-only, with its status, milestones and task progress. A client’s question lands on the same ticket your team works, and internal notes on that ticket never reach the portal. Invoices come from Finance, and clients can download a PDF or pay by card through Stripe or Revolut. They can also sign proposals, accept estimates, sign contracts, read the Docs pages you mark for clients, and upload files to you.

Access is invite-only unless you choose otherwise. If you allow self-registration, email verification and admin approval are both on by default, and clients can sign in with a one-time link instead of a password. Portal users are free and unlimited on every plan, so there is no reason to invite only one contact per client.

For a consultancy, the portal is one part of a starting point researched for consulting firms. Cyril is pre-launch, opening to founding members first.