What is the "right" way to group your Request / Issue Types?

[CJ Messick]

I am very, very new to JSM.  We have 15 different support teams and a very long list of environments / products that our customers can submit a ticket for help.

Most of the teams would have the same issue types (New Accounts, Change Permissions, Fix account, Patch server, Report Issue, Report Outage, etc...).

If I make the Request GROUP the name of the team, then we lose that information in the ticket.  Ergo, if I have an Oracle DBA request group and an Oracle HR request group and both have New Account as an Issue Type...there's no way to tell which queue the request should go to when the ticket is created as the Request Group "name" is not available to me.

In essence I have many Teams that do many of the same task types for a myriad of different servers, environments and products...and frankly, I have no idea how to set up the JSM project such that each team gets their own tickets.

I know the Component list is going to play an important role, but this presents other problems as there doesn't seem to be a way to prevent multiple selections (where it doesn't make sense) or to have a programmatic list without using an add-on that I don't believe we have.

[CJ Messick]

Update : While I still don't fully understand the "right" way to go about this, I have learned there are multiple "right" paths to take as well as an order of magnitude higher of "wrong" ways to go about this.  However, it is now a non-issue as the requirement update recently received implies the portal needs to look / act / feel like a ServiceNow portal.

I am stunned.  But at least I now have direction.

[CJ Messick]

Update : 

What I eventually ended up doing was to abstract out our processes / teams.  So I have a System Operations request group and therein have a Change Permissions, New Account, Fix Account, Report Issue, Report Outage, Upgrade system as the selections.  Within those I made a Component list available for each of the various teams that exist within the System Operations umbrella.

I have no idea if this is the right "path" so to speak.  At least now I have something to build the queue(s) on and proceed with trying to figure out Automation and SLA rules.  Seems like there's gazillion ways to do this and it's difficult to nail down the "best" one to suit the environment.

[CJ Messick]

I have since been told, using components for Team names is bad practice.  Nor can I use the TEAM field that is already there as it is "shared" across the Enterprise and it defaults to being a hidden field anyway so it's useless to the customer.

Back to square one.