What makes a good Customer Portal?

[Kerli Loopman]

I regularly introduce new employees to the Jira Service Management customer portal, and I am always afraid someone will say: "Why do we have to use that?" or something like that.

No one says that, but sometimes I get the feeling that they think so, or I see in the statistics that email is preferred way to make a request.

I want it to be useful, not an obligation to fill out annoying forms

What makes a customer portal a good portal?

Help center and knowledge base

This is probably one of the most well-known values of a customer portal, but definitely not the only one.
How have you designed the help center / knowledge base for your JSM customers? How have you structured the articles so that they are easy to find?

Forms

Do you use forms associated with request types? I use them mainly because they can help make the content more dynamic depending on which fields have been previously filled in.

Asset fields in request forms

I think it's better to use asset object fields instead of custom drop-down fields where possible. If you use them as well, please comment how you use them.

Design and plugins

Do you use only the default options or any plugins to design the customer portal?

If there's anything else I have not mentioned that helps making a great and useful portal for customers, please let me know!

[Sam Nadarajan]

It's a case-by-case basis for me, at a minimum though I'll have a customer portal for each support team fielding requests, so that the same person doesn't need to go multiple service projects to do their work. I'll use labels on pages so that they are more likely to appear for certain request types, but to be honest I don't go too deep into this.

Like you mentioned, I will use forms only when I need dynamic functionality OR if I need a number of fields for the request type that don't need to be queryable through JQL. Otherwise I'll just use Jira's custom fields. Most forms I configure on the portal don't desire that level of complexity!

Yes if you are already maintaining assets in Assets then using the Asset Objects field type instead of a dropdown is best. If you are on the Jira Service Management Standard plan this won't be an option so companies have to make do with what they have.

I haven't used marketplace applications to extend the customer portal functionality, because the default options so far have been sufficient.

I also think that sometimes the functionality available in the portal is underutilized. For example, adding help text and instructions for the request type on top of the request type description is nice to have, adding field descriptions and changing the names of fields to be more descriptive is important, setting preset values on fields when submitting request types, and enabling workflow transitions on the portal where they make sense are a few of the underutilized features that the JSM Help Center/Portal have to offer.

Good thoughts here @Kerli Loopman 

[Kerli Loopman]

Found an article that supports this discussion: https://community.atlassian.com/t5/Confluence-articles/How-to-Use-Confluence-as-a-Knowledge-Base/ba-p/2129974#M5091

[Kerli Loopman]

Thanks! This reminded me that in organization managed projects you can hide and predefine some fields. For example on some requests I don't need for user to define a Summary, so I hide them and use prefilled summary for example "Request for access" and change the summary on creation with automation depending on chosen fields to "Request for access: First Name, Last Name, Software name". I think it is not possible to use smart values when predefining some fields straight in request form editing view but automation works.

This is one reason I like organization managed service projects more, because the last time I checked this, the Summary field can't be hidden on team managed service project.