Build a customer portal that helps B2B customers find answers and manage support

A customer portal gives people a consistent place to find support knowledge and use the customer-facing support functions your organization enables. In Supportbench, the portal is configured as a Community. For a B2B team, the starting point is the customer relationship: which organizations and contacts the portal serves, what they should be able to see, and how a request reaches the right support process. Build that experience before spending time on visual customization.

Plan the customer’s first three tasks  ·  Create or open the Community  ·  Choose sign-in and case access deliberately  ·  Choose a useful knowledge structure  ·  Configure the address and customer sign-in  ·  Customize appearance without confusing drafts and live settings  ·  Verify the complete customer experience  ·  Example: one customer organization, several support contacts  ·  Troubleshoot portal setup

Plan the customer’s first three tasks

Write down what an intended customer should accomplish: find an answer, submit a useful request, and follow the support work they are authorized to see. Use the customer’s terminology and likely questions. A portal with attractive branding but unclear access or request routing will still create avoidable support work.

• Identify the audience: public visitors, signed-in customer Contacts, selected customer roles, or a combination supported by the configuration.
• Choose the knowledge topics that answer real customer tasks. Keep internal operating instructions restricted.
• Decide what information a customer must provide for a useful request and which Division/Queue should receive it.
• Agree how Company and Contact relationships affect customer access. A branded URL is not an access boundary by itself.
• Identify an owner for the portal’s knowledge, routing, branding and periodic access review.

Use a representative permitted customer and an excluded customer for testing. An administrator’s own session is not proof of what a customer sees. Keep test records and screenshots free of private customer information.

Create or open the Community

1. Open Settings → Self-Service → Customer portal. You need the relevant Administer communities authority.
2. Choose New Community, or open the existing portal whose purpose you are maintaining. Prefer updating the intended portal over creating a duplicate with nearly the same name.
3. On Setup, enter the intended Name and Description. Treat Description as an internal note explaining the purpose, not as assumed public homepage copy.
4. Review the available Division, Queue and reply-address defaults for the customer request process. Confirm the appropriate active state.
5. Configure access and knowledge deliberately using the next sections.
6. Choose Save Changes to save the portal settings, then reopen the record to confirm them.

Separate the portal’s name and appearance from the customer identities it authorizes and the case defaults it supplies. A successful settings save confirms that configuration was stored; it does not prove that DNS, customer sign-in or a complete support workflow works.

Choose sign-in and case access deliberately

Do not infer access from a Company name alone or enable broad options just to make a missing case appear. First identify the Contact, the specific case relationship and the current portal scope. The focused case-visibility guide below explains the Division setting and how to test it.

Choose a useful knowledge structure

1. Review Knowledge base containers and Show all containers. Choose the topics appropriate to this portal’s audience.
2. Ensure the knowledge-base experience is enabled as intended and the relevant topics/articles are published for the correct audience.
3. Check article restrictions and portal scope, including customer roles, Divisions and applicable tags/assets.
4. Open representative topics and articles under the intended customer identity. Include an article that should be excluded.
5. Search using customer language and confirm the result leads to a complete, current procedure.

Organize the menu around customer tasks, such as installation, troubleshooting and service requests. Use focused titles and useful summaries, and give each topic a clear purpose. A small set of well-maintained paths is easier to use than a large collection of old announcements and duplicated answers.

Configure the address and customer sign-in

Use Portal address to review the Alias or custom-domain configuration and any DNS validation steps shown for that route. Confirm the actual address the customer will use and the resulting secure connection. Do not announce a new domain merely because an alias or custom-domain field was saved.

Use the portal’s security/sign-in controls to configure the intended customer login experience. For SAML, follow the current provider-specific and general SAML guides. Keep the portal host, identity-provider settings and Contact/Company matching rules consistent, and test the actual customer result.

Saved compatibility fields such as SAML Allowed IP ranges and Username field do not establish the current Core enforcement behavior described in older help text. Use the corrected configuration reference below and the supported assertion identity/mapping workflow; do not rely on those fields to create an access restriction.

Customize appearance without confusing drafts and live settings

Review Branding, Design/Page templates, Languages and Files for the parts of the experience you need to maintain. Keep headings, links and instructions understandable on a phone and without relying entirely on images.

• Start with consistent branding and clear navigation. Avoid changing templates merely to compensate for missing knowledge.
• Use supported Liquid objects/tags for the specific page context. A variable available on a case page is not automatically available on every page.
• Preview design changes and verify representative pages before publishing them.
• Treat applying a theme as a replacement operation: read the warning and review what it changes in the current design. Do not assume an old Auto Update instruction still applies.
• Use the design workflow’s Publish action for design drafts when ready. Save Changes for portal settings is a different action.

Review translated labels, links and empty states as part of the customer task. Do not publish a menu item that leads to an unavailable workflow simply because a template contains a link. Forums or other legacy routes should not be assumed to be configured by controls that are absent from the current editor.

Verify the complete customer experience

1. Open the intended portal address as a signed-out visitor and check the expected sign-in/public behavior.
2. Sign in as the representative permitted Contact through the configured method. Confirm the correct customer identity and expected Company context.
3. Find a known allowed article through navigation and search; confirm a restricted article remains unavailable.
4. Check a permitted case and a case that should be excluded. Review Division and secondary-contact scenarios only when they are part of the intended design.
5. If request creation is enabled, use an approved test scenario and verify the created case’s customer relationship, Division/Queue and operational ownership. Creating a test request is a real data change; plan it accordingly.
6. Check the same tasks at a narrow viewport, including tables, navigation, form labels and error messages.
7. Record the tested configuration and any remaining failure before announcing the portal to customers.

Example: one customer organization, several support contacts

A customer’s technical administrators need troubleshooting knowledge and their authorized service cases. A commercial contact may have different responsibilities. The support team defines those relationships and access choices, exposes the relevant knowledge topics and routes new technical requests to the intended support process.

The team then tests those two customer experiences separately. If a technical case is missing because it belongs to another permitted Division, the team investigates the focused visibility setting rather than granting unrelated Company-wide access. The result is a portal whose navigation and case context reflect the actual B2B relationship.

Troubleshoot portal setup

Continue learning

• Reference every customer-portal setting
• Show permitted customer cases across portal Divisions
• Organize knowledge topics and access
• Customize portal pages with Liquid
• Configure customer SAML sign-in