Drei lebendige E-Mail-Signaturen,
eine Challenge.
Drei kleine Sachen an einem Wochenende gebaut. Dann ist mir aufgefallen, was sie eigentlich sind — und was sie noch nicht sind.
Kurz — Eine Signatur war früher ein statisches Artefakt. Muss sie nicht mehr sein. Drei Demos zum Beweis (Radio, News, WM), eine M365-Challenge, um’s weiterzubringen.
Was du siehst: ein lebendiges Badge für GDS.FM, mein Lieblings-Radio in Zürich. Mail aufmachen, das Badge zeigt, was gerade läuft. \o/ markiert die Stelle.
Die Technik ist unspektakulär. Ein Cloudflare Worker zieht die Now-Playing-API der Station, bäckt den aktuellen Track in ein SVG, liefert das als Bild aus. Cache 25 Sekunden. ~100 Zeilen Code.
Was das Ding eigentlich ist
Eine Signatur war früher ein statisches Artefakt. Name, Rolle, Link, fertig. Einmal geschrieben, zwei Jahre lang abgestanden.
Diese hier ist generativ. Jedes Mal wenn jemand die Mail öffnet, wird ein Interface für diesen Moment zusammengebaut, aus Live-Kontext. Derselbe <img>-Tag, den E-Mail-Clients seit 1998 rendern. Anderer Inhalt darunter.
Um zu zeigen, dass das Muster auch mit anderen Quellen funktioniert, habe ich zwei weitere gebaut.
Drei Quellen,
eine Form.
Derselbe Cloudflare Worker, drei verschiedene Routen. Das Muster (Kontextquelle → Compute → Rendering-Ziel) ist über alle drei identisch. Nur die Source-URL ändert sich.
- 01
Der aktuell laufende Track eines Radiosenders
Das Original. Airtime API → Worker → SVG. Das Beispiel oben.
Gebaut - 02
Top of Hacker News
Gleicher Worker, zweite Route. RSS statt Airtime. ~30 zusätzliche Zeilen.
Gebaut - 03
Die letzten drei WM-Resultate
Gleicher Worker, dritte Route. TheSportsDB Free API. Die WM 2026 läuft, während ich das schreibe.
Gebaut
Hacker News ist nur die Demo-Quelle. Der spannende Move ist, das Ding auf den internen Kontext eures Teams zu richten — die Confluence-Updates, die eure Kolleginnen sowieso schon schreiben, die GitHub-Releases, die euer Team eh schon ausliefert.
| Plattform | RSS / Feed-Endpunkt |
|---|---|
| Confluence Cloud (pro Space) | /wiki/spaces/{KEY}/blog.rss |
| SharePoint News | /_layouts/15/listfeed.aspx?List={GUID} |
| GitHub Releases | github.com/{org}/{repo}/releases.atom |
| Atlassian Statuspage | {page}.statuspage.io/history.rss |
| Notion (veröffentlichte Seite) | via super.so oder notion-to-rss |
| Jira Issues | Jira issueviews Search XML Feed |
| Astro / Hugo / Ghost Blog | /rss.xml |
Internes Confluence braucht OAuth. Öffentliche Quellen brauchen nichts. So oder so: gleicher Worker, gleiche ~30 Zeilen, andere URL in einer Konstante.
Drei Quellen, drei Signaturen, ein Worker. Die ersten zwei sind Empfehlungen an die Lesenden (hör das, lies das). Die dritte ist eine leise Ansage — "ich verfolge das Turnier auch." Alle sehen dasselbe. Das ist die langweilige Version.
Die interessante Version ist die, die ich nicht gebaut habe
Statisch ist okay. Statisch ist ausgeliefert. Aber der eigentlich spannende Move ist, wenn "für alle gleich" zu "pro Empfängerin anders" wird.
Stell dir das WM-Badge nochmal vor. Aber beim Senden liest ein Agent, an wen die Mail geht, checkt das Land, wählt den passenden Kontext. "Hopp Schwiiz" mit dem Score von gestern Abend für eine Schweizer Kollegin. "Forza Italia" für einen Partner in Mailand. Ein neutrales "enjoy the tournament" sonst. Gleiche Mail, andere Signatur, pro Person.
Das ist ein 2–3-Tage-Build in einem M365-Tenant. Die Bausteine sind bekannt.
OnMessageSend-Event-Handler. Tenant-deploybar via M365 Admin Center./users/{email}/profile); öffentlicher Lookup für extern.Eine architektonische Einschränkung vorweg: die Outlook-Signatur ist eine Client-seitige Einstellung. Du kannst das Signatur-Feld nicht dynamisch pro Empfängerin aus dem eingebauten Outlook-Feature heraus umschreiben. Entweder ein Outlook Web Add-in ändert beim Senden den E-Mail-Body (sichtbar für die Absenderin), oder eine serverseitige Regel schreibt das Ganze beim Versand um (sauberer für Compliance, weniger sichtbar). Für etwas so Sichtbares ist der Add-in-Weg der richtige.
M365- und Copilot-
Consultants — euer Wochenende.
Ich habe die langweilige Version gebaut. Drei Signaturen, gleiche Daten für alle, ~250 Zeilen Worker-Code. Funktioniert. Ship it. Nächstes Thema.
Die Version, die ich sehen will, ist die pro-Empfängerin. WM ist nur das Demo — nehmt irgendeine Kontextquelle. Das Badge ändert sich, je nachdem wer liest.
Die Bausteine sind oben aufgeführt. Der Architektur-Writeup steht auf dieser Seite. Die Datenquellen sind öffentlich. Was übrig bleibt, ist genau der Teil, in dem ihr mehr wisst als ich: ein Add-in in einem Tenant ausrollen, Copilot Studio oder eine Azure Function verdrahten, und die Consent- und Audit-Story kohärent machen.
Wer diese Woche eine funktionierende Tenant-Deployment ausliefert, taggt mich. Die erste, die ich live sehe, bekommt einen Writeup hier auf bridge-work.ai/lab.
Ich bin ehrlich neugierig, wer von euch zuerst ausliefert. Und ich bin ehrlich neugierig, wessen Consent- und Audit-Pattern am ehrlichsten ist.
Natürlich geht’s eigentlich nicht um Fussball
Das Turnier ist ein anschauliches Beispiel, weil es gerade läuft. Das Muster hat nichts mit Sport zu tun.
An eine Aufsichtsbehörde statt an einen Partner gesendet, kann derselbe dynamische Block die passende Compliance-Referenz pro Jurisdiktion anhängen. An eine Kundin statt eine Kollegin, kann er die Case Study zeigen, die zu ihrer Branche passt. In einer mehrsprachigen Organisation grüsst er in der Arbeitssprache der Empfängerin und zeigt das jüngste interne Update aus ihrer Region. Im Sales kann er das relevanteste Stück Evidenz für die Pipeline-Stage der Empfängerin tragen. Im Customer Success den letzten Help-Center-Artikel in der richtigen Sprache.
Das sind keine Verzierungen. Das ist der Unterschied zwischen einer Signatur, die sagt "ich existiere", und einer, die sagt "ich habe gelesen, worüber du gleich liest."
Das sind keine Blocker. Das ist die Produktoberfläche. Das ist auch der Grund, warum ich die pro-Empfängerin-Signatur für mehr als ein Spielzeug halte. Die Spielzeug-Version, die ich aus Spass bauen würde, sind WM-Begrüssungen. Die Version, die eine regulierte Organisation tatsächlich ausliefern kann, braucht den Consent-Flow benannt, das Audit-Log aufbewahrt, den Failure-Mode geübt.
Das ist der Teil, über den ich beruflich nachdenke.
Quelle · Compute
· Render · Governance.
Die gleiche Form funktioniert für alle drei gebauten Versionen, und für die, die ich nicht gebaut habe.
<img>-Tag. Oder, mit einem Send-Time-Add-in, ein HTML-Block, der vor dem Senden injiziert wird.Der Lego-Stein ist günstig. Die spannende Frage über alle vier Versionen hinweg ist nicht "können wir." Sie ist, wo die neue Oberfläche auf alte Governance trifft. Das ist die Naht.
Das ist der Teil, über den ich beruflich nachdenke. Aber die Spielzeuge funktionieren. Und Spielzeuge sind, wie ich die Nähte finde.
Das Radio läuft. Hacker News aktualisiert. Die WM schiesst Tore. \o/
Selber probieren
Das Ganze liegt auf GitHub. Ein Worker-File, drei Demo-Routen, ~250 Zeilen. Fork machen, die Source-URLs auf irgendetwas richten. Oder — wenn du Copilot-Consultant bist — mit der M365-Architektur oben anfangen und mir zeigen, was du ausgeliefert hast.