Skip to main content

Broader Process Sharing - Service Request Fulfillment

While at a BMC UserWorld conference a few years ago, I wrote the following. It still applies and I wanted to put it down in a permanent spot where I could find it later.

==========

We're perfecting the Service Desk call center. What would it look like if we invited other campus support units to share our processes and tools, if not our Service Desk?

My recent experience moving into a new building has sharpened my focus on this issue. I'd like to share a taste of my experience by way of introduction and illustration of my implementation recommendation.

In my new office, I need to obtain keys, request door locks to be installed, deal with furniture alterations, move network and power outlets that were obstructed by furniture, request appropriate signage for our department, order new furniture, resolve electrical wiring problems involving and interface with the furniture, request building card swipe access, request thermostat adjustments, and request permanent placement of a projector in our conference room.

All of these tasks dealt with different departments, but involved a nearly identical process. I needed to locate the appropriate contact and submit a request, either via telephone, email, or web form. The service requests involved some degree of personal consulting and approval. I then had to track the progress of each request through to completion.

With each department, the procedure to request and track the service was different. Some of my requests were immediately taken care of. Others were more troublesome. In one case, the department marked the work as complete even though it hadn't been. There was no uniform way for me to learn the status of my multiple requests or to provide feedback to the various service entities.

It would be ideal to have a unified Service Request Management tool that allows users to browse a service catalog, understand pricing and billing options, request service, track order status, receive notifications, add comments, and evaluate completion. Such a system would act as a front-end interface to other existing systems. The work isn't completed in this system, but merely tracked within it. Since we expect each department is already tracking this workflow in some way, we wouldn't expect this to be an increase in work, just a modification.

The benefits in efficiency and customer satisfaction in such a system would justify a significant investment by the university in such a tool.

Comments

Popular posts from this blog

Sitting or Standing at Work

I've read some stuff about the negative effects of sitting for prolonged periods of time. As a consequence, I've been experimenting with standing more at work when the task will permit it. I've been enjoying it. I think the next step to make that work even better would be to get a desk that can quickly raise or lower. (The glacial speed movements of some electric raise/lower desks would discourage much use.) Here are some resources I've found interesting.

NY Times article is a good summaryThis piece from Exercise and Sport Science Reviews is co-sponsored by Steelcase, the furniture makers, so I must take it with a grain of salt, but it recommends standing as an activity that should be categorized as superior to sitting, whereas they have been both lumped together as "sedentary" in previous literature. An abstract with says standing or sitting on a therapy ball are about the same, and both more active than sitting in a chair. This survey of papers says the resu…

Preparing for New Ratings System

In January we will start in earnest on rewriting the "Student Ratings" system. The system is to allow students to rate their professors and the courses they are taking. (I am hoping we can change the name of the system to better reflect what it does. We aren't rating the students, after all. That is what grades are for.)
Gene and I had a good conversation with Nate W. and Tom M. today about the general design principles of the system. This is a project where we are going to try out our model of having separate teams work on the UI and the web services and treat them as parallel projects. Our hope is that we can get better and more reliable web services if they are ONLY way to talk to a system rather than just the tack-on way that the main programmers don't use because direct-to-database is faster.

How much will you remember?

There is a commonly passed around "stat" that, according to a blog post I recently read, isn't true. You've probably seen it or heard it.

It is said that people remember:10% of what they read20% of what they hear30% of what they see50% of what they see and hear70% of what they write and say90% of what they say as they do
The blog author says:
Quite where these numbers come from is a mystery to many, and indeed it is difficult to understand what 90% retention actually means… 90% of what for how long? As a model it looks and on first thought appears to be credible, however as many of us will know some people have almost 100% retention for a considerable period of time if they read something, others teach others from a structure or procedure which they themselves do not understand!Thanks, RapidBI, for pointing out this common misconception!