ServiceDesk 4.8.80 Update 02/02/19

ServiceDesk has had simple and base-level verification-of-addresses since Day 1. It's based on a couple of factors. One: when you pick a street from the dropdown StreetList, you know the insertion is a true street name, and is properly spelled. Two: immediately upon your pick, the system checks to see if the address number that you've provided fits within the range of valid numbers for that street, and warns you if otherwise.

In spite of those basics, a lot of people manage to put in addresses that are either not: (a) valid at all; or (b) in such form as can be automatically digested when you or a technician seek to load such addresses into MapPoint, GoogleMaps or Bing. Either situation can lead to a lot of frustration, and to seriously-compromised productivity.

We've made a solution.

You might have noticed this solution was somewhat previewed when, some six weeks back, we introduced telephone number validation. For that, we added a place in the Settings form where you can activate the telephone-number-validation feature. Right below that, we advance-placed a similar settings area (though it was inactive until now) for activating this new address-verification feature (i.e., we knew we had it coming):

As with the telephone-number-validation feature, you can choose to resist using this feature at all (the default), to use it solely on the basis of volitionally making a request when wanted (that's the "ad hoc" method); or you may choose to have the verification happen for you automatically in the background.

As with telephone-number-validation, there is a fee for this online service. Happily, this one is small: just $0.009 per verification incident. That is nine-tenths of one cent.

If using the ad hoc method, you can initiate a verification request by doing a Ctrl-Click on the address box in either a Callsheet or JobRecord (it's the same mouse action as is done on a telephone number box to initiate a telephone-number-validation request).

If using the automated method, validation may be automatically triggered at any of several points, including:

• When picking a street from the dropdown StreetList

• When using the ItemLocate or ZoneSchedule functions

• When otherwise creating an appointment

• When inserting address information from a prior job

• When doing the Job/Sale transition from a Callsheet

Automated verification will be invisible to the user, unless the result is to indicate that an address is not valid. In that case, a message will pop up similar to this:

It is then, obviously, up to the user to obtain better address information from the customer.

A reason for having this automated check occur at so many potential points is to assure that a CSR who is potentially ignoring a bad address situation gets repeatedly pestered, Regardless, please rest assured that just as soon as any address verifies as valid, the system so marks it (in a behind-the-scenes location), and further automated requests are not made on that item (unless the existing address is edited, in which case it's fair game for automated checking to again occur).

In contrast to the automated method , if you invoke an ad hoc request (which you can do either with the ad hoc of automated setting), and if the verification request returns with an indication the address is indeed valid, you'll receive an explicit message so indicating, similar to this:

We believe, if you harness this new and powerful tool (especially if you harness it in automated mode), you'll find the frequency of addresses that cannot be parsed into external mapping, route optimization and route guidance (in particular and especially for your techs using Mobile) will be dramatically reduced. The frequency of incidents should indeed be reduced to near (and perhaps absolutely at) zero.

If you did not know, you can create and maintain a list of part numbers on which, when you are ordering or otherwise processing with such numbers, ServiceDesk will give you a customized alert (it's called the "PartsHotList")

You can do similarly for model numbers (it's called the "ModelsHotList"). However, until now this list was triggered for alert only within a very limited set of operations. Specifically, it was triggered only in the context of operations within a UnitInfoSheet (UIS). Now it checks much more broadly. In particular, it additionally checks when you:

• create or process an internal part order

• schedule from a Callsheet that has a model number in its "ExtraNotes" (as, typically, inserted there by one of the DispatchLink utilities)

• operate with SD-MobileLink Ver. 2.0.96 or above (that version and forward will, on any applicable dispatch, upload to your techs an AttnNote advising when any ModelsHotList matter is relevant).

As another improvement, the system will now perceive a match from a presumably complete number as applicable to a machine you are working on, to a listing in your ModelsHotList that may not include all of the extended digits.  Thus, you can have fewer listings in your ModelsHotList, including just enough digits to assure you narrow down hits to just the models you want, and just that one listing for the entire series.

What about this saving of lives thing (i.e., in this section's header)?

Well, suppose there is a manufacturer recall on a safety defect. In your ModelsHotList, you put in an entry for the model series that is involved. Thereby, when dealing with such a model, you and your techs are informed. On that basis, you volunteer to your customer to take care of the recall issue -- potentially indeed saving a life, and at the very least gaining your customer's gratitude.

Many times we've added a feature here and another feature there, and it does not occur to us (at least not until after a clever user points it out)  there is potential collision between the two. Typically, this is a collision we would have coded the system to address -- if only we'd realized it existed. However, we did not realize it, and sometimes it's amazing how long the situation can persist before we become aware.

In this case we have for many years had a feature where, as you're checking in parts via the F8 form, the system checks behind-the-scenes to see if any more parts are needed on the job. If it's indeed the last needed part for the job, the system will generally (assuming the job is not already scheduled, and assuming it is not linked to other JobRecords that are potentially still waiting for parts) create an invitation for you to consent for the underlying JobRecord being placed into Working-To-Schedule status, and, potentially (if you've opted to use such mechanisms) for the customer to be invited to invoke scheduling via automated means:

Also many years ago, we added a feature whereby you can designate jobs as being for in-shop repair (i.e., as opposed to the more typical on-site work at a customer's location).

Here's the collision. It doesn't make sense for the standard, last-part-for-job-is-being-checked-in invitations to be made -- where it's a shop-job.

Many thanks to Heather at J&M Appliance for pointing this out.

Now, instead of being presented with the above dialog when a last-needed part is being checked in on a shop-job, you'll see this instead:

This obviously makes much more sense for the situation.