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.