Mechanisms here are structured for maximum freedom. If you want to skip any operation in the further-work area, for example, and proceed direct to printing or emailing, it’s permitted. If you want to skip the signature, the system likewise permits that. If you don’t even want to bother with a ticket, it’sup to you and your company policies.

Within this context, there are some things to know.

Specifically, if you skip further-work on your ticket and instead go straight to email or print, your ticket will be assembled straight from data as found in the Assemble area.

By robust contrast, if you do any further-work (modifying, within an actual ticket-layout, results as otherwise pulled from the Assemble area), the print or emailed product will be based instead on that further-work. This means text within the Assemble area becomes no longer relevant.

There is thus a transition: from a state where the final ticket is based on text pulled direct from the Assemble area — to where it’s instead based on refinements done in the Further-Work area. To make itobvious to you when (and if) this transition has occurred, the system moderately transforms itself to so signify:

What you see here is the transformed state. Again, this occurs whenever you do any refining work downstream of the Assemble area. The Assemble area itself becomes greyed-out to signify your work is past that stage, and has progressed into the further-work stage.

As just one more note in this overall strategy, please consider the View/Sign function. Much as the email and print functions (as involved in final-use) may vary in source (from either the Assemble or Further-Work areas), the View/Sign function itself may similarly vary in source. Specifically, if still in“use-from-Assembly-area” stage, its image (for presentation to the customer and signature) will be formulated directly from what’s in the Assemble area. If past that stage (e.g., because of add-on work within a prior ticket or because of user edits within Preview/Revise), its image will instead be based on that further work (exactly the same as with the Email and Print functions).

Please be certain to absorb the following:

1. Aside from the task of entering monies received, SD-Mobile’s Print page is almost solely about preparing a document for presentation to your customer;
2. Text in its Assemble area is for information about the present visit only; and
3. Work here is one-way only; changes as made in the Further-Work area will not affect (upstream)text in the Assemble area (text moves from Assemble-to-Further, not vice versa).

We emphasize the above points because, absent their absorption, folks often encounter frustration.

Segway to details

Having outlined the general strategy, we now focus on specific elements.

If you flat-rate your labor, the concept is to list individual labor items here:

While items could be manually entered here, the right way is to create a FlatRates file (see FlatRate setup), which accommodates pulling each item as wanted from a drop down. Most folks will not use this section unless they have first prepared such a file.

In explaining general concepts we said text in the Assemble area is “almost solely” for insertion to aticket as needed for customer presentation. This section offers (as but one of its functions) an allowedexception. Back in the PVR page there is a box labeled “Describe Work Performed.”

It represents one of the few places you might need to seriously type. But not if you use a particular facility on the Print page. Specifically, you can use items inserted in its List Labor Items section as a means to insert text to this PVR page box. To setup for this purpose, click on the “Work-Description Options” button (as found in the top-right of our List Labor Items section). In result, you’ll see this:

If you examine the options, you’ll see on the left you can specify the rules by which flat-rate description text inserts to the PVR page’s Work-Description box for you.

On the right, you’ll also see there are options for which of two descriptions will be inserted to the “Work Description” section of your ticket (or if it’s a combination of two). This is because, in essence, the Work-Description section on your PVR page is one potential description, and the summation of flat-rate descriptions (on the Print page) is another. Conceivably, either or both could be inserted to the final ticket. The options (on the right-hand side of this pale-blue setup sheet) allow you to specify which.

This section is designed to populate for you, based on parts you indicate as having been used (or ordered) from within the PVR page. It allows you to edit here, for inclusion and pricing as concerns ticket usage. In other words, if there are items you do not want included on the ticket, you can right click to delete from this listing. If there are line items you want included (but that did not otherwise auto-insert), you can manually type them here.* Likewise, you can manually alter pricing, if desired.

Remember this is for presentation to the customer only! Items manually typed here will not be pulled from your ServiceDesk inventory. To ensure proper inventory control the item should be added on the PVR page.

You’ll notice there is a button in the section’s top-right corner labeled “Re-load Parts from PVR Page.”Here’s why. When you first open the Print page on a particular job, the system at that moment pulls parts items from the PVR page for insertion here. It does not as a matter of normal course re-do that process if you happen to tab back to the PVR page (say to add-in a part you first forgot), then back to the Print page again. That’s where the above-described button comes in.

This is simply where amounts are totaled. The “Total Parts” section is greyed, to indicate you cannot directly edit there. The reason is because the figure is calculated for you, based on what’s in the PartsSold section. The Total-Ticket box is similarly greyed, for it likewise auto-calculates. The Labor box will auto-calculate based on amounts in the List-of-Labor-Items box, or you can fill in an amount manually.The S.Call box (may be labeled “Other,” depending on your settings) is solely for manual fill-in. The Sales-Tax box will auto-calculate, based on taxable amounts and the tax-rates as applicable to the job(which, in turn, will normally auto-fill for you into the Tax-Rates boxes just to the right of this section).

