Let me explain with some examples :
In case , if the Accounts / Sites are geographically distributed and you want to configure dedicated technicians for them , we can make use of Site-Refer-Sites feature (similar to default settings but applicable for group of sites)
ie) Assume - Account A is in USA. - A couple of Sites (Branch offices) are in New York, New Jersey,Dubai
Account B is in UAE - A couple of Sites (Branch offices) are in New York, Dubai.
Account C is in India - A couple of Sites (Branch offices) are in Goa,Bangalore,Newyork.
Here , as an MSP , you might have Sites(Branch) offices in Newyork, Dubai,Bangalore.
These Sites(branch) technicians will work for related Account's Branch offices.
ie - Tech A from MSP Newyork branch - Hardware Team Will work for Account A - New York Site, Account B - New York Site, Account C - Newyork site.
Tech B from MSP Dubai branch - Hardware Team Will work for Account A - Dubai Site, Account B - Dubai Site.
Now using Site - refer - sites feature -> You have to create a group alone under MSP Newyork branch (Custom Site) - named Hardware Team - Make the Account A - New York Site and Account C - Newyork site's to refer MSP Newyork branch.
Similarly - create another Site (Custom Site) - MSP - Dubai and you have to create group under MSP - Dubai - named Hardware team - Make the Account A - Dubai Site and Account B - Dubai site's to refer MSP Dubai branch.
By doing this , you have single control over sites and any change in the technician / group , you can simply update only the relavant MSP branch sites groups.
Here you have to understand your Account/Sites pattern alone and create Sites and map the relavant Account's Sites to follow them. This hugely help you in maintaining the application effectively.
In General practise , users dont have 1000 of support groups. ie. No organization is having 1000 of Support groups or Teams that are expertise in different areas. So above approach will reduce creating unwanted Support groups (and filters)
-------------------------
If you have custom SLA and if that gets affected, please check the below solution :
You have to create different Levels alone based on Site name - Goto Admin -> Level -> Level1_SiteName.
Format should be Level_SiteName - Ex - Level_London, Level_Newyork,Level_Dubai. and so on.
Now You can retain all the existing configurations under Refer / Custom combination as it is.
Under Admin -> Business rules -> New rule -> Under Actions -> Make use of If - IF condition -> Create a rule -> To set Level based on Site names.
Ex - If Site name is AccountA_Lodon, Then Custom Action update field -> Level = Level_London
If Site name is AccountB_Dubai , then custom Action update field -> Level = Level_Dubai.
and So on.
PS : If you use Site-Refer-Sites, select MSP relavant site and configure SLA , Business rules accordingly.
Now under existing SLA -> add your level criteria, Level as Level_London to apply relavant SLA.
Level = Level_Dubai, to apply relevant SLA.
This should solve your problem.
In case it wont , please explain the issue / design flaw in detail so that we can revisit.