July 1999
Volume 15
Number 4
Student Self-Service - More Than a Web Front End
It's hard to think of any enterprise these days that still requires you to show up in person to conduct your business, unless there is something physical to be picked up or dropped off, unless you're eating a meal or getting fitted for glasses. For instance, people rarely go down to the office in person to straighten out the gas bill, arrange to have a new telephone line installed, or add a premium cable service. The only exceptions that come readily to mind are the motor vehicle bureau, the unemployment office, and off-track betting, all of which cultivate a faintly penal attitude and don't usually serve as models for higher education. The most up-to-date businesses don't even require you to talk to a representative by phone. They let you cancel a book you've ordered or place a buy order for stocks by using a Web browser.
In contrast, student administrative services at many schools work on an older model. If you want to remove a hold or get into a class that you need desperately, chances are you will go and wait your turn at the bursar's office or the registrar's office, perhaps zigzagging across campus to see your adviser or an instructor as well. Some schools have attempted to streamline students' Grail quests by setting up a combined office that provides "one stop shopping," but the assumption remains that the student will still have to appear in person to work his or her bureaucratic mojo.
Over time, an admirable goal would be to reduce the traffic as much as possible in the student administrative areas. This doesn't mean turning off the lights completely -- we will still need people to keep the operations running smoothly. But the staff in these offices should be as surprised to have a student show up in person to solve a problem as the staff in the power plant would be. They shouldn't expect many phone calls from desperate students either.
That is not because everything should be handled by machines. As much of business as possible should be handled by machines; more about that later. But the important thing is that administrative offices shouldn't come between the principals in the important transactions that matter in a student's life. For instance, if there is a need for special permission to get into a closed course that a student must take to graduate, then the principals are the student and an instructor, adviser, or dean, depending on the rules that the school has set up. The machine should allow the student to make the request and allow the proper official to make the decision, without other human intermediaries. Even if that decision is best handled in a face-to-face meeting between the principals, the adviser or instructor should be able to enter the decision directly and effectively into the system, rather than sending the student down to the registrar's office with a slip of paper authorizing the office to put the decision into force at a later time. Then the student should not have to wait for the decision to work its way through somebody's in-basket before going on with the next step.
One of the objections that is raised against this approach is the Principle of the Candy Jar. In many offices of registrars, bursars, and financial aid counselors, there stands a jar dispensing M&Ms or Tootsie Rolls to students. This will often be pointed to with pride. "The students like to come here. They even drop in to see us and grab some candy when they don't have a problem. In our college, human contact is highly valued. Our office is an important part of the college's relationship with the students." The principle is a good one, but it is in the wrong place.
Primary services are ones that people value for their own sake, such as getting to sit in a room with a gifted faculty member and learning about an interesting topic. Secondary services are ones that only fulfill a need that the service provider created in the first place. For instance, the desk labeled "Special Services" at the airport provides a secondary service. Having canceled your flight and thereby invalidated the ticket you hold in your hand, the airline provides you with the opportunity at the Special Services counter to get new reservations that will get you to the same destination, only later. No amount of niceness on the part of the counter agents can make this into a primary service.
There has recently been a trend toward something called "self service" on many campuses and among vendors of student information system (SIS) application software. In the light of what we've just been discussing, this is more properly called "direct service." In the direct service environment, you don't have to wait in line at a counter to have somebody else tell you what the computer says about you. On the other hand, you are not left entirely on your own in fixing the problem, as the term "self service" might imply. The student and the person representing the college, if one is required, can each perform their sides of the transaction directly on the computer. The machine lets the student iron out 99% of the obstacles without needing another person to intervene. When you do need human help, it is provided directly by the person who has the authority to resolve your issue, and the machine aids your contacting that person.
To achieve this level of direct services, you need more than
just Web pages that act as a front end to a traditional SIS application. Just
adding Web pages that let students add and drop courses or view their accounts
is not enough. Implementing the direct services environment for students
requires at least the following conditions:
As many of the rules as possible should be in the computer, instead of just
being carried around in people's
heads. If the computer is capable of handling only basic, normal conditions,
then students will be quickly shunted to a counter to handle the exceptions.
Those exceptions quickly turn into bottlenecks. This may require that some rules
be codified (perhaps for the first time) and may even suggest that some rules be
simplified or eliminated.
For example, take a look at what happens in your institution
when the enrollment limit on a class is reached. Some limits may be rigid (that
course has a lab, and there are only 25 student stations). Some may have quite
specific rules for admitting students beyond the limit (senior majors can always
get in). Others may be entirely subjective (that instructor likes to make
one-by-one decisions herself after the limit is reached). Does the system treat
all of these alike, simply flashing the message "section
closed"? Or does the system apply more
complex rules where they have been established, and take advantage of the
information the system already has about the student (checking the student's
major before applying the enrollment limit in the first place, allowing the
student into the course if majors have automatic override of limits)? And does
the system share further information with the student about her alternatives and
next steps ("this section has a strict
enrollment limit based on the class facility,"
"the waiting list is already closed,"
"limited additional seats may be
available with instructor's
authorization")? And if contact with a
person is advisable, does the system encourage and facilitate that contact? (See
the discussion below of work flow.)
The rules should be easy to put into the system and easy to change. It is
part of the basic nature of an institution of higher education to continually
refine rules and add new ones. This should not require recourse to the
programming department, or else the rules will just be implemented in somebody's
head instead of in the machine, and we will be back to where we started. The
system for establishing machine rules should be flexible, so that each local
authority (department, major, college) can have its own peculiarities and
maintain the rules itself. The system must be based on effective dates, so that
rules can cover different periods of time and the system can keep track of which
rules apply to which transactions.
In short, rules should be in the system as data, not as
programming code. As with other kinds of data, the data owner should be the data
maintainer.
The system must support true workflow. "Workflow"
has become a favorite buzzword with vendors of administrative information
systems. Perhaps that is because it is one of those self-congratulatory names:
What could sound harder than "work"?
What could sound easier than "flow"?
Whatever its marketing purposes, the term "workflow"
has a solid meaning that is relevant to direct service for students. Workflow
allows, among other things, that rules be set up to route requests for
permission and authorization automatically to the right person. Then it allows
the permissions to be sent back through the system and to take effect
automatically.
A real workflow system includes a notification tree that is represented in the system as data and can be changed easily, as well as a way to track where work has stalled in the flow and reroute it after a waiting period has passed. For the direct service model, it is key that even the student be able to track a task through the workflow system. Otherwise, students will be frustrated about requests disappearing into a black hole. Few systems have rich workflow environments implemented today, although several vendors are working hard at improving the features they call by that name. It is also important to recognize that administering a workflow system is a job in itself, and at some universities is actually assigned to a whole new office.
In the cartoon strip "For Better or For Worse," Anthony recently signed on to help out his friend Gordy at Gordy's gas station. Comically, Anthony gets involved in upgrading the files on Gordy's ancient computer with a new database, while Gordy ends up still pumping the gas. I'm not sure this was Lynn Johnston's point, but didn't Anthony make a mistake that we in higher education can ponder? Anthony quite naturally gravitated toward the "back room" at the gas station to make his contribution. Maybe he should have paid more attention to the customer service side of the business, and encouraged Gordy to put in those new gas pumps where you can use your credit card. Then Gordy wouldn't be pumping so much gas either, and he might find that's the way the customers prefer it. JS
John Savarese is a consultant with Edutech International.
The Edutech Report is a monthly publication of Magna Publications
The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President: William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.