outsource
Every Thursday someone on the team spends forty minutes turning the board into a status update for the client. The update is accurate on the Thursday and wrong by the Monday. The client, meanwhile, has taken to asking in a group chat, because the chat answers faster than the document does. Files for the project live in three places depending on who sent them.
This is the situation client portal software is bought to fix, and it is also the situation a badly chosen portal makes worse. A portal that is a separate place, filled in by hand, is simply the Thursday document with a login screen. It will be current for the first month and abandoned by the third. The portals that survive are the ones showing the same records the team is already working in, with access narrowed rather than content duplicated.
Vendor feature lists are long. The questions clients bring are short, and there are four of them.
Where is this, and is the date still the date. The overwhelming majority of portal visits are this question. It does not need a dashboard. It needs the current state of the pieces that matter to the client, and a visible delivery date that moves when it moves.
What is waiting on me. The single highest value thing a portal can show, and the one most often missing. Client side delays are common and usually invisible until they are being argued about. A list of items blocked on the client, each with the date it started waiting, changes the tone of every status conversation.
Where is the current version of that file. Not all files. The approved brief, the latest deliverable, the signed documents. A portal that mirrors an entire drive makes this question harder to answer rather than easier.
What changed, and what it cost. Approved changes, revised dates, invoices. This is the part clients remember, and the part most portals leave to email.
A portal that answers those four well, and nothing else, will be used. One that answers them alongside twenty other panels usually will not, because the four get buried.
Products sold under the same phrase are built for three different jobs, and the mismatch between them is the most common buying mistake.
| Shape | Built for | Signs it is the right one |
|---|---|---|
| Support portal | Many customers each raising tickets | Volume of requests, need for a knowledge base and SLA reporting |
| Project portal | A handful of clients, each with ongoing delivery work | Status, deliverables, approvals and dates matter more than tickets |
| Deal or onboarding room | One shared space per prospect or new account | Content is mostly documents and a sequence of steps, finite in length |
The support shape and the project shape look similar in a demo and behave nothing alike. A ticketing portal asks the client to open a request and wait. A project portal shows work already planned and asks the client to respond to specific things. An agency that buys the former for the latter's job ends up with a portal where the client opens tickets asking for status updates, which is the original problem wearing a new interface.
The onboarding room is the narrowest and often the most appropriate for finite engagements. It is not built to run for two years, and choosing it for a long relationship means migrating later.
A portal is a view onto work, or it is a second place where the work is described. The second kind dies, and it dies for a reason that has nothing to do with the software's quality.
Duplicated status has a maintenance cost that falls on the busiest person on the team, and that cost is paid weekly whether or not the client reads it. The moment a deadline gets tight, the portal update is the first thing dropped. Once it is a fortnight stale, the client stops trusting it, goes back to asking in chat, and the portal becomes a subscription nobody cancels.
Three questions separate a view from a copy.
Does updating the work update the portal. If the answer involves a person copying anything, the portal is a copy.
Is there one record or two. A task that exists internally as one item and externally as a summary written by hand is two records, and two records disagree.
Who is responsible for the portal being current. If the answer is a named person rather than nobody, the design is wrong. Nobody should need to be responsible, because nothing should need doing.
This is why the strongest option for a small team is often not a dedicated portal product at all. It is guest access to the same boards the team already uses, scoped down to what the client should see. The client sees real state, because it is the real state, and no separate update exists to go stale. Teams checking whether the boards they already keep can be narrowed for outside viewers usually find the answer changes the whole decision.
The phrase sounds like marketing and describes a real design question. Four layers of access need deciding, and most portal problems come from treating them as one setting.
Which records are visible. The useful default is a whole board or project per client, rather than per item, because per item permissions have to be maintained by someone and will eventually be got wrong. Structuring work so each client's items sit on their own board makes the access question answer itself.
What a guest may do. Read, comment, or edit. Comment is the setting that matters most and the one people skip past. A client who can comment on the item itself stops sending feedback by email, which means the feedback lands where the work is instead of in somebody's inbox.
Which fields and conversations are hidden. Internal notes, estimates, hourly figures and frank discussion about the client's own decisions all belong in the workspace and not in the client's view. If the tool cannot separate an internal thread from a shared one, the team will self censor in the place where it needs to speak plainly, and the real conversation moves to private messages.
What happens when someone leaves. Guest accounts outlive the relationships that created them. A quarterly review of who still has access is dull and prevents the worst incidents. Any serious choice should include reading how access and deletion are handled before the first client is invited.
One more point, easy to miss in a demo: notifications. A portal that emails the client about every internal comment will be muted within a week, and a muted portal is worse than none, because both sides now believe the other has been informed.
Four routes exist, and the right one depends on how many clients there are and how much the work differs between them.
| Route | Strength | Cost that shows up later |
|---|---|---|
| Dedicated portal product | Built for the purpose, white labelling usually included | Work has to be entered or synced into it, and sync is never complete |
| No code builder over existing data | Exactly the fields wanted, on the wanted domain | Somebody owns it forever, including when the schema changes |
| Guest access in the project tool | No duplication, real state, nothing to maintain | Branding is the tool's, not the firm's |
| Shared drive plus a status document | Free, familiar, no onboarding | Manual, and it answers none of the four questions well |
The honest trade off is branding against duplication. A dedicated portal or a custom build gives a client experience carrying the firm's name on the firm's domain. Guest access in the working tool gives a client experience that is always current, on somebody else's domain, with somebody else's logo in the corner.
Which matters more is a business judgement, not a technical one. For a firm whose positioning depends on a seamless branded experience, the portal product is worth its maintenance. For a team of five delivering work where being accurate beats being polished, the branded portal is usually the expensive option that goes stale, and narrowed access to the real boards is the one still in use next year. Where the work also needs to be visible on a timeline rather than only as a list, a tool carrying board and timeline views over the same items removes the main reason teams start building a separate portal at all.
A portal can be correct, current and completely ignored. The habit on the client side is a separate piece of work from the setup, and three things decide it.
One link, sent by one person, repeatedly. New places get used when they are the answer to a question rather than an announcement. The strongest method is to stop answering status questions in chat with the answer, and instead reply with the link and one line. Two or three rounds of that establishes where the answer lives. Sending a launch email and then continuing to answer in chat teaches the opposite lesson.
A reason to visit that is not status. Approvals work best. If the place where a deliverable is approved is the portal, the client goes there because a decision is waiting, and sees everything else while they are there. A portal offering only information gives no reason to open it on a quiet week.
Nothing to learn. Client side users log in occasionally and will not learn an interface. That means one board, not five, default views that need no configuring, and no request that the client set up notification preferences before the thing is useful. Any onboarding step longer than a paragraph is a step that will not be completed.
It is worth naming what the client does not have to do. They are not being asked to adopt a tool, maintain anything, or attend a walkthrough. Where a portal is pitched to a client as a change to how they work, it meets resistance that has nothing to do with the software. Where it is simply the place the answer now lives, it is adopted without discussion.
Six checks, in the order they cause regret.
Does the client's view update when the work updates, without anyone copying anything. Can internal discussion be kept genuinely separate from shared discussion. Can a guest comment without being able to edit. What does the client receive by email, and can that be turned down. What happens to the client's access, and to their files, at the end of the engagement. And what is the cost per client, since portal products that charge per external user get expensive in exactly the case where the portal is succeeding.
Two further checks apply if files are central. Whether the portal stores files or links to them determines where the authoritative copy lives, and having two copies of a signed document is worse than having one in a slightly awkward place. And whether a client can upload is the difference between a portal and a brochure.
Before evaluating any product, write down the four questions a client currently asks and where each answer lives today. If all four already exist somewhere the team maintains, the task is narrowing access to it, not buying a second system.
Then run one client on it for a month, with one board, comment access, and internal notes kept separate. A month is enough to see whether the client stops asking in chat, which is the only test that matters. Teams starting from boards they already keep can see how Pinateca handles guests and scoped access before committing to a dedicated portal.
For a handful of clients, guest access to the boards the team already works in is usually stronger, because the client sees real state and nothing needs updating by hand. A dedicated product earns its cost when branding on an owned domain matters commercially, or when the number of external users is large enough to need self service.
Almost always because the portal is a second copy of the work. Copying status into it is a weekly cost that gets dropped the first time a deadline is tight, and a portal that is a fortnight stale loses the client's trust permanently. A portal that shows the same records the team works in has nothing to go stale.
Choose a tool where internal threads and shared threads are genuinely separate, and check it before inviting anyone. If the separation is not reliable, the team will hold frank conversation somewhere else entirely, and the workspace stops being a record of how decisions were made.
Read the current state of their work, see what is waiting on them, find the approved files, and comment. Comment access is the one most often skipped and the most valuable, because it moves feedback out of email and onto the item it concerns. Edit access is rarely appropriate.
A list of items blocked on the client, each showing how long it has been waiting. Client side delay is normal and usually invisible until it is being disputed. Making it visible without comment changes the conversation about dates more than any progress bar does.