I'm kind of working on something similar. Have a suite of tests running every day for multiple applications in the same suite in a single pipeline. Here's a couple of things that I've found worked well.
Pipeline Setup - If you can, separate the tests by application or ownership into different stages in the pipeline. This makes it much easier to separate who to send work to when a test fails. Stages can be run and organized by test assemblies and or categories.
Test Setup - If you can, append the full request and response to your logs. Include a link to the application logs if possible. The request (including headers) means that it can be reproduced outside of the test. Response, including status code and response payload helps understand what's happening. The link to the logs is nice, but, with all of the included information, they should be able to find it very quickly.
Notifications - I like to have a slack channel where notifications can be sent. Only send notifications when it fails. If it's 100%, don't notify. Do your part to prevent notification fatigue. Make sure that the stage(s) that failed are mentioned so only teams responsible for those applications will investigate. Ideally, when they look at that stage, they can see exactly what test(s) failed, exactly what was used, and maybe a link to the log.
Next thing I'm working on figuring out is automatically creating a bug ticket on the board for the team who owns the application tested in that stage.
I've found with a couple of steps, the developers spend less time investigating issues and continue to be able to be responsible for their own testing. I spend less time with maintenance, and less time investigating issues, giving me more time to work on other automation initiatives.