What percent of work time in your office is spent on the telephone with customers? Half? Perhaps more? Certainly, it’s a lot. Consider how much you’d save if that time was cut in half, while even better managing the same work flow. We believe, with systems described here, you can do that, and much more.
How much time does a consumer spend, on average, in arranging for a needed repair, calling to inquire on status, working to re-schedule, etc.? Is it five accumulated minutes per repair, ten, twenty? How much time is lost playing telephone tag? How great is the frustration when the customer can’t take care of business unless they manage to call during business hours? How much more would it mean, to them, if they could manage all such matters instantly, and at any hour wanted?
This “handbook” is provided to help you understand how to fully harness the system we’ve created to achieve these purposes.
Organizationally, there are but three chapters here. The first describes general concepts. Among other matters, it provides a simple, itemized listing of the 12 scenarios SD-CyberOffice is programmed to manage. The second is a how-to. It sequentially describes basics of setup and use for each of those 12 scenarios. The third describes ways you can augment and customize, including creation of your own preferred text as applicable in several of the contexts, inclusion of techs’ pictures in confirmation emails, and so on.
If you follow the prescriptions here, we don’t think you can help but reap rich rewards.
Our main objective in the CyberOffice system is to move from a person-to-person and voice-based mode of communication, when working with customers, to one based instead on such modes of automation as can be achieved via email, text-messaging, web interfaces and automated calling. It is to save time (enormous amounts), enhance efficiency and convenience, and wow your customers via a vivid demonstration of how truly hi-tech your company is.
It further serves to convince your customer the significant bill he or she has paid is more than justified. This is because — with so a pungent demonstration of infrastructure — it becomes more than obvious a great deal more goes into the provision of world-class service than just sending out a grease monkey (the common consumer’s perception).
For a highly practical overview in which you can actually see and work in at least some of the interfaces, go here. Scroll down, and you'll you can test several CyberOffice interfaces, pretending you are a consumer.
The primary operative elements in this system are: (1) your own website; (2) a set of specialized web interfaces that are “plugged into” your website; (3) ServiceDesk; (4) a compact utility that runs in the background at one station in your office (called SD-CyberLink, it provides communication between ServiceDesk and the online interfaces); (5) email; and (6) for some functions, SD-Mobile.
Your website is, in general, your responsibility (if you do not have one, we can provide both design and hosting; if interested, ask for details). It’s general role (at least so far as CyberOffice is concerned), is to provide a context for the various interfaces via which your customer will conduct his/her relevant online activity. Those interfaces consist of elements that are essentially plugged-in to your website.
As for the “plug-ins” themselves, the actual interfaces are in fact “hosted” on a Rossware server. Thus, it only “appears” to your customer that, when within these interfaces, they are directly “in” your website. Technically, they’re in interfaces provided by Rossware (though fit into windows within yours). This strategy eliminates any need for you to install, host and manage the machinery yourself, and overall makes the setup much easier.
The compact management utility is called “SD-CyberLink” (CyberLink for short). It’s a tiny program whose job is to periodically upload information to that remote server. This information allows the various interfaces (as provided there) to interact appropriately with your customer. In particular, it will initially upload information about your company and setup (contact telephone number, email address, etc). On a periodic basis (typically once per 10 minutes, though you are free to change the interval), it uploads live data that indicates the days on which you have vacancies for scheduling, and other relevant info.
In addition to uploading information, the CyberLink also downloads information from the remote server whenever relevant information appears there. When a customer books a new job via Scenario 1, for 3 example, CyberLink grabs the info and plugs it into a ServiceDesk Callsheet. When a customer schedules in response to a Scenario 2 or 3 emailed request, the info is likewise grabbed by CyberLink and plugged into ServiceDesk. Similarly, when a customer confirms, cancels or reschedules in response to a confirmation request (whether the request was via email or RoboCall), CyberLink again downloads the response, and plugs the resulting info perfectly into ServiceDesk.
Besides being the recipient of on-line job-creation, scheduling and confirmation activity (as downloaded by CyberLink), ServiceDesk is also the entity via which you’ll generate and send the email requests that initiate Scenario 2, 3 and 4 activities. For each such Scenario, there are contexts within ServiceDesk for initiating these emails, as will be discussed more fully in Chapter 2.
As for entities that send emails, it’s not just ServiceDesk that’s involved. Two other applications also get in on the emailing act.
CyberLink itself is configured to send emails in some contexts. As an example, it immediately sends a confirmation email when a customer first books a job online. Similarly (and if this option is enabled), it sends a follow-up when a customer confirms an appointment (this one invites your customer to use the techtracking feature, and provides a hot-link to make it easy).
SD-MobileLink (which more generally provides information shuttling for the SD-Mobile system) also gets in on the act. If optionally set, for example, it will send an email whenever a tech has a completed a visit but not completed the repair (this one mildly apologizes for the fact the repair could not be completed, promises strong efforts to expedite progress, and provides a hot-link on which the customer can click to monitor continuing progress). As another option, it can be set to send an email post-completion that thanks the customer for their business, and invites them to complete a very brief online survey.
To summarize, the CyberOffice system consists of outward communication and inward.
Outward communication consists, within applicable web-interfaces, of such things as availability for particular days scheduling as applicable to particular zips, job status and technician tracking. It is also provided via a series of different emails as generated by ServiceDesk, CyberLink and MobileLink.
Inward communication consists of info generated by your customer when she interacts via the online interfaces, including her acts when: (a) initially scheduling; (b) re-scheduling after parts have arrived; (c) confirming (or re-booking) her appointment; (d) completing surveys; and (e) miscellaneous other.
All functions from your end are either automated or -- at least -- semi-automated.
The CyberLink installer may be downloaded from the CyberOffice downloads page on our website (https://www.rossware.com/resources/downloads). It runs like most any other Windows installer. We do not update the installer often, which means more than likely it will be installing an older copy of the program. For such reason, we suggest you perform an update immediately after doing the install.
We also want to emphasize the importance of one detail. Please be sure to follow the advice (as provided in your introductory email) to setup Windows so it will auto-start CyberLink (at the computer where you’ve determined to run it) when Windows itself boots.
Otherwise, humans being what we are, there is every likelihood you’ll forget to re-start CyberLink after some Windows rebooting event, and for some indeterminate period you’ll have customers going on-line to schedule themselves, with no prompt acknowledgement being sent (not a good impression to give your consumer), no information popping into ServiceDesk in response, and so on.
For obvious reasons, it’s important for that utility to run 24/7.
If you’ve previously setup for reception of automated dispatches via ServiceBench, ServicePower, Samsung or LG (using any of the applicable DispatchLink utilities), it follows you already know about (and have implemented) the ZoneScheduler system within ServiceDesk. In such a case, there is likely no need to read further in this section.
The exception would be if your ZoneScheduler setup is configured to use just one zone, and is also using the option that allows you to forego creation of a ZoneList.txt file (with this option, all related functions assume every job fits within your one [default] zone). CyberOffice cannot directly rely on this mode, because it needs an actual list of zips, to upload to the CyberOffice server (in turn, this allows the on-line scheduling interface to know if a consumer with a given zip is a legitimate candidate for scheduling).
Given this need, you must at minimum provide CyberLink with a list of zips. To state it otherwise, even if you’ve otherwise setup the ZoneScheduler system, but have chosen the “no-ZoneList-file,-default-zone-only” mode, you’ll in fact have some zone-setup work to do for CyberLink.
If, in particular, you want to stick with that mode (whether already setup that way for other purposes, or setting up presently), you can satisfy CyberLink’s need for a list of zips by making a different file.
Specifically, please make and save to your server’s \sd\netdata folder a file called ZipsForCyber.txt. For contents, simply place in the file one line of text for each zip you want to offer for service within CyberOffice. Each such line should consist simply of said zip, and nothing else.
Again, if you’ve setup ZoneScheduling in ServiceDesk for other purposes (and without relying on the “no-ZoneList-file” mode), there is no need to even be concerned with this. The simple bottom line is that the CyberLink program needs a list of zips, one way or the other.
CyberLink uses the very same mechanisms to determine your availability status for uploading to the remote server (which allows it, then, to present available scheduling dates to your on-line customers).
If you have not (by reason of such prior use) already had occasion to acquaint yourself with ServiceDesk’s ZoneScheduler system, it’s time to do so now.
The basic concept is to provide a venue in which you can indicate what your job capacity is for given days. Based on this, programs such as those DispatchLink utilities and CyberLink can make a comparison, for any given day, between programmed capacity and what’s actually scheduled—in order to determine if vacancies remain.
An added twist is that, if beneficial to overall strategy, you are permitted to divide your territory into as many “zones” as wanted, each being defined via a list of zipcodes. This is particularly helpful if there are areas you wish to service only on particular days of the week (in which case you could make their allocations zero on other days), or if your territory is so large that it’s impractical, say, to have techs that normally work in one region cross-over and help out in another region on days when their area is light and the other heavy.
At any rate, if you’ve not done so previously, you’ll need to setup the ZoneScheduler system. We’ve long had an instruction document for the purpose. It’s called ZoneSchedulerInstructions.pdf, and can be found in the c:\sd folder at any station where ServiceDesk has been installed (look in the root \sd folder of the server drive if you’re setup in thin-client mode).
When you examine the CyberLink utility’s interface, you’ll see it has a button labeled ‘Upload Core Values.’ That button’s function is to upload, to the remote server, several details about your company, including the zipcodes you service. Importantly, it also uploads from the ServiceDesk UnitInfo system its lists of machine Types, Makes and Selling Dealers.
The web-scheduling interface needs these lists so it can present them as dropdowns, to your customer, when she schedules on-line.
Given that such lists will be presented to your on-line customers, it’s a good idea to make sure you’ve got them cleaned up and optimized, within ServiceDesk, so your customers will see exactly what you want them to see.
And then there’s option 2.
We’ve ran into a couple of users who wanted to maintain very extensive lists within ServiceDesk, while presenting more limited lists to the on-line customer. If you’d like to do this, simply make a new copy of the UnitInfo.mdb file (as found in the \sd\netdata folder on your server). Name this new file UnitInfo-ForWeb.mdb, and place it in the very same folder. Open this new file in Microsoft Access, 2 remove all the tables except the three of concern (DealerList, MakesList and TypesList). Then edit the lists to preference.
If you don’t possess Microsoft’s Access program, there’s an easy workaround. When you make that copy of the existing UnitInfo.mdb file, save it (and this is prior to re-naming it) to the \sd\netdata folder at a station in your network (but not the server itself) that’s operating in Thick-Client mode (i.e., it has its own set of \sd folders). Then, at that station and from within ServiceDesk’s Settings form, momentarily set it to use its own c:\ drive as the server. At this point, ServiceDesk (at such station) should be using other than its normal operating files (i.e., what you’ve placed into its local c:\sd\netdata folder, including your to-be-edited copy of the UnitInfo.mdb file). From this instance of ServiceDesk, go into the UnitInfo form and use its mechanisms to edit the lists as desired for website presentation. Don’t worry about otherwise messing up your UnitInfo data here, for this is only a copy you’re working with. After you’ve edited the lists as desired, re-set ServiceDesk to use the proper/intended drive as server (i.e., so you’re back to the proper operational setup, looking at real operating data). Now, go to the copy you made and edited (i.e., via ServiceDesk in temporary/not-true-server mode). Re-name it (per above instructions), then copy it into your true server’s \sd\netdata folder (note that you’re not replacing the operating file; you’re simply moving in a new one under different name).
If you don’t have any stations operating in Thick-Client mode (i.e., all are setup as Thin), another workaround (this would need to be done during non-business hours, when others -- including techs in the field via SD-Mobile -- are not otherwise accessing the data) would be to make a copy of UnitInfo.mdb that’s intended as your “this-is-my-real-copy-for-true-operation” instance. Save it elsewhere (i.e., a place that’s safe from editing, outside the \sd\netdata folder). Then use the UnitInfo form from within ServiceDesk to edit the lists as wanted for web-presentation purposes (again, don’t worry about what you’re otherwise doing to the data). After you’ve finished, go into your server’s \sd\netdata folder and do the above-specified re-naming on what was formerly the operating UnitInfo.mdb file. Then, go back to the copy your made at the beginning (i.e., your “this-was-my-real-copy-for-operation” instance) and copy it back into your server’s \sd\netdata folder.
You are, in short, doing a simple dosie-doe, and it’s easy if you simply think it through. Be sure if using the second method, though, that you don’t fail to copy your operating copy of the file back into the server’s \sd\netdata folder. That last step is critical!
As for how the CyberLink utility reacts, it simply looks (in all cases) to see if you’ve provided this alternative UnitInfo file (i.e., the one named UnitInfo-ForWeb.mdb). If it sees that you have one, it pulls the lists (for uploading to the remote server) from there. If not, it pulls from your standard UnitInfo file.
Though not part of our original CyberOffice scheme, it has nevertheless become almost central to it. Quite simply, my.rossware.com provides you with an online interface where you can manage several elements that are pertinent to use of SD-CyberOffice, and review others (it also has some relevance to use of SD-Mobile).
To use the interface, simply go there by clicking on one of the links here provided, or type “my.rossware.com” into your web browser. Once there, login using the same credentials (UserID and password) as otherwise assigned to you by Rossware for use in SD-CyberOffice (in almost all cases these will be the same credentials as assigned to your company for use in SD-Mobile).
According to your preference, need and circumstances, ServiceDesk, SD-CyberLink and SD-MobileLink may all be involved in sending comunications to your customers on you behalf. These communications may be via email, SMS-text-messaging and/or robo-call. Those applications must all be equipped to participate in any such sending as may wish to do.
In regard to emailing, each of involved applications has an Email setup window where you must do the email setup for the application involved (the window for ServiceDesk is accessed under "File Functions"in the MainMenu; SD-CyberLink and SD-MobileLink have access buttons right on their respective application faces. Beyond that, here is a document that provides background information and specific considerations regarding email setup:
(In fact, you may access the same document via a button that's in each email setup window itself.)
Please bear in mind that settings for the email setup are particular to each application and to each user login.
In regard to text-messaging and robo-calling, those require that you use particular setup elements that are provided for you at the my.rossware.com interface. To be more specific, once you have setup for robo-calling there, you are automatically also setup for text-messaging.
As its title implies, this chapter has a section for each scenario of CyberOffice operation. Each section has base level instructions. To emphasize, these are base-level instructions only. You must turn to Chapter 3 to learn about setting up for customized text, and similar.
With each of the above elements setup (and CyberLink properly configured, running, and with its "Core Data" having been uploaded), you're now ready, cocked and primed to begin seeing new, scheduled service requests pop right into ServiceDesk -- wondrously, without any office personnel having expended a moment speaking with your customer.
If you want to pretend you're a customer booking a repair via this system and on your own website as setup pursuant to the above instructions, it's a very good idea. Of course, you might prefer to do this while avoiding any fee as connected with what's only a "pretend" booking. It's easy to accomplish this. Just make the customer's name "TEST" when you setup the pretend online booking. Our billing system is setup to recognize any online booking with "TEST" as the customer name as pretend only, and will create no fee in such connection.
Suppose a property management company calls, seeking service at one of their rentals. Or perhaps it’s a home warranty company seeking service for a policy holder. Regardless, they provide all the order information, and you now need to contact the ultimate consumer, for scheduling.
If not using on-line scheduling, you might very well keep the order information in a ServiceDesk Callsheet, pending success in reaching the consumer and creating the first appointment (at which point you’d then do the Job/Sale transition).
But here's a better idea. Don’t wait. Go ahead. Right away, when you get the order, do a Job/Sale transition from the Callsheet. Then, go to the resulting JobRecord, and there invoke the process to email (or SMS text-message) a scheduling request to the consumer (this presupposes, of course, that you’ve been provided an email address or SMS-capable telephone number; otherwise you’ll be stuck with conventional methods).
How do you do this?
Well, the current-JobRecords form in ServiceDesk suffers from a little challenge. There are more things that can be done there than there is space for unique buttons. For that reason, we’re increasingly making single buttons do double-duty. That is now the case with the ‘Scheduling’ button. Formerly, it had one function: you could left-click on it (or strike Alt-S on your keyboard) to initiate the standard scheduling options.
Those functions are still exactly the same, but now there is a second option. It’s invoked by either right-clicking on the button (as opposed to left-clicking) or striking Ctrl-S on your keyboard (as opposed to Alt-S).
Specifically, this alternative causes ServiceDesk to offer a menu of communicative options whereby it will send a communication to the consumer asking her to schedule. Best among these (there is even one for robo-calling, but it can't do this) are options that include a hyperlink, on which the user is asked to click so as to go to a scheduling interface on your website (of course provided as part part of this scenario). Both emails and text-messages can work in this fashion. Alternately, you may choose any of three forms of communication with a request for the customer to call your office and schedule.
All you must do is take your pick, and ServiceDesk does the rest.
When the customer receives the email and proceeds as directed, she’s taken to a very nice interface where the scheduling task is performed. Within moments, the resulting information will pop perfectly into ServiceDesk (via action of the CyberLink utility). In short, you’ll see the appointment appear in the ScheduleList and DispatchMap, and the narrative JobHistory will be appended to explain who went on-line (and when) to schedule the appointment.
This is much like Scenario 2, except the intent is for use on jobs where the tech has already been there, ordered parts, the parts have arrived, and re-scheduling is now needed.
These communications can be invoked from either of two contexts:
Everything else, from the perspective of what you’re doing within ServiceDesk, is exactly the same as in Scenario 2 (ServiceDesk itself configures the communications appropriately to the circumstance, uploads applicable data to the remote server, etc.).
The notion here is, sometime in the afternoon or evening of each day, you’ve worked out the assignments and sequence of jobs for tomorrow’s work (if you’re not using the auto-time-frame-estimator for this purpose, we highly recommend it). Now you need to: (a) remind your customers of their appointments; (b) inform them of the time frame within which you’re expecting the tech to arrive; and (c) confirm they’ll actually be there.
Obviously, if done via manual means, the above is a very time-consuming and laborious task.
What this features accomplishes is, at your request (or it can even be set to happen automatically, as a backup), ServiceDesk will itself send a communication to each of those customers reminding of the next day's appointment, informing of the time-frame, and asking for confirmation that each each such customer will be there and ready to receive your technician.
If the communication is via email or text-message, it will include a hyperlink on which your customer is asked to click, which then opens an online interface via which confirmation (or cancellation, if necessary) may be indicated.
If the communication is via robo-call, the customer is directed to "Press 1 to confirm," "Press 2 to cancel," etc.
Regardless of the communication form that's involved, each customer's response goes automatically right back into ServiceDesk. When you arrive in the office the next morning, you can look at the tech-list area in the DispatchMap and see, next to each appointment reference, a symbol that indicates if the customer has confirmed, or not (there is an alternate "durable" display that will continue to show this even after the normal symbol indicator has changed to show further progress during the day). There is even a little snippet added into the narrative JobHistory describing the confirmation.
You will want to do some setting up in ServiceDesk on this feature. We have a document that is specifically about that:
The above document also describes how to trigger the send-outs of these communication each day.
The idea here is, when the tech has already had his visit on a job and could not then complete it (likely because parts had to be ordered), and when the customer finds herself wondering (perhaps a few days later) what's happening on the job, there is no need for her to call your office so as to inquire. Instead, she can go to a nice online interface and see exactly what's happening.
There are two paths by which your customer may, potentially, get to that online interface.
One is, after the technician has completed any visit (and where the job still not complete), SD-MobileLink can send a communication to the customer informing of the availability of this status-checking resource, and with a hyperlink that will take here right there, with her own job already selected and shown. To enable this sending, you just need to activate a particular checkbox in SD-MobileLink:
The second path is you may provide one or more buttons on your website, on which your customer is invited to click, so as to check on job status. To get the url that needs to underlie such buttons, go to your my.rossware.com interface.
Regardless of which paths you provide your customer, it's essential to this feature that needed data is provided online. To enable this, it's essentialy that you have this box checked in the SD-CyberLink program:
You'll notice (if looking above) there are some other checkboxes associated with Job-Status Checking. If you float pointer over those while in the actual application, ToolTips will display with brief explanation. We do want to make a point here. It is that we very highly suggest that you expose to your customer the "whole history" (this refers to the JobRecord's narrative history) your your customer.
To be sure, many service companies object to this concept, fearful that embarrassing stuff might have gotten into such narratives. There's a simple solution: assure you're diligent on every job, that that embarrassing stuff is never added into these narratives. When you customer is allowed to see each dutiful step you are doing on her job to bring it to completion, it can mean a lot.
Setup for this scenario closely parallels what’s done for Scenario 5. In fact, it parallels so closely you may use the same instructions as found in the 2nd through 8th paragraphs of the preceding section, and simply adapt, as obviously applicable, for this scenario.
Where a substantive difference arises between is in the method used to provide your customer with an email hyperlink that enables "hot-visits" to the web page in question (here, it’s your tech-tracking page, as opposed to your job-status-checking page) — in particular, in providing an email that gives your customer a hyperlink to open the page as for a particular job, as opposed to merely having "cold-link" buttons provided on your website.
You may recall from the prior section that we are presently configured to have the program optionally send emails after any visit where the tech did not finish. These emails express regret the job was not completed, and provide a link the customer may click on to monitor the job’s progress (i.e., Job-Status Checking).
The parallel for that here is simply in a different place and operation. Specifically, it’s provided via the utility itself (i.e., is not "farmed out" to MobileLink), and, instead of being paired to the tech’s non-completion after a visit, it’s paired to the Scenario 4 Confirmation
process.
Specifically, after ServiceDesk emails the customer to request confirmation of a next-day’s appointment, and after the customer then proceeds to your website’s online interface to make that confirmation, the CyberLink program immediately follows with an email that says, essentially, "Hey, thanks for the confirmation, and... incidentally.... if tomorrow you happen to be wondering how your tech is running, click this link."
Presently, the CyberLink program will do this automatically any time it downloads an email-triggered appointment confirmation — assuming, at least, you’ve otherwise set it up to accommodate technician tracking. In other words, we have not presently given you an option to NOT have such emails sent, you’re otherwise using the online confirmation feature, and you’ve otherwise setup your system to offer technician tracking. If you happen to an "off" feature for this, you’ll have to let us know.
This is a system we added in 2011 for the sake of giving you supremely-valuable metrics via which to measure customer impressions, and the effectiveness of both office and technical staff in creating robust customer goodwill. It uses the system, which employs just four simple (rate-on-a-scale-of-one-to-ten) questions. These questions are so cleverly engineered that it enables targeted measuring of specific employees, and positively DOES NOT impose an unwanted burden on your customers.
To implement the survey system is simplicity itself. Simple “turn it on” via a provided checkbox in the SD-CyberLink interface:
With the box checked, as SD-MobileLink program downloads any PVR on which the job is complete, it will email the customer a polite little request asking if he/she will complete an extremely quick survey. If the customer consents by clicking on a provided link, he/she is taken to the following (except it will have your company’s name on top):
Your customer completes the survey and the information auto-compiles for you. To review and analyze results, just login to your dashboard, and pick "Survey System" from the sub-menu. You’ll then see a series of pages where you can look at individual surveys (along with customer comments), overall statistics, and metrics as applicable to each of your personnel (the system knows behind-the-scenes who took each call, which tech did the work, and so on). There’s even a page to compare your company’s score with the average of companies using the system, and to customize text as presented to your customer.
Another feature (in particular, on the Customize page) allows you to set a "Low Scores" threshold. The simple idea is you may want to receive a direct alert (via email or SD-Mail) any time a customer is significantly unhappy. This allows you to proactively contact the customer and seek to turn their feeling around (you can imagine just the fact that you care enough to make the effort is likely to have a large effect on customer feelings). Besides setting the "Low Score" threshold at which these alerts are triggered, you may also designate the particular email to which they are sent.
Added most recently is a box (also on the Customize page) where you may set a "High Score" threshold. The idea behind this is, if the customer was very delighted with you (in particular, as indicated by the level of “High Score” threshold you indicate), it’s likely to be highly beneficial if you invite him or her to post one or more online reviews regarding your company (e.g., to Yelp, Google Reviews, etc.). It’s likely even a better idea if you provide a hyperlink on which he or she may click so as to go right to such a site and then review.
In other words, you’ll likely benefit enormously if such a delighted customer sees something like this (embedded within the context of your own website, of course):
To setup for such a Link-to-External-Review-Site response, requires just three things:
What happens within the underlying machinery, basically, is as each survey completes it looks to see if you’ve provided the special (i.e., “with invitation”) thank you text. If you have, and if the survey reaches your designated threshold, it presents that particular page setup as
opposed to the standard thank you page. It’s really that simple.
Using this added mechanism is totally optional, so far as your use of the system is concerned. We believe, however, your use of this option can serve to dramatically increase the quantity of positive reviews that are posted for you. That, in turn, should serve to dramatically
drive new COD business in your direction.
We first made this feature solely for Rossware-direct use (i.e., to facilitate our clients requesting emergency/after-hours service from us). Having made it for our own use (as provider of service to you), we realized some of you might like to use the same mechanisms to offer emergency/after-hours service to your customers.
The underlying concern, when structuring something like this, is you do not want to have your personnel woken in the middle of the night (or interrupted while in the middle of a holiday celebration) on the basis of mere customer whim. If a customer or client is going to create this kind of imposition, they must be willing to pay a commensurately large sum in exchange (getting someone out of bed or similar is a pretty big deal, after all).
So, we’ve structured a system that will allow your customers, via an interface on your website, to pay whatever large sum you determine is required, and once that amount is actually transacted (via online bankcard), mechanisms then pop into place to text or telephone a succession of personnel you configure, to assure the customer receives the emergency response he/she bargained for.
The beauty, in other words, is you can set a significantly large sum (say $300) and no one is awakened until and unless the customer first pays it. The customer ends up happy, because (even if expensive) he/she was ultimately able to get the emergency response needed. And you and/or your personnel are happy, because, though it’s not nice to have to respond in the middle of the night, if you’ve made the fee sufficiently high, it winds up being rather well worth it (depending on where you set your fee, it’s also likely to be a relatively infrequent event).
To setup for provision of this option you simply must navigate to the "Emergency Rescue" setup page within your login, configure there as needed, and “turn-on” the feature within your SD-CyberLink interface:
Then of course, stand ready to exceptionally please the occasional customer in desperate need, and to somewhat enlarge your revenue.
We began adding RoboCalling functions in early 2012, and have found them to be a tremendous hit. If you do not know, RoboCalling means a machine makes a telephone call for you, and uses a synthesized voice (following a programmed script) to speak with your customer.
Again, basic setup is done via your login (select “RoboCalling” from the menu there).
Once you’ve done the underlying setup, use of RoboCalling depends on the particular context. For Scenario 3 (to request scheduling from the customer when parts arrive) and for Scenario 4 (to request confirmation on an appointment), when you’re in the applicable context within ServiceDesk itself, you’ll be presented with an option whether to email or RoboCall, and can proceed per preference. In fact, you’ll see there are sub-options, such as to prefer email if an email for the customer exists, and otherwise to RoboCall instead.
In regard to appointment confirmations, the RoboCall script is configured to request the customer press one telephone key to confirm, another to cancel, etc. The result pipes automatically right back into ServiceDesk. It’s a little less powerful in regard to options offered than is the email-triggered online interface (no ability for the customer to actually reschedule without talking to a person), but is reasonably effective, regardless.
Much like the Survey option, this is another that pre-supposes you’re using SD-Mobile (it would hardly be applicable if you were not). To setup (and assuming you’ve first done the RoboCalling base-setup via ), simply check the enabling box within your SD-CyberLink interface:
With that done, it will cause your techs in SD-Mobile to encounter a new experience. As they finish one job (and assuming it’s not the last in their day’s lineup), they’ll get a prompt something like this:
All it takes is your tech’s simple consent for the RoboCall to go forward to the customer (or a tiny bit of quick user interaction to provide an other-than-standard “I’m on my way”). People love this. We are planning to add an email-customer-tech-is-on-his-way option (and configure the email to include the tech’s picture), but this is one we’ve not gotten to yet.
The idea here is you may want some kind of telephone call to go to your customers when the job is completed. Though you could make any kind of message as wanted, the users that particularly wanted this were envisioning something like this:
Given this basic concept, we realized folks wanting post-completion RoboCalls might want different scripts employed for different contexts (and might also prefer different timing in regard to when the calls go out). Given this, we’ve setup to allow such variation. Specifically, there’s a dedicated section within the SD-CyberLink interface, as follows:
Focusing first on the bottom-half of this section (under the heading ”calls to go out:”), the general idea is you may choose for these RoboCalls to be made within a few minutes of the tech leaving the home (with his repair completed); or that evening (at an approximate time you specify); or the next day (again, at an approximate time you specify). It's that simple.
We'll now move to examination of controls in the top-half of this section (those under the heading "use script type:"). Again, it's simple. If you want post-completion RoboCalls going out on your COD jobs, simply set the script number you want used for that context (otherwise leave blank in lieu of the number, and no calls such calls will go out on this variety of job). Ditto for calls as made to the consumer where the job involves a third-party-payer other than those for which you specifically designated a particular script.
Regarding that last sentence, you may notice it implies you can designate particular scripts for use with specific third-party payers (or, more properly, for use with the consumers associated with them). But, you may notice, there is no place in the above-shown section of controls for such specific-to-particular-payer script settings. That's because, if you want to pick a script for use in conjunction with any particular third-party payer, it's done from within ServiceDesk itself. Specifically, there is a setting for this purpose in the QuickEntryTemplate form, as applicable to any such payer:
The idea is simple. If you want a particular post-completion RoboCall script used in conjunction with consumers associated with a particular third-party-payer client, simply designate the script number, in that client's QuickEntryTemplate. Okay, but what about all this regarding scripts and script numbers? Where do you get or make those?
This is another function to perform via your my.rossware.com interface. There is an interface there (under menu-selection “RoboCalling”) via which you can create and manage up to five separate post-completion scripts, each identified via sequential number.
So, setup your scripts (or just a single one if that’s all you want), and set to use those you want in the contexts you want. That’s all there is to it.
If you have read and implemented the descriptions as provided above, you should now be setup for basic and effective CyberOffice implementation. Regardless, things can always be made even better, and that is what this chapter is primarily about.
You may recall that in our discussion on Scenario 1 we described how it’s optimum to setup any "Book your repair now" button, on your website, so that when it hyperlinks to the online scheduler it places that scheduler interface within a frame that’s embedded within one of our own webpages. This maintains a fully professional and trademarked-to-your-business consumer experience, along with a comforting sense of continuity. In that context, such embedding is easy. It’s a simple matter of how the link is structured from within your own web design.
To contrast with that situation, there are several CyberOffice interfaces that are consumer-accessed via hyperlinks as embedded within emails (these are emails that your system will be creating and sending to the consumer). Since these emailed hyperlinks directly reference Rossware machinery (and not elements that reside directly within your website), it is a somewhat more complex to make the interfaces appear within pages of your website.
In particular, Scenarios 2 through 4 involve emailing to request initial booking on a third-party-dispatched job, emailing to request re-scheduling after parts arrive, and emailing to request appointment confirmation. Scenario 5 involves sending an email that invites a consumer to click in order to track his/her technician on the day of the appointment. Scenario 6 involves sending an email that invites a consumer to click in order to check on job status, after a technician visit that failed to result in completion.
Regardless, don't worry, we've made the solution easy. Instructions are in this document:
How to Add or Change iFrame Embed Codes
As an added consideration, though our primary topic in this little sub-section has is about making system-created and email-linked interfaces appear within the context of your own webpages, there is another situation you may want to employ. Specifically, you may have occasion where wanting to embed the Scenario 1 (initial job-creation and booking) interface within one of your own webpages, but when called from a hyperlinked context outside your own website.
Suppose, for example, you have a property management company that uses its own custom software, and they want to have a button on which they may click to instantly be in your scheduling interface. Or you have a dealer that similarly wants a button. Or you are in email correspondence with a potential customer, and you want to reply with something along the lines of:
"Sure, we can do that; just go ahead and book your job by clicking this link."
In any such case, you could make a hyperlink that:
(a) goes to your own webpage where there is a further button to click on for scheduling (in which case embedding the resulting interface within your webpage is simple); or
(b) directs to the naked (not embedded within your webpage) initial booking interface (a link such as "https://sched.rosssware.com/?id=XXXX", but with your business id instead of XXXX, would be sufficient for that).
Obviously, though, neither of those would be most desired.
To create a link that takes such a person directly to your initial booking page and embedded in your website, just follow the same formula as is described in the document referenced above.
In several contexts, CyberOffice presents the consumer with communicative email text: sentences and paragraphs hat are designed to convey important elements of meaning. In some cases, communication may be via RoboCall and/or SMS Text-Messaging instead. Regardless of context, we’ve done our best to pre-“can” any such language as is involved, so as to make it optimum for wide acceptance and maximum clarity.
However, we recognize you may want to have text presented differently. Thus, we’ve configured a mechanism via which to allow customization. We have a separate document that details precisely how to do it. To view that document, click here.
This is one Mrs. Consumer loves: having a picture of the technician before he arrives. It adds a safety element: she can look past her door and be confident it’s really your guy, before opening, because she’s already seen a picture of him. It also adds nicely to the aura of professionalism surrounding your company.
To setup for inclusion of tech pictures is very simple. At core, all you must do is place the desired picture (as appropriate to any particular tech) in the correct folder online. When you request sending of confirmation emails in ServiceDesk, it will look in this folder for a picture corresponding to the applicable tech. If it finds the picture, it will include it in the email. Otherwise, it will proceed per normal.
In regard to each tech picture, there are some caveats.
That’s really all you need to know about setup. Rossware machinery takes care of the rest.
To be more specific, when ServiceDesk is creating a confirmation email, and when it finds a picture exists for the assigned tech, it inserts that picture within the email just after the email’s reference to the tech’s name (inserting a double-line space both before and after the picture). This makes for a nice appearance, and will work with either the default confirmation text or your own customized text.
It’s quite obvious that much of the automation, as here discussed, depends on having your customer’s email address. For customers who’ve initiated their jobs online, that’s not an issue (the email address comes, part and parcel, with the job).
For customers who order their service conventionally, by contrast (i.e., via telephone), your call-takers must ask for a new item of information. You’ll have to overcome some inertia, in this regard, because your call-takers are not used to doing it, and we all know human nature. Certainly, you could institute some reward program to encourage call-takers to change their habits, but our thinking is that the most important factor is assuring they are trained to ask for the email address in a manner that keeps both they and the customer
comfortable. Much of that effort, we believe, is teaching them how to use optimum dialog.
For example, one way of requesting the email address would be as follows:
You should teach your call-takers that, with so simple a statement, the consumer is simultaneously assured you have a valid need for her email, and she’s put on notice she should be checking it while the repair is pending.
An alternative dialog, after having asked for and received regular address and telephone numbers, could be:
A little role-playing and rehearsal with your call-takers is likely all you’ll need to get them going. Maybe even make a party of it, with refreshments, and so on.
You likely also should include a little practice as to how to react when a customer says they have no email. Our thinking is a simple reaction such as this should suffice:
Don’t underestimate the effectiveness of role-playing, especially in a group setting. It may seem corny, but it works. On top of that, if you have some kind of special meeting for the purpose, it will imprint far more indelibly in your call-takers’ minds that, henceforth, they really will be doing their jobs differently in this respect.
One more suggestion is that you role-play how to give assurances when a customer is worried that her email address might be used for marketing. Actually, you first need to decide what your policy will be in that regard. Most obviously, you’ll never share the email address with others, and that can be one level of assurance for the customer. But an intermediate question is whether you’ll allow yourself to use the email address for your own marketing. Our recommendation is no, for this allows your call-takers to assure the customer that the email will only be used for managing the job. But you need to decide (and inform your call-takers), so they’ll know just how much they can honestly promise. Be sure you rehearse with them, so they’ll know how to do it optimally.
Our estimation is that, if you follow suggestions outlined here, you’ll be able to acquire email addresses in at least 90 percent of cases where consumers phone in seeking service. That’s now, in 2012. In a very few years, we figure, it should get extremely close to 100 percent.
Of course, today that is only one method of receiving job orders. In particular, you may have a significant percentage of orders coming from home warranty companies (hopefully, automated via our EmailedDispatchReceiver). You may have another percentage coming directly from manufacturers (hopefully, automated via our DispatchLink utilities).
Regardless of the method, it will obviously be strongly to your advantage if these third-party vendors of service provide the consumer’s email address, as an added element in the information conveyed to you. For any that do not do so presently, our suggestion is that you beg, plead, kick and cajole—seeking to persuade them to do so.
Remember, yours is not the only voice. If you’re pestering a particular entity (like, say, American Home Shield), and so are several of your compatriots, there’s a hope (at least) that eventually such voices will be heard (if you’re curious, at Rossware we’ve long been on the campaign).
To the consumer, scheduling on-line can be a huge convenience and attraction. For that reason, we suggest promoting the concept broadly. Advertise the ability (with appropriate url) on your business cards and invoices, in your yellow pages ads, on stickers that are attached to the machine that’s been repaired, on promo magnets, and so on.
On your website directly, we suggest making the ability to directly book . It’s a big sales feature, after all. In fact, if you have one of the fancy websites with several different pages, it’s likely a good idea to have a big prominent button on
We also suggest modifying your recorded voice greetings to inform consumers that instead of waiting for your return call or in the queue, they can go on-line to schedule their repair. No doubt, a good many consumers will say “Yea, that’s even better.” They’ll hang up and do it post haste—thus assuring you actually get the job (i.e., they won’t call someone else after losing patience when waiting to communicate with you). Plus, your queue will be trimmed for others.
You might also train your techs to casually ask the consumer, as they’re engaged in conversation, if the job was booked on-line. If the answer is no, that will lead (quite naturally) to discussion of the fact that it was an option.
All of this should further distinguish you, and give you a significant edge over the competition.
Beyond direct-to-the-consumer promotion, don’t forget those who order service (or might to do so) on behalf of consumers. Property managers are one strong possibility (how much more would they like to be able just to go on-line and order service?).
Most particularly, what about those local dealers that you’d like to have always send work your way, instead of to a competitor? Go there. Show the sales personnel how easily and immediately they can book a job for their customer. Sales people to be heroes. Give them the means by which to do so, and they’ll love you for it. More importantly, you can then all but count on the work being yours.
One day Karie and I, here, were surprised to learn that an early adopter of on-line scheduling was using it for a purpose we’d not thought of. He employs a couple of gals that handle incoming calls from their homes. Instead of bothering to network them into his office, he simply has them go on-line to his scheduling page, and book calls in that manner.
It’s possible you could have a commercial answering service book calls similarly. We’re not sure of all the potential variations, but we’re betting that, with the imagination of all you clever folks out there, we’ll hear of still more cool ideas. Please let us know.
