ServiceDesk 4.8.112 Update 08/19/19

Having ServiceDesk work directly with your telephone system is a no-brainer.

What I mean is, if you are not already enjoying such integration, this is something should want, and that you should work to setup in your office.

The two major aspects are integrated CallerID (see who's calling, the status of pending jobs, etc., before even picking up the phone) and auto-dialing (need to call a customer: just click on the number in ServiceDesk, and it's immediately dialed for you).

Until nineteen months ago, it was not necessarily easy to setup all this stuff. Then our friends at Service Company Solutions (SCS) built some new wherewithal on their side; we added some on ours . . . and, based on the combination of that work, you could finally enjoy the power of such integration (and of a great telephone system to boot) as a very easy, virtually turn-key solution (ask them to do it, and they do it for you).

We first announced it here.

This present improvement is specifically for Rossware clients who run multiple business instances, each via a different instance of ServiceDesk (for those of you who not so involved, it may interest you to know there are many who do this). Until now, the mechanism we created to tell the system which particular business instance is being called, as the phone rings (and therefore which instance of ServiceDesk to show the CallerID information within), was not as ideal as many wanted. It depended on the area code of the caller, and that is not always a reliable basis to know which business it is that the caller has intended to call. Now the system makes its determination based on which business telephone is used, which obviously is much more sensible.

If you are one of those multiple-business ServiceDesk users and are using the SCS phone system, please contact SCS and ask them to set you up for these new improvements. From the Rossware side, all you need is to be running from this ServiceDesk release or newer. From the SCS side, they'll be setting you up with a new copy of a little background utility, and updating a little underlying information file.

If you are any ServiceDesk user and are not yet taking advantage of a SCS phone system and its integration with ServiceDesk, I highly encourage you to contact SCS and learn how much their system can do for you.

BTW, let's give a shout out to Brian at SCS. He was the one who engineered the operational concept behind the new and improved scheme.

To finally be able to announce this, I confess lifts a huge weight from my shoulders.

For Rossware's U.S. clients, the Census Bureau provides a raw data source that is perfect for our needs. From it, we are able to mine and process as needed to build each of the custom street files that are part of each client's unique ServiceDesk setup . Years ago we had to pay some moderately significant sums for that data, but for the many years now it's been completely free.

Obtaining Canadian data (in particular, data that has such fields as we need) has been far more difficult. In the very early years, we'd been unable to find any sufficient Canadian data, so Canadian setups were generally done without custom street files. Then, in 2005, we found a data source that had all the fields we needed. It was a sweet day. We were happy. Our Canadian clients were happy. Blah, blah, blah.

Well, we were all mostly happy.

It turned out this data was a bit weak here and there (i.e., missing streets it should have had), and it was inaccurate here and there (claiming falsely that a particular street had a latitude and longitude significantly different than its real latitude and longitude).

Worse still, within a year of first purchase of this data (all Canadian data is purchased), the company that provided it disappeared.

That disappearance was bad.

It meant that our best Canadian data, besides suffering from being a bit weak and inaccurate here and there, over time became increasingly out of date (i.e., none of the newly-built streets were in it).

We did not take this lying down.

It was virtually a yearly ritual for me to spend episodes of at least a couple of days (sometimes several) searching desperately for a new data source (I wore out Google fifteen times over).

Finally, last March (and after truly incredible effort), I found a new source. Also, I verified -- besides being up-to-date -- this new source is strong where the old was weak, and is accurate where the old was inaccurate.

So (you may be wondering), if I found this great new source in March (and I purchased a subscription to automatic updates from that source as well), why is this announcement coming only now?

The reason is because this new source lacks some fields that we've historically used. Those fields indicate the address ranges of each street segment. With that indication, underlying program code is able to precisely "hone" its understanding of which street segment is applicable for any address number, and which particular, full-six-digit PostalCode should be used. Without that element of data, we had to come up with a whole new strategy -- and had to write the program code to implement it as well. .

So that's what's finally been accomplished.

Karie (our outside contractor who does such things) will be re-building data for each of our Canadian clients, based on the new source and new method. If you would like to be nearer to the front of the line in regard to her work, we welcome you to place a request with anyone on our our support team (you can just call if wanted, or email support@rossware.net).

You'll notice a couple of things are different, after you're updated.

First, in the StreetList dropdown, there will only be a single entry for each particular street (previously there could be multiple instances for each instance of the street under varying PostalCode segments). At the least, this fact of seeing only a single entry for each street will make selection of the desired street easier and faster.

Second, the quantity of characters as shown for the PostalCode will vary among the listings. The reason is because each particular street may have multiple entries in the underlying data, and each of those multiple will a PostalCode that is distinct from other listings for that same street. The listings that you see in the dropdown will only show the extent of PostalCode  that is common to all of the underlying listings for each such street.

Third, when you pick your street from the dropdown, you will usually see a list of PostalCodes appear immediately to the right:

Your task then is to pick the particular PostalCode that goes with your customer's actual address.  The system will then do the insertion, including grid reference, and so on. (The only exception from seeing that side-list of PostalCodes after street selection is if there is only a single instance of that street in the underlying data; if that's the case, you will not see a list of PostalCodes appear, for there is no need for it.)

Fourth, in the absence of address-range information in the new data source, there is no longer any built-in verification that the address number that you've typed is valid for the street and PostalCode that is picked (it's something that simply cannot be done, based on this new and best data source that we've been able to obtain, for Canada). Because of this, there is now all the more reason why Canadian users, especially, may want to employ the built-in and Gold-Quality Address-Verification service that was announced here.

We hope you Kinookians will find a level of enjoyment in this new data that is at least commensurate with how hard we have worked to provide it to you.

Please let us know.