I mostly agree with this. If you observe the KPI set used to run support teams, especially with large inbound you will see NPS used as a proxy for quality of resolution but folks mostly don’t respond to those prompts.
More interesting to support team managers are things like deflection rate (didn’t get to an agent) involvement rate (needed an agent) and eventually resolution rate (resolved issue). The last one in the absence of feedback is only a very weak proxy for a resolved issue.
If you consider customer support a cost center, you can guess how managers would optimize these numbers.
I don’t necessarily think there is much wrong with this - having a good product with excellent design, build and proactive support (docs, manuals, walkthroughs, proactive comms) - is likely very good for both customers and the business serving them.
I work mostly with Engineering teams, and consider slack inbound a pathology. Slack is great for collab in places, but it’s not a strong way to manage inbound, IMO.
The teams I’m responsible for make it easy for their stakeholder to raise issues, asks in a more deliberate, calmer way e.g. via GitHub issues or manager email. In exchange, we commit to mutually agreed response times on certain categories of business critical issues.
Generally, I don’t think it takes an ADHD diagnosis for slack inbound to completely kill your productivity, it’s a general problem. I don’t have ADHD but have strong empathy for how this must be a complete nightmare for you.
Perhaps have a manager put some structure on your inbound on your behalf?