Multiple Sevice Portals VS One Service Portal

[Drishti Maharaj]

Hi, my company wants to make a change to how our current service portals are set up and I'm trying to see if this would be a good way about doing this. Essentially we have multiple service portals for different teams within the Technology space, eg, Infrastructure, Cyber Security, Enterprise Support, Operations, etc.

The service portals are seperate currently as there's only certain people who can handle Infrastructure requests, Enterprise requests, etc. It's per the teams and their skill sets itself and what other access they have on internal systems.

The idea is to now have one service portal instead that services all there areas. They want to possibly have multiple portal groups within this with each named after a different system or team. Eg, System A, System B, Infrastructure Team, Enterprise Team, etc. And then within the portal group, 3 request types for an incident, service request and alert (this would be the issue type also).

Based on a current list, it's currently over 20 portal groups showing within one service portal and I don't think it's going to be very user friendly either.

Is there a suggestion for a different way for this? My initial suggestion was to keep the service portals as is but then add the 3 request types for an incident, service request and alert (this would be the issue type also) instead.

[Jon Kelley]

For one of my clients we run a help center that houses various groups (Enterprise Application, Infrastructure, HR, Operations, etc.) and within those groups are the request types that separate out what the issue/request is, so something similar to what your company's idea is.

However with the various systems, we have one request type within our Enterprise Applications group that holds a asset tied field that allows the user to choose which system and fields that follow that are open enough to where people can report the issue instead of having various issue types, request types for each delegated system. Internally in JSM, this populates a queue in a project where people that work on the systems support get the tickets and work through them accordingly of course. With this company in particular, if we created a group for every system we would have at least a dozen groups for that alone. Consolidating the systems into one request type with asset based fields has worked wonders and in my opinion looks cleaner so that way other teams don't have to spend time digging for their group within the help center.

From experience, I found that having a large amount of groups is absolutely not user friendly even if its just for internal teams doing offboarding, device requests or email issues.