ServiceDesk 4.5.29 Update 08/10/11

Edited

Happiness in Smiley Faces

If you examine the following image as extracted from a DispatchMap, you'll see some objects you've not seen before:

 

If those new objects are not jumping out at you, look specifically for smiley faces (though, actually, not all are smiling).  There are three of them.  They are the new feature being announced here.  What are they for? 

Quite simply, they are to equip the person who arranges your technicians' scheduling and routes with a feedback mechanism that encourages real diligence in achieving optimization.  It makes a lot of difference to your operation's profitability, after all, if those routes are efficiently arranged.  It makes a huge difference.  Since pretty much the beginning in ServiceDesk, we have provided mileage figures within the DispatchMap, hoping operators would use such numbers as a means to self-score their finesse, seeking (we've always hoped) to whittle each tech's average-miles-per-job figure to the smallest level possible.  But (and alas), the sad news is many simply ignore those figures.   For such reason, something more concrete has been needed by way of encouragement -- to reach into the operator's psyche, as it were, with a more pungent encouragement to optimize. 

That's exactly what the smiley faces are for.  Next to the mileage-summary at the bottom of each tech's listing of jobs, you may now have a smiley face (varying between happy, neutral and sad) that applies to that particular tech's route.  In the top-left corner of the map as a whole is another, larger smiley face, which similarly varies in expression depending on whether the day's entire roster of jobs meets specified targets for mileage efficiency. 

Based on the above, anyone in the office can have instant and obvious visual feedback regarding whether efficient routing has been achieved. 

Even more concretely, they can be encouraged to fix things.  Just a glance at the frowny face in the above image, for example, suggests that Arthur Manoogian's route needs a fix.  Look over at his route, and you can see, instead of sending him from the Smith job to Bazooka to Ross, it would be more efficient to put Ross in the middle.  A quick mouse action would do this . . . and, instantly . . . his mileage-summary's frowny face would turn to a smile! 

To implement this new capability requires a little setup on your part.  Specifically, ServiceDesk cannot know what "mood" to put on a particular smiley face without knowing what is a reasonable mileage target, for efficiency, as applied to the tech involved (techs that work in predominantly rural rural areas will obviously have higher per-job "par" figures than those working in condensed metropolitan areas).  You're going to provide that information to ServiceDesk in a new box as available within the Technician-Properties window of the Settings form.  To bring up this window, go to your ServiceDesk Settings form (Ctrl-F1), look in the Tech-Roster section, and click on the technician of interest.  That opens his Properties window.  The new box to fill-in is shown here:

Just to be clear, what we're referring to here is what you want your operators to consider as a par figure, for the tech involved, in terms of average per-job-miles in his route.  For example, if you were to estimate that 80 miles is typically about what the driving distance should be for ten jobs, you'd figure an average of 8 miles-per-job, and place that figure (i.e., 8) into the above box.  

Beyond setup is the matter of how the system actually works, within the DispatchMap. 

In such regard, please be aware that smiley faces will not appear for any tech for whom you have not specified (as per above) a "Target average miles" figure. 

But how does the system decide what mood to put on the face?

Very simple.  If, for the tech's actual route as planned, the system predicts an average miles-per-job figure that's within 10% of the tech's target figure, ServiceDesk will present a neutral face for that tech.  If the predicted figure is better than that 10% margin, it will present a happy face.  If it's worse, it will present a frowny face.  A similar strategy inheres for the larger, roster-wide smiley face in the Map's top-left corner.  The difference there is that it's roster-wide comparisons that are made, so you can judge if on average a particular day's routes merit a smile, a neutral face, or worse. 

As a further aid, the system offers supplemental information if you float your mousepointer over one of the visual indicators.  If you float your pointer over a tech's mileage summary area (or the smiley face itself), for example, you'll get a tooltip that informs you of what is the target figure for that tech (for easy and quick comparison to the actual/operational figure):

Similarly, if you float your pointer over the smiley face in the map's top-left, you'll get a cogent summary regard the data underlying its "mood:"

We hope you'll make extensive use of this new tool, and profit exceedingly from it. 

Installment Two on Improved Specification for Tech's Begin-Route and End-Route Locations

Since we added automated route-optimization via-call-to-MapPoint, some few years back (see entry here accompanying Rel. 4.3.76), there's been a mechanism to specify, for any given tech, whether you want the system to figure his driving begins at his home, at the office, or at the first job otherwise picked for him.  Same thing, essentially, in respect to where his driving ends for the day (both specifications can be referred to as "route end-nodes).  This specification was actually part of the route-optimization dialog.  Just a few releases back, though (see entry accompanying Rel. 4.5.25), we announced an improved method that makes the specification independent of the routine dialogue. 

It turns out that was a short-lived improvement, for it's superseded by what's announced here.  Both prior incarnations of this feature saved the relevant settings to the applicable station's local registry, which meant it was a local setting only, and even if set at one station, there'd be no effect on what happened at others.  For the new "Smiley Face" feature, we needed better than that.  In fact, prior to this release, all of the per-tech mileage estimates have assumed each tech begins and ends at the office (regardless of settings for route-optimization) -- an assumption that in this age is increasingly untrue.  We needed to fix that to make this feature all that it should be, and with such expanded use it was also important that such specifications take effect throughout all stations in your network, and not just locally. 

That is the precise improvement that's being described in this entry.  A few short paragraphs above (scroll up a tiny bit to see), we highlighted a particular new control within the Settings form's Tech-Properties window.  Right next to it are two others, now highlighted here:

As above hinted, this is now the place where you can make specifications system-wide, regarding expected end-nodes in a tech's route.  Indeed, though on the face of the new controls it appears you can only select from among two options ("Home" or "Office"), you are in fact free to select neither, which in effect gives you a third choice.  (if you've prior selected one and want to de-select, just click again).  If you do select neither, the system will refrain from implicitly adding such a leg to the tech's route.   

Regardless of what you pick for a tech, the system will apply your selection when: (1) calling to MapPoint for its automated route-optimization; (2) calling to MapPoint to load and display a route; (3) calling to GoogleMaps to load and display a route; (4) exporting  route data to a file; and/or (5) calculating a tech's predicted total miles and average-miles-per-job. 

Please finally be advised that, from this release forward, ServiceDesk will ignore any such local specification on a tech's route-end-nodes as was formerly provided.  If you have in the past been relying on such specs, we strongly suggest you go into your Settings form, click on each tech, and re-specify what's wanted for him.