Jira Help Centre Portal What Customers See

A customer visiting your help centre sees the portals they have access to, a search box, and - once logged in - their own requests. On a portal page they see its name, a welcome line, request groups and the request types inside them, each with a plain-language name and a one-line description.

Notice what is missing: no ticket keys to memorise beyond their own, no workflow diagrams, no assignee names unless you choose to show activity, no internal comments. That restraint is the design. The customer sees their problem, its status in words like Waiting for support or Resolved, and the conversation. Everything else is your machinery.

1. Name the portal like a human - 'IT Helpdesk' beats 'Service Project ITSM-02' every time
2. Write the welcome text - one or two lines saying what this desk handles and what to use instead for emergencies
3. Order request types by frequency - the thing people need weekly goes first, not the thing you built first
4. Write descriptions in user language - "something stopped working", not "incident management intake"
5. Upload a simple logo so the page visibly belongs to your organisation, not to Atlassian

That is the whole first pass. Announcement banners and polished artwork can wait; clear names cannot.

The single feature that changes customer behaviour is the requests list: every ticket they raised, its status, and the full thread, visible any time without asking anyone. The week your users discover they can check a ticket at midnight instead of chasing the IT person at 9 AM, your interruption load drops.

Help it along: agents should reply on the ticket, not on a side channel, because a reply given on a call leaves the portal looking dead and trains the customer to call again. The portal is only trustworthy if it is where the truth lives.

If you connect a knowledge base (Confluence) to the project, the portal starts doing quiet, valuable work: as a customer types their summary, matching articles are suggested, and a share of users solve their own problem and never raise a ticket at all. Password-reset style questions are the classic case - one good article deflects them forever.

Honest scope: this needs the knowledge base set up and articles written in the customer's language, and the search is only as good as your titles. It is the best second project after launch, not a day-one checkbox.

You decide the door policy per project. The common shapes:

• Internal desk - only people in your organisation can raise requests; cleanest for IT helpdesks
• Named customers - you invite customer accounts; right for B2B support to known clients
• Open portal - anyone with the link can sign up and raise; powerful and spam-prone in equal measure

Customers only ever see their own requests (plus any deliberately shared with their organisation). Two customers of the same portal cannot browse each other's tickets - that separation is built in, not a setting you must remember.

Be clear about what money buys here. On the free and standard tiers you control names, welcome text, logo, colours in a limited way, request layout and announcements. You do not get a fully custom website: the structure, the forms' behaviour and the page skeleton are Atlassian's, and heavy theming belongs to higher tiers and marketplace apps.

For almost every real helpdesk this is fine - users want a fast form and a truthful status, not your brand guidelines rendered in CSS. Spend your energy on request-type wording and agent reply habits; those are the portal, as far as your customers are concerned.