Jump to content

Tom Wellige

Root Moderator
  • Content Count

    2,857
  • Joined

  • Last visited

  • Days Won

    93

Tom Wellige last won the day on November 5

Tom Wellige had the most liked content!

Community Reputation

53 Excellent

4 Followers

About Tom Wellige

Profile Information

  • Gender
    Male
  • Interests
    SwyxWare, Software Development, Flight Simulation

Recent Profile Visitors

7,273 profile views
  1. From 2009 to 2011 mirjam baumberger wrote a great blog, the "Fridays' Swyx Tip". Every Friday she posted a tip regarding the usage of SwyxWare and connected tools and devices. As the old forum is offline, this article series will be restored here again over the time. Please note that some information in this article series might not be valid anymore with current SwyxWare versions. This blog article was originally posted on 13.02.2009 01:38 Dear Swyx Users Did you know that Swyx allows supervisors and call centre manager to monitor conversation of their agents? Call intrusion is part of Swyx Option Pack Monitor and enables managers to silently listen into current conversations on the Swyx Server. The intruder can also barge in to the conversation and assist the agent or he can join as a full participant and talk to both parties simultaneously. In the screen shot, John is intruding on David’s conversation. A simple right click on Davids Speed Dial, select call intrusion and John is connected to Davids call. Once connected ,John can changed his "listening mode" to "speak mode" by entering the DTMF digits *24*2# . *24*1# Listening only *24*2# Listen to both sides, speak with agent *24*3# Listen to both sides, speak with both sides. You hear both call partners. You hear both call partners, and the agent hears you. The other call partner (e.g. the external customer) hears only the agent. You can participate directly in the conversation. In the Swyx Administration, you have to configure the Users or Groups which are allowed to intrude on the agent. Go to: > Users\Properties\Administration\Call Intrusion. Then add the "Call intrusion" field in the context menu of the SpeedDial add the following registry key to the Intruders PC: HKEY_LOCAL_MACHINE\SOFTWARE\Swyx\SwyxIt!\CurrentVersion\Options\SpeedDialMenus\Key1 Here you add three new String Values: CommandLine = callto:%SpeedDialPeernumber%*24*1# MenuLabel = Call Intrusion Working Directory = C:\\ Have a good weekend and happy Swyxing... Regards Mirjam @ IT Net World Ltd, NZ & AUS SWYX Distributor http://www.itnetworld.co.nz/
  2. Im Prinzip machst Du da alles richtig. Ich verstehe allerdings nicht, warum die beiden "Datum/Uhrzeit" Blöche in Folge für den Vormittag und Nachmittag von Montag bis Donnerstag nicht klappen sollten. Du hast nicht zufällig noch die alte Version (idealerweise als .RSE Datei exportiert)? Dann würde ich da gerne mal einen Blick drauf werfen.
  3. Ebenso darfst Du den Ruf im PreProcessing nicht annehmen, da sonst anschliessend der "Regel übersprungen" Ausgang nicht mehr funktioniert, d.h. nachfoglende Regeln werden NICHT mehr gestartet. Das gilt für alle GSE Regeln, und so auch für das PreProcessing. Indem Du eine Ansage abspielst verbindet der Server den Ruf um die Ansage abspielen zu können.
  4. From 2009 to 2011 mirjam baumberger wrote a great blog, the "Fridays' Swyx Tip". Every Friday she posted a tip regarding the usage of SwyxWare and connected tools and devices. As the old forum is offline, this article series will be restored here again over the time. Please note that some information in this article series might not be valid anymore with current SwyxWare versions. This blog article was originally posted on 30.01.2009 04:07 Dear Swyx Users Did you know that you can define a custom ringing sound ? When Swyx receives an incoming call you can actually play a custom ringing tone to the caller while the call is connecting to its destination. Scenario: After your standard trading hours, SwyxWare is advising the caller that they will be connected to the after hours service team. While your customers is listening to the instruction on how your after-hours service is working, Swyx is already trying the get a hold of your standby staff. How can you do that? By opening your ECR script and editing the Connect To block. By default the system alert sound is played but you have also an option to select a individual WAV/MP3 file. From the drop down list select a file. Browse your hard drive by clicking on . When searching, you can also choose a file in MP3 format. Upon selection, the MP3 file will automatically be converted into the supported WAV format and saved in your personal directory on the SwyxServer. The converted files are therefore available for use later. During the conversion process, the Info dialog "Please wait, the file is being converted into WAV format" will open. To listen to your new select alert file click on . Click on , to stop playing the file. Or you can even record your own altering announcement To record a new alert announcement click on : You will then be prompted to enter a file name. The following window appears: "Start Recording". Click on "Start" to begin recording the announcement. Stop the recording by clicking on . To delete the selected file, click on . Have a good weekend and happy Swyxing... Regards Mirjam @ IT Net World Ltd, NZ & AUS SWYX Distributor http://www.itnetworld.co.nz/
  5. Genau so ist es. Ob jetzt 1-100, 1-50 oder 1-20 ist egal, das entscheidest Du selbst.
  6. There is always one colleague in the group who is never answering group calls! Does this sound familiar to you? When connecting a call to a group it depends on the group configuration, how the call will be signaled to the group members: Parallel - all phones of all members ring simultaneously Random - one member is picked randomly from the group Rotary - the first call goes to member 1, the second call to member 2, a.s.o. Sequential - the call goes to member 1, if member one is not available (timeout, busy, not logged in) it goes to member 2, if member 2 is not available it goes to member 3, a.s.o. The next new call will go first to member one In many cases these hunt group selections are sufficient, but there is one selection missing in the list which is getting asked for every once in a while: Longest Waiting/Idle The call routing of the SwyxWare wouldn't be the call rouging if this problem couldn't be fixed in there What is needed is a reliable source of information when a certain user had is latest call (disconnect time). This information can be taken from the call detail records. For the ease of usage, they need to be written into a database instead of a text file (refer to KB article Write Call Details Records into a database (kb2491)). Without going too much into details, we will add a small trigger onto this table. This trigger will be called for every newly added record, takes user name and disconnect time from it and stores it also into an additional table "LongestWaiting" into the database. When it is necessary to know when a certain user had his latest disconnect, one only needs to look into "LongestWaiting" table. We use a small GSE Action (comparable with a function in any programming language, it is just "written" with the GSE). This GSE Action takes the group the call should be connected to as parameter (refer to my blog article #6: Make it easy!). It uses the GetUserByAddress method of the PBXConfig Server Script API to resolve all users from the given group. With the list of users the database (LongestWaiting" table will be queried to get a list of all users in the order of old disconnect time first. The GSE Action tries now to connect the call to the users in the list, starting with the first one. If this user is not available (timeout, busy, not logged in) it goes on with the second in the list, a.s.o.. It goes on until the call is either connected or the call wasn't taken by any user. The usage of this GSE Action is actually quite simple, it replaces the standard "Connect To" block by The GSE action takes a few parameters, with the "Destination" being the most important one. This is the group which the call should be delivered to with the new "longest waiting/idle" hunt group type. A complete description, manual and download can be found in the Longest Waiting Hunt Group project, being a part of the Open ECR Extensions project here on Swyx Forum. Enjoy! PS: don't miss to take a look into the ECR Useful Link Collection
  7. Nein, da muss nicht noch etwas zusätzliches installiert werden. Microsoft gibt sich nur einige Mühe es zu verstecken
  8. Das Rufjournal im SwyxIt! zeigt die Rufdauer leider nicht an. Das lässt sich auch per Konfiguration nicht ändern. Das Rufjournal im Outlook zeigt sie allerdings an:
  9. Wie gesagt, den Umleitungsstatus bekommst Du nur im Call Routing des entsprechenden Benutzers abgefragt. Out of the Box sehe ich da keine einfache Lösung. Auch persistente Variablen lösen Dein Problem nicht wirklich, denn in dem Augenblick in dem der Benutzer X seine Umleitung setzt ja kein Call Routing angestossen wird mit dem den neuen Status selber speichern könntest. Die komplette Umleitungskonfiguration kann über den ConfigDataStore abgefagt werden, da sind vom Call Routing aus aber einige Klimmzüge für notwendig. Finally steht die Umleitungskonfiguration in der SwyxWare Datenbank. Technisch kann es natürlich niemand verhindern dass dort z.B. ein Call Routing Skript der Zentrale hineinschaut um sich mal in Bezug auf den Benutzer X ein wenig schlauer zu machen... Es sei allerdings ausdrücklich darauf hingewiesen, dass es dafür an keiner Stelle Support gibt. Bei schreibenden Zugriff auf die Datenbank würde sogar der komplette Support für diesen Server eingestellt.
  10. Du kannst die (ersten n) Namenstasten eines Benutzers auf alle Benutzer einer Gruppe direkt mit der SwyxWare Admnistration verteilen. Das geht über das "Eigenschaften klonen..." im Kontextmenü eines Benutzers:
  11. Hallo Mathias, das mit dem Status ist einfach (siehe hier), das mit der Umleitungskonfiguration eines anderen Benutzers geht leider nicht. Du kannst von Call Routing aus nur auf die eigene Umleitungskonfiguration zugreifen. PBXUser.BusyRedirect PBXUser.BusyRedirectNumber PBXUser.DelayedRedirect PBXUser.DelayedRedirectNumber PBXUser.DelayedRedirectTimeout PBXUser.UnconditionalRedirect PBXUser.UnconditionalRedirectNumber Vielleicht kannst Du ja die Call Routings der anderen Personen die Du abfragen willst/musst mit einbeziehen?
  12. Sorry, I have no ETA information at hand.
  13. When it comes to develop call routing scripts with some own VBScript code in it, it might become handy to be able to have a look on what your code is doing. There are lots of so called "debugging" possibilities, but at this point you have to believe me, the only really reliably working method is placing your own log/trace information into the server trace file. Before you say that those trace files are way too large and confusing for you, they are not, once you know how to read them and how to filter the stuff you are interested in out. In the forum post "How to filter SwyxWare traces for call routing output of a single call" I have explained already in detail how this can easily be done. So lets focus on how to get your own information into the server trace file. This can simply be done with PBXScript.OutputTrace. PBXScript.OutputTrace "Hello World!" So what should be written into the server trace and what not? And how will I find my own trace output quickly and easily? By taking a look into the server trace file you figure that the SwyxWare traces quite a lot of stuff, not only errors but also tons of other information and events. You should do the same in your own VBScript code as well. Do not only trace errors your run into but also every kind of information that might become useful later on when you have to analyse the call routing if for some reason it doesn't work anymore like the many months before. The more information you place into the trace file the more easy it will become to pin point a problem later on. You might not even have to get into the script and work yourself into it if the traces are already informative enough. Lets assume you have written yourself a VBSscript function to do what ever you need to do, placed it into the Start block and call it later on e.g. in an Evaluate block. Taking all said above into consideration, that following is something like a "best practice" function template in terms of tracing: Function DoWhatever ( Parameter1, Parameter2 ) PBXScript.OutputTrace "---------> DoWhatever" PBXScript.OutputTrace "Parameter1 = " & Parameter1 PBXScript.OutputTrace "Parameter2 = " & Parameter2 On Error Resume Next Dim bReturn bReturn = False ' do what ever your function needs to do ' ... If Err <> 0 Then PBXScript.OutputTrace "Error while doing something!" PBXScript.OutputTrace "(Err) " & Err.Description Else PBXScript.OutputTrace "Successfully did something" End If ' if you "calculate" something, it is always a good idea to trace the result of it Dim sSQL sSQL = "SELECT * FROM MyTable WHERE value1 = " Parameter1 & " AND value2 = " & Parameter2 PBXScript.OutputTrace sSQL DoWhatever = bReturn PBXScript.OutputTrace "bReturn = " & bReturn PBXScript.OutputTrace "<--------- DoWhatever" End Function Lets go through the template, step by step... The first and the last thing you function should do it to trace that you have entered and left it again. PBXScript.OutputTrace "---------> DoWhatever" PBXScript.OutputTrace "<--------- DoWhatever" The arrows should tell you that you go into your function and go out of it again. All trace lines in between these two arrow lines will be made by your function. So they also help to find your stuff quickly. If your function takes parameters it is a good idea to trace them. If your function doesn't work and it get already come crap parameters it is not surprising that it fails later on. PBXScript.OutputTrace "Parameter1 = " & Parameter1 PBXScript.OutputTrace "Parameter2 = " & Parameter2 If you have disabled the standard error handling (will be part of a future blog post) you need to check every "dangerous" call yourself, if it succeeded or not. For example you try to write something into a text file it could happen that the file doesn't exist or is read only. Or you try to access a database which is currently not reachable. So if you check for the outcome of such a call do not only trace errors but also that it succeeded. If Err <> 0 Then PBXScript.OutputTrace "Error while doing something!" PBXScript.OutputTrace "(Err) " & Err.Description Else PBXScript.OutputTrace "Successfully did something" End If If you calculate something within your function, e.g. build an SQL statement to run against a database and use some current values (e.g. the function parameters) to do so, it is a good idea to write the result of this into the trace. To stay with the SQL statement example this will enable you later on to copy&paste the statement from the trace file and test it directly against your database. Dim sSQL sSQL = "SELECT * FROM MyTable WHERE value1 = " Parameter1 & " AND value2 = " & Parameter2 PBXScript.OutputTrace sSQL And finally, if your function returns a value, just trace this value: PBXScript.OutputTrace "bReturn = " & bReturn You don't need to put all trace stuff into your function from the beginning, while you are still developing it. But once it is finished and tested you should put trace output in it. You can't trace too much information, just too few. The more information you trace the more easy it will become later on to identify a problem if the call routing script ceases to work. Enjoy! PS: don't miss to take a look into the ECR Useful Link Collection
×
×
  • 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.