Es gibt ja seit geraumer Zeit die Möglichkeit, bei verpassten Anrufen durch die Telefonanlage Extern-Nachher-Kontext eine vom System generierte E-Mail versenden zu lassen.
Das funktioniert auch gut und mit etwas Aufwand kann man die E-Mail dann auf der Empfangsseite entsprechend automatisch parsen und weiter verarbeiten.
Problem hierbei: Man kann nicht definieren, an welche E-Mail-Adresse die Benachrichtigung geschickt wird. Es wird also entweder immer die des Benutzers und die vom Team genommen. Das schränkt die Möglichkeiten dann schon wieder ein.
Daher möchte ich vorschlagen, dass man neben der Benachrichtigung per E-Mail auch eine Benachrichtigung an eine einstellbare URL ermöglicht, der man dann die Daten aus dem Anruf wie Rufnummer, Labels etc. übergeben kann.
Hilfsweise wäre (zumindest für mich persönlich) auch alternativ denkbar, dass man
zumindest die E-Mail-Adresse frei hinterlegen kann (meinetwegen auch erst nach einem Bestätigungsprozess der E-Mail-Adresse, damit man nicht jede beliebige Adresse angeben kann).
den Nachrichteninhalt selbst bestimmen kann. Vor allem sollte die Möglichkeit bestehen, neben Datum, Uhrzeit und Nummer von A- und B-Teilnehmer auch die auch im Callrecord vorhandenen Informationen zu Labels, Call-Chain, Telefonbuch-Eintrags-ID etc. übermitteln zu können. Dann wäre das echt auch als E-Mail brauchbar und bedürfte keinem URL-Aufruf.
Gruß
Michael
P.S.: Argumente wie “das versteht ein Anwender nicht oder er kann da sonstigen Blödsinn eintragen” zählen nicht wirklich, weil er sich die Telefonanlage auch an vielen anderen Stellen kaputt konfigurieren kann.
Wo siehst Du hier Themen? Für was solle ich den DS berücksichtigen? Dafür dass ich anstelle einer E-Mail zu einem verpassten Anruf an eine beliebige E-Mail-Adresse, die zudem noch nicht digital signiert ist, den Aufruf eines Webhooks bevorzuge bei dem die komplette Kommunikation verschlüsselt stattfindet?
90% der Kunden arbeiten mit nicht signierten E-Mails. Bestenfalls ist der Transportweg verschlüsselt. Da ist mir eine Server zu Server Kommunikation deutlich lieber.
Meinetwegen kann Punkt 2 ganz entfallen, wenn ich dafür eine eindeutige Call-ID bekomme, über die ich die Daten in Echtzeit performant abfragen kann oder mir in der E-Mail nur die Call-ID geliefert wird. Aber 2023 E-Mails über verpasste Anrufe versenden, die ich anschließend händisch bearbeiten muss, ist so typisch für Deutschland wie das Faxgerät bei gliechzeitiger Veröffentlichung privatester Informationen in den sozialen Medien.
Datenschutz ist gut und wichtig, sollte uns jedoch nicht daran hindern, digitaler zu werden oder gleich alles digitale aus diesen Gründen zu verhindern.
Also erstmal für das Gesetz und um deinen Kunden Probleme damit zu ersparen.
Ein Webhook impliziert keine verschlüsselte Übertragung. Zusätzlich, wenn er einfachheitshalber auf GET-Parameter gesetzt wird, landen diese in den Serverlogs, was bei einer Löschungsanfrage neben den Daten, die die Skripte generieren, ebenfalls bereinigt werden muss.
Auch hier sind potenzielle Adressen von nicht DSGVO-konformen Drittdiensten auszuschließen, da wir sonst eine Weitergabe an Drittdienste zur Datenverarbeitung haben. Das muss der Admin bedenken, aber mit der falschen Einstellung natürlich schnell ein Problem.
Es gibt immer datenschutzkonforme Wege. Natürlich sind diese aufwendiger, aber in der Regel kein großes Hindernis, wenn man es nicht schnell zusammenfuschen will.
Da gehe ich mit, käme aber nie auf die Idee, unverschlüsselte Webhooks zu verwenden. Und ich denke, Pascom würde das auch dadurch verhinden, dass serverseitig ausschließlich https genutzt wird (und wenn man denn unbedingt will auch keine selbstsignierten Zertifikate erlaubt.
Deshalb stelle ich mir das so vor, dass man solche Dinge als POST im Body übermittelt. Zumindest sollte die Option vorhanden sein.
Es ist imho nicht die Aufgabe von Pascom, den Datenschutz für die Kunden zu überwachen. Dafür gibt es die DSB in den Unternehmen, die entsprechende Prozesse zu bewerten haben.
Übrigens hat man solche Konstrukte an ganz vielen anderen Stellen ja auch. Niemand verhindert, dass ich eine E-Mail-Adresse eines Drittanbieters verwende, an die z.B. Anrufbenachrichtigungen gehen.
Letztlich ist das derzeit aber eh nur ein frommer Wunsch, überhaupt mal eine solchen Funktion zu haben. Ist ja schließlich Weihnachten
Und ich bin mir auch sicher, dass die Devs von Pascom das schon richtig gut umsetzen werden, wenn es mal irgendwann soweit ist. Steht halt derzeit aus nachvollziehbaren Gründen nicht so weit oben auf der Prio-Liste
Ich habe nichts gegen deine Idee. Ich wollte nur darauf hinweisen, dass sich an dieser Stelle einige Fettnäpfchen verbergen, und gerade Script-Konstrukte dazu einladen, in diese zu treten. Vielleicht könnte Pascom auch einfach die Benachrichtigungen an sich ‘schicker’ gestalten und diese über ein Webportal oder einen eigenen Tab im Client anbieten, um dort alle Informationen ansprechend aufzubereiten?
Kleine Bemerkung am Rande: Ein Datenschutzbeauftragter (DSB) muss es erst ab 20 Mitarbeitern geben, die ständig mit der automatisierten Verarbeitung von personenbezogenen Daten beschäftigt sind. Davor sind die Unternehmen in der Regel der Expertise des Dienstleisters ausgeliefert. Es sollte niemals einfacher sein, es falsch zu machen, als es richtig zu tun. Also abwarten und schauen, wie Pascom es umsetzt.
Für die Übertragung von Daten zu anderen SaaS Diensten oder Plattformen allgemein gibt es Auftragsdatenverarbeitunsgsverträge. Ich sehe kein Datenschutzthema beim PBX Betreiber, wenn Daten aus der Telefonanlage in ein ERP importiert werden.
Ich wünsche mir auch ein eventbasiertes Webhook, z.B., um nach jeden beendeten Anruf einen Job im ERP zustarten.
Pascom könnte sicher helfen, in dem sie verschlüsselte Protokolle zwingend voraussetzen. Aber Pascom hat rein gar nichts damit zu tun, ob Kunden Daten aus Pascom extrahieren, weiterleiten oder anderweitig verarbeiten. Das könnten Sie weder rechtlich, noch technisch verbieten.
Dass man die PBX beim Datenschutzkonzept berücksichtigen muss ist klar, hat aber rein gar nichts mit dem Vorschlag hier zu tun.
Das war, wie gesagt, auch nur ein Hinweis, da es bei solchen Konstrukten viele Fettnäpfchen gibt, unter denen in erster Linie potenziell der Kunde leiden kann oder wird.
