Jump to content

Rückfrage serverseitig (.NET/API/...) einleiten


jodost

Recommended Posts

  • Most Valued User

Hallo alle,

 

ich suche eine Lösung für folgendes Problem:

 

1. Anruf kommt rein, Mitarbeiter geht ran

2. Mitarbeiter füllt zu diesem Anruf ein Intranet-Formular aus. Dort soll er auf Knopfdruck einen Kollegen auswählen können, an den er den Anruf hinverbinden kann. Also sozusagen Namenstasten auf einer Intranet-Webseite (und eben nicht im SwyxIt selbst)

3. Mitarbeiter klickt diese Namenstaste an und leitet so eine Rückfrage ein

 

Bei den Windows-Nutzern müsste das recht einfach sein, der Knopfdruck verlinkt einfach auf tel:+4912345 und SwyxIt! macht den Rest.

 

Bei den Mac-Nutzern reagiert der Swyx-Client nicht auf tel:, sondern Facetime drängelt sich immer vor. Ich habe noch nicht rausgefunden, wie man das ändern kann. Aber vor allen Dingen haben wir auch Mac-Nutzer mit Systemtelefon, für die wäre das ohne CTI-Funktion wertlos.

 

Und dann würde ich am liebsten auch einem Überlauf-Callcenter diese Möglichkeit geben, da habe ich gar keine Möglichkeit, einen Client zu installieren.

 

Ich bräuchte also eine Möglichkeit, auf dem Server ein laufendes Gespräch zu nehmen und eine Rückfrage einzuleiten. Ich befürchte, ich kenne die Antwort, aber hat jemand eine Idee, ob das gehen kann?

Link to comment
Share on other sites


Es tut mir leid die Bedürchtungen bestätigen zu müssen, aber die SwyxWare hat derzeit keine Server seitiges Call Control welches hierfür verwendet werden müsste.

 

Es ist richtig, dass die Sache auf Windows Rechnern sehr einfach ist. Hier kann einfach ein "tel" Link verwendet werden. Ebenso kann bei der Verwendung vom Internet Explorer auch direkt vom JavaScript Code in der Webseite auf das Client SDK des SwyxIt!s zugegriffen werden. 

 

Für den Mac habe ich leider keinen Lösungsansatz spontan parat.

Link to comment
Share on other sites


  • Most Valued User

Das Formular kann via SPA (z.B. Angular) in Echtzeit gefüttert werden.

Ähnlich könnte man ein Webinterface bauen, welches auf dem Server das Call-Handling mit Hilfe des Client SDK steuert. Leider kenne ich mich mit dem Client SDK zu wenig aus, wäre aber ein Ansatz, um sich vom lokalen Client zu lösen.

Link to comment
Share on other sites


  • Most Valued User
2 minutes ago, ogoettlich said:

Das Formular kann via SPA (z.B. Angular) in Echtzeit gefüttert werden.

Ähnlich könnte man ein Webinterface bauen, welches auf dem Server das Call-Handling mit Hilfe des Client SDK steuert. Leider kenne ich mich mit dem Client SDK zu wenig aus, wäre aber ein Ansatz, um sich vom lokalen Client zu lösen.

 

Das Formular ist nicht das Problem, auch nicht, alle relevanten Informationen aus Swyx, Ticketsystem usw. rauszuziehen. Die eine Hälfte unserer Firma ist seit 15 Jahren Web-Agentur, die andere seit 10 Jahren Swyx-Hosting-Partner. Das kriegen wir hin :-)

 

Das Client SDK auf dem Server würde aber doch nur was bringen für Anrufe, die dieser Client handhabt, oder? Also am Ende für jeden Mitarbeiter SwyxIt! per CTI in einer RDP-Umgebung oder so... das wollen wir ja gerade nicht.

Link to comment
Share on other sites


  • Most Valued User

Das wäre die Frage, ob über das Client SDK bestehende Calls gehandelt werden können, oder nur eigen-initiierte. Im besten Fall würde das Client SDK ausgelagert laufen und die Parameter per (Web)interface erhalten (CallId, Zielrufnummer) und den Call entsprechend managen (unabhängig vom Client).

Link to comment
Share on other sites


  • Most Valued User

das ClientSDK steuert ja nur den Client, und der sieht ja nur seine eigenen Anrufe.

 

Man könnte höchstens über CTI+ den per SDK gesteuerten Client plus die normale Nebenstelle des Mitarbeiters pairen. Hab ich schon durchgespielt, aber das wird dann vom Aufwand schon bald absurd (denn so ein Pairing könnte ja immer nur einen Anruf und eine Nebenstelle abdecken, d.h. ein zweiter Anruf oder ein zweites Weiterverbinden usw. wäre dann schon wieder raus...

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.