Firstly, the message center isn't necessarily available to the people who need to take the action - so helping the global admins and service administrators to get the message out to the people who really need to know has to be a priority. I know from the support end that sometimes things that we have announced repeatedly via various channels - including the message center - can still come as a surprise to some end users.
Following on from that it is not only great to know you have told the right people the message - but even better to know they heard the message and have taken action and completed whatever it is they need to do (even if it is only to acknowledge that they heard!). Planner and the sample I describe on my blog allows this communication to happen - not just into Planner, but by using a Plan in a Microsoft Team is a great place for the conversation to continue if necessary!
As an example I've been automatically assigned the task for MC118086 - We're making some changes to SharePoint Online pages - so I can review the task, mark it in progress and set the start date - then reach out to my colleagues to see if we would be impacted here?
As I'm already in Teams I can start up a conversation.
Then once I'm satisfied that the issue is a non-issue - I can close it down - or if it needs more work I could then add a new task in Planner for whoever will carry out the remediation. No more surprises!
The Office 365 Global Admin can look over the entire plan if they need to and monitor the progress.
In my samples I've used a single plan and then buckets for each product - but with integration to teams you may well have different teams and plans that need to be notified. Easy enough - you can just build out the sample to not just use one PlanId - but have multiple Plans as part of the configuration json file so that the task gets put into the right Team's plan - in the right bucket and assigned to the right resource. I also do an hourly pull and then check if the title already exists in Planner. You could use some different logic here and also track the status of the messages and treat them differently if you needed to. Plenty of scope for message handling - but also other service information that can be read with the same API.