Why are email notifications for approval requests so inefficient?
Many software products have mechanisms for requesting approval for certain actions or changes. I have been an approver for many things over the years. For example, on the Kubernetes project, I was an approver for the code repos, website, chat spaces, email groups, and several other things.
Often these disparate systems send email notifications for approval requests. In my experience, these requests are a lot less efficient than they could be.
Typically, notification emails will be sent to all individuals who have the power to resolve the request, often separately, rather than on the same thread. It’s often desirable to have multiple approvers in order to reduce approval latency, have coverage across time zones and during vacations, etc. Resolving the request, such as by approving or rejecting it, frequently requires navigating to the web console or mobile app for the product, and sometimes even finding and opening the specific request. The worst case is emails that just tell you that there are outstanding requests without telling you what they are.
When a request is resolved, in some cases, the product request dashboards don’t update automatically, so one doesn’t find out until trying to resolve the issue. In other cases, the request will disappear entirely without notifying the other approvers of the outcome, so if another approver resolved it, it requires some investigation to figure out whether it was approved or rejected, and who made the decision. Audit logs often have very little information and have restricted access, so one may need to check the settings of whatever may have been changed and/or ask the other approvers what happened. If you disagree with the decision, reverting it may not be easy. When you trust whatever decision other approvers would make, the exercise was a waste of time.
When request volume and frequency are significant, it becomes more efficient for approvers to poll outstanding requests than to respond to such notification emails. So, if there’s a way to disable notifications, I do. If there isn’t, I filter them, but the text of the email notifications often changes over time, so filters need to be updated regularly. Additionally, requesters then (understandably) ping approvers by chat. It’s an arms race. Another challenge occurs when there isn’t an easy way to manage the recipients of notifications for long-duration in-flight requests when approvers change.
Why are there so many obvious inefficiencies in these product experiences? Is there a mismatch in expectations regarding individual responsibility rather than collective responsibility? Or security or privacy concerns with email? Is it not considered worthwhile from a business-value perspective to invest in a better experience for approvers? Do these products expect most users to integrate first-class request-handling mechanisms, such as issue-tracking systems like Jira?
Now that chat products appear to be the new groups mechanisms, it would be nice if routing approval request notifications to chat would become as ubiquitous as email notifications were in the past. At least in chat, it’s obvious that requests should be routed to shared spaces so that all approvers can see all the same requests at the same time, and, ideally, what the resolutions were. Moreover, it would be straightforward to resolve them in context, using a card with a button or form, or an old-school slash command. Sadly, the lack of a chat standard makes this outcome less likely, so probably we’ll be stuck with these email notifications for the foreseeable future.
