Scoping a first customer portal around one real workflow

Customers keep asking for the same documents, the same approval status, the same "where are we up to". Staff dig it out of email, send it again, and hope the latest version is the right one.

That's usually when someone says we need a customer portal. Fair. A login and a dashboard only help if the information behind them is reliable and the next action is obvious.

Start with the task staff keep repeating

I don't start with features. I start with the sentence: customers should be able to do this without asking a member of staff. Then I ask how often it happens and what staff currently do to help.

A service business might need customers to open the latest proposal, request a change, and see whether a reply is due. That's concrete enough to design and test. "Better customer experience" isn't.

When an existing tool is enough

Before building anything, I look at what you already use. If it has a customer area that covers the job, setting that up is often the sensible first move. A bespoke app brings hosting, updates, and support you own forever.

I check a few basics:

• Can customers finish the task without staff copying data between systems?
• Can you control who sees each document or request?
• Can staff handle exceptions without inventing a second unofficial process?
• Can you get your data out if you change direction later?

If the existing option meets those, I want a clear reason to replace it. The fact that Laravel can build a portal doesn't mean you should.

When a custom portal is worth talking about

Custom work earns its keep when the workflow is specific enough that off-the-shelf leaves real gaps. Customers across several sites. Approvals that must come from a named person. Data sitting in systems that don't talk to each other.

"We need approvals" can mean one confirmation button or three stages with exceptions. Those are different projects. Bring a real example of how it works today, including the awkward cases. The customer who changes their mind. The document that needs replacing. The request that can't be completed cleanly. Those details decide whether the proposed build will be useful.

Ship one complete workflow first

I prefer a smaller first version that finishes one useful job. Clearer acceptance test. Real use before the wishlist grows.

For document approval, a first release might include:

• Staff assign a document to the right customer.
• The customer sees which version needs attention.
• An authorised person approves it or asks for a change.
• Staff see the response and know what happens next.
• Both sides can refer back to the recorded decision.

That's enough to talk about permissions, notifications, and the staff side. Chat, invoicing, reporting, and a mobile app can wait until there is a business reason. They don't all belong in the first estimate.

Who owns the data, and who can see what

If the portal shows information from another system, decide where that information is maintained. One place to change an address, update a status, or replace a document. Otherwise staff end up keeping two versions and the portal looks finished while the admin work remains.

For each integration I ask what happens when the data is late, incomplete, or missing. Last known update with a timestamp? A clear "unavailable" message? A route to contact someone? A confident status nobody trusts is a poor result.

A login only proves who someone is. It doesn't decide which customer records they may open. I want the brief to spell out the difference between a customer admin, a normal customer user, and your own staff. Can they invite colleagues? Approve a request? Download every document for their organisation? What changes when someone leaves?

I also want tests that one customer's account can't reach another customer's records, including through direct links and downloads. Hiding a button isn't enough.

Make the awkward path usable

Happy-path demos are easy. Useful questions are what happens when a customer uploads the wrong file, misses an invite, or needs help finishing a request.

Include a clear support route and a staff view that shows what the customer is staring at. If staff can't see the stuck state, the work returns to email. Mobile matters too. If someone is expected to approve from their phone, test that on a small screen. A desktop dashboard squeezed down isn't automatically a good mobile experience.

If a portal sounds like the right fit, that sits under my Laravel development work. When the app needs to keep evolving after launch, I also do Laravel systems and ongoing support. Pricing and ways of working sit on the service pricing page. A portal needs its own scope. A generic starting figure isn't a quote for your process.

Want to talk it through? Use the form on dawsony.com and tell me the one task customers keep chasing, the systems involved, and where staff step in today. No spec needed.