For your use case, you can experiment with just views and dashboards.
I see several possibilities depending on your environment.

What you put in the title is not an option, though - as you cannot raise 2 different severities for the same event - that would be quite confusing in any OSS scenario.
I'm explaining what I mean at the end of this list.

Option 1
A possible strategy could be to add a standard view for the team that has to treat the alarm as "Critical" and a separate set of views with just the alarm counts and no alarm colour on a different Visual page, if the second team needs just some sort of info. No service definition needed. Alternatively, the second overview can be embedded or implemented in a dashboard.

Worth noting you can configure different default pages for each team by using workspaces.

Option 2
One powerful feature in a DMS is the "alarm Ownership" in alarm console - when used, that gives instant feedback to anyone connected, showing who is taking care of the alarm. Access to the alarm console can also be restricted if needed.
Considering all the three blocks of the Cube GUI (Visual, Surveyor and alarm console), rather than just the visual overview, can make a huge difference in terms of time and effort required to duplicate in the Visual views what is already present in other parts of the GUI.

Option 3
If you want to experiment with services, the service layer allows you to have a separation, so that if a back-up resource is in alarm but not actually used, you can give a nudge to the team responsible for the device but give evidence to service managers that there is just loss of redundancy at service layer.

Generally, at DataMiner level, an element can be seen as a collection of parameters; a service can be seen as a collection of one or more parameter values belonging to one or more elements.

I often associate the concept of a service with a full end-to-end transmission line, i.e. a few KPIs across selected elements.
But indeed a dataminer service can be as simple as one parameter value coming from one element.

For completeness, severity wise, parameters can be duplicated with a different filter within the same alarm template, allowing you to define different severity criteria for the same parameter, depending on the filter - I often do this with bitrate thresholds, depending on the encoding flavour (SD, HD, UHD ...). But this is still a unique set of severity values for a given event (defined as the single row in your alarm template).
In this example, anything named as TEST is excluded within the same alarm template and for the same parameter:

Last but not least, if your element is built with a protocol that supports DVEs, you can indeed assign a different alarm template to each different DVE - this can be achieved by associating alarm templates to the child elements rather than to the main element (where the polling IP is).  The DVE can still use only 1 alarm template at a time, this to keep the severity consistent across the element or the DVE. In this example, I have 1 polling IP = 1 device, but I'm monitoring only the DVE associated with slot 2 and slot 21 - the other DVEs have no alarm template associated, but each different slot can have its own alarm template:

As said, just for completeness - for your use case I'd experiment with option 1.
HTH,
A.