Organisationen, die Dynamics 365 Customer Service, Sales und Field Service einsetzen, behandeln externen Zugriff meist als drei getrennte Probleme: hier ein Case-Portal, dort eine Idee für Bestellverfolgung, für Field Service oft gar nichts.
Power Pages lizenziert nicht pro Workload, sondern pro Website. Authentifizierte Nutzer werden einmal pro Website und Monat gezählt, unabhängig davon, wie viele D365-Workloads diese Website anbindet. Ein Kunde, der einen Fallstatus prüft, eine Bestellung verfolgt und einen Serviceeinsatz bestätigt, ist in einem einzigen Portal ein authentifizierter Nutzer, nicht drei.
Drei getrennte Zugriffswege bedeuten drei Logins, drei Lizenzrechnungen, drei uneinheitliche Erfahrungen. Ein Portal, das alle drei Workloads abbildet, bedeutet einen lizenzierten Nutzerpool für alles zusammen.
Genau das übersieht die ROI-Diskussion meistens. Es geht nicht nur um Supportkosten pro Fall, sondern um den Lizenz-Multiplikator über jeden D365-Workload hinweg, den ein Kunde berührt. Ein Portal ist kein Nice-to-have für eine einzelne App, es ist das wirtschaftliche Fundament, das eine Multi-App-D365-Investition für die Menschen außerhalb Ihrer Organisation wie eine kohärente Plattform wirken lässt.
Mehr dazu: Die fallspezifische Supportkosten-Rechnung zeigt Self-Service-Portal im Kundenservice: ROI & Einsparpotenzial. Die vollständige Lizenz-Aufschlüsselung hinter dem „pro Website"-Argument oben finden Sie in Power Pages Kosten & Lizenzierung: Die vollständige Übersicht.
Genau dieses gebündelte Zugriffsmodell kartiere ich in einem Architektur-Workshop, bevor eine einzige Portalseite gebaut wird.
