SUBSCRIBE NOW!

Vol. 32 No. 2 — March 2012

Things That Motivated Us

Initially, Help Central was designed to address the inadequacies in the library’s old, static HTML web-based support system, including haphazard issue reporting by staff and tracking these issues and their solutions. The old request form provided only limited fields for defining the request (name, email, and comments). Further, the web-based support system lacked intelligent workflow design. Upon form submission, the data was packaged as an email and distributed to the same personnel regardless of the issue or need. The web-based support system also lacked sufficient issue tracking and reporting capabilities since data resided within email messages in Outlook. There was no central repository where requestors could monitor the status of their requests, and conversely, there was nowhere for the support personnel to compile their progress and work toward a solution. Also, there was no way to obtain meaningful statistics without a very laborious manual process (copying email data to a spreadsheet).

Reporting any other issues not related to the website system was, at best, done haphazardly through email. Sometimes it went to the right person, but if not, the person who received the email had to track down the sender or try to figure out who should have received the email in an effort to get it routed appropriately. This was inefficient and frustrating, and it delayed resolving the issue. Sometimes a single issue was reported separately to two different people who would then work on the issue independently. Further, our small systems staff was having a hard time keeping things organized in email. Issues were getting lost amid all the rest of the email we receive.

Since there was no real process or procedure in place for reporting issues, there was also no way to track progress or the solutions. Repeated issues with a certain vendor or application were often missed because no one was reviewing the issues reported and because they simply were not being collected. There was no one place to go and review issues. Further, when a solution was discovered, there was no method for systematically recording the solution. Even if an individual kept a cheat sheet or notes, others had no way of benefiting from this information unless they knew to ask for it. If the problem reoccurred, the solution would often have to be “rediscovered.”

While none of these problems caused library services to come to a screeching halt, we knew we could do better, and we believed SharePoint held the solution for us. SharePoint is great for developing dynamic lists and forms quickly, attaching intelligent workflows to them, and integrating list data with other products for analysis and reporting. The migration of the library’s website to Joomla! provided an excellent opportunity to implement a new, user- and management-oriented solution to our web-based support needs.

From Static Forms to Workflow Trackers

We migrated the static HTML form into an enhanced form that would compile the data entered. We wanted to keep the form as simple as possible for end users while giving them a place to organize, document, and track their work. We also wanted to give users the ability to generate reports. What we ended up with was the Service Request Form shown here:

The service request form only has two required fields: subject and request type. The subject (or title field) is required by SharePoint. We use it to generate a subject line in outgoing emails, which are generated by workflows and are automatically routed to both the requestor and the assignee(s). The request type field determines who is assigned to (and receives) the request. For example, if the head of reference fills out a request and chooses ILLiad as the request type, then the systems librarian and the information systems specialist are both assigned to the request;if remote access is chosen as the request type, then the systems librarian and serials librarian receive the request. Having multiple people assigned to any given request also ensures that someone gets the issue if other members of the request type group are away from the office. As a fail-safe, there is a management group, which also receives copies of all emails submitted by the request form.

This functionality eliminated the need for staff to have to figure out to whom to report which problems; they simply needed to know what kind of problem they were experiencing. Initially, we included under request type only those areas that were the direct responsibility of the systems department, such as the website, ILLiad, ILS (HIP/Horizon), SharePoint, and WordPress. We also included “other” as a request type to serve as a catchall for anything that did not fit the other categories; systems staff would route those requests to the appropriate people. As Help Central grew, other request types and library staff were added to the system. For instance, we divided the library website into four request types (News, Database Page, FAQ Page, and Joomla!) and used workflows so that each of those requests gets assigned to the people responsible for those areas. We also added a request type for “resource issues,” which is intentionally broad and vague and goes to the most people. This request type is for any problem involving library resources, such as ejournals, ebooks, and databases. This request type includes the most people because it can sometimes be difficult to tell if the issue is with the database, with a specific journal, with an ebook, or with a website. All the requestor has to know is that there is an issue with a resource, while the five people who received the request know who handles each type of issue.

SharePoint workflows automatically notify the requestor and the assignee(s) when a service request is submitted and then again when the service request is closed. The notifications are sent via email messages with the subject line “Help Central: [Subject originally entered].”

Since all emails from Help Central come from a single email address and all have the words “Help Central” at the beginning of the subject line, it is easy to create Outlook rules for them too.

Once created in Help Central, the request is in a central place where both the requestor and assignee(s) can track the service request via specialized dashboards with dynamic views for both requestor and assignee(s). At this point, the request can be edited to include much more information about the issue.

Tracking, Monitoring, and Reporting

Keep in mind that in SharePoint, views and reports can be created from any of the fields. “Task status,” for instance, is a very useful field for monitoring purposes. We started with just three status indicators, but now, we have seven: Not Started (default), In Progress, Completed, Deferred, Watching, Waiting on Someone Else, and Cancelled. Users can view all service requests and then filter the list so only the jobs in progress are displayed.

