Build branded portals where your sales team logs in to create and manage proposals. Enterprise plan.
The Sales Portal is a second app alongside the configurator. You build a branded, AI-generated portal where your own sales team logs in to create and manage proposals for customers. Reps work inside your configurators, and every proposal moves through a clear lifecycle so managers always know where each deal stands. Switch between the Configurator and Sales Portal apps using the app switcher at the top of the sidebar.
Each workspace has one stable portal address at /[workspace]/portal — the published portal your reps sign in to. Whichever design you have live is what they see there, so the address never changes when you switch or republish designs. From there reps reach their deals at /portal/proposals and open a configurator to build one at /portal/configure.
Portal members are not Spokbee account users — they sign in at a separate portal login page, kept apart from your Spokbee dashboard account. There are two ways to give a rep access:
Every member has one of four roles, which set what they can do inside the portal. In the dashboard Members page these show up as Admin, Sales Manager, Sales Rep, and Sales Ops — the underlying role keys are admin, manager, rep, and ops:
Roles are a starting point — each member also carries individual permissions (such as manage members, approve proposals, and see all proposals) that an admin can fine-tune per person.
There are two places to manage who’s on the team. Workspace owners and admins manage reps from the dashboard Members page (this needs the workspace “Manage team” permission). Inside a live portal, a member who holds the manage members permission can manage the team too.
A proposal is a quote a rep builds from your configurators, so it builds on the same quotes and approvals engine described in the Quotes and Approval Workflows articles. It moves through these states:
| Stage | Meaning |
|---|---|
| Draft | The rep is still building the proposal. |
| Submitted | The owning rep has sent it for review. |
| In progress | An approver is reviewing it. |
| Approved / Not approved | An approver recorded a decision. |
| Ordered | An approved proposal was converted into an order. |
Who can move a proposal between stages depends on ownership and the approve permission:
| Transition | Who can do it |
|---|---|
| Draft → Submitted (and resubmitting a returned proposal) | Only the rep who owns the proposal. |
| Submitted or In progress → Approved / Not approved | Any member with the approve permission — but not on their own proposal, unless they're an admin (four-eyes). |
| Approved → Ordered | Any approver, with no four-eyes restriction. |
Four-eyes review keeps a rep from signing off on their own deal. A returned (not approved) proposal goes back to its owner, who can revise it and re-submit for another pass.
A proposal’s owner — or a workspace admin — can edit its line items only while it’s in an editable stage: draft, submitted, in progress, or returned. Once a proposal is approved or ordered its items are locked, so the approval it already cleared can’t be quietly changed after the fact. Drafts stay private to their owner; an admin can edit someone else’s proposal only after it has been submitted.
A rep can delete their own proposal while it is still a draft. An admin can delete any proposal at any stage.
Email notifications are deliberately minimal. When a proposal is approved, Spokbee can email the workspace owner — not the rep — but only if the live portal design has the “email me when a proposal is approved” option turned on. No emails fire on any other transition.
You can attach custom forms that reps complete at key moments — when they first log in (onboarding), as a card on their dashboard, before they open a configurator, when they add a product to a proposal, or when they submit a proposal. A blocking form must be completed before the rep can continue; an optional form appears as a skippable prompt. Onboarding forms always block until they’re done. Forms can be targeted to specific roles or products, and are managed once for the whole workspace from the Forms page.
The login page is a closed, safe set of options — a logo, a background image or color, a headline and subtext, accent and text colors, a font (sans, serif, or mono), and a layout (centered, left, or right) — with AI assist to fill them in. There is no custom CSS, HTML, or JavaScript.