Client portal for small business: size it by client sessions, not features

Short answer: A client portal for small business is one shared space where clients hand over briefs, files, approvals or payments instead of emailing them. Buy for the single job your clients repeat most — intake, delivery, support or billing — not all four at once.

A portal earns its place when clients have to come back to the same place more than a handful of times per project. There are four jobs it can do, and most small businesses have a problem in exactly one of them. Buying a platform that covers all four often produces a login screen nobody visits and a second place to lose files.

So this is a sizing question before it is a shortlist question. What follows: how to classify the job, how to size the portal by client sessions, a 60-point fit score with two veto criteria, the cost line that comparison tables leave out, and the four ways small-business portals quietly die.

Five terms used throughout:

• Structured brief — A form with named, required fields, so answers come out as data you can reuse rather than a paragraph you re-type.
• Scoped link — A per-project or per-person URL that opens a specific workspace without an account.
• Magic link — A one-time sign-in link emailed to the client, used instead of a password.
• Steps-to-first-action — The number of taps between receiving your link and completing the first useful thing.
• Audit trail — A timestamped record of who did or approved what, attached to a named deliverable.

The four jobs, and why "all-in-one" breaks at five clients

Each job has a different traffic shape. Intake is a burst at the start and then silence. Support is a trickle that runs for years. Tools tend to be built around one of those shapes and bolt the others on, which is why a mismatch usually shows up in month two rather than during the demo.

A helpdesk-style portal often handles intake badly: it has tickets, not required fields, so a client can open a "new website" request that says nothing you can quote from. An intake portal often handles support badly: it has structured briefs, not ticket states, so a request from month seven has nowhere to live. Check which shape a candidate was built for before you compare feature lists.

Classifying your own situation costs ten minutes. Open your sent folder, take the last five threads that irritated you, and label each one intake, delivery, support or billing. If four of five land in the same column, you are buying for that column. If they scatter evenly, you probably have a process problem that no portal fixes, and you should write down your handoff steps before you shop.

Size by client sessions per project, not by feature count

A "client session" is any time a client has to look at something, hand something over, or make a call on something. Count it from your last three projects: every email you sent asking for an asset, every email that arrived with an attachment, every review round, and every call that existed only because someone needed to be walked through a file.

That number decides the tier.

Under 5 sessions per project. One shared link, no account. At this volume the account is more work than the thing the account protects. A one-page brief link plus an upload area covers it.

5 to 20 sessions. One workspace per project, opened with a scoped link or a magic link, carrying your branding, holding the brief, the files and the current status. Small studios, consultancies and trades businesses often sit here, and it is the tier where over-buying is easiest.

Over 20 sessions, or a relationship measured in years. Now accounts, roles and a real permission model start paying for themselves: retainer clients, bookkeeping, managed IT, anything where three people on the client side each need a different view. Ask about audit trails here, because in this tier someone will eventually ask who approved what in March.

A portal your client visits twice is a folder with a login screen.

The account-creation tax

Count the steps between "client receives your link" and "client has done the first useful thing" — uploaded a file, or answered the first brief question. Call it steps-to-first-action. Vendors rarely publish it, and it takes ten minutes to measure yourself.

Over four steps, budget for a second conversation about the tool itself. That conversation has a recognisable shape: the client cannot find the password reset mail, it is in spam, you resend the invite, and you have become unpaid support for software you pay for. The client who most needs the structure — the one who sends logos as screenshots pasted into a document — is often the first to drop out.

This is why cluein.me lets clients complete a brief and upload files without creating an account: at intake volume, the login often costs more than it returns. In the support and billing lanes the calculation reverses, because a client who returns dozens of times over two years needs a stable identity, not a link that may have been forwarded.

Measure steps-to-first-action yourself, on your own phone, on mobile data, with the email client your clients actually use. Do not measure it from your desktop while logged in as the owner.

A 60-point fit score, with two vetoes

Six dimensions, ten points each. Score any candidate during a trial rather than from a features page.

