Client portal & internal consoleIn pilot

Clients see where their work stands. The team keeps working in ClickUp.

A client portal and an internal console share one database and sync both ways with ClickUp. Clients submit requests and follow progress without being given access to the team's project tool.

53automated checks that one client cannot see another's data
2interfaces on one codebase: client portal and internal console
Client portal overview with a status board of requests: in progress, with you, in revision and completed
Rebuilt interface · illustrative data

The business problem

The delivery team ran every project in ClickUp. That is the right place for the team, but it is not something to hand to a client: it shows internal tasks, owners and notes. Clients still need to submit requests, see what is in progress, know when work will land and approve what comes back.

What changed

Yash built two interfaces on one codebase. The client portal is dark and shows a status board, a timeline, a "needs you" list and request forms. The internal console is light and is where the team sets up each client workspace, forms and templates, and sees every request with its sync state.

A new request creates the matching task tree in ClickUp. Status and due-date changes in ClickUp flow back through a webhook. Clients see a coarse status and an expected date, not internal task names.

Before & after

AreaBeforeAfter
Client visibilityStatus lived in a tool the client could not useA portal with a status board, timeline and "needs you" list
New requestsTyped into ClickUp by handSubmitted through a form; the task tree is created in ClickUp
Team viewOne list per client in ClickUpOne console across clients, with a sync state on every request
What clients seeWhatever ClickUp showedCoarse status and expected date only; internal tasks and fields are hidden

The business value

The value is in client trust and in team time spent answering status questions, but no time saving has been measured, so none is claimed. The portal has been deployed and used by internal reviewers, who fed back a round of fixes that were built from their notes.

How to read the status

This is in pilot, not general release. A readiness audit in October listed open items, including an untested restore and rollback and a project-rule gap, and a November review round produced further fixes. It has not been signed off for all clients.

Why the system is dependable

Each client workspace is isolated in the database, and 53 automated checks try to read across workspaces. Failed syncs to ClickUp are kept as queued operations and retried, with a Retry button for the team. A health endpoint and a scheduled sync back up the webhook. Changes were released against 57 database migrations, 27 scripted checks and nine browser test files.

A closer look at the build

Internal console request list with status, ClickUp sync state and links to ClickUpInternal console: every request with its sync state (full size, opens in a new tab)Client portal timeline showing when each request is expected to landClient portal: when each request lands (full size, opens in a new tab)

Rebuilt screens with fictional data. Client names, people and requests are illustrative.

Could this work for your team?

If clients keep asking for status because your delivery tool is not something they can see, a portal over the tool you already use can answer them without a second system of record.

Talk through a similar project
Keep exploring

More case studies

All case studies