How to Manage Variable Service Call Rates

We begin with clarification. The topic in this section does not involve such varying rate setups that you may have with high-volume-clients for whom you setup Quick-Entry-Templates ("QET"s). For those, each rate setup may be uniquely specified within each corresponding QET.

What we're concerned with here is if you wish to have varying rates on jobs performed for more ordinary customers (typically COD), with such rates depending on such factors as distance from your office, the community where a service call is to be performed, type of machine to be serviced, etc.

Miles-Determined S.Call Rates

Some servicers want to vary their service call amount based, simply, on distance of each job from the office. Setting up for this is easy. Simply create a file/document that indicates your miles-based formula (or, potentially, kilometres-based if you're in Canada; please see more below). The document should have three simple lines of text (and optionally two more), as follows:

  • Quantity of miles that are included in your base service call amount, without added fee (can be 0 if you prefer)
  • In dollars, amount of your base service call fee
  • Add-on amount for each mile that is beyond the quantity included in your base amount
  • Optionally place the word "True" if you want to have the calculated amount rendered to the penny, without rounding to the nearest whole dollar
  • Optionally place the word "True" if you want distance to be based on Google's true-driving-distance calculator, as opposed to on basis of internal algorithms

Thus, your document might look as simple as this:

Those three lines of text would tell ServiceDesk that you include the first 5 miles of distance from your office within a base service call amount of $95, and that you add 95 cents for each mile that is more than 5 miles out.

We recommend using Notepad for creation of this document, but you can use any text editor you wish. Regardless, the document must be saved as as simple text file (easy with Notepad, because that's its standard format), and with filename of MileageRates.txt. Also, it must be saved into the \sd\netdata folder on your ServiceDesk server.

ServiceDesk does a few things, based on seeing this file.

First. when you use the "Item-Locate to DispatchMap" feature (achieved by right-clicking on an address in either a Callsheet or JobRecord), it will show estimated miles in the caption at top, along with the calculated service call amount:

This allows you to readily quote the amount to any such customer as to whom you may be speaking.

Second, you can double-click on a zip or postal code as present in a Callsheet's City/State/Zip box and see a distance estimate and S.Call amount as based on distance from your office to the center of that zip or postal code.

Third, if you do "ZipCodes Export" from your DispatchMap (it's one of the options that's offered when you hit Ctrl-P), the export will include distance estimates for each zip along with a calcuated service call amount for that distance/zip combination.

Fourth (and most importantly, when you do the Job/Sale transition from a Callsheet, ServiceDesk will auto-populate a box in the Create Job/Sale form, indicating the miles-determined service call amount. This is a not normally-visible box. To toggle it into visible state, just hit the Ctrl button your keyboard. Hit Ctrl again to toggle it back to not-visible.

At any rate, when toggling to show the amount, and assuming you have indeed communicated the quote to your customer, you should click on the indicated button to so confirm.

Ad-Hoc Setting of S.Call Amount

To date, we've only setup for automated calculation of a variable service call amount where the basis is as above-described (i.e., dependent on quantity of miles between office and service location). Potentially (and of course if there is demand for it), we could create other bases, such as applicable Zone, type of machine, make, etc. -- or a combination of those.

Regardless, automation is not strictly required. If wanted, you may use whatever is your own private basis, quote your customers accordingly, and use that box (shown in the preceding section) to record precisely what you have quoted, and also click on the button to confirm that you did so.

What Happens When there is a Button-Click Confirmed S.Call Quote in the Create Job/Sale form?

This assumes, of course, that you proceed with creation of a JobRecord, with the the button having been clicked to confirm your quote was communicated to the customer. What happens is as follows.

First, the quoted amount inserts into the JobRecord's narrative history:

Second, if you setup a field for it in your custom up-front invoice setup (see here), ServiceDesk will auto-populate that with the indicated service call amount.

Third, when SD-MobileLink creates an applicable dispatch for a tech, it will see that note in the underlying JobRecord's history, and on such basis will create an ExtraNote in the dispatch that looks something like this:

This allows the tech to readily see the quoted amount.

Fourth, SD-Mobile itself sees these ExtraNotes, and auto-populates its S.Call box (in the formulate-ticket page) accordingly.

About the Google True-Driving-Distance Option

The standard method that's used to calculate distance is a simple and somewhat crude algorithm. ServiceDesk uses simple trigonometry to calculate the straight-line distance between such DispatchMap coordinates as are applicable to your office and as are applicable to the job in question. It then applies a mathematical fudge factor to estimate how much longer a true driving distance is likely to be, on average. In other words, it does not account for actual road layout. The algorithm accounts for the fact that a longer straight-line distance is not likely to have a true-driving distance that is so much horribly greater than straight-line, as is a shorter straight-line distance. Thus (and as examples) the fudge factor would render a straight-line distance of 1 mile with estimated driving distance of 2.2 miles; a straight-line distance of 10 miles with an estimated driving distance of 14.7 miles, and a straight-line distance of 50 miles with an estimated driving distance of 64.6 miles.

It's possible you'd prefer real miles, as opposed to estimated miles.

If yes, you may so specify by using the fifth line of text in your MileageRates.txt file, as described in this chapter's second section. When you place the word "True" in that fifth line, ServiceDesk will not use its own internal algorithm. Instead, in particular contexts where distance needs to be calculated, it will make a call to Google indicating your office address and the service location address, requesting the Google report back on what is the true and genuine driving distance between the two. It will then use the figure that Google reports back. What's more, when you do an Item-Locate action to your DispatchMap, instead of indicating an indication of "estimated" miles, it will instead show:

Another difference is, if you are a Canadian user, the Google True-Driving-Distance method will automatically give you distance in kilometres instead of in miles:

This means, naturally, if you select this option and are Canadian, you should assure that, in your MileageRates.txt file, you specify quantities in kilometres rather than in miles.

A tiny downside in programatically using this Google feature is it's not free. Google charges us for the required programmatic access, and we must pass such cost through to you. The fee is $0.009 per incident (nine-tenths of one cent, which we automatically add into your monthly billing). Regardless, we've structured it so even this less-than-a-penny fee will be limited in its dings. Suppose you are in a Callsheet and right-click on an address to Item-Locate into the DispatchMap. Assuming you have this feature turned on, ServiceDesk will at that moment make its request to Google, get the result back, and insert it into the Callsheet's MoreInfo section, such as you see here:

Once it's there, it can be directly referenced by ServiceDesk when needed again (such as if you again do an Item-Locate to the DispatchMap, for example, or when you do the Create-Job/Sale transition, etc. Thus, there is no need for repeated calls to Google on the same item. We believe, with such structure, this is a feature you can use with very minimal cost.

Present Limitations

At least as of it's initial introduction in late 2020, the Google True-Driving-Distance figure (once obtained), is used by ServiceDesk in three contexts:  (1) when doing an Item-Locate to the DispatchMap from a Callsheet (in which case it displays distance and calculated S.Call amount at top of DispatchMap); (2) when you do a Create-Job/Sale transition from a Callsheet to a JobRecord (in which case it populates the S.Call amount box accordingly, and allows you to confirm that you communicated the amount to your customer); and (3) when you do an Item-Locate directly from a subsequent JobRecord (which will have same distance figure in it as was obtained when at the Callsheet level, and will be used to similarly display in the DispatchMap).

Please note in this chapter's second section we describe two other functions associated with a MileageRates.txt file (double-click on a zip or postal code in a Callsheet to get distance/rates and export zip/postal codes with S.Call rates). Those other two functions have not at this time been upgraded to use the Google True-Driving-Distance option. Likewise, they've not been upgraded to provide figures on basis kilometres rather than miles.

As one more note, Google's True-Driving-Distance calculator has long been offered as a basis to auto-fill a mileage fee in warranty claims (see here). That is a separate use within ServiceDesk of essentially that same Google service.