Below 35, keep looking. Between 35 and 47, it is workable for one lane, so do not standardise the whole business on it. From 48, you can make it the default.

Two dimensions veto regardless of total. A zero on ownership and exit means your client's assets live somewhere you cannot fully retrieve them from. A zero on access control means you have no answer for the client who asks who can see their unreleased brand files. Ask both questions in writing before the trial ends, get the vendor's answer on data location and deletion in writing too, and check your own storage and data-handling obligations with a qualified advisor rather than assuming a vendor's marketing covers them.

For the longer version of this evaluation, including the export-format questions, see how to choose client portal software for your agency.

The cost line that comparison tables leave out

Comparison articles print the monthly figure. The figure that matters is annual, and it has three terms:

Annual cost = (P × C × M) + storage overage + (A × C × R)

• P — Price per active client or workspace per month, taken from the vendor's own pricing page on the day you decide, not from a listicle
• C — Projects you start per year
• M — Months each workspace stays open
• A — Admin hours per project spent setting up and tidying the portal (minutes ÷ 60)
• R — Your own hourly rate

The term people get wrong is M.

Worked example (illustrative figures, not vendor pricing): A studio runs 14 projects a year. If a workspace closes at handoff after three months, average concurrent workspaces are 14 × 3/12 = 3.5. If workspaces stay open because nobody archives them — the client "might come back" — the same 14 projects average 14 × 9/12 = 10.5. Identical work, three times the billable units, on any tool that prices per client or per active project. Storage tends to follow the same curve, because few people delete gigabytes of source files from a workspace they never open.

The admin term is smaller but worth measuring. Example: 25 admin minutes per project across 14 projects works out to roughly 5.8 hours a year. Time your own setup once and substitute your real figures — that is your baseline for judging any route that promises to remove the setup work.

One ratio helps narrow the pricing shape, as a rough rule of thumb rather than a rule: divide active clients by people on your team. With many clients per team member, per-seat or flat pricing tends to work in your favour; with very few, per-client pricing often does, because you are paying for a handful of workspaces instead of several logins. Anywhere in between, run both figures against the vendor's current pricing page and let the export question decide.

Build or buy at small-business scale

Building your own portal is reasonable in a narrow band. A workable rule of thumb: build only when both conditions hold — a sustained load of concurrent client workspaces (roughly 15 or more), and a field, permission or integration requirement that nothing in your shortlist covers. One condition alone is not enough. Fifteen workspaces with ordinary requirements is a subscription. An exotic requirement at four workspaces is a spreadsheet and an email.

Then price the build in hours, not enthusiasm. Budget the initial work, then budget maintenance per quarter: dependency updates, upload handling, backups, the login flow, and the one bug that appears when a client uploads a very large video file. Compare that quarterly figure against the subscription you avoided. If your hourly rate makes the maintenance more expensive than the tool, you have built yourself a second business you do not bill for.

What should actually be in it

Eight things are load-bearing:

1. Project identity — Scope in one paragraph, dates, and who is allowed to decide what

2. A structured brief with required fields, so an incomplete answer is visible before the project starts

3. File upload with validation — Accepted types, size limits, and a clear error the client understands

4. One readable status the client can check without asking you

5. An approval record with timestamps and names attached to specific deliverables

6. Notifications with a floor and a ceiling — The client sees the ones that block progress, not fourteen a day

7. An export you control, covering both files and brief content

8. Access removal, so a departed contact stops seeing the files on the day they leave

Six more are conditional: invoicing and payment, ticket states, a knowledge base, e-signature, effort or time visibility, and white-label branding on your own domain. Add each only when you can name the thread it replaces.

The item most often missing is number four, in a form the client can read. Internal task states — "in QA", "blocked", "sprint 3" — are not a status. "We are waiting on your logo files, everything else is ready" is. Treat each "any update?" email as a status line you never wrote in the client's language.

Three routes to creating one

Route A — A dedicated portal tool. Usually opinionated about one lane and priced per month. You give up deep customisation and accept someone else's field structure. Time the setup of one real workspace during the trial instead of trusting a marketing claim about speed.

