Please note this manual has a companion/counterpart in the Auto-Dialer Handbook. Arguably, one handbook might have incorporated instructions to cover both areas. However, they are rather different animals and . . . well . . . circumstances simply did not evolve that way.
Getting Caller-ID information integrated into your ServiceDesk call-taking screen is powerful. Before even picking up the phone, a CSR can easily know who is calling, past history and current status on any pending job. Potentially, the phone may be answered with a greeting such as:
You might imagine: that kind of greeting could impress your customer very much.
Of course, integrated Caller-ID also allows you to effortlessly and perfectly insert telephone numbers — simply for the sake of getting them into Callsheets, where needed.
Later chapters will describe how to get Caller-ID information into ServiceDesk. In this chapter, we’ll describe how it appears, and how to use it.
Basically, if the phone is ringing, you want to place the Windows focus into ServiceDesk’s first-vacant Callsheet (the shortcut command by which to instantly get there, from any other Callsheet, is Ctrl-End; if you need to first instantly get the focus into your Callsheets, hit F1).
When the first-vacant Callsheet has the Windows focus, and when Caller-ID info is currently offered, it will display such info in this fashion:
To make direct use of the displayed name, simply click on it. In response, the system will insert the name into the CustomerName box. This, obviously (besides getting the name into the box), will trigger a CstmrDbase search on that name, just the same as if you’d typed it.
Similarly, to make direct use of the displayed telephone number, simply click on it. Just the same as clicking on the name, this both inserts the text, plus automatically triggers a CstmrDbase search.
Usage is that simple.
This company specializes in creating hardware that’s designed to pull Caller-ID info out of the stream of data that’s associated with incoming phone calls — in particular, in a context that makes the data available to software systems running within local PCs. It’s their hardware that we first created program code to work with.
If you are interested using a CallerID.com solution, we suggest you go to their website and review their offerings. They have systems that work with old-fashioned telephone lines and ones that work with more modern VOIP-based systems. If you need more explanation than you can glean from looking directly at what is online-presented, their personnel are very accessible and easy to talk to.
If you decide you want to purchase any CallerID.com device, Rossware can get you a 10 percent discount by placing the order for you.
In terms of interfacing with your computer system, CallerID.com hardware falls into two broad classes: (1) devices that connect directly to a particular PC (and thus only provide info to that PC; and (2) devices that connect to your network via an Ethernet port (and thus provide information to any computer that’s in the network).
Many years back, when we first created integration with CallerID.com devices, they only offered hardware in the first category. Naturally, ServiceDesk users did not want to buy a separate Caller-ID device for each ServiceDesk station. So, we made a system whereby the particular computer that connects to the device may offer to share its information with others in the network, and others in the network can look for (and receive) that shared-by-a-particular-station information.
Setup for the above is (as is setup for all elements of Caller-ID integration) managed via ServiceDesk’s CallerID-Setup interface. In particular, it’s done via the set of selections shown here:
When any of the above options are selected, boxes appear within the body of the interface, which include instructions on what needs to be filled in, so as to enable the intended functionality. We think, going forward, few people will be purchasing the older style hardware that corresponds with these options, so will not delve more into instructions in their regard at this time.
The other method for using a CallerID.com device is via any of their (more modern) devices that are designed to connect directly into your network via an Ethernet port. These are super-easy to setup with all of your stations, and are a wonderful way to go. For this option, you’ll of course use this selection:
If you do not know, Service Company Solutions (SCC) is the company that provides the Appliance Repair BlueBook and MyPartsHelp (solutions Rossware systems also integrate with, which are likewise also specifically tailored toward appliance service companies). In 2018 they began offering full-featured telephony systems, and we created integrations with these as well.
The thing that is particularly nice about our integration with SCC telephony is it works simultaneously for both auto-dialing and Caller-ID integration, and it’s near turn-key in nature.
There are two main elements in making this integration work.
First, SCS personnel will place a little application into the applicable \sd folder (same as where the Servdesk.exe application file is installed). This little app is called “SCS-Listener.exe.” Its purpose is to act as the communicative messenger, between the SCS system and ServiceDesk. In particular, when the SCS system receives an incoming telephone call, it opens an instance of the SCS-Listener, and simultaneously provides it with applicable Caller-ID info. The SCS-Listener, in turn, takes the info, and provides it to ServiceDesk.
Second (in regard to setup), either you or SCS personnel will (at each ServiceDesk station where integration is wanted) go into its CallerID Setupinterface, and there select the radio button that’s pointed toward here:
With that button selected, you’ll see boxes appear in the body of the interface that request just two values: (1) the IP Address of the station involved; and (2) the Port Number that you wish to have the SCS-Listener app use when communicating to that station.
In regard to the applicable IP Address, you can easily determine what is any particular station’s IP Address assignment by opening a command prompt and running IPConfig.
Generally speaking, the router that manages a network assigns each device in the network with this identifier. Absent optimum configuration, it’s possible that after a router re-boot or if a new router is installed, IP addresses as assigned to each station may be different than they were before. If this happens, the corresponding setting, in each CallerID Setup interface, will need to be changed to match (also, configurations should be changed to prevent the same event from again occurring).
In regard to picking a Port Number, it is technically permissible for you to pick any number that is not otherwise in use within the involved Windows desktop, that is valid as a Port Number, and that is unique to the station (in other words, each ServiceDesk station must pick a Port Number for this purpose that is different than Port Numbers picked by any other station).
Generally speaking, Port Numbers are used as a method to identify a particular channel of communication (it’s like a title or identifier for a channel), and any number between 1 and 65535 may potentially be used for the purpose. However, numbers below 2500 are often used for fixed purposes within PC environments. For purposes of Caller-ID communication, Rossware systems limit your choice to a range of 2500 to 65528.
There is a reason this uniqueness is important. We’ll explain.
When the SCS-Listener app is called by the SCS telephony system, we want it to send Caller-ID info to the particular ServiceDesk station where the phone is ringing. In particular, we want it to send such info to that ServiceDesk station, and not to others in the network.
This is where, in particular, use of this Port Number selection becomes hyper relevant. It’s by using (choosing to speak through, so to speak) the Port Number that’s been picked for a particular station that the SCS-Listener app manages to talk directly to that station, and to that station alone.
You might wonder: how does the SCS-Listener app know what Port Number has been picked by the applicable station, so as to know that’s the one it should “speak” through. It’s done via the Windows System Registry. Basically, each station saves the Port Number that’s been picked for it into a section of the Registry that is unique to that station (for clarity, we are using the word “station” here in a manner that has meaning identical to Windows Desktop instance). When the SCS-Listener app runs, it is called to run by a softphone instance that’s running in the same Windows Desktop as is the ServiceDesk station of interest (this is true whether it’s a virtual station or a true physical one). Thus, it runs in the same processor (virtual or physical) as the applicable ServiceDesk instance, and accesses the same Windows registry. So, when it looks for the applicable Port Number setting in that registry, it acquires exactly the same number as was set in the applicable ServiceDesk instance.
Obviously, it could be somewhat of a painful management burden, if you were seeking to manually keep track of each Port Number used in each station, so as to assure that, as you’re assigning a Port Number in a new station, you do not again use a number you already used. So, we made little cheat. It’s enabled by the next element in setup.
Third, SCS personnel will install a file in the \sd\netdata folder on your ServiceDesk server. The file is called PortNumberScheme.csv. It contains a list of Port Numbers that may potentially be used. When a Port Number needs to be picked in the ServiceDesk CallerID Setup interface, the system will behind-the-scenes look in this file for an available number. Once that number is saved, the system will likewise write to this file to keep track of that fact that number is in-use, so that another station will then refrain from picking it.
Be assured, the system does behind-the-scenes housekeeping too. If a station formerly picked a particular Port Number (and claimed it in the file), then for some reason later picked a different number, it will automatically remove its claim from the prior-picked number. Similarly, if you even try to pick a number that has a claim on it as made by another station, the system will not permit it, and will explain the reason why. The one element of housekeeping we’ve not built in is to remove claims by retired computers or users (claims are in fact made on the basis of Windows user names). It’s possible that after several years, if you look in the file, you’ll see a bunch of Port Numbers are claimed by user names that have long been absent from your setup. If so, you can simply manually edit so as to remove such stale claims.
So long as you are only running one business instance of ServiceDesk in your network, SCS-Systems integration setup is just this simple.
Why did some users have to throw this at us?
Assuming you are not running multiple ServiceDesk businesses in one network, you don’t need to worry about this section.
We wish we did not need to worry, but . . . darn it . . . we must.
This was a bit of a tough situation to work out, but we’ve done it. Here are steps that must be taken in setup:
The first column should contain the name of each ServiceDesk business that will be operating in the network. This field is for human-reading/reference purposes, and is not machine-matched to anything, so you may take liberty in how you spell, capitalize, etc.
The second column must contain a particular string and must be a precise match to the needed string. Within ServiceDesk, we employ use of what we call a UniqueFileName, and this is what must be inserted into this field, as applicable to each business in question There are a number of ways you can determine what is the UniqueFileName as connected to a particular ServiceDesk business. Perhaps most straightforward is to open the Servdesk.inifile as present in the \sd folder as applicable to the business in question. Its second line will contain the applicable UniqueFileName.
The third column is where you indicate which area codes are applicable to each business. Please simply separate each of multiple area codes by a comma. Please understand these area code listing will be used to identify for a user which business is more likely the applicable one, as connected to an incoming call, and while there is no mechanical impediment against listing the same area code for multiple business line-items, there is also no benefit. The system is going to flag as likely applicable the first business it sees, in the sequence, that lists the area code that matches an incoming call. For this reason, it will make best sense for you to list any area code that potentially fits to multiple businesses solely to the one that is more likely to be involved, with that area code.
Then fill-in other values as appropriate. Please note, with this box checked, the system will no longer be looking for a vacant Port Number (and claiming a Port Number as used) on basis of a PortNumberScheme.csv file located in the \sd\netdata folder as applicable to the particular business. Rather, it will be using a PartNumberScheme.csv file that’s common to each of the multiple businesses, and located specifically at c:\sd. Please also note the claim will not be based solely on the applicable Windows username (as it is in standard configuration). Rather, it will be based on the applicable Windows username in combination with the applicable business UniqueFileName. Thus, a single user may claim a particular unique number in connection with business-A, a different unique number in connection with business-B, and so on.
In addition to this PortNumberScheme.csv “claim” to a Port Number being modified (to indicate the particular ServiceDesk business instance that’s involved in the claim), the Key as used in the saved registry setting is likewise modified — so as to include a reference to the particular ServiceDesk business instance that is involved. (Thus, for example, instead of a Key simply being “PortNumberForScsListenerToUse,” it will instead be rendered as something like “PortNumberForScsListenerToUse-Aardvark.” This is critical. When, in the SCS-Listener.exe app, a user picks the ServiceDesk business instance to be targeted for receiving the Caller-ID information, that app must have means to know which Port Number to use — so as to target the intended user and intended ServiceDesk business instance. It’s by looking for this particular modified registry setting (i.e., which includes reference to the particular ServiceDesk business instance) that it manages to “know” this information.
As you can see, the likely-applicable business (likely applicable on basis of area code) is selected. Regardless, a user can pick any of the listed businesses, and the applicable Caller-ID info should then be sent to the corresponding-instance of ServiceDesk (to there appear in standard fashion). In fact, if a user wants to pick the business already selected, he/she can simply hit Enter on his/her keyboard.