Customer Portals

Customer portals give external users a simple way to submit requests, report issues, and follow progress without needing full access to your internal workspace. Requests submitted through a portal become work items, so the internal team triages and delivers them with the same boards, backlogs, and views as the rest of their work.

Portal hub with customer-facing portal cards

What portals are for

Use portals for:

  • Support requests
  • Bug reports
  • Feature requests
  • Customer onboarding tasks
  • Internal service desks (HR, IT, facilities)
  • Approval or intake workflows

Portal hub

The portal hub is the landing page where signed-in customers see the portals available to them. Each portal has its own name, branding, request types, and access rules, so different customer groups can see different things.

Request types

A request type is the form a customer fills out. Examples include "Report a bug," "Request access," "Ask a question," or "Submit a change request." Each request type has its own form, its own destination workspace, and its own default fields.

Write request types from the customer's perspective. Avoid internal team language unless the portal is only used by internal users.

Good portal forms

A good form asks for enough information to act, but not so much that customers avoid using it.

Start with:

  • A short summary
  • A description
  • Contact or account details (only if not already known from sign-in)
  • Priority or impact, when relevant
  • Attachments, when useful

You can always ask follow-up questions in the portal thread once the request is open.

Customer organisations and contacts

Customers can be grouped into customer organisations. Within an organisation, contacts can have roles (for example primary contact, billing contact, technical lead) so the internal team knows who to escalate to. Organisations and roles can be used to scope which portals a customer sees.

Customer sign-in

Portals have their own customer accounts, separate from internal users. Customers sign in to a portal to submit a request and to follow it through to resolution. They never gain access to the internal workspace.

Working with portal requests

Once submitted, a portal request becomes a tracked work item. The internal team can triage, assign, comment, and move it through any workflow. Comments are split into two streams:

  • Public. Visible to the customer in the portal.
  • Internal. Visible only to the team.

This lets the team discuss the work freely while still keeping the customer up to date.

Practical tips

  • Use clear, customer-facing names for request types.
  • Avoid internal jargon in form labels and instructions.
  • Set expectations about response times directly in the portal.
  • Keep customers updated when status changes, even if there is no action yet.
  • Keep internal notes and customer-facing communication clearly separated. Mistaking one for the other is the most common portal incident.