Route B — Your own website. A members area or a plugin on your CMS. You own the domain, the branding and the data location, and you own updates, backups and upload security along with them. Reasonable if you already maintain the site weekly, expensive in attention if you do not. The specific trade-offs for the CMS route are in choosing a WordPress client portal plugin.

Route C — Stitched generic tools. A form tool, a cloud drive and a shared document. The recurring work sits in the per-client setup: creating folders, setting permissions and sharing links by hand for every new project, and re-typing free-text answers into your own document.

Rather than trusting anyone's ranking of these three, measure four numbers on your own last project and compare them route by route:

Pick by three inputs: whether the brief has to come out structured and reusable, whether your clients will realistically create an account, and how many new client setups you do per month. Once new-client setups become a weekly task, manual folder-and-permission work is usually the first thing worth automating, regardless of which route you started on.

Free plans: seven things to check first

Free tiers change, and any figure in an article is out of date by the time you read it, so verify current limits and terms on the vendor's own pricing page before you commit. What stays constant is the list of questions:

1. What is counted — Team seats, client seats, projects, or gigabytes. A plan generous with seats can still stop you at two projects.

2. Behaviour at the cap — Does an upload fail mid-project, or does the plan degrade gracefully?

3. Retention after inactivity or downgrade — How long files survive, and whether you get a warning.

4. Export — Files and brief content, in a format you can open in five years.

5. Whose brand the client sees on the page where they hand over their logo files.

6. The link itself — A bare vendor subdomain with a random string looks, to a cautious client, much like a phishing test.

7. Deletion on request — What you do when a client asks you to remove their data, and how long it takes.

Run check 4 before you upload anything belonging to a real client. Export is easy to test on day one and painful to discover on the day you leave.

Four ways small-business portals die

The dead portal. Clients log in twice and go back to email. Test it on day 30: count logins per active client. Under two in a month, the portal is a file dump, and you either move the decisions into it or close it and stop paying.

The second source of truth. Files live in the portal, decisions live in a chat app. Take your last approval and try to prove from the portal alone who approved what and on which date. If you cannot, the portal is decorative and the risk sits with you. This is a channel problem more than a tool problem, and it is worth reading the 40-point test before you add another client communication channel.

Security theatre. A login screen in front of file links that work for anyone who has them. Test: copy a file link, open a private browsing window, and try it while logged out. Do this before you promise a client anything about access.

The portal you maintain. Self-hosted or plugin-based, and slowly becoming a side project. Test: add up the hours it consumed in the last six months and compare them against the subscription you were avoiding.

A ten-day trial, run on one real project

Trials fail when they are explored rather than used. Pick one live project and one client who tolerates a hiccup.

• Day 1 — Set up one workspace, your real brief questions, your real file types
• Day 2 — Send it to the client. Send nothing else. No email chains running alongside it
• Days 3–5 — Record steps-to-first-action, and every question the client asks about the tool rather than the project
• Day 6 — Introduce a scope change and see whether the change is visible in the portal a week later
• Day 8 — Take an approval and check what the record looks like
• Day 9 — Export everything and open the export on a different machine
• Day 10 — Read the cancellation terms and find out precisely what you keep

The staged version of this, with what to check at each workflow point, is in our client portal free-trial walkthrough.

The nine-item close-out checklist

Closing a workspace is what keeps M small in the cost formula, and it is one of the easiest steps to skip.

1. Final files exported into your own archive, not left sitting in the portal

2. Brief content exported as structured data and as a readable document

3. Approval record exported with names and dates intact

4. Credentials handed over and removed from the portal

5. Client access downgraded to read-only or revoked on a date you agreed in writing

6. Workspace archived so it stops counting toward billing

7. Large source files moved off the storage you rent monthly

8. Reusable brief answers copied into your template library

9. One line written down about what the client misunderstood in the brief

Do the ninth one. It is the only item on the list that makes the next project cheaper.