Building an IT helpdesk for multiple customers

Kevin Duar

What would be best practice to set this up ? 
I would have to create a new portal for each customer which would be accessible with customers/portals/1 -x ?

How could I set up one help Portal for all customers so they can submit tickets 
Would I have to manage my customers in Teams ?

Also can I restrict access to knowledgebase articles for customers - should only be for internal documentation.  

I'm a little bit lost at the moment

Rick Nankivell-1

Hi Kevin. I'm Rick, also new(ish) to this community. Long time reader but this is my first answer. Please be kind. ;-)

My work has only recently migrated us from Jira server to cloud, and I, as the company SME and Org-admin, am currently building out our Customer portals, so i'll try to explain simply.

It's not 1 portal per customer.. it is 1 "Help Center" per Atlassian cloud subscription/tenant. The Help Center is your top level landing page for all your Customers.

We get 1 Customer Portal per JSM project, accessed via the Help Centre. Each JSM project you have will natively display their Customer Portal "tile" in the Help Centre.(IT, HR, Facilities etc) - with optional hide capabilites.

Customers is an access Role, granting permission to only access the Help Center (and JSM projects within it, configured as enabled by default)

From the Help Center, customers find a big Search box at the top. Searching will return KB-style, how-to "articles" from one or more knowledgebase/s, which can be created by any JSM agent(or Confluence user).

I'm uncertain about permissions within the JSM project's KB, as we use full Confluence, but I believe articles can be permissioned per page or per space as required to be shown to, or hidden from, customers.

Each JSM project's portal displays as a tile, below the search box. Clicking into a portal, the customer is presented with Portal groups, which serve as pathways/options to your different Request Types (built by project admins or higher).

Request Types are essentially Forms like Issue Create screens, containing Fields from the back end which are available in the project. ..but can be renamed with user-friendly names and descriptions to help guide customers to the correct selection, which leads to the appropriate Issue Type.

As with the usual Create screen, Request Type Fields can be a mix of droplist selections, free text boxes, date pickers and more,..configured as optional or mandatory, or prepopulated and hidden.

TIP: Finding a balanced combination of both can lead to a simple and well-adopted experience for customers.. while they triage their own issues with all the required information!

Correctly populated issues can "magically" filter into appropriate resolver Queues (no waiting for front-line triage!), with enough detail for the resolver agent to understand, process & resolve the issue from the outset, saving the back end team loads of time!

Request Types are easy to create and configure - FUN, even! - and can be as broad or specific as you like/need, with each linking to an Issue Type on the agent (Service Desk Team) side.

And now we're back in agent country.. transitions per workflow, comments with (optional) notifications.. and with correct planning, communication and adoption, reduced issue numbers and emails. 

(but remember the tip about finding the right balance for your customers.. 50 mandatory fields in a Request Type may be better for us as agents, but wont be well adopted by the customers)

https://support.atlassian.com/jira-service-management-cloud/docs/get-to-know-the-main-jira-service-management-features/

https://confluence.atlassian.com/servicemanagementserver/best-practices-for-designing-the-customer-portal-939926586.html#:~:text=Every%20service%20project%20comes%20with,interact%20with%20your%20service%20team.

https://support.atlassian.com/jira-service-management-cloud/docs/set-up-and-manage-portal-access/

I hope this helps.

 

More experienced people are welcome to correct me, or elaborate as needed. (I'm still learning too!)