In the bottom of this section is a checkbox (to insert amounts as prior collected on the job), you will likely seldom use. Its purpose is if money was collected on the job outside the context of a prior Mobile ticket (e.g., by the office and over the phone when the customer called for service). In that case,checking the box will be the means of inserting credit to your ticket. If prior collections were within the context of a prior Mobile ticket, however, use of the prior Mobile ticket (discussed further on) will be the better means of present crediting.

This section contains a series of check boxes that may be used to alter final setup on the ticket. The first three checkboxes are in a group, for each involves omitting some level of detail from the ticket. The first in the sequence omits itemized parts pricing only. The second omits all pricing except the final total (in older versions this was called “Hide Constituent Amounts”). The third omits even the total (in older versions this was called “Do as a Work-Completion Document’).

Following that initial group is a checkbox labeled “Do as ‘Estimate Only’.” When this is checked, a large“Estimate Only” watermark will appear as background on the ticket. Last is a checkbox that allows using an alternate language (French if your base language is English, or vice versa).

Since these “Finesse Output” checkboxes are in the Assemble area, they will appear greyed-out once you do a Further-Work action that advances past the Assemble stage. However, though greyed-out and appearing at such point to be non-functional, they will in fact continue to function. This may seem contradictory, but the interface must serve conflicting needs. On the one hand, it needs to visually cue you to when you’re in the “Further-Work” stage (hence greying-out of the Assemble area), while nevertheless permitting you to continue with Finessing, when and if needed.

Operation in this section is fairly self-evident. We should remind, though, this section is a very strong exception to the rule that, generally, the Print page is solely about assembling information for presentation to your customer. This Money-Collected section has direct operational connections with ServiceDesk’s Funds-Control system. In other words, when you enter money as received here, that information feeds directly into the system by which ServiceDesk manages every item of money received.It’s a lot more than just presentation to the customer, though it does involve that as well.

If you are a U.S. user, we highly recommend you setup a merchant account with Merchant Warehouse,and use the direct/integrated Virtual Terminal (it’s what’s offered then you click on the “Run a Credit/Debit button”). It’s a great time, effort and money saver. It enhances accuracy too, and impresses your customers.

Segway past discussion on the “Assemble” area

We have now discussed five major sections as present in the “Assemble” area of the Print page. Wenext proceed to discuss the “Further-Work” area.

If it’s your first visit on a job and no ticket was advance-prepared by the office, the left-most of the above-focused buttons will have no relevance (it will also be greyed-out and non-functional). For such reason, we’ll begin this discussion by discussing the middle above-focused button.

As you can see, that button is labeled “Preview/Revise”. We suggest you try a setup and click on it, then click on the next button to its right (labeled “View/Sign”). You’ll see that each shows you identical ticket content, but in a rather different way.

The Preview/Revise button presents the ticket in an editable format. In other words, you can go into each of its boxes, and do any modification you might wish to do (the distinction with work here, as compared to the Assemble area, is here you’re working on final product). Why is this needed? In some instances, there may be elements you want on the final ticket that are not practical to “load for its input,” so to speak, from the Assemble area. Any time this need arises, this is where to fulfill it.

By contrast, the View/Sign button presents the ticket as an actual image, rather than as a set of editable boxes. It further allows provision for showing it to your customer as such, and mechanics for your customer to electronically sign.

Given the above, we hope you can see, if direct output from the Assemble area needs no modification prior to customer signature, there’s no need to use the Preview/Revise button. Go straight to View/Sign, and do not pass go.

Now that we’ve discussed the right-most two buttons in this area, it’s time to discuss the left-most one(i.e., within a frame labeled “Past/Prior Ticket,” and with a direct caption of “Review/Continue”).

What is this button for?

In the first place, you might think this button would be useful to simply see what was on a prior ticket as connected to the job. Indeed, this button could be used for the purpose, but there’s another that is generally better suited. Within SD-Mobile’s Job-Details page is a button that allows you merely to view a prior ticket:

As situated on that other page, moreover, that button is where you’re more likely to need it for mere viewing purposes (as when beginning or anticipating work on the visit, rather than after having completed such work).

Given this, the button on which we’re now focused (in the Print page) has a more specific purpose. To fully comprehend this purpose, please consider an old-fashioned paper-and-ink ticket system, where the tech goes out with a multi-part form. Typically he’ll fill-in information on the first visit as pertinent to that visit, and give the customer a copy from the back (we’re talking carbon-type paper here). When here turns on a subsequent visit, he’ll have the remaining part of the form set, and write in added information as pertains to that visit. Again, he’ll peel off a back copy for the customer (likely having asked the customer to sign in each instance).

To emulate the above scenario is the purpose in our Print page’s Past/Prior-Ticket, Review/Continue button. The simple concept is, if a tech has been there on a prior visit and saved a ticket, he can bring up that prior save and — just as in the paper-and-ink scenario — add-in information that’s pertinent to the present visit. Thereby, he produces a result that’s inclusive to both (or all, if even more than two)visits.

