Will our customers actually use it?

Some will immediately, and adoption grows in proportion to how much faster the portal is than calling. The reliable predictor is not demographics, it is the gap: where signing in and finding the answer takes twenty seconds and the phone takes four minutes, people switch. Where the portal takes a password reset and three clicks to reach a number that is two days stale, they do not, and they are right.

Our data is sensitive. Is a portal safe?

Sensitivity is the argument for designing it rather than adding it on. Scoped access so an account can only reach its own records, encryption in transit and at rest, logging of every view and download, retention rules per record type, and a documented list of what the portal holds and who can reach it. What was built gets written down so a privacy officer can review it, and the determination is theirs to make.

Can it connect to our practice management or ERP system?

Most modern systems can be connected and some are considerably harder than others. The answer depends on the specific system by name and version, whether it is hosted or on premises, what its interface offers, and whether a test environment exists. Older and locked down systems are where the surprises live, which is why they are the first thing to check rather than the last.

What if only a fifth of customers adopt it?

That can still be the whole business case, and it depends entirely on which fifth. Contact volume is rarely distributed evenly: a small number of high-frequency accounts usually generate a large share of routine questions. The metric that matters is contacts deflected, not accounts created, and an adoption number without a contact number behind it tells you almost nothing.

Should we build the customer side or the staff side first?

Neither on its own. Build one question type end to end, both sides, and put it in front of real customers with the phone line still open. A customer view with no staff tooling creates a second place for your team to check, which adds work rather than removing it, and that is the most common way a portal makes things worse.

A material study in bright daylight. A thick rope of clear turquoise glass strands arches over like a doorway, wound once with a pearl silver band, its feet planted in a rippled pale floor with a second arch continuing off frame.

Home
Insights
Web Applications and Portals
What a portal is worth

Decision guide

What a customer portalis actually worth.

A portal is worth the arithmetic of deflected contacts: how many times a year customers ask a question a system already knows the answer to, how long each one costs, and what share the portal can really take. The first two numbers are already recorded in systems you run.

Every input to the calculation below comes from a phone log, a shared inbox or a ticket queue. Nothing in this article supplies a benchmark, because a benchmark from somebody else is a number about their business. Written 23 September 2026.

HUREAL / Material studies

The count

The number you needis already recorded.

A portal is a machine for removing repeated questions. Its value is therefore a count, and the count already exists in systems most businesses already run. It is almost never looked at, because nobody owns the question, and it takes about a week of low effort to produce.

Take four consecutive weeks, chosen to be ordinary rather than quiet or peak, and classify every inbound contact by what it was about. Four sources between them hold nearly all of it: the shared inbox, which can be searched by subject phrase; the phone system's call log, which gives volume and duration even where nobody logged a reason; the activity records in the CRM; and the ticket queue if one exists.

For each question type, record three things. Volume, as contacts per week. Handling time, as the minutes from the contact arriving to it being resolved. And which system holds the answer, by name, because a question whose answer lives only in somebody's head is not a portal candidate, it is a different project.

The number you should not invent. The true cost of a two-minute question is higher than two minutes, because the person answering it was doing something else. That difference is real and it is specific to how your team works. Either measure it by asking people to note when they got back to what they were doing, or leave it out entirely and know your answer is conservative. Applying a multiplier you read somewhere produces a business case that cannot survive being questioned.

The rate

Deflection is nota percentage you can borrow.

Having counted the contacts of a deflectable type, the temptation is to multiply by a deflection rate. Every proposal in this category contains one. Almost none of them can say where it came from, and a rate taken from another company is a fact about that company's customers, its systems and its sign-in flow.

Deflection is a chain, and it breaks at the weakest link rather than averaging across them. For one contact to be deflected, the customer has to know the portal exists, have an account, be able to get into it, find the answer, and find it faster than calling would have been. Each of those has its own failure rate and they multiply, which is why portals with excellent screens and a bad password reset deflect almost nothing.

The measurement that works is a pilot, and it is cheaper than the argument about the rate. Take a subset of customers, ideally the ones who contact you most. Give them the portal. Leave the phone line open and do not restrict anything. Then compare contacts per customer per month, for that subset, before and after, against the rest of the base as a control. That produces your deflection rate, on your customers, and it is the only version of the number that will survive a finance review.

What to measure, in order of usefulness

Contacts per customer per month, for the pilot group and the control group. This is the whole answer and everything else is diagnostic.
Then, where it broke

Accounts created as a share of those invited. Sign-ins as a share of accounts. Successful answers as a share of sign-ins. Three ratios, and the smallest one is the thing to fix next.
And the one that decides whether to widen it

Contacts from the pilot group that were about something the portal already answers. That number is the gap between what the portal can do and what customers know it can do, and it is usually solved with communication rather than with software.

The candidates

Four questions,and what each one needs.

Routine inbound contact in a service business tends to collapse into four types. They are worth separating because they have different costs: two of them need only a read from an existing system, and two need the portal to write back into one, which is a materially larger piece of work.

