How to Evaluate Client Portal Software Without Being Sold To

Client portal evaluations go wrong in a predictable way. The buyer assembles a feature list, sits through three demonstrations, scores them, and picks the highest total. Every product scores well, because every product was demonstrated by somebody who knows exactly which path through it works. Six months later the firm discovers the problem nobody asked about, and it is almost never a missing feature. It is a shape of work the product does not support.

A better evaluation replaces the feature list with a set of specific scenarios drawn from the firm's own week, and insists on seeing them performed rather than described. What follows is a structure for doing that, and it is written to be usable against any vendor including this one.

Before you contact anybody: write down what you are replacing

The evaluation is only as good as the description of the current state, and most firms skip this because they believe they already know. Write it down anyway, because the written version is always different from the remembered one.

• List every place a client currently receives something: email, a file-sharing link, a shared drive, a meeting, an attachment on an invoice.
• Count how many separate places a person would have to look to answer "what has this client been sent this quarter".
• Name the last three times something went to the wrong recipient or the wrong version went out. These are your real requirements.
• Write down who currently spends time on this and how much. Without a baseline, no benefit can be measured later.

The access control questions, asked before anything else

A client portal is an access control product wearing a collaboration interface. If the access model is wrong, nothing else matters, and the access model is the hardest thing to change after adoption. Ask these first and stop the evaluation if the answers are vague.

• Can one client organisation contain people with different visibility, so a finance contact sees invoices and a project contact does not?
• Can access be scoped below the engagement, to a single workstream, when a client's own divisions must not see each other?
• What exactly happens when a named client contact leaves their company? Is there one action that revokes everything, and is it auditable?
• Is there a record of who viewed each document and when, and can it be exported? A permission model without a viewing log cannot answer the question a dispute will ask.
• How does the product handle a person who works for two of your clients? This is common in regulated sectors and is where weak models fail loudly.

The demonstration script, written by you

Send the vendor a script in advance and ask them to perform it live in a session you record. A vendor who declines to work from your script is telling you something useful. The script should contain the ordinary week, not the impressive edge case.

• Onboard a new client contact from scratch, including the invitation email they receive, shown as they would see it.
• Publish a status report to a client, then correct a number in it and show what the client sees about the correction.
• Raise a request to the client, have it ignored, and show what the system does about that on its own without anybody remembering.
• Have the client approve something, then show where that approval lives and how it would be produced in a dispute two years later.
• Remove a person's access mid-engagement and show what they can and cannot still reach.
• Show the same screens on a phone. Client contacts read on phones and the mobile experience is where portals most often quietly fail.

The questions vendors dislike

These are not gotchas. Each one maps to a failure that has happened to somebody, and a good vendor has a straight answer ready.

• What is your median time to restore service after an incident, and where is your public status history?
• When we leave, what exactly can we take, in what format, and does it include the audit trail or only the documents?
• Which of your customers of our size can we speak to without you on the call?
• What does this cost in year three, with our expected growth, including every client contact we would need to add?
• What was the last feature you removed, and how were customers told? A product that has never removed anything has either never made a mistake or does not admit them.
• Where is our data stored, who can access it inside your company, and what happens to it when we cancel?

The pricing traps

Portal pricing is where evaluations most often mislead, because the demonstration is priced differently from the deployment. Three specific things to check.

First, whether client contacts are billable. A per-user price that includes your staff and excludes clients looks cheap until the fiftieth client contact. Second, whether storage is capped, and what the overage costs, because document-heavy engagements accumulate faster than anybody forecasts. Third, whether the features you were shown are in the tier you were quoted. Single sign-on, audit export and granular permissions are frequently the enterprise tier, and they are frequently the reason you are buying.

Run a real pilot, on a real client

A pilot on a sandbox with invented data proves nothing, because invented data is always tidy. Run one live engagement with one real client who has agreed to be a pilot, for a fixed period, with a written list of what would count as success.

The measurements that matter are behavioural rather than technical. Did client contacts return without being chased? Did the number of status questions arriving by email fall? Did your own team put things in the portal, or did they keep emailing and copy afterwards? That last one is the single best predictor of whether the rollout will succeed, and it is invisible in any feature comparison.

The competitive landscape, honestly described

The market divides roughly into three groups and they are not really competing with each other, which is why cross-group comparisons are unhelpful.

There are secure file exchange products, strongest on document control and regulated transfer and weakest on anything resembling project delivery. There are dedicated portal products aimed at small firms and agencies, strong on branding, onboarding and ease of setup, generally lighter on permission depth and audit. And there are professional services platforms where the portal is one surface of a larger delivery system, which are heavier to adopt and are the only group that can show a client something derived from the firm's own live delivery record rather than something published to them.

Atlas, by WRX Stack, sits in the third group. That is a statement about shape rather than superiority: if the problem is exchanging documents securely with counterparties, a file exchange product is a better answer and costs less. The third group earns its weight only when the client-facing view has to stay honest against a delivery record that changes daily.