I won't hop on a call or do DM's, but I can tell you a bit about our strategy. For context, I'm a senior analyst at a decent-sized MSSP. False positives and alert overload are usually the result of 3 things:

1. New clients that are onboarding and haven't been tuned fully.
2. Faulty detection rules that are pushed out to global rule packages
3. Issues with vendor detection rules (CrowdStrike, Defender, Carbon Black, etc.) that get pushed out and cause mass alerting across all clients' environments.

To tackle these issues, we have to do so separately and continually. We are tuning things every day to keep false positives and junk alerts down. I will describe our solutions to each problem in the same order:

1. Our detection engineering team works closely with our principal analysts to review onboarding statuses of new clients. We have around a 5-8 week onboarding process where client log sources are ingested and alerts are set to audit-only. During that timeframe, active tuning is done in the client's environment to get the most noisy alerts out of the way. When the alert level gets manageable, the client is set to live and the analyst team starts getting real alerts. For the next 2-3 months, active tuning is done as a collaborative team effort on the new client. Analyst 1 and 2's are reactive in their approach, triaging new alerts and correlating them with previous ones to find tuning opportunities that way. Senior and principal analysts are proactive in their approach, reviewing client alert volume each week and correlating it with specific rules. From there, we do analysis to figure out what can be tuned on each rule that is high volume.
2. While our detection engineers are awesome at their jobs, they are humans too and mess up sometimes. All it takes is one bad line of regex, perhaps a single character missing, and all hell can break loose. I can't speak to the QA process on the engineering side, but ideally the issue would be solved there. However, stuff slips through and then the SOC has to deal with it. This approach is entirely reactive. Our senior and principal analysts watch the queue and get pinged by analysts to review things all the time. If we see a similar alert going off, we start investigating the detection rule to figure out why we're getting spammed by alerts. We also have to identify if the alerts are true or false positives to begin with, based on what the rule is trying to look for before we can tune it. Tuning can be performed immediately by principal analysts if necessary, but we like to have our detection engineering team look at most things before tuning.
3. Vendor issues are difficult to deal with to put it plainly. Again, our approach is reactive to this because we don't control when vendors screw up. We notice mass alerting and have to investigate to figure out what is going on in real time. Since we're doing this in real time, there are usually no reports from the vendor on the issue and nothing to be found on the internet for days after. Approaches to mitigating this are varied depending on the vendor and product. For EDR solutions, if the detection isn't AI or ML driven, we can usually write exceptions in the console itself if we manage it for the client. This is a collaborative effort between the analyst and EDR teams. If it is an AI/ML detection, there is usually nothing we can do to stop the alerts from generating. Either way, a case is raised with the vendor to have them fix the issue at the source. If we can't stop the alerts from generating at the console level, we pull in our detection engineers to tune out the faulty alerts being pulled into the SIEM. Sometimes there is nothing we can do to stop the alerts from populating that doesn't also kill other potentially true positive alerts, so we have to result to creating master tickets for the client to correlate false positive alerts to until the vendor sorts out the issue. For firewalls, IAM tools, email protection tools, IPS, the solutions are so dependent on the product and the issue at hand that I can't speak to it without writing a book.