The four routine question types, and what each one requires
The question	What it needs from your systems	What it needs from the portal
Where is my order or my job	A read from the system that actually holds status, which is usually an ERP, a job management system or a carrier feed.	A status with a timestamp on it and a stated next step. A status with no date is the same as no status.
When am I booked, and can I move it	Read and write against the real calendar, including staff, resources, buffers and the rules about who can do what.	Real availability rather than a request form, and a cancellation policy applied by the system rather than by an apology.
Do you have my document, and here is another	A document store with per-account permissions and an audit trail, which is often the thing that does not exist yet.	Exchange in both directions, a record of who uploaded what and when, and a notification to a person when something arrives.
What do I owe, and can I pay it	A read from the accounting or billing system, and a payment route that reconciles back into it without a person re-keying.	The invoice as the customer expects to see it, the balance, and payment without a phone call.

Scroll the table sideways to read it.

A first phase that takes the two highest-volume types is almost always a better project than one that takes all four thinly. Two types done properly change the contact numbers. Four types done partially produce a portal that customers try once.

The other half

Half of a portalfaces your own team.

What a portal needs on the staff side

A view of exactly what the customer can see, so a phone call can be answered without guessing. A queue for the cases the portal handed over, with an owner and an age on each. Calendar exceptions and overrides, because real businesses have them. A waitlist, if bookings are involved. And the ability to act on behalf of a customer who cannot, which is the case that arrives on day two.

Roughly half the build sits here, and it is the half that gets cut when a budget tightens, because it is invisible to the buyer. Cutting it produces a second screen your team has to remember to check, which is a new job rather than a removed one.

Why the portal has to read the source

A portal that reads from a nightly copy is confidently wrong for up to a day. That is worse than no portal, because a customer who is shown a delivery date acts on it: they book a crew, they tell their own customer, they stop calling. A portal that silently lies is a portal that creates escalations rather than removing them.

Where the source system genuinely cannot be read live, the honest design shows the age of the data on the screen, in words, next to the number. A date that says as at 6am today is trustworthy. The same date with nothing next to it is not.

Design for the customers who will never use it, too. They are not going away, they should not receive a worse service, and the portal's real job for them is to shorten the queue they are waiting in.

The second return

The saving is real.It is not the whole case.

Deflected contacts are the number a portal is justified on, and they are rarely the number that makes it worth having two years later. Three other effects show up, and each of them is measurable if it is set up to be measured before launch rather than argued about afterwards.

Bookings outside office hours
The share of appointments made when nobody was available to take a call. This is not a deflected contact. It is a contact that would never have happened, and it is counted separately or it is lost in the arithmetic.
Time to resolution, not just time saved
A document requested at nine at night and uploaded at nine at night moves a file forward by a day. Across a pipeline, that compounds into something a deflection count never shows.
Fewer errors in re-keying
Every routine question answered by a person is also a chance to give a slightly wrong answer. A portal reading the source does not misread its own screen.
A record where there was a conversation
Document exchange in a system with an audit trail replaces an email thread nobody can find, which matters most on the day somebody disputes what was sent.

And the cost nobody puts in the model. A portal is software with accounts in it, which means it now needs patching, monitoring, a support route for people who cannot sign in, and a privacy position that has to be maintained rather than written once. Put a running cost in the business case from the start. A project that is only justified when its running cost is omitted was not justified.

Questions

Questions peopleactually ask.

Will our customers actually use it?

Some will immediately, and adoption grows in proportion to how much faster the portal is than calling. The reliable predictor is not demographics, it is the gap: where signing in and finding the answer takes twenty seconds and the phone takes four minutes, people switch. Where the portal takes a password reset and three clicks to reach a number that is two days stale, they do not, and they are right.
Our data is sensitive. Is a portal safe?

Sensitivity is the argument for designing it rather than adding it on. Scoped access so an account can only reach its own records, encryption in transit and at rest, logging of every view and download, retention rules per record type, and a documented list of what the portal holds and who can reach it. What was built gets written down so a privacy officer can review it, and the determination is theirs to make.
Can it connect to our practice management or ERP system?

Most modern systems can be connected and some are considerably harder than others. The answer depends on the specific system by name and version, whether it is hosted or on premises, what its interface offers, and whether a test environment exists. Older and locked down systems are where the surprises live, which is why they are the first thing to check rather than the last.
What if only a fifth of customers adopt it?

That can still be the whole business case, and it depends entirely on which fifth. Contact volume is rarely distributed evenly: a small number of high-frequency accounts usually generate a large share of routine questions. The metric that matters is contacts deflected, not accounts created, and an adoption number without a contact number behind it tells you almost nothing.
Should we build the customer side or the staff side first?

Neither on its own. Build one question type end to end, both sides, and put it in front of real customers with the phone line still open. A customer view with no staff tooling creates a second place for your team to check, which adds work rather than removing it, and that is the most common way a portal makes things worse.

Three that followfrom this one.

The service behind this article

Counting first,building second.

A Web Applications and Portals engagement opens by counting the questions rather than by drawing screens, because the count decides both what gets built and whether it should be. The output of that first stage is a document about your contact volume, and it is useful whether or not anything is built.

The discovery call does the counting with the people who answer the phone. What customers contact you about, how often, which system holds each answer, and which two question types would carry the pilot. The written proposal carries the arithmetic and a scope priced against it.

Book a discovery call

More on this subject in the Web Applications and Portals index, and everything else at Insights.

A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Software you own from day one.