Build a Client Portal From Your Existing Spreadsheet
Every consultancy, agency, and service business runs into the same weekly pattern once they pass a certain client count. A client emails asking for an update. The partner, account manager, or owner writes a short status paragraph, sends it, closes the thread. Two weeks later, the same client emails asking for the same update again. The reply is a slightly-edited copy of the previous one. Across fifteen active engagements, the pattern consumes the better part of a working day every week — and every one of those status emails is a piece of work the client would happily do themselves if they had somewhere to look.
The underlying information is already being tracked. Most firms in this pattern keep a spreadsheet of active engagements. Client, project, stage, next milestone, last contact, assigned lead. The spreadsheet is the system of record. It is already up to date. The weekly translation from the state of the spreadsheet into individual status emails for each client is a copy-paste job that does not need to exist.
A client portal is the version of that spreadsheet that clients can look at directly — filtered to their own row, wrapped in a branded page, accessible with a login. The mechanics are simpler than most people assume, and the result — once clients have learned to use it — is a meaningful drop in the volume of small operational emails.
The walkthrough, with real timestamps
Our example is the engagement spreadsheet a boutique consultancy keeps. It has one tab, thirty-one rows, and fourteen columns — client, engagement name, stage, lead, kickoff date, next milestone, status notes, contract link, deliverable link, invoice status, last contact, next contact, internal notes, client contact email.
0:00 — Upload the spreadsheet. The file is read. Columns are typed. Crucially, the client column is recognised as the relationship field — the column that will eventually determine who sees which row.
1:30 — Describe what each client should see. A single prompt. You type: "A client portal. Each client sees their own engagements, stage, next milestone, deliverable links, and invoice status. They do not see internal notes or other clients' rows. They can download deliverables and upload new documents. They see a status badge that updates when the stage changes." The portal structure forms around this.
3:00 — Define access. You decide how clients log in. The default is one login per client contact, scoped to that client's engagements. If a client organisation has several stakeholders who need access — a finance contact alongside the programme lead — multiple logins can be created per client, each with the same view. Team members on your side get admin access; they see all clients.
4:30 — Map columns to portal sections. This is the step where the spreadsheet's columns get organised into a portal layout. Contract links and deliverable links go into a Documents section. Stage, next milestone, and status notes become a Status panel. Invoice status goes into an Invoices section. Internal notes are explicitly excluded from the client view — they stay on the admin side.
6:00 — Review the generated portal. A live preview appears. You log in as one of the clients. You see only that client's engagements. The document links work. The status is current. The invoice section renders. The internal notes are, correctly, invisible. You switch back to the admin view and confirm that you see everything.
8:00 — Publish and invite. The portal goes live at your own URL. You pick one client to pilot with — the one who most often emails asking for status. You send the invitation link. The client logs in, sees their engagements, and immediately understands the format. The first status email has been replaced by a bookmark.
What the client sees — and what stays private
A common concern with a portal built from a spreadsheet is the fear that something the client should not see will leak through. The fear is reasonable; the solution is straightforward, and worth spelling out.
The portal is filtered at the row level. Each logged-in client sees only the rows of the spreadsheet that match their client field. They never see other clients. The filter is not a client-side trick that clever inspection could bypass — it is applied by the portal itself before any data is sent to the browser.
The portal is also filtered at the column level. You explicitly mark which columns are client-visible and which are admin-only. Internal notes, margin, lead-source, sales commentary — anything that belongs to your side of the engagement — stays on the admin side. The client's view contains only the fields you chose to expose.
Document access follows the same pattern. A contract lives on the portal with a link that is specific to that engagement; a client does not see other clients' contracts, and there is no URL-guessing path to them. Uploaded documents from the client side land in the admin view of the right engagement.
The underlying spreadsheet stays yours. You can keep working from it exactly as before. Changes you make in the spreadsheet flow into the portal. Changes clients make in the portal (uploads, submitted forms) flow back into the admin view. There is no version-drift problem — the portal and the spreadsheet are two views of the same underlying records.
What you manage, what the client manages
Once the portal is live, the working rhythm changes in small, specific ways. Neither side gains or loses anything dramatic; the handoffs just move.
On your side, you manage the state of the engagement as you always did. Update the stage when work moves forward. Link a new deliverable when it is ready. Move the invoice status to Paid when a payment clears. The spreadsheet or the admin portal view are both acceptable places to do this — whichever one fits the habits your team already has.
On the client side, they look things up instead of asking for them. They download the deliverable instead of emailing to ask where it is. They see that an invoice is in "Awaiting Payment" instead of receiving a reminder email. When they need to send a document — an onboarding form, a signed statement of work, a revised brief — they upload it into the portal rather than emailing an attachment. A notification lands with you when they do.
Notifications sit between the two sides, quietly. When a stage changes on your side, the client contact gets an email that the portal has been updated. When a document is uploaded from their side, the engagement lead gets an email that a new document is waiting. These are the small responsive behaviours that the weekly status-email habit was trying to cover manually; automating them is most of the relief.
Roll out one client first
The fastest way to find out whether a portal is a good fit for your practice is not to launch it for all thirty clients at once. It is to pick one client, ship it for them, let them live with it for two weeks, and gather the specific friction.
Pick the client who most often asks for status. They have the most to gain and they are the most likely to actually use the portal. Send them the invitation with a short note — "we're piloting a new way of sharing the status of the engagement, log in here, let us know how it feels". Watch what they do. Answer the questions that come back.
Two weeks is enough to see whether the portal does what it should. The usual findings are small: a wording change on the status badge, an additional column that clients care about that you had left internal, a file that the client wishes lived on the portal and currently lives in an email thread. All of these are edits you make in a minute.
Then roll the portal out to the next three or four clients. Then the rest. The pacing is not cautious; it is deliberate. Each wave teaches you something you would not have learned by launching to everyone on day one. By the time the whole roster has been moved over, the portal has already been shaped by your actual clients, not by your assumptions about them.
Getting started
If you already keep an engagement spreadsheet, the fastest way to see whether this fits your practice is to upload it and see what comes back. The spreadsheet stays intact. The portal is a separate artefact; you can preview it, show it to one colleague, and decide whether to invite a real client before anything external happens.
If your operation is more about knowledge management than engagement tracking — a growing library of methodology, templates, and deliverable types — the companion Word-to-knowledge-base walkthrough covers that adjacent case, and the consulting-firms guide walks through both patterns together. If the underlying file is a customer CRM rather than an engagement tracker, the CRM walkthrough is the closer match.
The tool page for this flow, with examples of portals published from spreadsheets, is at /convert-spreadsheet-to-portal.
