GBCORP BLOG · IT SERVICES
Customer Portal Development: B2B Accounts, Roles and Data
A portal for business customers has two problems a consumer app does not: one customer is really several people, and the data usually lives in a system nobody wants to touch. Solve those first, and the screens are the easy part.
Customer portal development produces a signed-in area, on the web and in an app, where customers see their invoices, orders, documents and requests without calling anyone. GBCORP’s White-Label Customer Portal covers the common case, configured on your domain. This article is about what makes a business-to-business portal harder, and how to decide what to configure and what to develop.
Where the data comes from
| What customers see | Where it lives today | How it usually reaches the portal |
|---|---|---|
| Invoices and statements | Accounting system | Scheduled export or a connection, read only in the portal |
| Orders and delivery status | Order system or warehouse | A connection if one exists, a scheduled file if not |
| Contracts and certificates | Shared folders | Uploaded per customer, with access history |
| Datasheets and manuals | Marketing or product team | Uploaded and shared with the customers concerned |
| Requests and quotes | The portal itself | Raised by customers, answered from your console |
The honest question is how fresh each item needs to be. Last night’s invoices are usually fine, while stock and delivery status may need a live connection. A nightly file is cheap and robust. A live link costs more and is only worth it if customers act on the difference.
One customer, several people
A business customer is a buyer, someone in accounts and perhaps a site manager. The buyer needs orders and quotes, accounts needs invoices and statements, and the site manager needs delivery notes and certificates. They do not all need all of it. Agree a small set of roles, decide who at each customer can invite colleagues, and make it simple to remove someone who leaves. Otherwise shared logins appear, and any record of who did what disappears with them.
Configure or develop
The configured portal already provides a branded sign-in on your domain, invoices, receipts, statements, order and request history and per-customer documents. Develop on top of it when you need a connection to your accounting or order system, company accounts with several roles, or customer-specific prices and approvals. Each is scoped and priced before work starts, so the portal can go live first and gain connections in later releases.
Checklist before development
- List what customers call about most, with rough counts for a month.
- For each item, name the system it lives in and who controls it.
- Decide how fresh each one needs to be: live, hourly or nightly.
- Define a few roles, and who at the customer can add people.
- Choose five friendly customers for the first invitations.
- Set the figure that shows success: fewer requests for copies.
The numbers to expect
The configured portal goes live within one to five working days on the web, at a flat monthly plan. Connections to your own systems arrive in releases of two to six weeks at a fixed price, after a one-week scoping priced on its own. Customised or more complex functionality is quoted separately before any work starts.
A worked example
Consider an industrial-supply company with a few hundred trade accounts. Two people in accounts spend their mornings re-sending invoices and certificates. Counting a month of requests shows that most ask for copies of documents, a smaller group ask where an order is and very few ask anything requiring judgement. The first release is the configured portal: a nightly export from accounting brings in invoices and statements, and certificates and datasheets are uploaded per customer. Five friendly customers try it for two weeks and ask for one change, a search by order number. The company then invites accounts in batches, with a sentence added to every invoice e-mail. A connection to the warehouse for live order status is left until the counts show it is still needed.
Permissions tested, not assumed
The worst thing a portal can do is show one customer another customer’s invoice. Access must be enforced on the server for each request, tied to the signed-in person and their company, rather than simply hiding links on the screen. Test it deliberately before launch: sign in as one customer and try the web address of another customer’s document. Repeat that test whenever a new kind of record is added, and keep the access history, so a question about who opened a document can be answered in a minute.
What to leave out of version one
Portals tend to grow without anyone deciding they should, so the first version ought to be dull. Leave out dashboards with charts nobody asked for, discussion forums and anything that requires data you cannot yet supply reliably. A short menu with the three things customers actually came for will be used, and a long one will be abandoned at the first wrong figure. Accuracy matters more than breadth, since a single incorrect balance sends customers back to the phone.
Rolling out to trade customers
Business customers change habits slowly. Invite them in small groups, starting with those who contact you most. Add one sentence and a link to each invoice e-mail, and when someone asks for a copy, send it while also pointing to the document in the portal, until the customer gets used to looking there first.
Quotes and requests
A portal is also a way of receiving work. Customers raise requests and quotes from it and your team answers from a console, so each conversation stays attached to the customer instead of one person’s inbox. When someone is away, a colleague can see the history, and response times become something you can measure.
Finding old documents
A portal gains trust the first time someone finds a two-year-old certificate in seconds. Agree how far back to load history, label documents in the words customers use and allow search by their own order or reference number. Loading an archive takes effort once, and then saves a request each time it is used.
Security customers will ask about
Larger customers may ask how their records are protected. The portal uses a server-enforced password policy, single-use reset links and e-mail from your own mailbox, with DMARC and DNSSEC on your domain. Keep a short written answer ready, because procurement teams often ask the same questions each year.
Ownership terms
Your domain, your customer data, your documents and your outgoing e-mail stay yours, in a dedicated project exportable at any time. Any connection developed to your own systems is documented with its release, so it does not depend on one person’s memory. GBCORP takes no commission if you add payments later.
Questions we hear first
Do we need a mobile app as well?
Often the browser is enough for people at a desk, while the app helps people on site. Both come from the same product.
Can customers pay invoices in the portal?
Payments can be added later without a new sign-in. They settle to your own gateway account, with no GBCORP commission.
Will it replace our accounting system?
No. The accounting system stays the record. The portal shows its information to the customer it belongs to.
How do we stop one customer seeing another customer’s documents?
Each record is tied to a customer, and access is checked on the server for every request, not merely hidden on the screen.
Where to start
The GBCORP White-Label Customer Portal is the priced starting point; the GBCORP web development hub covers custom work around it. For what the portal includes and costs, read white label customer portal; for property and clinics, read tenant portal development and patient portal development.
GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Business Lounge, and EV's & Solutions.
