Choose a customer portal builder by starting with the records customers must see and the actions they may take. Then test whether the product can enforce that access, fit your support and CRM workflow, and be maintained by the team that will own it. For example, if two contacts at one company need to track shared support tickets, test that exact scenario before comparing page design or AI features.
A public help center is usually sufficient for general answers. Private tickets or account specific records require an authenticated portal and an explicit identity and permission model. Use this sequence: define customer tasks, test visibility, compare documented capabilities, and verify commercial and operational requirements.
Customer portal or help center: what must customers access?
A help center publishes general support content that may be available to anonymous visitors. A customer portal can include that content, but its defining purpose is to give authenticated customers access to private records or actions, such as submitting and tracking a ticket.
Classify each proposed customer task into one of three permission types:
- Public content: read general articles or FAQs without signing in.
- Authenticated read: view a private ticket, account specific instruction, or other permitted record.
- Customer write: submit a ticket or update an approved field.
Do not assume that the term customer portal means customers can view invoices, subscriptions, entitlements, or custom CRM objects. Verify that the product supports the object, that an integration or connection is available where needed, and that the selected plan and permissions allow the use case. HubSpot documents a login protected support portal for ticket access, while Zoho Desk describes a client portal with knowledge content, ticketing, and community capabilities. Salesforce Experience Cloud can expose Salesforce records, including custom objects, when the required access controls are configured.
Start a requirements list with the customer visible object, permitted action, system of record, and owner of any change. If you are reviewing the broader customer and account data model, consider how it fits your CRM systems.
Write access and ownership requirements before comparing vendors
Identify the system of record for contacts, companies, tickets, and account level data. Record which application owns each field and where an approved customer update must be saved. Next, define how customers obtain an identity: invitation, self registration, single sign on, or an external identity provider. Decide what happens when a contact is deactivated, an account closes, or a contract expires.
Be specific about record scope. A customer may see records tied to their contact, all permitted records for their company, or only records that meet additional account or contact conditions. These models are not interchangeable. Test with customer identities, not only an administrator preview.
| Test scenario | Expected visibility | Evidence to retain |
|---|---|---|
| One contact, one account | Only intended records appear | Customer view and record IDs |
| Two contacts at one account | Each sees only the approved contact or company scope | Results from both logins |
| Contact linked to multiple records | Only records allowed by defined relationships appear | Association and visibility checks |
| Deactivated contact or expired contract | Access follows the documented offboarding rule | Login and record access results |
| Limited permission internal user | Administration does not exceed assigned access | Role and permission review |
For every identity, verify both what is visible and what is denied. A page that loads successfully does not demonstrate that record sharing is correct. When comparing commercial plans, also separate agent seats, external users or members, logins, and contacts.
A portal’s most important feature may be its record access model, not its page builder. Test customer identities against both allowed and denied records, then retain the evidence as a release artifact.
Buy a portal or build one?
A packaged product may shift some infrastructure, platform maintenance, and update work to a vendor. It does not remove your responsibility to configure access, review privacy terms, test integrations, and maintain customer facing content. A custom build offers control over workflows and data boundaries, but your organization must also operate identity, permissions, integrations, accessibility, monitoring, patching, and future migration.
Use documented product capabilities
Check whether the standard workflow supports your identities, record scope, integrations, and required actions. Budget for licenses, configuration, integration, administration, and vendor review.
Own the full operating model
Consider custom work when a documented requirement cannot be met by changing the process, configuring a product, or using a supported integration. Name the long term owners for engineering, security, support, and change management.
Make a gap list before funding custom development. For each gap, decide whether to change the process, configure the product, use a verified integration, or build a component with an assigned operational owner. Estimate total cost from actual licenses, usage, implementation, integration, support, and ongoing administration. General build versus buy guidance can frame the discussion, but broad AI investment estimates are not customer portal cost or timeline benchmarks.
Compare documented customer portal capabilities
The comparison below describes documented scope, not a universal ranking. Product packaging and plan inclusion can change. Verify the exact product, edition, license, region, and written commercial terms before purchase.
| Platform | Documented portal scope | First fit check |
|---|---|---|
| HubSpot Service Hub | Its login protected support portal displays tickets. Documented visibility options include contact associated tickets, primary company tickets, or company tickets subject to configured contact property criteria. | Available with Service Hub Professional and Enterprise. Confirm the visibility model and ensure intended conversations are associated with tickets. The portal does not display every conversation. |
| Freshdesk | Freshworks documents ticket submission and tracking, knowledge base and community capabilities, branding, custom URLs, multiple portals, themes, forms, and ticket filters. | Confirm the exact Freshdesk product and edition support each requirement. Freshdesk and Freshdesk Omni are separate products. |
| Zoho Desk | Zoho describes a client portal for knowledge content, FAQs, community or forum features, ticket submission and tracking, and support workflows. | Check edition and regional plan details, especially for integrations and features described on the product page. |
| Salesforce Experience Cloud | Customer Account Portal patterns can provide access to Salesforce data and custom objects, with connected data options also documented. | External users, licenses, account and contact relationships, object permissions, and sharing must be deliberately configured. |
Vendor documentation: HubSpot support portal setup and ticket visibility; Freshdesk portal overview; Freshdesk product packaging; Zoho Desk client portal; and Salesforce Customer Account Portal.
HubSpot’s documentation is particularly important for teams expecting a unified inbox view: only tickets appear in its support portal, and conversations not associated with tickets do not appear. Its setup also requires a connected domain, an inbox or help desk destination, and customer access settings. Review your current HubSpot systems configuration alongside those requirements.
Set up and test the portal around real customer records
Use a staged rollout with clear owners. For HubSpot, documented setup includes a connected domain, a selected inbox or help desk, optional support form configuration, and a ticket visibility choice. Freshdesk documents portal management, branding, forms, themes, filters, and optional custom URLs, subject to product and edition. In Salesforce, page visibility is separate from record access: external user records, licenses, profiles or permission sets, roles, object access, and sharing all need review.
Treat permission changes as release gates. In Salesforce, create external users from the appropriate contact or person account relationship, assign the required external user license and permissions, then test record sharing separately from page visibility. See Salesforce guidance on creating external users and page access settings.
Use AI for assistance, not authorization
AI may help suggest a knowledge article, classify a ticket topic, summarize a message, or draft a reply for human review if the selected product and plan document that capability. Use deterministic rules for identity, account status, entitlements, record visibility, billing, and permission to update a field.
For example, a hypothetical portal workflow could use AI to classify a request for a billing address change. The support system supplies the ticket ID and authenticated contact. AI proposes a request type and extracts the address. A deterministic check confirms that the contact belongs to the expected active account, that required fields are valid, and that the requested field is writable. A change affecting tax details, legal entity, or invoice ownership goes to billing or finance for approval.
{
"event_id": "evt_example_1042",
"source_system": "illustrative_support_portal",
"source_object_type": "ticket",
"source_object_id": "ticket_example_319",
"event_type": "ai_recommendation",
"event_timestamp": "illustrative_timestamp",
"run_id": "run_example_07",
"request_type": "billing_address_change",
"proposed_value": {
"city": "Illustrative City",
"postal_code": "A1B 2C3"
},
"confidence": 0.94,
"model_identifier": "recorded_model_name",
"prompt_version": "address_review_v1",
"source_ids": [
"ticket_example_319"
]
}The values above are illustrative, not a vendor data contract. Store one row per recommendation run, not a mixture of recommendations and daily totals. Reject missing categories, unsupported request types, malformed fields, or confidence below a configured threshold. Require a valid source identifier for each cited recommendation and route ambiguous requests to a person.
Before write back, verify that the selected product exposes the required API, permissions, pagination, rate limits, retry behavior, and idempotency support. Where duplicate processing matters, use a database enforced unique constraint or transactional upsert. A lookup followed by create is not race safe when concurrent workers can process the same event. Keep daily summaries in a separate reporting table with a portal ID, reporting date, metric name, and metric value.
If a defined support task warrants evaluating AI agents, specify the task, allowed output, validation rules, source provenance, and human fallback before connecting it to customer data.
Check security, pricing, and operating fit before purchase
Verify the exact product SKU, edition, billing term, region, agent or member definition, usage charges, minimum commitment, and add ons. Pricing pages can be region sensitive, and product lines may differ. Do not compare Freshdesk with Freshdesk Omni as though they were the same SKU. Obtain current plan details or a written quote rather than relying on generic per seat ranges.
Review the vendor’s trust materials, data processing terms, hosting options, audit reports, retention and deletion terms, and contractual responsibilities for the selected product. Then test your own configuration. A managed service can shift some infrastructure work to the vendor, but it does not automatically make a portal secure or satisfy your organization’s obligations.
- Does the exact SKU include each required portal feature, API, and integration?
- Can two contacts at the same company see exactly the records intended for each?
- What happens when a contact is deactivated or a contract expires?
- Can customers view sensitive attachments or private comments, and is that intended?
- Do external user licenses, member limits, AI usage, and regional terms match the quote?
- Who owns access requests, content updates, integrations, and vendor changes?
For HubSpot, test attachment behavior as well as ticket visibility. Its documentation notes that attachments involving Sensitive Data settings may not be viewable to customers through the portal. For Salesforce, review guest access, object permissions, field level access, and sharing separately. Page visibility alone does not control access to every record.
Frequently asked questions
Can customers see all tickets for their company?
Only when the product supports that visibility model and the relevant account and contact rules are configured. Test with multiple customer identities at the same account, including records that should remain private.
Can a portal expose invoices or custom CRM objects?
Not by default. Confirm product support, the integration or data connection, permissions, and plan requirements. Salesforce documents customer portal access to CRM records and custom objects, subject to configuration and sharing.
Can a small team launch a portal without developers?
Some products document configurable portal administration, but effort depends on identity, domains, content, integrations, forms, and testing. A simple portal still needs a named owner and customer access tests.
Can a portal be white labeled or localized?
Verify custom domains, branding controls, themes, and language support against the exact product and plan. Do not infer availability from another vendor or edition.
How should we evaluate AI claims?
Ask which task AI performs, what data it uses, whether it can change records, how outputs are evaluated, and what happens when confidence is low. Treat performance figures as vendor or customer specific unless their method and denominator are clear.
Choose for access fit and operational ownership
Define customer tasks and data first. Test identity and record visibility, shortlist products whose documented capabilities fit, then verify plan, security, and ownership. Pilot with representative customer accounts before broad launch. A simpler portal with correct access rules and an accountable owner is a stronger starting point than a highly customizable experience with unclear permissions.