Skip to content

A client portal for agencies: what to share, what to keep inside and how to roll it out

Decide what an agency client portal should show, how approvals, files and invoices work inside it, and how to roll it out to clients with a practical checklist.

Illustrative envelopes sorted into letter trays with a hand passing one to a teammate
AI-generated editorial illustration. Practical examples are illustrative.

Clients ask the same questions on most projects. Where are we? What do you need from me? Where is the latest version? Has the invoice been paid? Each answer usually costs an email, and each email can be missed, forwarded to the wrong person or buried under a newer thread.

A client portal gives those answers a permanent address. Done well, it reduces routine messages and makes approvals clearer. Done badly, it exposes internal notes, confuses clients with information they cannot act on or becomes another place nobody checks. This guide covers what to put in a portal, what to leave out and how to introduce it.

The useful idea

A client portal is useful when it answers the client’s next question without a message. Share decisions, deliverables and what you need from them; keep the internal debate inside.

Decide what job the portal does

Start from the client’s questions rather than your tool’s features. For most agencies the portal’s job is to show progress against agreed milestones, collect approvals and inputs, hold the current versions of deliverables and show what has been invoiced and paid.

Write the job down in one sentence and share it with the team. It becomes the test for every later request to add something. ‘The portal shows the client what is agreed, what is next and what we need from them’ is clear enough to rule things in and out.

What to share

Share information that is settled and actionable. A milestone with its date and status, a deliverable waiting for review, an invoice with its due date and a list of inputs the team is waiting for all help the client do their part.

Show versions deliberately. A client who can see every draft may review the wrong one. Publish the version that is ready for review and keep the working files inside until then.

ShareKeep inside
Agreed milestones and their statusInternal estimates and stretch dates
Deliverables ready for reviewWorking drafts and internal critique
Inputs you need, with datesWho on the team is behind and why
Invoices and payment statusMargins, rates and cost of the work
Decisions and approvalsThe internal debate that led to a recommendation

Make approvals explicit

An approval should name what was approved, by whom and when. ‘Looks good’ in an email thread is weak evidence when a project is later disputed. A portal can record a named person approving a specific version, which protects both sides.

Agree who can approve before the project starts. If the client’s day-to-day contact cannot approve budget changes, the portal should not make it look as if they can. Match the approval rights to the decision process you recorded at onboarding.

  • Name the approver for each kind of decision.
  • Approve a specific version, not ‘the latest’.
  • Record the date and any conditions attached.
  • Tell the team when an approval arrives, so work can continue.

Control access carefully

Invite the people the client names, not everyone on a thread. Review access when people change roles or leave the client’s organisation. A portal link forwarded around a client company is a common way for information to reach people it was not meant for.

Check what each person can see before you invite them. Finance contacts may need invoices but not creative drafts; a reviewer may need drafts but not invoices. If your tool supports different access for different people, use it rather than one shared login.

Roll it out one client at a time

Start with a client who is comfortable with new tools and a project with a clear milestone ahead. Walk them through it on a call, show where to find the next action and ask what they expected to see but could not find.

Keep email working during the transition. Clients will reply to emails for a while; move the decision into the portal and confirm it there. Once a few clients use it comfortably, make it part of onboarding so new clients start there from the first week.

Use the portal to ask for what you need

Late client inputs are one of the most common reasons agency projects slip. Copy, logins, brand files and feedback often arrive after the date the team planned around, because the request was buried in a long email or sent to someone who was not responsible for it.

List each input you need in the portal with a named person on the client side and a date. When the date passes, the gap is visible to both sides without anyone writing a chasing email. When an input arrives, attach it where the team will use it rather than leaving it in a download folder.

  • Name the input precisely: ‘final homepage copy’, not ‘content’.
  • Assign it to a person at the client, not to the company.
  • Give a date and explain what it affects if it is late.
  • Confirm receipt so the client knows it landed.

Check whether it is working

After a few weeks, ask two simple questions. Are clients finding what they need without asking? Are approvals arriving faster and with less back and forth? If the answer to both is no, look at what clients actually open and what they still ask about by email.

Remove anything nobody uses. A portal with fewer, clearer sections is easier to trust than one that mirrors every internal view. The goal is fewer routine messages and clearer decisions, not a second workspace for the client to maintain.

How Tamaam approaches it

In Tamaam, the portal shows a client the work the studio chooses to share, from the same records the team uses, so there is no second copy to keep up to date. The product is in early access; adapt the checklist below to whichever portal you use.

Client portal rollout checklist

Copy this for the first clients you invite.

CLIENT PORTAL ROLLOUT
Client: [name]
Portal’s job: [one sentence]
People invited: [name / role / what they can see]
Approvers: [decision type / named person]
Shared: [milestones / deliverables / inputs needed / invoices]
Kept inside: [drafts / internal notes / rates]
Walkthrough call: [date / who]
First action for the client: [what / by when]
Email transition: [how replies are moved into the portal]
Review access on: [date]
Feedback from the client: [what they looked for and could not find]

Bring the context into your workspace.

Explore how Tamaam connects the relationship and the work around it. Tamaam is in development; product pages show previews and illustrative workflows. Joining early access does not start a subscription.

Found something we should clarify? Send a correction or question.