Overview of a typical daily process

Having now examined the basic structure of a ServiceDesk “factory”along with the typical sequence for a single jobwe’ll now overview how that all stacks up in terms of the typical sequence of work tasks, throughout the day, in a typical ServiceDesk office. In fact, to make it more concrete, we’ll describe a typical day in our own office.

Beginning at approximately 7:00 am our secretary Brenda arrives and immediately un-forwards the phones (we forward the lines to an answering service when we’re gone at night). She then calls the answering service and informs them we’re ready to receive our messages. They push a button on their end; their computer dials ours, ServiceDesk picks up, receives the messages, and inserts each into a waiting Callsheet. Brenda then begins dealing with the messages. Some are from people who want return calls (which of course she does). Some describe service orders (with appointments) that the answering service booked for us. If the latter (or if she takes a service order herself on the basis of a return call), she finesses the information on the Callsheet somewhat (it’s rarely perfect as received from the service), then creates a job from each (often I’ll hear the printer bang out about five service tickets in short order at this time).

When each job is created, its appointment goes automatically into the ScheduleList (along with ones previously scheduled), and is viewable from the DispatchMap. So, about this time, Brenda takes a look to see what’s shaped up there. She’ll do some juggling, moving this job to one tech’s schedule, taking this from someone else, and so on, trying to give each a sensible route that’s as efficient as possible. If she’s having difficulty, she may ask for my help and I’ll go to work on it (or I occasionally just volunteer).

At the same time, the phone is ringing with new calls. Some are people inquiring about existing jobs, and it’s always a simple matter for her to instantly find all the information she needs to intelligently respond. Others are from people wanting to order service. Most she handles entirely on her own in about a minute, writing the order, scheduling, deciding which technician to assign, and creating the job (as I hear the printer banging out still more service tickets), and so on. Some people want to discuss price first, and these she transfers to me (at the same time transferring the Callsheet, on which she’s already taken some information, to my desk). After I’ve discussed enough to persuade the caller to schedule service, I’ll usually transfer back to Brenda. If she’s presently got a couple of lines going, however, I’ll take the rest of the information myself (filling in the Callsheet), schedule with them, and create the job (thus hearing another service ticket bang out on the printer).

By the time technicians begin arriving at around 8:00 am, we’ve typically got their schedules pretty much filled. At any rate, usually they’re not ready to head out immediately, because first (unless they’ve done it the afternoon or evening before), they need to make PostVisitReports on their previous day’s work. We provide a dedicated desk and computer for them to use for this purpose, and their arrivals are staggered so they’re seldom in each other’s way.

Once each technician has made his reports and turned in the previous day’s tickets, he asks for restock to his truck. Brenda or I strike a few keys and instantly see what he needs, walk into the storeroom and pull it for him, then strike a few more keys to report what’s been transferred. Then he gets the stack of invoices that’s assigned as his current day’s work (which Brenda has put together based on how we sorted out each technician’s route from the DispatchMap), and he heads out to do it. At this point Brenda goes to the DispatchMap and (since the technician has now actually received these jobs) checks off each one as having been dispatched.

When the buzz of arriving and departing technician’s is over (of course with calls coming in intermittently all the time), Brenda is usually ready to begin transmitting Parts Inquiry/Request documents to various suppliers, in response to the requests for non-stocking parts made by technicians in connection with their PostVisitReports (i.e., those just made in reporting on the previous day’s jobs). For this purpose she uses the PartsProcess system, and completes the task in very short order.

With that task done, Brenda will probably next turn to the stack of invoices the technicians turned in. Most are completions, and with them are various amounts of money. She separates completed invoices from those still pending and places each into their own stacks. Checks and Bankcard slips go into a place we’ve established for the purpose, and cash into a normally-locked cash drawer (she keeps a handwritten journal there indicating how much cash was received in conjunction with each invoice; and this can be compared later to the ServiceDesk FundsJournal if there is any discrepancy). She further separates among the completed invoices between those that are paid in full and those that are to be billed. Then with these two stacks she begins making entries into ServiceDesk to record the completed sales. Each invoice is then stamped (with a simple little date-stamper) to indicate the fact that it was recorded to the SalesJournal. Those that are fully paid go into a stack (eventually relegated to boxes) where we keep all completed-and-paid invoices. For those that are being billed she prepares envelopes to mail the billing copy, and puts our office copy into a system of slots we maintain for that purpose.

