This week, we return to our exploration of the SharePoint intranet I built to support NBC Olympics during the broadcast of the XXX Summer Olympics in London. (See "SharePoint Intranet: How We Did It, Part 1, 2, 3, 4, 5.") Because of my background not only with SharePoint, but with the core Microsoft server, client, identity, and administration technologies, I’ve found myself helping several customers build self-help portals for users. The goals of such portals are to reduce help desk calls, increase responsiveness and availability of help to users, and increase the visibility of solutions provided by the IT organization to its business customers.
In London, we built a very simple end-user-facing Help Desk site on SharePoint Server 2010. This week, I’ll share with you three of the crazy-easy big wins we supported with that Help Desk site.
Before we do, let me send you greetings from 38,000 feet! Conference season has begun, and today marks the first of about 10 weeks of travel between now and Christmas. I’m en route to the SharePoint Leadership Forum in Washington, DC on Thursday where I will be delivering a keynote that uses lessons learned from NBC Olympics to (I hope) challenge and inspire delegates to take the next steps forward on their SharePoint journeys.
Coincidentally, the SharePoint Leadership Forum is being held at the Swedish Embassy, and immediately after it, I hop on a plane towards Stockholm for the SharePoint & Exchange Forum, which will be held on Monday and Tuesday.
And, for those of you who were disconnected from the technology universe over the last week, Office 2013, SharePoint 2013, Lync 2013, and Exchange 2013 all RTM’d on Thursday. Bits are out in the wild here and there, but for us mere mortals, we’re being told to wait until “mid November” before we can download them from TechNet, MSDN, and the like—timing that coincides nicely with the SharePoint Conference.
So now, back to today’s topic: three easy wins for a Help Desk site on SharePoint.
SharePoint Help Desk Site
As I’ve described in previous articles, our environment is one that is built in a matter of days, and it must support more than 3,000 users. Many of those users bring with them laptops from their jobs in other parts of NBC, but we also deploy close to a thousand desktops and laptops that are used only during the Games, for contractors.
During the “tsunami,” as we call it, of users arriving at the International Broadcast Centre, there are charter jumbo jets dropping literally hundreds off at a time. These users must get immediately to work, so we need to ensure that there is minimal friction between the technology and the user’s business requirements. And the most critical things we need to provide them are network connectivity, applications, and printers. So, we wanted to empower users to self-serve these IT offerings.
We created the Help Desk site as a site collection in our “apps” app (http://olyapps), and we linked to each of the major components of the site from the primary, global navigation from the intranet home page, seen in Figure 1 below.
We offered self-service printer installation for users in three broad geographic areas: the International Broadcast Centre and venues in London, our field shop and hotels, and our operations in New York City. Each of those links took users to a page in a pages library. On the page, we inserted a page viewer web part. You can see the result in Figure 2 below.
Typically, a page viewer web part displays another web site in an IFRAME. For our printer installation, we configured the page viewer web part to show a file, and the address we configured was the UNC address of the server itself, e.g. \\servername. That address shows all shares on a server, and because our servers were dedicated print servers, and were not also hosting shared folders, the result was a super-easy-to-configure view of printers. Users simply double-clicked the printer they needed. Windows does not require elevated credentials to install a shared printer.
It was easy for users to identify the “correct” printer because, first, the naming standard we had in place for printer share names made sense and, second, because each printer had a label on it with its share name, so users could simply glance at the printer they wanted, then find the same name on the SharePoint site. Double-click. Done.
We also created a central location from which users could self-serve the installation of applications. We provided instructions, a link to the application installation package, and information about any permissions necessary—for example, application-specific permissions to back-end data sources. Figure 3 shows an example.
Network Connectivity and FAQ
Finally, we created an FAQ and trained the Help Desk staff to post content whenever they had the same questions more than a couple of times. One of the most common questions regarded internet connectivity, which required a proxy setting. We estimate that several hundred people self-served their own solution for proxy configuration with this simple FAQ, shown in Figure 4.
With these and other very simple solutions, we provided value to our customers, we demonstrated our commitment to helping them—to trusting them to solve their own problems given the right information, we reduced our workload and costs, and made it possible to administer a dynamic, large enterprise with an insanely lean IT staff. None of these are rocket science. What it boiled down to was listening to and anticipating what our customers wanted.
The Help Desk functionality also introduced users to our SharePoint based intranet. Basically, the first question most users would have was, “How can I connect to the internet to get my [external] email?” By pointing them to the resource, they were encultrated into our value proposition of the intranet as the one-stop shop for everything they need to get their job done.
Helping Users Help Themselves
That’s how we helped our users. Next week we’ll look at how we helped ourselves—the IT staff itself—with our internal IT administration and support site.