How to plan a client portal
Before sketching screens, there are three questions that determine whether a client portal will actually get used.
A well-planned client portal cuts down on emails, calls and your team's time. A poorly planned one becomes just another screen nobody uses, because emailing someone you trust will always be easier than logging into something new.
The first question is what specific task it solves. "So the client can see everything" isn't a goal, it's an unprioritized feature list. A portal that solves one high-value task well — say, checking an order's status without calling — drives more adoption than one with ten lukewarm sections.
The second is what it specifically replaces. If a client today asks for an invoice by email, the portal has to be objectively faster than sending that email, or nobody will change the habit. This shapes not just which features the portal has, but how simple it has to be to log in and find what you're looking for.
The third is who will actually use it. A portal for twenty corporate clients with one dedicated admin user is a different problem than one for thousands of end customers who'll log in once in a while. The first can tolerate more complexity; the second needs to be obvious from the first second.
Only with those three answers does it make sense to design screens. A client portal isn't a "digitize everything" project — it's solving a handful of concrete tasks better than they get solved today by email or by phone.