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:
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: