For as long as I've been working with InService, there have always been service level outages designed as the 'lowest' level of outage to accommodate the concept [and real-world scenario] of multiple customers/meters/premises being serviced by an individual transformer.

We have projects that have multiple service level outages defined as well, and some have business processes built around the level of dispatchers who are permitted to work on transformer and service level outages vs. any higher protective device (fuse, switch, etc.).

There is currently a hard rule that the first call on a xfmr results in a service level outage.

BUT ... if that xfmr has only one customer, and if oms_ta > Outage Prediction > SingleCustXfmrEvt is set to T, then a xfmr level outage will be created instead.  Several projects have this capability turned on.  Perhaps this might be a partial solution for you?

Beyond SingleCustXfmrEvt, the other hard rule is that a second call on the same xfmr [from a different premise, in order to avoid a single caller/premise from 'loading' up the call count, which could impact rollup behavior] will result in the outage being updated to a xfmr outage.

So, in a nutshell:  barring SingleCustXfmrEvt, it takes two calls [from different customers/premises] to result in a xfmr level.

Some projects that have more urban areas may have dozens to hundreds of customers associated with an individual xfmr.  So, they would rather deal with service level outages (and lower customer counts) than xfmr outages (with higher customer counts) in these cases.

Service level outages allow for single outages with a single customer count (and a single call).  And, if configured, SingleCustXfmrEvt allows a xfmr level outage to be created if there is truly only one customer associated with the xfmr.  Overall, it would be more inaccurate from a count standpoint to have a single call be treated as xfmr level outage if there were more than one customer associated with that xfmr.

This is how InService has been designed and working for as long as I've been working with it.

That being said, one potential workaround for you might be to change the event type associated with your service level outage (device_id=101 in oms_metafeatures) to something like 'XFMR_S' (presuming your xfmr level outage was something like 'XFMR').  Note that it would still be treated as a service level outage in all respects, but at least you'd have a way of making it 'look' xfmr-ish.

Another approach might be to have your dispatchers MoveUp all service level outages whenever they first come in?

There is lots of underlying code currently in place in several places, such as rollup/aggregation, Move Up/Down, etc. which has the concept of service level outages embedded in it, so I'm not sure how readily this could be enhanced or changed to handle a 'no service level' approach.

There was another project who actually was asking if it would be possible to INCREASE the number of calls it takes in order to update a service level outage to a xfmr level outage (i.e. from 2 to say 5).  Currently there is not (the number is 2) ... but, perhaps, keeping both these ideas in mind, you could file an enhancement request to be considered, which might parameterize the number of calls (from distinct premises) on an individual xfmr it takes to update it to a xfmr level outage -- including the notion that 0 or 1 might mean that a single call results in a xfmr level outage (i.e. 'no service level outages').  Not sure how feasible this might be product-wise, but might be worth filing at least?