It stinks!

You invest significantly in assuring a job is completed with competence, professionalism, skill and superb customer service.  You made the consumer happy, and another machine is running smoothly again.  Sadly, however, there's a matter that everyone involved slipped up on.  The underlying third-party client had a strict authorization limit, and the work as performed significantly surpassed it.  Someone should have caught it, and assured that either that authorization was increased, or that you did not proceed with the repair.  But, no one did, and now it's too late to get the needed authorization increase.  After all that fine work and investment, you end up eating it.

It should never happen, and now we've added a system to help you assure it does not.

First, you must assure that each JobRecord in ServiceDesk has an appropriate indication of the applicable pre-auth limit, if any.  These may be indicated in either of two ways:

Method A: Place the pre-autho amount in the right-hand side of the LocationName box, with a precise preceding title, in this fashion:

A nice benefit of using this method is you may configure each applicable QuickEntryTemplate to already-be populated with this format.

Method B: Add an AttnNote (aka "StickyNote") that similarly uses the key phrase "PreAuthLimit" with the actual amount following.  E.g.:

As a general concept, the SD-MobileLink program will look for a pre-auth amount in either context, and, if finding it in either, will upload that amount as an explicit value in the dispatch as provided to each technician.

This leads to the second thing you must do to use this new feature.  Please assure you are using SD-MobileLink Ver. 2.0.42 or above.

The third thing you must do is assure your techs (if using the Windows version of SD-Mobile) are updated to Ver. 2.0.73 or above (if your techs are using the iOS version, we expect its Ver. 1.93 will likely have this new enhancement; though that version has not yet been released).

So, what happens within the tech's Mobile interface on basis of this new feature?

Quite simply, the system looks at several points to see if it appears investments on the job (and the likely fee that needs to be charged for such investments) has (or is likely to) exceed whatever is indicated as the pre-auth limit.

For example, a check is made when the tech first opens a job.  If the investment as already made appears to threaten the pre-auth limit, the tech will get a message similar to this:

Another check is made whenever the tech goes to finalize any ticket.  This one is actually a little different in that, rather than attempting to analyze the investments that have gone (or which may be going) into the job, it looks simply at the bottom-line dollar value in the ticket, and warns if that particular value exceeds any provided pre-auth limit, as follows:

Finally, a check is made when the tech goes to submit each job's PVR.  Here, the system may encounter a few different circumstances.

For example, investment may not yet exceed a provided pre-auth limit, but it may appear as though contemplated future investments will do so, in which case the tech will receive a message like this:

Or, it may be the case that present investments already exceed a provided pre-auth limit, and even more investments are contemplated, which will produce a message like this:

Finally, it's possible present investments exceed a provided pre-autho limit, but at least no further investments are contemplated, in which case the tech should see a message like this:

As you can see, it's a plethora of possibilities, regarding warnings the tech may receive, depending on circumstances.  Regardless, the purpose is to help keep you out of that terrible "stinky" situation.

To further assist you in this goal, we all understand that some techs may simply disregard these otherwise helpful messages, and, if they do, you may still find yourself in that "stinky" situation.  If so, we've also created a basis by which you may more stringently discipline any such techs . . . and, hopefully, mold them into team players that better help you avoid the stink.  It's based on the fact that, usually, people reform better when they know they are (or will be) caught.  Here's how it works.

Each time SD-Mobile gives the tech any warning such as the above, it adds it to a tally that will be reported in the applicable PVR narrative.  So, for example, you might find yourself in that stinky situation on a particular job.  You look in the narrative history, and in the PVR you read something like this (with highlighting added for emphasis here; you won't see it in the actual narrative):

\___
12/3/15 8:58: GR there 3 FRI, 8:43 to 9:55, replaced main seal, ordrng 1 00-05-048 (bearing), used 1 2-11124 (BELT) from stock, pckd up 1 00-07-765 (support), warned three times against exceeding $100 pre-auth limit, O-emld tckt [SdLink\73092a.png] (via SDM)
/�

Our thinking is that when you as a manager have your nice little "sit-down" with an involved (stinky-making) tech, and when you are able to point out to him that he had (and evidently chose to ignore) these very direct warnings, it's going to make for a much more compelling scolding than otherwise.  Likewise, he is going to realize that going forward it's going to be far more incumbent on him to pay due attention.

You may be curious as to what are the actual mechanics by which these newly-added systems calculate what likely needs to be the minimum charge for such investments (in time and materials) as have been put into a job, or which are contemplated?

The simple answer is the underlying mechanics are neither simple, nor will they in any case produce perfect predictions.  A very rough (and generally somewhat conservative) approximation of needed total-sale is the best that's even hoped for.

If you must know more details, here is a brief guide:

1. SD-MobileLink calculates all investments as made to date, and uploads that as a single value to SD-Mobile.  It's calculation follows these rules:
2. If any prior trips, the first is valued at $75, subsequent trips valued at $25, and time on the job at $75/hour.
3. Any inventory parts as prior used are valued at the MasterPartsPlan-indicated retail, if any; otherwise at indicated cost plus 15 percent plus shipping.
4. Any s/o parts as prior used are valued at cost if the sell-for price has been set zero (it's the OEM warranty situation); or at the indicated sell-for if there if a non-zero sell-for has been indicated; or at an indicated vendor-recommended retail if that is indicated, and otherwise at purchase cost if that is indicated.
5. SD-Mobile uses similar logic.  More particularly,
6. For calculating present labor investment, it counts the tech's present trip according to the same scheme as in 1a, and adds present time (based on his "I've arrived" and "I've Finished" clicks) likewise according to the same time rate scheme.
7. For calculating a corresponding present materials investment, it looks at what the tech indicates was used from stock or via local purchase, along with what is indicated as having been used from the job's PartsPick list.
8. For calculating anticipated future labor investment, it looks to see if the tech has indicated the job is not done.  If so, it looks at the "Next Visit JobCount" window to see what value the tech has placed there.  Whatever is value it multiplies by the same hour basis as in 1a, and also calculates the anticipated future trip accordingly.
9. For calculating anticipated future materials investment, it looks at parts the tech has indicated he wishes for the office to order.
10. It adds all these values to whatever was calculated (and uploaded) by SD-MobileLink as the value of prior investments.

In all, this underlying machinery is a little complex, and it's certainly imperfect.  It's also not customized.  We threw in those simple basis rates (for trips and time), knowing they would not be perfect fits for, well, anyone.  But (and regardless), we suspect this scheme will provide needed warnings in almost all instances where it's beginning to look as though a reasonably-anticipated-as-to-be-needed sale amount is likely to exceed a pre-auth amount (especially if by large degrees).  Simultaneously, we think the scheme is likely to produce no more than a moderate rate of false alarms.  That is what we are shooting for.

‍