For those staffers assigned to work on multiple request types, sorting by request type and then by task status is extremely useful. Sorting by assignee is also a great tool for supervisors.

SharePoint’s reporting capabilities really shine through in Help Central. The data gathered through the service request form can be tabulated in a variety of ways. Data can be tied to Excel, providing up-to-date information at any point. Pivot lists and charts, which are excellent for annual reports, can be dynamically created that show, by date, how many requests were completed by requestor, assignee, request type, etc. These spreadsheets also serve as a useful backup. Data can also be linked to an Access database, which provides even more powerful reporting capabilities. For example, an SQL query can be written to update statements, which can join multiple lists or update several items at once. Web parts that show average resolution time, status, and priority can be developed in SharePoint Designer. This functionally really shows where staff time is being spent and can dramatically illustrate if something is maybe more trouble than it is worth. If there was no other benefit from Help Central, the data compilation alone would be worth using the form.

Sorting Our Recurring Problems and Continuously Improving

Another aspect to Help Central that has been very useful for systems staff is the ability to automatically populate a knowledgebase with service request data. In the ILLiad example given earlier, the check box to include this service request in the knowledgebase is selected, which automatically includes the service request in Help Central’s knowledgebase. This is excellent for specific errors. Every so often, for example, staff using the ILS client get the error message, “Program is using more memory than specified.” That error is entered into the comments field of a service request and marked for the knowledgebase so the error and the solution can be searched for if it arises again. While all of Help Central is searchable,a custom search scope was developed; the scope uses the knowledgebase field as filtering criteria to provide staff with refined and relevant search results. As the site grows, it becomes much more efficient to mark certain items, such as issues that most certainly will happen again or for things that happen once a year, and to use search refinements for the knowledgebase.

Help Central is still a work in progress. For instance, one area for improvement is workflow-driven notification of updates to tickets. SharePoint has an “Alert me” notification feature, which provides practically any SharePoint content with a variety of notification options; however, at the moment, this feature must be set manually. The requestor could s­ et an alert for his or her requests, but this functionality has to be set manually. Presently, requestors must log in to SharePoint to check on the status of their service requests, but in the meantime, SharePoint lists and views can be sorted by any of the fields on the form, including modified date, so people can at least see what has recently been updated.

We have recently implemented three improvements to Help Central. First, we added a new field (requestor) that allows users to create requests on behalf of others, inserting the third party into the workflow while removing the initial request creator from the workflow. Until recently, if someone called to report a problem because he or she could not get to a computer to enter it, anyone could enter the service request; however, the service request would be in the name of the person who entered it into the system, not the actual requestor. This meant the real requestor, who actually knew the issue background, would not get the emails or see the service in the “My Active Service Requests” portion of Help Central. If the requestor field is left blank, then the person logged in becomes the requestor.

The second improvement recently made to the site was designed to include others on requests. To accomplish this, we added a new field (request copy) that allows the requestor to add additional names to the request. The underlying workflow and supporting web parts add these people to the notification schedule as well as to the individual request queues. This improvement gives people the option of adding someone, such as a supervisor, who they think might want or need to know about the issue.

The third improvement was designed to supplement the assignment of tasks. To do this, we added a new list (Service rep assignments) that includes the request type and people-picker fields. For each request type, we supplied the names of individuals associated with the task. Through the underlying workflow of the service request list, we fill the assigned-to field of the service request list with values supplied from the people-picker field of the service rep assignments list. The advantage of using a secondary list for task assignments is efficiency. Prior to this change, we had to open the workflow in SharePoint Designer and manually add or remove user email addresses, which are associated with particular request type variables. Now, the request type variables read the service rep assignments’ people-picker field values. So we simply add or remove users from the secondary list as needed and never have to open the workflow to make these changes.

Where Do We Go From Here

Overall, implementing Help Central in SharePoint has been successful on multiple fronts. For the systems staff, having everything in a central location has definitely increased efficiency and accuracy in dealing with the variety of requests. Having a knowledgebase to search for service requests has saved time and decreased frustration. Supervisors can easily log in to Help Central, get an overview of the issues their departments are working on, and scan for trends, both positive and negative. Those who are assigned to work on service requests can track their requests and generate nifty color graphs for individual evaluations and effort reporting.

The challenges, however, are still the same. The learning curve for SharePoint is not something that should be taken lightly. It is an investment. SharePoint jargon alone is overwhelming, and the changes to SharePoint 2010 are enough to make one using SharePoint 2007 both weep and rejoice. With that said, it has been well worth the effort for us. Since the university has a site license, tagging along on SharePoint has been a good investment, and SharePoint 2010 does make a number of improvements to the system. If you have not implemented SharePoint and your institution is still using SharePoint 2007, just wait for 2010. Learning the new version, not the old, is definitely the way to go. But do give it a chance; it does have a lot to offer.