The calls you stop taking
Count how many inbound contacts are simply requests for status: where is my order, has that been approved, when is the engineer coming, can you resend the invoice. In most operations it is a substantial share of all contact, and every one of those interruptions costs more than the answer is worth.
A portal removes them by publishing the same information your team would have looked up, from the same system of record.
Why the system of record matters
A portal fed by a separate copy of the data becomes a liability within a month, because the copy drifts. The version that works reads live from the system that already holds the truth, which is why portal projects are so often really integration projects wearing a nicer interface.
- One source for each fact, with the portal reading rather than storing
- A clear rule for what the customer can see and what stays internal
- Timestamps, so nobody argues about when something changed
- An audit trail of what the customer did, not just what you did
What to publish first
Start narrow. Status of live work, key documents, and the ability to raise something new. That covers the majority of contact reasons in most businesses. Payments, self-service changes and richer history can follow once the first version is genuinely being used.
If a portal launches with everything, nobody can tell which part earned its place.
The second-order effects
Two things tend to follow. Internal record-keeping improves quickly, because the data is now visible to the customer and errors get reported. And the sales conversation changes: a client who can see progress asks better questions and chases less, which is a quieter but real commercial benefit.
What to measure
Before build: inbound status contacts per week, and average time to answer them. After: the same numbers, plus portal logins per active customer. If logins are low, the problem is usually that the portal answers a question people were not asking.
