SD-Mobile is a cutting-edge system for automating information linkage between the field-tech and office. Working entirely behind the scenes, it provides each field tech with comprehensive and real-time data concerning the dispatches assigned to him, including additions and cancellations throughout the day. It simultaneously provides the office with real-time data concerning each tech’s progress, including all pertinent details concerning what transpired at each job.
In short, SD-Mobile is a 21st Century system for the truly modern service business. Congratulations on your choice.
This handbook assumes you’ve contacted Rossware to request setup of your Mobile account on their end, and have received your “Setup” email. It’s designed to help you begin operation easily, quickly and with almost zero fuss. It’s barely 23 pages (portions of which can be skipped if not applicable), and is easy reading.
The SD-Mobile system involves two programs:
The general scheme is as follows:
For the most part (and with understanding of the general scheme, as explained above), use of the two programs will be self-explanatory.
To begin your use of this system, you must first install the software. For SD-MobileLink and SD-Mobile-w, installer utilities are found on the SD-Mobile downloads page. To get there, you can use this link:
https://www.rossware.com/resources/downloads/SDM/index.html
You can also navigate there via menu options found on Rossware’s main webpage, http://rossware.net (also available via hyperlink in the ServiceDesk About form). Simply choose Updates, then SD-Mobile.
To run either installer, first click on the applicable hyperlink, then (when prompted) choose “open” or “run.” After several moments, the system will open a folder that contains three files. Click on the file called Setup.exe, and follow the prompts. Generally, it’s best to accept default answers as the installer setup progresses.
If wanting to install SDM-i, it’s the same as installing any other iPad or iPhone app. Just go to the App Store, and search on “Rossware”.
When you received your setup email on SD-Mobile, it will include your User Account Number and Password. You’ll find both Mobile itself (regardless of which version) and MobileLink have boxes in which these unique credentials must be filled in.
It's also necessary to do some work in ServiceDesk.
Specifically, you must go to the ServiceDesk Settings form, and there designate each tech that you wish to have running with SD-Mobile (if you do not, his name will not be uploaded by SD-MobileLink, as a tech who’s authorized to use the system).
To designate applicable techs, locate the List of Technicians section in your ServiceDesk Settings form, and select an applicable tech. Then, in the grey Technician Properties box to the right, activate the checkbox which indicates he 'Is Using’ SDMobile. At the same time, be sure to create a password for his log-in.
With this done, SD-MobileLink will know to upload the applicable techs’ names (and login passwords) to the remote server. This, in turn, allows those techs to log-in via SDMobile.
In this regard (and when you look at the SD-MobileLink program), you’ll see it’s structured to update several different kinds of data, including your TechRoster. It’s set to do this at timed intervals. In regard to updating Dispatch info and PVRs, the system connects to the remote server with each timed event regardless of whether changes have been detected in ServiceDesk. In regard to uploading the TechRoster and several other matters, however, it only uploads when it detects changes have been made.
Regardless of the above, let’s say that within ServiceDesk (and as per the above description) you just designated some techs as ‘Is Using’ SD-Mobile, and you do not wish to wait for the timed update interval for SD-MobileLink to upload this fact to the remote server. Within the SD-MobileLink program, you’ll see there’s a button you can click to make it happen immediately.
There are similar buttons to force immediate uploading of your StockList (used by SDMobile for the tech to indicate parts used from stock), UIS Lists (provides your list of Types, Makes and Selling Dealers so the Mobile tech can have drop-downs for same), and so on.
BTW, accurate maintenance of the list of such technicians are use SD-Mobile is your responsibility. If a tech is no longer with you, be sure you either remove him from the roster of techs in your ServiceDesk Settings form, or at least de-activate the checkbox that indicates he “Is Using” SD-Mobile. So long as he’s listed and with checkbox activated, he’ll be tallied in the billing as a tech on your SD-Mobile roster, and you’ll be charge at the applicable monthly rate.
For use in the office, no new hardware is needed. You already have one or more office computers, and presumably have a good internet connection there as well.
For the mobile end (and as previously mentioned), SD-Mobile may be used in either a full-Windows platform or in an iPad or iPhone.
If preferring a Windows platform, netbooks were a once popular solution (essentially they were very small laptops with limited computing power). More recently, netbooks have been superseded by Windows tablets, so, pretty much, your Windows-side options are between a laptop versus tablet. Regardless, bear in mind that tablets can indeed be easily configured in the traditional clamshell-with-keyboard mode, either via inherent design (e.g., the Asus Transformer or Microsoft Surface, etc.) or via the add-on of an accessory sleeve/keyboard. Historically, the availability of incorporated air-card/cellular capability has lagged, in the Windows-tablet world (i.e., as compared to Apple), but as of early 2015 this is rapidly changing.
If preferring the iPad/iPhone path, your options are obviously much more simple, because there is only one line of devices from which to choose. If choosing an iPad, most likely you will want to add an accessory sleeve/keyboard. Most techs find the iPad Mini is a very convenient size. Most companies are choosing the upper-end model that includes built-in air-card/cellular capability. Any iPad or iPhone that’s running iOS 7 or above should be compatible.
Regardless of whether choosing the Windows or Apple route, for at least the purpose of running SD-Mobile, you do not need extra computing power and/or extra ram. The base-level devices will perfectly suffice.
To give you some idea on pricing, a bargain-basement Windows tablet plus add-on sleeve/keyboard can typically be obtained for less than $150. That’s pretty cheap. Alternatively, you can get something like the Asus Transformer (a really nice device) for about $350. Once or twice we’ve seen an air card/cellular equipped HP tablet offered at just (from Walmart) at just $149, with an air card that may be configured to work with any of the major carriers. If purchasing a Windows device, please be sure it is full and true Windows (i.e., not Windows-RT, which is a much more limited operating system that only masquerades under the “Windows” name).
Apple devices generally cost more. On checking presently, the cheapest iPad is $249 (stand-alone, no sleeve/keyboard), and lacks built-in air-card/cellular capability. The cheapest with that capability is $429. Regardless, the feedback that we’ve received from those companies that have deployed both is that their techs significantly prefer an Apple-side solution.
As for internet connection (and as mentioned), you can do it internally within each device via built-in capability, or externally (and the choice is entirely up to you). Aside from the connecting hardware, you will also need a data plan. We suggest you internet shop to see what options are currently available to you, and decide what best fits your need. As for level of data usage you can anticipate, our reports from users indicate that most techs fit well and easily at under 2 GB per month.
The best advice in regard to printing mobile tickets is . . . don’t do it!
Just do e-tickets. It’s the modern way, and is usually best.
Also, we wish to tell you that every Rossware client that was first skeptical about eliminating normal paper tickets (but nevertheless did it) soon found . . . well, what do you know . . . it ended up being wonderful after all.
If we cannot at this time sell you on that (i.e., you feel really determined to provide your customers with paper invoices in each and every instance), this section is for you. Otherwise (if, in other words, you are willing to rely at least primarily on e-tickets), please feel free to skip this section.
If, in fact, your techs are going to be using SDM-i, you might as well skip this section anyway. That version of SD-Mobile does not have any direct printing capability built into it. Thus, you should pay attention to this section only if you’ll have one or more techs using SDM-w (which, in fact, does have robust direct-printing ability).
As for what printer setup your techs should use, it’s entirely up to you. SDM-w will print to any Windows-compatible printer. Likewise, it will auto-adapt its output for whatever paper size your Windows-compatible device uses.
Some technicians have used small but still office-type inkjet printers. A virtue is they’re cheap. A downside is the tech has to go out to the truck to get the customer’s invoice, 2 and of course an inverter is needed to supply the printer with its needed 115v AC power input.
There are a number of more compact, “mobile” inkjets on the market, and if you check the pricing you’ll see there’s a significant premium for going tiny. For years, we’ve been happy with a Canon ip90. It’s pretty small, yet prints to full, letter-size paper (we have a client who keeps his ip90, along with other supplies, in briefcase that he carries in with him). Figure around $250 to purchase.
Another option is the little micro thermal printers that store their paper on a roll. We acquired a designed-for-service (i.e., “ruggedized”) Printek RT43 BT that connects via Blue Tooth and also includes a credit card reader (and may optionally be attached to a barcode reader). It’s a very sweet machine (can be worn on a tech’s belt), though some may consider pricey at around $750 typical retail. We are in fact Printek dealer, and with that status can provide you with significant discounts from list (price sheet at http://rossware.net/MiniManuals/Printek-PriceList.pdf).
For the purpose of our tradeshow demo-ing, we also purchased the very tiny Brother MPrint 140BT. It has the size and approximate appearance of an old-fashioned cigarette case. It prints individual 3" by 4" sheets, and also connects to the computer via BlueTooth. Ran us about $370.
Just as there is nothing in SD-Mobile to mandate mobile printing, there is likewise nothing to mandate live and in-the-field processing of credit card transactions. Nor is there anything—even if you want your techs to run such transactions live—to mandate their use of a swiper (i.e., our Virtual Terminal happily permits keying in of credit card data).
However, given the fact that many merchant-account setups penalize non-swiped transactions, and of course it takes less time and effort to swipe, we think you’ll likely want to make your techs swiper-equipped.
We also think you’ll almost certainly want to have them do that swiping in a manner that’s fully and direct-integrated with SD-Mobile. Any other mode is going to cost you more (in SD-Mobile, there is no fee aside from the standard Merchant discounts). Plus, any non-integrated system will involve separate entry of each transactional detail, thereby involving more tech time and greater possibility of error (as opposed to the perfect integration that’s involved when running within a unified and coherent system).
In fact, with the SD-Mobile unified credit-card-charge system, all you need for swiping is a simple MCR (magnetic card reader) device that can be had for less than $50 each. On the Windows side, you can use any Magtek HID-type USB-connecting reader (we particularly recommend their model 21040140). On the iPad side, please use the IDTech Shuttle.
For other details on using our built-inVirtual Terminal system, please consult this document.
First, we don’t think there is usually great benefit in equipping your techs with a barcode scanner. A likely exception will be if the day has finally arrived when most model and serial plates include barcodes of model and serial. When that day is reached, then there may indeed be a significant benefit.
If in fact you wish to equip your techs with barcode scanners, you may rely on the fact that SDM-w will work seamlessly with any Windows-compatible scanner, and SDM-i will work seamlessly within any iPad-compatible scanner.
Beyond this, if you’d find yourself wanting to equip your techs with one of the those fancy Printek setups, some (at least) of those may be equipped with attached scanners that are simultaneously compatible with SDM-w.
To use scanners within either version of SD-Mobile, simply place the cursor in a textbox where you want to scanned data to appear, then scan. It’s really that simple.
Many service companies are paying for, essentially, two cell-system accounts for each tech: one for his voice communication (aka cell phone) and another for his data communication (aka air card). This may be perfectly practical, but it also may be more pricey than is actually needed. There are a couple of strategies via both forms of communication may be accomplished on one and the same account.
If you think of the hardware and communication environment as the sea with which SDMobile will live and propel itself as it’s doing its work (and you must provide that sea, of course), please also consider other denizens within the sea. In particular, please consider such difficulty as may be involved if SD-Mobile finds itself attempting to swim in a sea infested with sharks.
Please pardon the metaphor, but in the Window world (yes, you in the Apple world may grin in smug satisfaction as this particular issue is discussed), there are two varieties of Great White Shark. They go by the names Norton (Symantec) and McAfee.
Those two anti-virus protection systems are infamous for wreaking havoc with programs like SD-Mobile. If you think about it, it’s not surprising. After all, SD-Mobile is engaged in near constant communication with other systems via the internet. To a virus protection software, this kind of activity can (potentially) make it look much like a virus.
Of course, a really good anti-virus protection system nevertheless manages to distinguish between a good program (like SD-Mobile) versus a lousy virus. We have found the protection systems that are included in Windows and are also free(specifically, it’s Microsoft Security Essentials if you’re in Windows 7, or Microsoft Defender if you’re in Windows 8 or above) generally do well in this regard. There maybe others that likewise do well. Regardless, Norton and McAfee often fail. And, when they fail, they end up curtailing essential SD-Mobile operations.
For this reason, we very strongly recommend (in particular, if you’re operating SDM-was opposed to SDM-i) that you carefully assure your computers do not have either Norton or McAfee running on them. This is not always easy, because either Norton or McAfee are almost always pre-installed on new computers, and they can sometimes be as difficult to remove as is a virus itself. Please, whatever it takes, do it, and assure you instead have a less troublesome antivirus system protecting you.
If you defy this advice, it’s likely you will find SD-Mobile succeeds for a while regardless.Just because there are sharks in the sea, it doesn’t mean they’ll always (or immediately)eat you. The longer you swim with them, however, the more likely it becomes. When it does finally happen, you’ll find it causes you great frustration, because things will notwork as per design. Wondering what’s wrong, you’ll contact us, and we’ll likewiseencounter frustration (along with wasted time and resources). Please don’t allow those sharks to remain. We all have much better things to do with our time.
As previously mentioned, actual operation of the two programs is mostly self-explanatory. But a few things on the mobile end may not be obvious. We’ll endeavor to describe those here.
As intimated when discussing hardware, SD-Mobile is endowed with all essential equipment for a technician to formulate a ticket in the field, collect a signature, and provide a copy to the customer (preferably as an e-ticket). All such work is done (as you might guess) via the ‘Print’ page.
The general concept on this page is that it has two list areas: one for parts items used,and one for labor items. The first will auto-fill based on parts that were indicated (as being used and/or ordered) back on the PVR page. It can then be edited to fit needed circumstances. The second can be filled in manually, or with semi-automation based on a flat-rate system and drop-downs (see applicable section following). It also has an area where charges are totaled, and tax added.
On the basis of this data, the system stands ready (when needed) to create an actual ticket image.
The first context in which such creation is likely to be wanted is for the purpose of collecting the customer’s electronic signature. The simple concept is, the tech clicks on the button labeled ‘Review and Sign,’ at which point the system creates the electronic ticket image, and presents it on-screen (in an interface which allows the customer to review and sign; please see Section C following).
The second context is for providing a copy to the customer, which may be done either by printing or emailing.
Regardless of context for which it is formulated, the electronic ticket image is “hardwired” (at least to a significant extent) into the design of Mobile (it’s just not practical in this context to reproduce the great flexibility in ticket design that’s otherwise enjoyed in ServiceDesk). But some flexibility is allowed (see Section B following).
As mentioned, the Print page is configured to work most easily (in terms of allowing the tech to fill-in a description of what he did and what the charges are) on the basis of a flat-rate system. It’s not essential (SD-Mobile will work fine without it), and you should not delay implementation while waiting to get one in place.
However, there are two factors we think should make you serious about setting one up as soon as possible.
One is the difficulty of typing descriptions of work performed in the mobile environment, whether owing to the fact techs are lousy at typing or because of limited physical circumstances (e.g., tiny or no keyboard). Another is the need to quickly populate a ticket, to be produced in the field, with descriptions of work performed, including appropriate charges.
Given these needs, we’ve designed the system to make very effective use of such a list.But you must provide the particular list you want to use. Likely the best method is by using the famous BlueBook, with which SD-Mobile perfectly integrates. And, your list must be formatted to the particular structure the system is designed to accommodate.We have a separate document, designed to walk you through setting up your flat-ratelist (in fact, we even provide a beginning list for you). Here is the link to that document.
We have already argued in favor of e-tickets over paper.
An emailed ticket will look exactly like a printed one (except it has a yellow background).It's done in the common .png format, so any customer with a computer should have no trouble opening it. An added benefit in using this method is it gives you an excuse tocollect the customer’s email address. There are just two issues to keep in mind:
You'll find in the MobileLink program there is an option to disallow the tech from direct-sending tickets (thereby forcing him to do it via the office). I suspect most of you will want to choose this option.
Whether the ticket is emailed or paper-printed by the tech, the system will create an electronic image of it. MobileLink will save this image to the ServiceDesk HLinks folder, and place a link thereto in the narrative history as added to the applicable JobRecord(i.e., as part of its PVR entry). At least, the above occurs if the system is equipped with that FreeImage.DLL file.
The standard mobile ticket contains a few items of text that will easily adapt to your circumstance, specifically in the header area at top. In particular, you can (and should)specify the telephone number and website url you wish to have appear on the mobile ticket. Just put these in applicable boxes of the SD-MobileLink interface, and the rest will take care of itself. Also, if you want to use a different ad-line than the standard/default one ("-- next time, book your job on-line --"), just type it into SDMobileLink’s applicable box.
If you’d like your tickets to look a little more stylized (the above-described header is all just plan text), you may replace the entire standardized header with an artistic/graphic one (i.e., containing your company’s stylized logo, and/or other accouterments). To do this, simply create the graphic image you want, and save it to your server’s \sd\netdatafolder under the name SdmLogo.jpg.
A final element of potential customization* involves the signature line. Absent you doing anything otherwise, the text immediately under it will default to something like: “I promise if I don’t pay this bill you’ll own my house, my cars and all my children.” (okay, a little less extreme). If you’d like different language, open any text editing program(NotePad, WordPad, Word, etc.), and type the text you want. Then save. Make sure to save it as a “Plain” or “Text Only” document. Save it to the \sd\netdata folder on your server, as filename SdMobileInvoiceText.TXT. Once you’ve done so, SD-MobileLink will see the file, upload its text, and each of your Tech’s instances of SD-Mobile will download the same, and use it in lieu of the written-by-us canned text.
We are occasionally asked for more extensive customizability of the Mobile ticket, such as is offered within ServiceDesk itself.Presently, this is not offered. Nor is Mobile equipped to create the same kind of tickets as offered within SD. There are reasons.
It requires a large programming infrastructure to accommodate layout-customizability in a ticket format that is simultaneously auto fillable(with particular job-data in each and every instance), user-editable (with edits saved, potentially even in multiples), and printable, via a customized-layout-adapting on-screen interface. To provide some indication of how difficult this is, we don’t believe any of our competitors has ever done it. We’ve done it within SD, but with huge investment, and in a context where — given the relatively large in-office platforms involved significant screen space and direct, in-office management as needed for setup and maintenance — accommodating such infrastructure is relatively feasible.
All such factors are lacking in the Mobile environment, and there’s the added factor that (for technicians and in platforms that are field-deployed) there’s a critical need to keep setup and deployment simple and trouble-free. Given such factors, we judged it best in this context to use a universal ticket format, maximally adaptable to every context and need (even to printing on tape-type printers, if that is the type employed by a given user).
There is, of course, a downside.
For every gain in design, there’s a cost. In gaining simplicity and robust freedom from complication, we lose the customizability you might otherwise prefer. There is reason for the expression: You can’t have your cake and eat it too. The world is full of compromises. We have aimed for the optimum compromise in this context. Your opinion may vary.
None of this means we’ll not add to user-selectable options, much as has been the pattern to date. It’s further possible (to the extent demand is apparent) we’ll offer dramatic variations. Your input in such regard is welcome, but as you provide it we urge you to be mindful of the dynamic above-described, which urges so strongly for simplicity. That dynamic will not go away.
We have discussed a lot of customizations you may do, including language and graphics on the Mobile ticket, flat-rate setups, disclaimers and their contents, etc.Besides these, there is a whole other category of customization in regard to such language as may be presented to your customer. This category involves elements of automated or semi-automated communication.
For example, on a routine basis SD-MobileLink will (at least unless you determine otherwise) be emailing e-tickets to each customer. There is “canned” language that it uses when this sending email. Optionally, it may likewise email an apology if the job was not completed during the current visit, along with an invitation for the customer to monitor job status via an online interface. Again, there is “canned” language that’s used. Finally, after job completion SD-MobileLink may optionally email the consumer an invitation to complete a very quick survey, and, again, there is “canned” language it uses for this.
Within SD-Mobile itself is a “call-ahead” function whereby the tech may elect to have underlying mechanisms either RoboCall or SMS-text notice to the customer that he is on his way (or, optionally, that expects to be there within a specified quantity of minutes). Again, this mechanism normally uses “canned” language.
In particular, each of these contexts use language that was composed by us, using great care in trying to formulate structure that we think is generally most optimum for the circumstances involved. It’s possible you’d prefer different language regardless. If so,we’ve provided for customization in these contexts too. Details are contained in this document.
Beginning with SD-Mobile Version 1.1.0, we added the ability to electronically capture a customer’s signature.
The simple idea (as reviewed in the prior chapter) is SD-Mobile displays an image of the ticket as it’s about to be printed or emailed (there’s a ‘Capture Signature’ button on the Print page for this purpose).
He’ll likely say something to the customer like “Would you please review this ticket and sign it.”
When the customer is ready to sign, she clicks the “Sign” button (or the tech can just hit‘Enter’ on his keyboard). This visibly enlarges the ticket image until its signing space occupies most of the screen. At this point, any pointing device may be used to scribble a signature.
Here’s a list of some possible pointing devices:
With touchpad of mouse, it’s necessary to hold down the mouse button (or its equivalent) while signing (essentially, ink does not flow from the pretend pen unless the button is down). If your tech wanted to make it easier for a tech-challenged customer (we’rethinking 96-year-old Mrs. Ambercrombie), a good trick would be to keep a small wireless mouse in his pocket. He could simply reach into his pocket while she’s signing, and hold down its button. Thus, she’d be using stylus on the touchpad, and have no need to simultaneously do anything else.
Purpose-made signature capture devices tend to be much more expensive (a few hundred dollars), and in our experience are not generally configured to mimic mouse input. Unless one can mimic mouse-input, it will not work with Mobile. In general, we are not recommending purpose-made signature capture devices.
Regardless of pointing device used, once the signature has been scribbled, the customer clicks the “Accept” button (or, again, the tech can just hit ‘Enter’). This saves the signature image with the ticket. Thus saved, it will print with the ticket (if printing is done), or be included as an emailed ticket image (if that’s the method), and of course will be saved within ServiceDesk data back at the office.
We just discussed electronic signature capture as connected with tickets (aka“invoices”). There is also ability to similarly capture electronic signatures, but in connection with special disclaimers (e.g., the customer agrees to hold you free from liability if the tech damages her floor while moving machinery).
Usage is very simple.
First, you must provide one or more disclaimers. By present design, the system allows you up to six (if more are needed, let us know).
If you wish to “from-scratch” create a disclaimer, open any text editor (e.g., Word,WordPad, NotePad, etc.). Type the desired Header (i.e., the “Title Bar” you want to have appear at the top of your disclaimer), then a vertical bar symbol (“|”), then the textBody you want to use.* Once all is typed and perfected, save it as a plain text file. It must be saved to the \sd\netdata folder on your server. If it’s your first and/or only disclaimer, name it SdMobileDisclaimer1.TXT. If it’s the second, name itSdMobileDisclaimer2.TXT. And so on. (The naming must be precise, because it’s only for those particular file names, and in the folder location described, that SD-MobileLinkwill look for the applicable purpose.)
You may elaborate further on this if desired. In particular, if you want any particular disclaimer to be mandatory (i.e., your techs are required to have the customer sign this disclaimer), you may add text after a second bar symbol (i.e., in a third section of text,where each section is separated by a bar symbol). This section of text may contain the word “ALL” if you wish for the disclaimer to be required on all jobs, or — if you want it only to be required when particular kinds of machines are being serviced — you may list those machine descriptions, separating each by a comma (or, if only one machine type is involved, simply list it alone with no commas). If listing machine types, be certain the spelling is exactly the same as you created in the SeviceDesk machine-types dropdown.
Much as in the case of your customized ticket/signature language, once you’ve done the above, SD-MobileLink will see the file (or files), upload each, and each of your Tech’s instances of SD-Mobile will download the same, and offer it (or them) for use in collecting signed disclaimers from customers in each applicable instance.
If, incidentally, you want to assure your creation/editing work at the office is immediately uploaded to the remote server (i.e. rather than waiting for the next timed event), you can click on this button in MobileLink:
To find, from the Mobile side, where to invoke the disclaimer option, just go to any job’s“Job Details” page. You’ll see a button as follows:
If, rather than composing your own disclaimers from scratch, you’d prefer to at least start with a very nice disclaimer set that has already been created, we have in fact provided a very nice set for you. You can open and/or download this set here.
If you are sufficiently fond of our example provisions, you can use them precisely as provided—with one exception. You must change the company name (as embodied within the text of each) to match your own.
At the least, our set of examples should provide you with ideas to use in creation of your own. In actual fact, however (and assuming you are in any service business that makes their particular subject matters applicable), we recommend that you use them with very minimal editing, aside from company name. They’ve been carefully composed with a good understanding (based on solid legal credentials and experience) of what most persuades most judges to take a disclaimer seriously. To be candid, that is a tall order.As a rule, most judges will mostly ignore most disclaimers. To have any chance of being taken with seriousness at all, a disclaimer generally needs the very qualities that have been built into these examples. If you change significantly from what is provided(and aside from incidentals), there is a very good chance you will be creating a weaker(rather than a stronger) result.
BTW, in any instance where a disclaimer is signed, the Mobile/MobileLink system will transmit it back to the office as part of the underlying PVR information. In result, you’ll see a reference to each signed disclaimer in any applicable JobHistory. That reference will include a hyperlink. To actually view a signed disclaimer, just double-click on the hyperlink.
In the above example, we signed three different disclaimers in SD-Mobile, and uploaded the PVR. Hence, there are three resulting disclaimer hyperlinks in the resulting JobHistory (there’s also a hyperlink for the underling ticket, which is not circled above).
One of our very first enhancements to the system, above base-level operation, was to add (on the mobile-end) a “Scheduling” page. This is a locus where the technician, supposing he’s ordering parts and is expecting to return, can pre-book his return appointment.
Those companies that have been using this practice (i.e, not within SD-Mobile, but via other means) swear by it. They say it makes the customer happier, and saves the office significant resources that are otherwise needed for it to re-schedule. The practice presupposes that parts will arrive within some normally expected period, but evidently that factor has become sufficiently reliable that the occasional need to cancel, because expected parts did not arrive, becomes the exception rather than rule.
SD-Mobile’s Scheduling page presents the tech with a calendar. The intent is to allow the tech to schedule intelligently, by informing him (via the calendar) of the particular days in which there are still openings available for the return visit (taking into account the customer’s zipcode and the JobCount value that’s expected for the return visit).Specifically, the calendar will show in bold those dates that are so available.
At least this will happen if SD-Mobile has access to appropriate availability data. This,naturally, raises the question: where does it seek such data? The simple answer is it looks on-line for SD-CyberOffice data as applicable to your company.
If you do not know, SD-CyberOffice is the system that, among other things, allows your customers to book their jobs on-line. To make that system work, it had to have a means of keeping your on-line interface informed of availability. Thus, we already created such machinery for SD-CyberOffice, and could see no sense in re-inventing it for SD-Mobile.Instead, we’ve designed SD-Mobile’s re-booking apparatus to “piggy-back” on the same machinery.
For this reason, you need to implement at least the basic tools of SD-CyberOffice, ifyour tech is to re-schedule intelligently via SD-Mobile (otherwise, he can still use thescheduling function, though it will be without knowledge of availability).One of our very first enhancements to the system, above base-level operation, was to add (on the mobile-end) a “Scheduling” page. This is a locus where the technician, supposing he’s ordering parts and is expecting to return, can pre-book his return appointment.
If you’re already using SD-CyberOffice, use of its data by SD-Mobile is absolutely automatic. Otherwise (and assuming you want your tech to be able to schedule intelligently), give us a call.
Almost as soon as we rolled out the first version of SD-Mobile, some folks wanted provision for their tech’s to “punch the TimeCard,” via it’s interface. So, we added the functionality.
Basically, the SD-Mobile interface has a button via which the tech can punch in, and another via which he can punch out. Based on such actions, the MobileLink program creates a file, for each such tech (i.e., any that uses the feature), that tracks such punch-in and punch-out events. Look for such files in the \sd\netdata folder on your server. For any tech, look for a file called TimeClock.XX.TXT (where XX is the two letter abbreviation for the tech wanted).
If you wish to direct review the data that’s in any file, open it in Excel, as that will nicely separate the columns.*
You'll notice two columns that may provide a bit of curiosity: they're labeled "InFudged?" and "OutFudged?". This indicates,simply, if the technician entered an In or Out time manually. The system allows him to do this, based on the fact he may have forgotten to log in, then find he needs to log out, or vice versa. However (and as you'll see) it flags any item so entered.
Besides providing facility to simply “punch-in” and “punch-out,” the SD-Mobile interface provides an interface in which, at the end of each workday, the technician is expect to review his timecard, revise if appropriate, and sign-off on its accuracy.
In particular, it is a very nice graphic interface that shows a colored timeline representing the portions of the day he was “on-the-clock” and portions he was off.Simultaneously, it shows the corresponding portions of time that he was clocked in for doing work at particular locations. An element of our thinking in this interface is the tech may notice a large band of time in which he was “on-the-clock,” yet was not clocked in for doing work at any particular location (how is that explained?). He may then have a dawning realization, such as: “Oh my gosh; I forgot to punch out for lunch.” The system provides a mechanism via which he can belatedly insert that “punch-out” time.
Correspondingly, within ServiceDesk back at the office, you are given opportunity by which to readily review these timecard graphics, as applicable to each technician and each day. Thus, you can readily see a visual comparison between times “on-the-clock”for each and such times as actually clocked-in for doing work at particular locations. It’s called the “DTR Viewer” facility. To employ it, simply go into your DispatchMap and page back to a particular day of interest. Then hit Alt-T on your keyboard (this is in the contextual cheat-sheet there, for when you need a reminder).
BTW, this within-ServiceDesk interface even indicates if the tech “certified” his timecard, as in fact he was urged to do by the SD-Mobile interface.
Sad to say, there are some techs for whom the word “scofflaw” might be deemed a compliment. These are techs that don’t always do precisely what they should, including the completion of PostVisitReports in real-time, as they complete each job and before proceeding to the next. We’ve added a system to help discipline this variety of tech.
Specifically, in the SD-MobileLink program you’ll see an option labeled “Disallow next job access until prior PVR is completed.” The general idea is, if the tech can’t see info for his next job, he’s forced to do the PVR on the one he’s presently finishing. Sensibly,this enforcement does not begin (for any given day) until after the tech has clocked in arrival at his first job. Thus, prior to that initial clock-in, he’s permitted to review all details of all jobs.
Of course, the system is built to recognize the fact that any number of extenuating circumstances may arise, for which exceptions are required. Thus, if the tech wants to proceed to the next job and has not completed a prior PVR, he’s presented with the following dialog:
If he chooses the second option, the next message is as follows:
As you can see, the system provides needed flexibility, while nevertheless giving the tech heavy motivation (and, ultimately, compulsion) to do the PVRs in a timely manner.
