Give customers a portal that gets the work done
We build portals for customers, partners, vendors and staff: a place to submit a request, get it approved and see it finished in the system you already run. You see one workflow working with real roles and permissions before deciding anything about the platform behind it.
Connecting the CRM or ERP you already run is the usual case. Building a new one alongside the portal is welcome too.
A portal that shows status is not the same as one that finishes work
These are situations people describe when a portal was built to be looked at, not used. Yours may be different.
The portal shows a status. The request still moves by email.
A customer or partner signs in, sees where things stand, then calls or emails to get something done. The portal became one more place to check, not where the work happens.
Every submission gets re-typed into the system of record
A request lands in an inbox or a ticket queue. Staff re-enter it into the CRM or ERP by hand, because the portal was never connected to write anything back.
One login model, several kinds of user
Customers, partners and staff often need different views of the same account. A portal built for one kind of user leaves someone seeing too much, or asking for access they should already have.
Exceptions have nowhere to go
A payment fails, a document is missing, an approval is declined. In a lot of portals that just ends the interaction, and no one owns getting the person to a working outcome.
We do not claim every portal fails this way. A portal built for support conversations, where a ticket and a reply is genuinely the job, works fine as it is. The question is whether your customers, partners or staff need to complete a task in the portal, beyond checking a status, and whether the portal you have today does that.
One workflow, built as screens, permissions and a connection to your systems
A portal here is the request your customers, partners or staff need to make, with the permission check, approval and record update that finishing it requires.
- Customer, client or partner user
- Signs in, sees their own account, submits a request, and follows it to an outcome instead of a status.
- Staff who approve and fulfil
- See exactly the requests waiting on them, approve or decline with a reason, and the source system updates at once.
- Staff who handle exceptions
- Pick up a declined payment, a missing document or a failed sync from a queue built for that.
- Administrator
- Sets who can see and do what, by role and account, and sees the trail of every change.
- CRM or ERP
- The system of record. The portal reads and writes to it, not around it.
- Documents, payments and messaging
- Uploads, invoices and notifications attach to the request they belong to.
- Identity and SSO
- Each person signs in once, with the access their role and account allow.
- The platform you already run
- Salesforce, HubSpot or something else keeps running. A portal can connect to it or sit beside a new CRM.
One request, from submission to a system update
Every record here is invented. The walkthrough shows the kind of request we build most often: a person outside your company asks for something, someone inside approves it, and the system of record changes because of that approval. Nobody re-types anything.
We use an invented scenario because a portal is full of other people's data, and a walkthrough of a real one needs its owner's approval first.
Request
A partner signs in and submits a change against their own account. The portal only shows the accounts and actions their role allows.
Approval
The request reaches a queue for the staff member who owns that account. They approve, decline or ask a question, with a reason attached.
System update
An approval writes the change to the CRM or ERP directly, the same record staff already use, not a copy of it.
Confirmation or exception
The partner sees the outcome in the portal and by email. A rejected change moves to an exception queue instead of disappearing.
What this does not show. No real company, client or partner is shown. It shows how one request moves through permissions, approval and an update to the source system, including what happens when that update fails. It does not show a live account, measured volume or a finished rollout.
Discovery, one request, a pilot, then a decision
Each step produces something you keep, whether or not you continue.
Discovery call
We learn your roles, systems and the request that matters most. You get a short written summary.
Map one workflow
A map of one request end to end: who submits it, who approves it, what system it updates, and where it can fail.
Scoped proposal
A fixed scope for a pilot: what gets built, for which roles, how it is judged and what it costs.
Working pilot
A small group of your customers, partners or staff use it with real data while the current process keeps running.
Your decision
You compare the pilot with how the request works today and choose: stop, extend it, or plan a wider rollout.
Rollout and support
A staged rollout to more roles and accounts, with maintenance agreed in writing.
The questions that decide whether this is a good idea
- Who owns the code?
- You do. It lives in your repository. Where we build on an open-source foundation, we name it and its licence first.
- Who maintains it after handoff?
- Settled before the pilot, in writing: who upgrades it, who secures it, who answers when it breaks, and what that costs. It can be us, your team, or both.
- Do we always build something new?
- No. Sometimes the right answer is to configure or extend the portal your CRM already includes. If that is what we see during discovery, we will say so.
- Will it connect to our CRM or ERP?
- That is most of the work. We map every integration during discovery and test each one in the pilot, including what happens when a sync fails.
- Who can see what?
- Permissions are built by role and by account, not one shared login. Every request and change leaves a record of who did what.
- Where does AI fit?
- Inside the workflow, with access to the right records and a person handling exceptions, not as a layer on unchanged screens.
Seven things to know before you scope a portal
You can gather these in an afternoon. They make every later conversation shorter, with us or with anyone else.
- Which roles need the portal: customers, partners, vendors, staff, or more than one
- What each role needs to actually do, not just see
- Which of those actions are conversations, and which change a record
- The system of record for each type of data involved
- What happens today when a request fails or gets declined
- Whether you plan to keep your current CRM, replace it, or run both for a while
- Who would maintain the portal after launch, and whether you have engineers
Plain answers
- Do we have to leave Salesforce or HubSpot to get a real portal?
- No. A portal can connect to the CRM you already run. Sometimes the better answer is to configure what you have, and we will say so.
- How is this different from a native portal like Experience Cloud?
- It depends on what your roles need to do, not just see. The comparison is in the guide, including where a native portal is the right call.
- How long does a pilot take?
- It depends on the workflow and its integrations. We set the length in the proposal, after mapping, not before.
- What does it cost?
- We quote a fixed scope once the workflow is mapped. We do not publish a price list, because scope decides cost.
The two people you would actually talk to
Custom Portal Studio is a site of The Goodstack Company. There is no sales team and no account manager. David and Vidur are the only two people involved, from the first email through the pilot and the maintenance after it.
David
David runs beLoved Health, a distribution company, and built the system it runs on: CRM, wholesale portal, invoicing, samples and affiliate payouts. He writes the code and runs the pilots.
Vidur
Vidur is the co-founder of Goodstack and leads product and design. He designed the original Goodstack and ran the studio with David. He has experience with SOC 2 compliance, which matters the moment a system touches a customer's data.
Start by mapping one request
Tell us who needs to use the portal, the systems involved, and the request that matters most today. We will reply with what we would look at first.