Service Desk Soft Start

A month ago, I talked about an information systems module for our service department.  Since then, Amici's IT and Service department have held a few meetings on expectations and mock ups of the module, not surprisingly called Service Desk. 

Service Desk was designed after our company's short-lived experiments with Request Tracker and OTRS, both open source web-based issue trackers.  We did not push through with web-based issue trackers because we needed a customized system well integrated with our current stack.  We were not looking for a help desk system, but instead a service and schedule management system.  OTRS felt too IT-ish, which our company is not.  Request Tracker lasted longer (two weeks) but lack of integration to our CRM proved cumbersome.

That was two years ago.  Service Desk collected dust instead of improving our service because the process to interface with it, the overall structure of our Service Department was only to be stabilized two years after.

Last Saturday, we formally introduced Service Desk to our sales force.  Rather than the original rudimentary table design that stressed outstanding service requests, it sported a new employee daily schedule interface that gives focus on scheduling constraints and resource management.  The table design is still available as an alternative view, but for the main target users, our service managers and our sales team, the daily schedule view remains the obvious choice.

Sales brought up an obvious request.  Should not Sales be allowed to create the service requests themselves?  Then, our service managers need only to monitor outstanding requests so that they can schedule them appropriately.


This option is readily available, should service request processes be revised.  In fact, this was the original design of the Service Desk.  However, it remains to be seen whether the size of our company shall warrant the process change.

Right now, when Sales request services, they usually call any one of three service managers to relay details and wait for an SR number.  Sometimes, it's easier to jot down details on a small sheet of paper and to hand that personally to our service managers.  Unfortunately, in practice a lot of waiting may have to be done either way.  Jotting down details on paper also duplicates encoding of the service request.

The proponents of the separation of duties for Service Requests and Job Orders espouses the advantages of the analogous Sale Order and Sale Invoice system.
 The requestors will themselves encode their requests, reducing the encoding bottleneck  by a factor up to 7 (20+ people to encode their own requests, rather than 3 to encode everyone's requests), and also reduce typical errors such as misspellings.  A standard work flow for requesting service is simply clicking on a Service button from the related Sale Invoice to automatically fill up fields and link the sale to the service request.  Service Managers can then focus on providing appropriate schedules for all outstanding requests.

The communication pattern between requestors and service managers will be different.  Instead of the current poll-waiting method whereby Sales busily waits for an available Service Manager to communicate his requests, a message passing, event-driven methodology becomes natural.  This is akin to email instead of the telephone.

Requestors will not have to wait for an SR number.  The computer system automatically provides a request ID and even notifies requestors via email any updates on their requests.  Service Managers will be notified of any pending requests and are free to schedule them.  Scheduling those requests in turn automatically notifies requestors of the new schedules.

I believe the SR <> JO system is appropriate especially for big companies.  The poll waiting communication pattern is obviously inefficient for large volume of issue/service tickets.  For our company however, our lower volume might not  give enough points to either methodologies.

Service Now Next Door

Along the restructuring of our service group this early came well thought plans, wishful experiments and wide-eyed thinking.  Within a few days from conception, we now have service request forms printed in triplicate, serialized, carbonized, glued, and in archaic colors.  Our service team has left the cramped office for a more spacious room.  They got some local phones sometimes working and then some.  Internet connection and wiring was assisted by yours truly.  And just today, they have another computer to play with!


The service request forms serve to put in writing whatever service is tasked to do.  And by that, I mean anything.  It actually surprised me the first couple of times I saw some non-operational tasks put in the service forms.  The service request forms (which I secretly call Job Order forms (because that's what I called them back in July last year in its computerized version)) are creatively colored white, pink, and yellow.  Not.  They're also conveniently segregated into two series: A and B.  I'm not sure which service group is A and which is B, but I'm pretty sure the service group has that written somewhere.  Last week, I was trying to encode some of the forms in the computer.  Unfortunately I encountered quite a number of cacographical issues.

I think they'll have to have some kind of filing cabinets sooner or later.  Although from what I see with the implementation so far, you wouldn't want to browse through them just to look for one particular form.  Thinking about filing so much data makes me want to study library science some time.

The service team has finally left our office, to the rightful dismay of office mates who habitually answer the phones.  One thing that made service a bit problematic was that it can be hard to get in touch with them.  Sometimes, you can't get one complete sentence from them without some preemptive phone call to distract them.  Although the communication issue is with much merit, the space problem is just as big an issue.  We have now three guys (1.4 + .75 + .85 = 3) sharing one chair, one table, one computer and half a phone.  When they get visitors (and they get lots of them), it can be crowded.  So moving them out sort of won that one.  At least temporarily.  I think the communication issue can be fixed in more creative ways.

Which is why they now have two local numbers.  Three would have been better.  But right now, the two are not yet perfectly working.  So let's work that out first.  It would have been fantastic if they can have a sort of local trunk number which our main office can dial to ring any available phone on their side.  That is certainly plausible if I can convince management to invest in an Asterisk server to replace our dinosaur of a PABX.  Other options include video intercom and instant messaging.

What happens if you've got 3 computer novices in an air conditioned room, well hidden from prying eyes, and  two computers with internet?  Chess death match anyone?  Well not really.  They haven't gone that far except for the nearly ubiquitous Facebook.  Now one is helping the other how to do some Empathy, while having fun with Cheese.  Then there's the question of how to shut down.

Service Revamp

This morning held a much awaited sales-service meet.  I would say much awaited as I've been expecting a major restructuring of service for a while now.  Our company has met much difficulties the past couple of years, ballooning in expenses and manpower, as well as service requests and back orders.  We've gone through several persons each doing his or her best to take on the daunting role of the service manager.  There were high expectations to be met.  Some have gone their separate ways.  Some have shifted to roles a bit less challenging.  And then some have persevered through thick and thin, goals met or unmet.  We've added people with different levels of training.  But after the past year, we still aren't there.  We're in much need of foundational and procedural improvements.

Unfortunately, I wasn't able to join in much of the meeting.  Actually, I might have missed the session completely if not for perky ears on an early curious morning.  I did my best to attend, even if I felt somewhat uninvited, although I skipped the delicious breakfast of tuyo and salted eggs -- dietary compulsions. Alas, with other important things to attend, it seems I only got to the intro and finale.  It might have been exponentially interesting to get to the gist of the meeting.

What can we expect?  From what I see, there will be papers and more, and trees crying.  Service order forms,  return forms, differentiation of repair and delivery/installations -- seems standard fare in traditional companies.  They will do much good in making our service operations measurable -- as long as they're properly implemented.  Splitting the service group to Repairs and Delivery/Installation can help in response times and specializations.  Ultimately it will be about customer satisfaction.  Expect things to become much much better.

~~~

As a side note, it seems I can't say much given how out of the loop I sometimes feel now about various company processes.  As I'm more of an IT and Supply Chain personnel, I'm still trying to see how the changes will fit in the overall scheme.  On one end, it's disheartening not to have input about the changes being implemented.  I've already wrote a service module in our in-house enterprise system, though it needed more love and attention, and actual use and tuning.  (I'm all for evolutionary programming, although right now I'm by myself.)  On the other end, I'm still excited to work on redesigning the service management module.  The past month, I've been contemplating on getting more hands-on service management experience.  There are naysayers on implementing it through computers, valid reasons all -- personnel "computational complexity", keeping things simple, etc.  But I don't really see the conflict.  It's a design problem.  That's the exciting part.