Blanket approvals and template documents that you can cut and paste notifications into are the way to go, especially when it's on a schedule like MS, Adobe & Oracle. If they push back, suggest a documented process (this is ITIL, right? You can avoid the need for a CAB if it's an approved and documented procedure) where you push the patches to a few test systems on Tuesday (in the case of MS) then deploy to the rest later in the week - whatever they are happy with - if there are no issues. Depending on your timezone Tuesday PM or Wednesday AM are good slots for weekly CABs to pick up this; push to the test servers on the day, then the rest at the end of the week. For *nix, i've done updates this way for anything that didn't require a reboot so only stuff like Kernel updates and major low-level libraries needed to get approval via a CAB.
For everything else, it's your call. Either the patch waits for the next regular CAB or you play the game and keep calling emergency CABs when there are justifiably critical updates, such as Heartbleed, or for the inevitable critical updates from MS every second Tuesday that impact your systems. The best tactic is to embrace ITIL and make it work for you, not allow them to make you jump through hoops and spend your time crafting unique documents for every patch. It also serves as a useful procedure check to make sure you don't mess up and have a contingency plan for when you do, and ultimately, if you get it right, you still get to dictate the schedule and make them do things in ways that you are happy to work with.