Other invoices turned in by the technicians, obviously, represent jobs still not complete. Most involve part-order/inquiries (which she’s already done via the PartsProcess system). She puts these into a slot indicating their status. Some may involve jobs where the customer stood us up, or for some other reason needs rescheduled. In any event, she’ll call in the attempt to reschedule each. If she succeeds, she immediately creates a new appointment via facilities in the JobsCurrent form (with relevant JobRecord loaded). Otherwise, she records the fact of her effort in the job’s History (also via the JobsCurrent form), and the invoice goes into a slot that’s provided for this category of situation.

During all this time, naturally, we’re also getting jobs dispatched to us by fax. Brenda’s pulling them from the fax machine as they come in, inputting the information into Callsheets, and calling homeowners in the effort to schedule. When she reaches them, she immediately schedules and creates a job (more banging of invoices from the printer). When she fails, she documents the effort in the respective Callsheet’s MoreInfo form.

By late morning we usually get our UPS shipment. Now it’s Brenda’s task to unpack the boxes, see what’s arrived, and match it to orders we’ve placed in connection with various jobs. For the last purpose she again turns to the PartsProcess system. This helps her match the parts to previous orders and their connected jobs, and she uses the system to document the part’s arrival, its cost, and so on. She then pulls the invoices for the connected jobs, and begins calling the customers to schedule for completion of their repairs. Again, if she reaches and can schedule with them, she does this immediately from the JobsCurrent form, then places the invoice into a slot (hanging on the wall) for the day and technician it’s been scheduled for. If she fails, she documents the effort within the job’s History.

While all these processes are taking place, naturally, the phone continues to ring with new callers wanting service. If they are anxious for service the same day, Brenda does a quick look at the DispatchMap to see if it looks like a suitably near technician can fit it in. If so, she schedules the customer and creates the job (more banging of invoices from the printer). She then pages the technician and places the job’s ticket on her desk as a reminder that it’s not yet officially dispatched. When she finally speaks with the technician and informs him of the job, she’ll go to the DispatchMap and check it off as having been dispatched.

Around noon or so, we usually get our mail. With it there are typically a few checks in payment for past jobs. Now it’s Brenda’s task to match these checks with the physical invoices they pertain to. Then, with the checks and connected invoices in front of her, she reports on these payments using the Funds form. Assuming the invoices are paid-in-full at this point (usually the case), she places them into the same stack of completed-and-paid invoices where we also put paid-up-front invoices (these simply had a detour first before making it there). ServiceDesk will have done the work in the meantime (based on her report) of checking off the Receivable record, making a final entry to the SalesJournal, and so on.

By early afternoon Brenda will have received responses from most of our suppliers on the Part Order/Inquiry requests that she earlier transmitted. If they confirm they are shipping an item, or if they provide a requested price, she’ll enter information accordingly into the PartsProcess system. If it’s a matter that involves calling a customer with a price for their approval, she’ll do this, and document the process within the job’s History, and so on.

In any event, these are the typical ServiceDesk-managed processes that occur every day in our office—and that should (for the most part at least) occur in yours when you’re operating in the ServiceDesk system. Hopefully, this narrative will help you have a general comprehension as to how the various pieces fitthat several can now, in fact, be considerably more automated than described here. Regardless, the basic process is that you manage calls and incidentally create jobs using Callsheets. You then manage jobs from their JobRecords, using several connected systems, including PostVisitReports, the PartsProcess system, the InventoryControl system, the Schedule and Dispatch system, and so on. Finally, you manage completion of jobs by recording each to the SalesJournal, then manage receivables, and so on. That’s it in a nutshell.

Of course (and as an aside here), also remember there are processes that occur more intermittently. About twice a week, for example, Brenda uses the FundsManagement system to prepare and make a deposit. Once a week or so, I’ll use the InventoryControl system to create an order for restock (or perhaps two or three different orders, to various suppliers). Once a month, we’ll create and send billing reminders. And so on.