From Audio Overview to an Automatic Podcast: how I turned the Microsoft 365 Message Center into a morning briefing on Telegram

The problem: too many messages, too little time

Anyone who manages a Microsoft 365 tenant knows this well: the Message Center is an indispensable tool, but keeping up every day with each announcement, planned update and feature retirement takes time and focus. It is not just a matter of reading — you need to understand what is changing, who is affected, whether action is required and by when.

---

The idea: a morning podcast

It all started with a feature I had discovered in Microsoft 365 Copilot: Audio Overview. Being able to upload a document to SharePoint or OneDrive and get an audio summary — complete with a two-voice podcast mode — struck me straight away. It would have been perfect: listening to the round-up of updates in the car on my way to the office.

The problem is that Audio Overview is not available as an action in Power Automate. As of today there is no connector that lets you automate its generation. The only way is manual: you upload the document containing all the new messages, click generate and listen. Useful, but impossible to automate.

From there I started thinking about how to replicate that same experience in a fully autonomous way, with no human intervention.

---

The solution: four scripts, one podcast

The architecture I built is made up of four steps run in sequence every morning, orchestrated by a master script.

1. Collecting the messages

The starting point is a call to the Microsoft Graph API with the ServiceMessage.Read.All permission, authenticated through an App Registration with a certificate. Messages from the last 24 hours are extracted and saved to a structured JSON file with the title, affected service, tags, dates and body text.

The JSON becomes the raw data that all the subsequent steps work on.

2. Generating the podcast script

The JSON file is passed to GPT-4o mini on Azure AI Foundry. I chose GPT-4o mini for practical reasons: the task is summarising and rewriting, it does not require complex reasoning, and the cost is in the region of a few cents a month for the daily volume I generate.

The prompt I have refined over time defines two distinct voices:

• Alex: the host, with a morning-radio tone, direct and with a clear voice.
• Sara: the technical expert, who answers precisely, cites dates and explains practical impacts and required actions.

One of the most interesting challenges was teaching the model to prioritise the messages correctly: retirements with imminent deadlines must come first and get more airtime, while new features with no immediate impact can be dealt with in a couple of lines. I solved this by pre-sorting the messages in the PowerShell code — split into three groups (Retirement, Admin impact, Informational) — before even passing them to the model, so that the order in the JSON already reflects the priority.

The result is a .txt file with the podcast script, ready for speech synthesis.

3. Converting to audio

The text script is passed line by line to the gpt-4o-mini-tts model, also on Azure AI Foundry. For each line identified as ALEX: or SARA:, a separate call is made to the TTS API with the corresponding voice (echo for Alex, nova for Sara) and specific style instructions for each. The audio chunks are then concatenated into a single .mp3 file.

The decision to use gpt-4o-mini-tts instead of Azure Speech Service — which I had initially considered, since it was already in the subscription — came down to quality. OpenAI’s TTS model, while accessible through the same Azure infrastructure, sounds far more natural, particularly in its rhythm and handling of pauses.

4. Delivery to Telegram

The last part of the pipeline sends the mp3 straight to a Telegram group via a dedicated bot. Choosing Telegram over a Teams workflow, saving to a SharePoint DL or email was deliberate: Teams, Outlook and SharePoint/OneDrive would all mean opening work apps. Telegram is one tap away, works brilliantly as an audio player on a smartphone, and the bot created with BotFather can be added to a group and shared with colleagues instantly.

---

How I scheduled everything

The whole pipeline runs on a Windows Server 2025 VM in Azure that I already had available, managed through two components:

Azure Automation handles the lifecycle of the VM itself: a PowerShell runbook starts the machine at 06:50 Monday to Friday and shuts it down at 08:10, once the pipeline has finished. This means the VM stays on for less than an hour and a half a day, keeping costs down.

Task Scheduler on the VM runs the master script at 07:00. The master calls the four scripts in sequence, checks their exit codes, records everything in a daily log and — if something goes wrong — can send an error notification.

The upshot is that every weekday morning, without any intervention, the podcast is available in the Telegram group by around 07:30.

---

Technology components used

The whole solution runs on Microsoft infrastructure, with a single external exception (Telegram), though it could easily be integrated via a Teams workflow/PnP PowerShell:

---

Future developments

The solution is up and running, but there are directions in which I would take it further:

• Interactive bot: today the bot is passive — it can only send. With an Azure Function handling the webhook, it could respond to commands (/oggi, /cerca Copilot, /scadenze) and become a proper lookup tool.
• Urgent alerts: if a message arrives with severity high or the Major change tag, the bot could send a notification immediately instead of waiting for the morning podcast.

---

Conclusion

The idea was simple: listen to Microsoft 365 updates in the car instead of reading them at my desk. Every morning at 07:25 I get a Telegram message with a ten-minute podcast. Alex and Sara bring me up to speed on everything that has changed in the tenant, starting with critical retirements and finishing with new features. This solution means I arrive at the office already up to date.