How to Assure Your Hierarchical Structure at ServicePower Meets SP-DispatchLink Expectations

In May of 2015 Rossware introduced the Ver. 5.x series of SP-DispatchLink (SPDL). This series abandons ServicePower’s (SP’s) old FTP-based communication channel, and employs its new web-services channel instead.

There is a peculiar feature in how SP setup for servicers to categorize their organizational structure. Whereas ServiceBench generally has you simply define a set of geographical zones (each particularly defined as a set of zipcodes), SP set out with a much more elaborate vision – thinking they would allow you, within their system, to setup a very hierarchical structure.

To be specific, they envision a potential for something like this:

If you look carefully at the above, you will see there are five levels in the hierarchy, and (as envisioned, at least) it positively does not well fit with any structural definition that we wish to convey to SP. In fact, we just want to define a set of geographical zones as applicable to you, as a particular servicer (arguably, perhaps, that makes for two levels in a hierarchy: you as the servicer, with your set of zones under you). Regardless, we have to work with the structure SP has defined. For such reason, we are forced to use their levels. The trick is we turn their first two layers into a single pipe (Servicer/Office), equating that one pipe to you as a single servicer. From that point downward, we branch into multiple pipes, where each such pipe is built from its own and single stack of SP’s layers three, four and five. Each of those (essentially, it’s an Area/Group/Technician stack) we treat as a conventional zone-equivalent:

Please note that, in spite of the name as given to nodes at the bottom rung in the hierarchy (i.e., “Technican”), we have no intent to treat that node as any reference to any particular technician. You may pretend that the title is “X” or anything else you choose. We are not using the node in the manner SP’s original designers may have intended. Rather, we are combining each in its own stack (with its own Area and Group above it) to form what in essence becomes (and for all practical purposes) the working equivalent of a geographic zone.

Our guess is that, in making its structure, SP designers had some more grandiose purpose in mind than we really want to make use of. Regardless, the above scheme works to simplify for our purpose, though with a small caveat.

It turns out SP’s online web interface allows you to name each node in your hierarchy according to pretty much whatever naming scheme you might choose. SP-DispatchLink is not so flexible. It assumes your hierarchy is setup with each node named according to a very particular scheme, as follows:

The top node (Servicer) is basically your login ID, and you needn’t worry about particular naming in its regard. For each other node, we’ve placed its included expression in quotes, because what’s shown is precisely what such names in each such node must have, and for as many zone equivalents as you care to setup (i.e., the Area1/Group1/Tech1 stack is made to be the equivalent of your Zone-1, the Area2/Group2/Tech2 stack is made the equivalent of your Zone-2, etc.). Please note a few matters:

1. You’ll see in your online setup web interface that nodes at the bottom three levels have both Names and Keys. Both should be set to match the above-displayed expression scheme.
   
2. In its web-services, SP includes “transactions” by which we may, supposedly, create precisely the above structure for you via automation. We have been sad to discover that, though provided (and though we in fact employ them), those transactions have a bit of a “hit-and-miss” operative effect (some seem to work, and some do not). Perhaps someday all such transactions will work consistently. Until then, you will need to use SP’s provided online interface to assure your structure matches the above, and for each of the zones that SPDL will be uploading availability information upon.
   
3. There is another web-service transaction that is fully effective, and it will save you a significant amount of work. Specifically, there is a transaction that allows us via automation to inform SP of the particular zipcodes as covered in each of your zone-equivalent stacks (as pulled, naturally, from your ZoneList.txt file). Given this, assuming you have created a suitable ZoneList.txt file, there is no need for you to manually maintain zipcode lists via your SP online interface.
   
4. Such information only uploads when, from within the SPDL utility, you click on its “Upload Node Structure Definitions” button. Be sure you do that before your initial use of SPDL, and as often afterward as you have occasion to do any editing or restructuring of your zone structure as defined within your ZoneList.txt file.
   
5. If you run multiple ServiceDesk instances and each for a separate business instance, it’s possible you will nevertheless have each of these business instances setup under a single ServicePower account. If so, you will need to modify the above-described zone-equivalent naming scheme so as to distinguish Zones 1 through X as applicable to Business-A from Zones 1 through X as applicable to Business-B, and so on. We have provided a mechanism to directly accomplish this. Quite simply, for any business instance (in particular, from within the instance of SP-DispatchLink that is running for that business) you may direct the utility to modify the above described node names with a suffix of your choice, thus enabling a ServicePower-side distinction between Zones 1 through X for one business and Zones 1 through X for another. It’s done by adding text (and for whatever suffix you choose) within this little window of the utility:
   

What this will do is cause SP-DispatchLink to use altered node names, with inclusion of your indicated suffix. Specifically (and as an example), with the above-indicated suffix, instead of using node names as follows:

• ‍Area2, Group2 and Tech2
• ‍SP-DispatchLink would instead use these node names:
• AreaLA2, GroupLA2 and TechLA2
• ‍If you need assistance, of course, our staff is here to help you.

‍