A customer emails to ask where their order is. Someone opens the ops system, checks the status, copies it into a reply and sends it. Ten minutes later a different customer asks for a copy of last month's invoice. Then someone wants to know whether their engineer is still booked for Thursday.
Every one of those answers already exists in your systems. Your team is just acting as the search box.
That is usually when a business starts asking about a customer portal. It is a good question, but it is often framed the wrong way. The hard part of a portal is not the login page or the dashboard. It is deciding exactly what each customer is allowed to see, and making sure the data behind it is true.
Symentic Technologies is a UK software company that builds custom operations systems, portals and integrations for SMEs in the UK, Australia and New Zealand, and we run two live SaaS platforms of our own. This post is how we think about a custom customer portal with clients, including when we would tell you not to build one.
The short answer
A custom customer portal is worth building when three things are true:
- Your customers repeatedly ask for information you already hold, such as order status, job progress, documents, invoices or bookings.
- That information lives in a system you control, or can reliably sync from.
- Off-the-shelf portals (the one built into your CRM, helpdesk or accounting tool) cannot show it, because the data or the rules are specific to how you work.
If your accounting or helpdesk tool already has a customer portal that covers what people ask for, switch that on first. It is cheaper and faster. Custom earns its place when the questions customers ask cut across several systems, or follow rules only your business has.
What a customer portal is actually for
A portal is not a brochure behind a login. The useful ones do a small number of jobs well:
- Answer status questions. Where is my order, job, application or request, and what happens next?
- Hand over documents. Invoices, quotes, certificates, reports and delivery notes, without someone attaching them to emails.
- Take structured requests. New orders, repeat orders, change requests or bookings, in a format your team can act on without retyping.
- Let customers fix their own details. Delivery addresses, contacts and billing details, with a record of who changed what.
A good test: list the last fifty customer emails your team answered. Mark the ones where the answer was a lookup in a system you already have. That list is the first version of your portal. Anything not on it can wait.
Five questions to answer before anyone designs a screen
1. Who is "the customer"?
In business-to-business work, a customer is rarely one person. It is a company with several people: someone who orders, someone who pays, a manager who wants to see everything and a site contact who should only see their site.
Decide this early. A portal where every user at a customer sees everything is simple to build and often wrong. A portal with roles (for example: admin, ordering, accounts, site-only) takes more thought but matches how your customers actually work. It is the same multi-tenant, role-based access problem we deal with in our own platforms.
2. Which system owns each piece of data?
The portal should not become a new place where data lives. It should show data from the systems that already own it: your ops system for orders and jobs, your accounting tool for invoices, your document store for certificates.
That means writing down, for each item the portal shows, where the true version lives and how fresh it needs to be. We covered why that matters in your ops system and Xero should agree. A portal that shows a customer the wrong balance does more damage than no portal at all, because now they have it in writing.
3. What should a customer never see?
Internal notes, margins, other customers' data, draft quotes, staff comments on a job. Make that list explicitly. It is much easier to design a portal around "only these fields are ever exposed" than to remember to hide sensitive ones later.
4. What can a customer change, and what happens next?
Every action in a portal is a promise. If a customer can place a repeat order at 11pm, who sees it, and when? If they change a delivery address, does that update a job that is already out? Map the step that follows each action before building the button.
5. Who will answer when the portal is wrong?
Portals create a new kind of question: "your portal says X, but...". Decide who owns those, and make sure staff can see exactly what the customer sees.
Security: the part that is not optional
A portal puts your business data on the internet behind a login. That makes two things critical.
Access control is the main risk
The most common serious flaw in web applications is not a clever hack. It is a logged-in user seeing something they should not, for example by changing an order number in the address bar. The OWASP Top 10, the most widely used reference list of web application security risks, ranks broken access control first in its 2025 edition, as it did in 2021.
In practice, that means every request for a record must check, on the server, that this user at this company is allowed to see that record. Not just hide the link in the interface. This should be tested deliberately, with one test customer trying to read another's data.
Logins should be strong without being painful
The UK's National Cyber Security Centre publishes guidance on choosing authentication methods for customers of an online service, and in April 2026 said passkeys should be the default login option for consumers. For a business portal, a sensible baseline is: no shared logins, a second factor or passkey for anyone who can see financial data or place orders, and an easy way for a customer's admin to remove a person who has left.
Personal data still comes under data protection law
If the portal shows names, contact details or anything else about individuals, UK GDPR, Australia's Privacy Act and New Zealand's Privacy Act 2020 all expect you to protect it appropriately. That is a design input, not a sign-off at the end: keep what you show to what is needed, log access to sensitive records, and know how you would respond if a customer reported seeing someone else's data. This is general guidance rather than legal advice; take advice on your own obligations.
Off-the-shelf portal vs custom portal
Be fair to off-the-shelf options. Many accounting, helpdesk and CRM tools include a portal, and for some businesses that is enough.
An off-the-shelf portal usually fits when:
- Customers mainly want invoices and payment links, or to raise and track support tickets.
- All the data they need already lives in that one tool.
- You are happy with that tool's layout, roles and branding.
A custom portal usually fits when:
- The answers customers want come from more than one system (orders from one place, documents from another, invoices from a third).
- Your process has steps a generic tool does not know about, such as approvals, site visits, production stages or compliance checks.
- Customers are companies with several roles, and access must follow your rules.
- You want customers to place structured orders or requests that flow straight into your operations system.
A middle path often works well: start with the portal your accounting tool provides for invoices, and build a small custom portal only for the order or job status that no tool can show. The rule we apply to Zapier versus custom integration applies here too: build custom only where the generic tool genuinely runs out.
How we would scope a first version
A first portal does not need to do everything. A version we would typically suggest scoping:
- One status view. The order, job or request list for that customer, with a clear current stage and a plain-English "what happens next".
- One document type. Usually invoices or delivery notes, pulled from where they already live.
- Roles. At least a customer admin and a standard user, with the admin able to invite and remove people.
- A staff "view as customer" mode, so your team sees exactly what the customer sees.
- Access tests that prove one customer cannot reach another's records.
Then measure the thing that started it: how many "where is my order?" emails still arrive. If that number drops, add the next feature. If it does not, find out why before building more.
We scope this in writing, with a fixed cost or a monthly retainer agreed before work starts, and the client owns the code, the hosting and the documentation. If the real issue is that a request passes through five tools before anyone acts on it, a portal will only show that mess to customers. Fix the flow first; we wrote about that in you don't need another SaaS login, you need fewer handoffs.
FAQ
What is a custom customer portal?
A custom customer portal is a secure website where your customers log in to see their own orders, jobs, documents and invoices, and to make requests, using data from your own systems and following your business's rules about who can see and do what.
When is a customer portal worth building?
When your team regularly answers customer questions by looking up information you already hold, and the tools you already use cannot show it to customers themselves. If your accounting or helpdesk tool's built-in portal covers what customers ask for, use that first.
Should a customer portal store its own data?
Usually not. A portal should display data from the systems that already own it, such as your operations system and accounting tool, so there is one version of the truth. It may store portal-specific things, such as user accounts and preferences.
What is the biggest security risk in a customer portal?
Broken access control: a logged-in user seeing or changing data that belongs to another customer. OWASP ranks it as the top web application security risk in its 2025 Top 10. Every request must be checked on the server, and that should be tested deliberately.
How long does a custom customer portal take to build?
It depends on how many systems it reads from and how complex your roles are. Focused builds we take on often reach production in six to twelve weeks, but nobody can give you an honest figure for yours until the scope is written down. We explained why in nobody can price your software from a blog post.
The short version
Build a customer portal to stop your team acting as a search box, not to add a login for the sake of it. Start from the questions customers actually ask, decide who the customer is and what each role may see, keep data in the systems that own it, and treat access control as the main risk. Start small, measure whether the emails drop, then grow it.
Your team spending hours answering "where is my order?" Book a 30-minute discovery call and walk us through how an order, job or request moves through your team today. We will tell you whether a portal would help, whether an off-the-shelf one would do, and what a first version should include. You can also see what we've built or get in touch by email.
Related reading: Zapier is great glue. It was never meant to run your business. · Your ops system and Xero should agree. Usually they don't. · You already built custom software. It's a spreadsheet. · Every supplier looks the same until you try to leave