We suggest you open a Print page as connected with an appointment on a job where one or more prior tickets were saved. You’ll see that upon selecting a prior such ticket, it’s displayed for you in the same Preview/Revise form as produced by the Preview/Revise button — only here it shows initially with a yellow background, to signify you’re looking at a past ticket (as opposed to present compilation from the Assemble area), and there are buttons arrayed along the bottom-left for insertion of data to this past ticket as concerns the present visit:

The buttons function exactly as their labels suggest. You can be selective in what’s inserted from your present Assemble area (as of course concerning the present visit), or just click the “All” button to add-in everything.

Why might you potentially want to select less than “All?”

Suppose that on the first visit you listed all the parts that were anticipated as needing to be used. One or more of those were ordered, and the present visit involved delivering and installing said parts. Given normal mechanisms, your Assemble area will be poised to insert the parts as used in the present visit,even though they are already listed on the prior ticket. Given this, you could click to insert the current“Description of Work” and “Money Received” (assuming you collected added money on this visit), but refrain from inserting parts sold.

Suppose instead that on this visit you used one part that was not prior anticipated, and hence was not listed on the prior ticket (i.e., in addition to others that were ordered in for this visit, and in fact are on that prior ticket). In that case, you could go ahead and do the PartsSold insertion, then (for any parts that end up being there twice, because of initial presence plus subsequent insertion), simply right-click on those line items to delete.

The latter might sound a little goofy, but we’ve not yet found total removal of the human element to be practical.

The general concept, regardless, is that these mechanisms allow you to combine present work within the same ticket as prior work on the same job. You can then go through the standard mechanisms to collect the customer’s signature, provide the document to your customer, etc.

One other element is your office can advance prepare a ticket for you, from within ServiceDesk, and you can open, use and augment that ticket here, using the same Past/Prior ticket mechanisms.

Suppose that in a second-visit scenario your completion work proceeds precisely as anticipated on the first visit (and as written-up for in the ticket as made on that visit). Thus, when you open that prior ticket, it already has all the line-items and fees, precisely as they need to be for final completion.Nothing needs to be done with the ticket except perhaps adding to the description that you completed the anticipated work, and adding any present collection of balance due.

We are supposing, in other words, that on the first visit you collected an initial deposit, something less than the anticipated final. On the second/completion visit, you need to collect the remaining balance.

In the simple scenario as just painted, it’s very easy. Simply open the prior ticket, see what it indicates as balance due, collect that amount from your customer, enter your collection in the Assemble area’s“Money-Collected” section, then use a button within the prior-ticket viewer to add your present MoneyCollected. The Payment’s Received section within the ticket will instantly update to show the added collection, and will now accurately reflect zero balance due.

It’s a tiny bit more complex (though still very easy) if your second visit involves fees for parts or labor that were not contemplated in the initial ticket. In this case, you have to first add-in the items that involve those added fees, to produce a new total (and new balance due) in the updated ticket (use mechanisms above-described to accomplish this).

Once you’ve done that, the precise balance due will be perfectly displayed (as a “bottom-line” summary)within your revised ticket’s “Payments-Received” section. Just glance, see what it is, collect the amount,and enter as per normal. The one trick here is to not be dissuaded by the fact the Print page’s “MoneyCollected” section will be greyed-out at this point. Just like the check-boxes section, it is greyed for consistency when you progress beyond the initial assembly stage. However, because it’s practically needed in particular situations (specifically, the one we are now describing), it remains operational nonetheless.

After you’ve collected and entered this revised balance-due, simply move back into the updated/revised prior-ticket, and click on the button to insert money-collected. Again, the Payments-Received section will update perfectly.

(Especially in an “Estimate-Only” ticket)

In some instances you’ll want to do more than a single ticket, even as connected with a single visit. This is particularly true if you use the ticket-device to work up a quote for the customer, but the customer is not yet ready to say yes. In that instance, you’ll want to save the entire format that involved the quotation, but make a different ticket encompassing solely the work as presently done (in most cases this is likely just your diagnostic fee).

How to accomplish?

Simply email or print the full-work-anticipated ticket as an “Estimate-Only” (i.e., check the button that inserts that watermark as background). Then, use the Print page’s “Save-As” button (bottom-right corner). This opens a dialog where you can save what you just created, but as other than the standard ticket. Your save will be designated as other-than-standard by adding a simple suffix, such as, say,“Estimate” or “Quote” (you can use whatever you like).

After you’ve saved this separate ticket, go back and click on the Preview/Revise button. Right-click to remove all the line-items that do not apply to your current/actual-present-work. Make sure it’s otherwise configured appropriately for the current work that you’re now charging on, have the customer sign, then email or print. The system now has copies of both tickets (the estimate-only, and real one).

In older versions of SD-Mobile the Sign-Disclaimers button (used to present special-purpose disclaimers to the customer for his or her electronic signature) was on the Print page. We belated realized that collecting signature for disclaimers is a function that needs done prior to work being performed, rather than after. For such reason, the button has been moved to the Job-Details page.