ServiceDesk 4.8.268 Update 12/05/22

We begin by offering a little history on claims. This will provide background for the new item we're about to discuss. (If you wish to skip this history, please advance to the bold-print paragraph, below).

Until the era of PCs, warranty claims had to be manually filled-in on multi-page/carbon-copy form-sets (usually the NARDA). You could put a form-set in your typewriter and type, or you could hand-write, pressing hard with your pen because there were (if I recall correctly) seven copies to get through. When you'd finally completed one or more form-sets (one for each claim), you'd then postal-mail your claim(s) off to the responsible manufacturer.

Yes, it was painful.

At least in the home appliance industry, Maytag was the first to allow claims to be made electronically (this was before Maytag was acquired by Whirlpool). You'd use a PC to compile claim information and save it in an electronic file (this file had to fit a particular format specified by Maytag). Then you'd upload your file to Maytag via an electronic bulletin board. Very probably, you'd be using a dial-up modem.  This was before creation of the world-wide-web, which led to the creation of websites, and of what we now think of as the "internet."

Naturally, we at Rossware created a mechanism in ServiceDesk to create these files. However, it was then up to you, the user, to upload them (via that clumsy electronic bulletin board) to Maytag.

Of course, the world advanced. Indeed, just as the true internet was beginning to gain traction, a company called Key Prestige International (KPI) was formed. Among other things, KPI created a website via which you could log into your KPI account, and from there (and instead of needing to use a clumsy electronic bulletin board) very easily upload claim files (these had to be in KPI's specified format, naturally, and applicable to such clients as KPI had taken on).

Then along came ServiceBench -- which, in regard to claims, did essentially the same as KPI. In other words, ServiceBench built a website that you could log into and, among other things, use a provided interface to upload claim files (these had to be in ServiceBench's specified format, of course, and as applicable to clients ServiceBench had taken on).

Naturally, Rossware created a mechanism in ServiceDesk to create claim files in both the KPI and ServiceBench formats. It was a pretty big advance, especially because ServiceDesk made it easy to create these claim files. Regardless, it was still up to each user to then take the next steps: specifically, log into the applicable website, navigate to its claims uploading interface, select the file or files to be uploaded, and upload.

Commonly called the "batch upload" method, this was the "state-of-art" method for a few years. Certainly, it was a big advance over postal-mailing of laboriously-filled-in paper claims. Regardless, it was still not good enough.

The real revolution came when, in cooperation with Rossware, ServiceBench created a system whereby ServiceDesk could directly send claims information to it, for direct processing. In other words, we eliminated any need for claim files, or for you to be involved in any separate upload effort. All such separate work was eliminated. Now you'd simply perfect your claim information in ServiceDesk, select "SB-WebDirect" as your claim-sending method -- then . . . bada bing bada boom . . . your claim information transferred directly into ServiceBench's system!

It was a great revolution.

It was indeed so great that KPI (which had in the interim changed its name to ServicePower) soon felt anxious to follow with its own similar, direct-claims-transmission ability.

But, KPI/ServicePower did it somewhat differently.

Whereas ServiceBench designed its system to receive claim information directly, and as claim-format direct-textual data (using, as its communication method, the HTTP internet protocol, later advanced to HTTPS), KPI/ServicePower was seemingly unable to move past the notion of claim files. Accordingly, to avoid need for you to manually upload such files, it simply made a method for ServiceDesk to instead upload them for you. For this, KPI/ServicePower designed its system to use an internet protocol called FTP (stands for File Transfer Protocol).

Ever since, our method of directly transmitting claims to ServicePower has been to behind-the-scenes create a claim file first, and then FTP-upload that file into a claims bucket that ServicePower sets up for your account.

This long-used FTP-based method has had some disadvantages. Happily, ServicePower recently offered a new channel. This new channel allows us to upload direct claims text via HTTPS instead (i.e., just like it's long been done with ServiceBench). With this release, ServiceDesk offers you the option to use this new method.

A small benefit in this method is you should be able to review your claims, within ServicePower's system, immediately after transmission (with the old method, claims would not show up -- if they showed up at all -- until after an uncertain period of delay).

A much larger advantage is enhanced communication. We'll explain.

When a claim file uploads via FTP, the only information that comes back from ServicePower is if the file successfully uploaded and dumped into your claims bucket. ServiceDesk gets no other information, and so cannot provide you with any greater information.

When a claim uploads to ServicePower via HTTPS, ServiceDesk immediately gets back much more meaningful information.

First, and in particular, it learns whether the claim itself -- as a claim -- successfully entered into ServicePower's claim-processing system. In contrast to this, under the FTP system, we only knew if a claim had dropped into your ServicePower claims bucket. We did not know more. More particularly, we did not know whether, after such dumping, ServicePower's system was then able to pull the file out and successfully parse its contents -- as basis to then insert such information into its claims processing system. You could only learn these facts, after the behind-the-scenes upload, by logging into your ServicePower account to check on the matter.

Beyond learning immediately whether your claim has successfully entered into ServicePower's claims-processing system, this new HTTPS method also allows us to know whether that initial entry was scrutinized as being "Complete" or "Incomplete."  If scrutinized as "Incomplete," we further learn the reason or reasons why it was scrutinized as incomplete.

And here is the great beauty. ServiceDesk will, as part of this new HTTPS path, immediately report back to you all of this information. It's something that you'll surely find very useful, and was simply not something we could do under the old FTP method.

PLEASE NOTE: You may have been setup by ServicePower to use credentials (username and password) for FTP purposes that are different from your standard ServicePower login credentials. Please do not insert any such FTP credentials into your ServicePower HTTPS-claims setup. They will not work there. For your ServicePower HTTPS claims setup, you should use exactly the same credentials as you are using to log into your ServicePower account.

We will likely discontinue the old FTP option once we know that several users have switched to using the new HTTPS method, and are confident that any kinks have been worked out.

Additionally, though the other entities that you see in the above list (e.g., Dacor, Fisher & Paykel) only receive compiled claims via the batch-upload method, it's possible we should remove such methods, as long-since superseded for ServiceBench and ServicePower. We'd needed to maintain those paths for a while because some folks, used to using them, were resistant to change. But "a while" passed a long time ago. It's now been years, and we suspect no one is still using them. If you disagree, please let us know. Otherwise, we'll likely drop those older methods as well.

Introduced some two-and-a-half years ago (with initial announcement here, and enhancements described here, here, here, here, here and here), whole-roster optimization uses artificial intelligence (AI) to study all the jobs that are on your roster for a day, all the techs that you have available, and decide which routes involving which techs will be most optimum. The full manual is here.

A couple of years prior to that we'd created a mechanism by which you may associate particular techs with particular zones (with initial announcement here, and a significant enhancement described here).  

A bit later (and as something of a corollary) we provided mechanisms by which you may associate machine types with departments and with skills required (as described here).

Anyway, this is all by way of context to explain that you may now, in regard to zones, limit your GraphHopper whole-roster optimization to just the particular zones that you want to have AI-optimized.

To do this, just create a file/document that has each zone number that you want to limit your GraphHopper optimization to include. You may (if it's your preferred method) use Excel and place each zone number in its own column, like this:

Or you could just open WordPad (or similar) and type each desired zone-number with separation by a comma.

Either way, just save your file in .csv format, and in ServiceDesk's \sd\netdata folder under the filename: WhchZonesToOptimize.csv

ServiceDesk will see the file, and then know to limit your GraphHopper optimization work to just the zone numbers that you have listed in it.

In particular, it will only work on jobs that are assigned to those zones, and will only involve such techs as are (in your WhchTechToWhchZone.csv file, see here) indicated as working in those zones.

I don't know why in the heck we did not think of this one right from the get-go.

I also don't know why (at least to my knowledge) none of our users suggested it.

It seems so obvious, in retrospect.

As it happens I (Glade Ross) was personally making use of a QuickPics image that I have in my test ServiceDesk setup. Seeking to use that image, I had a natural urge to copy it into my Windows clipboard, so that I could then paste elsewhere from there.

I right-clicked on the preview pic, and there was no option to copy.

Huh!

It should have been there. Intuitively, it positively should have been there!‍

Well, that function is there now . . . as it should have been all along.

We faced a problem last year (described here) where Microsoft's email system (it's called Office365, which you likely know if you use it) was intermittently refusing to complete email requests.

Well, it happened again, and we've provided solution again, with this update.