Microsoft Office 365 (O365) is a robust online system that, among other things, provides access to email and calendar services and gives end users the ability to synchronize data on their mobile devices. Supporting O365 is no easy task, especially in a university setting with a diverse audience of end users. But the University of New Mexico Information Technologies (UNM IT) is doing just that—and achieving exceptionally high first contact resolution rates, as well as huge growth in the use of our online knowledge base. How? By getting back to basics.
Background
In January 2011, UNM IT, in collaboration with the UNM community, made the decision to move from Communigate, a simple web-based email system, to O365. We decided to perform the email migration in phases, instead of using a “big bang” approach to migrate everyone all at once. The first phase of the O365 migration focused on the calendar, email, and mobile-device synchronization components, and was only for faculty, students, and retirees. The staff transition was scheduled for a future phase.
This initiative marked a significant expansion of the university’s communication service, and getting the service desk team involved early on proved to one of the keys to the success of the transition.
Testing and Development
The first step in developing a support model for O365, which was branded Lobomail, after UNM’s mascot, was to obtain test accounts for the service desk agents. The technical lead provided us with twenty accounts to start the early testing and initial knowledge development. Approximately one month prior to go-live, the agents’ production email accounts were migrated to the new system for alpha testing. This testing period ensured that the service desk agents were completely immersed in LoboMail, which increased their expertise in the new system and ensured thorough knowledge testing and development.
Two weeks later, we began beta testing. A group of end users volunteered to pilot the new LoboMail system. Their existing accounts were migrated to LoboMail and they were able to pilot all aspects of the new system, including support and knowledge articles.
Knowledge Creation and Development
The first step in creating new knowledge articles for LoboMail began with a review of the existing articles for the old email system. Using our own experience with the system and support expertise, as well as knowledge metrics like number of hits and user rating, we reviewed the content and identified knowledge articles that we felt could be carried over to the new system.
Once specific FAQs were identified, the service desk took a first pass at developing the answer content. We used our ITSM tool to route articles to technical subject matter experts (SMEs) for content review and approval; the SMEs then routed the articles back to the service desk for publishing in the knowledge base. Using this process, we were able to publish 66 percent of our knowledge prior to the start of alpha testing.
During alpha-testing phase, agents actively engaged knowledge management—using, flagging, fixing, and adding content (UFFA)—and identified the key triage documentation the service desk would reference when supporting end users. Our beta and pilot testers completed the same UFFA exercise, and as a result, 90 percent of knowledge articles (out of ninety-five, total) were published before go-live.
One thing that was particularly critical to our long-term success was avoiding duplication. We made temporary information regarding the LoboMail project available at the project website, lobomailinfo.unm.edu. Any information that was required after go-live would be published in the enterprise knowledge base, ensuring that content could be kept on a review cycle and made available to users long after the project was complete. Other published information, like marketing ads, referred end users to the knowledge base and project site.
Defining Support Boundaries
One of the most important, exciting, and challenging opportunities was setting and communicating realistic and sustainable customer expectations around support. We didn’t have the resources or environment to successfully support all of the features of LoboMail. In order to provide excellent customer service, we had to focus on supporting only basic functionality. The key to our success in this was effective communication; we clearly documented our support boundaries in the knowledge base, and referred end users to the UNM Business Policy as appropriate.
One of the boundaries we set related to forwarding email out of LoboMail to a third-party email provider. The knowledge article states:
The University of New Mexico does not support students forwarding their email outside LoboMail. UNM Business Policy 2540 states: “Students who choose to have their email forwarded to a private (unofficial) email address outside the official University net ID/email address (@unm.edu) do so at their own risk. The University is not responsible for any difficulties that may occur with privacy or security, in the proper or timely transmission, or in accessing email forwarded to any unofficial email address.”
LoboMail does not prevent students from setting up a rule forwarding UNM email to an external email system. However, in alignment with UNM Business Policy 2540, UNM IT does not offer customer support for this functionality.
We also set boundaries around connecting to LoboMail from a client and/or mobile device. We clearly stated that we would only provide support for Outlook clients and for mobile connections made using ActiveSync. While some end users weren’t happy, they understood and respected the boundaries, which have enabled us
to provide an optimal level of support.
Defining the Support Process
Another important task was defining the support process. Our process entailed searching the knowledge base and project site, logging all issues and questions in the ITSM tool, engaging in UFFA to create and refine our knowledge articles, and setting realistic customer expectations with regard to our support boundaries. This was obviously important for the service desk, but it was also important for the other IT staff who were supporting end users in the new system. We knew that all IT staff would be asked about LoboMail, whether or not they worked on the service desk, and it was important that every one of them followed the same process to ensure a consistent experience.
Something new that we tried for the first time was the creation of a tier 2 support team inside the service desk. This tier 2 role is a high-level student staff position, and it’s been critical in helping us improve our knowledge and achieve our high FCR rate.
Communications
The final piece of preparation before go-live involved developing user communications. To ensure consistency and help us maintain our customer focus in user communications, customer support approval was required on all communications. We established the following guiding principles:
- Keep it as short as possible, and include only information relevant to the customer group you’re targeting. Remember, it’s not about what IT wants to communicate; it’s about what customers want and need to know.
- Put the most important information at the top. Most customers won’t scroll down to read the entire email.
- Provide links to additional information, but only link to official and secure sites.
- Refer customers to established support channels and knowledge sources.
- Use bullet points and white space to bring attention to key items.
Go-Live
Go-live began two weeks before the start of the semester, and we used a phased rollout to avoid high-volume business cycles, level out the support load, and ensure that we had sufficient resources available to meet customer demands. We migrated approximately 10,000 students each day (≈ 39,000 total), and we made the migrations in the early morning so that customer support would be open and available by the beginning of the school day.
During the first week of go-live, the service desk received 531 requests for LoboMail support, with an FCR of 89 percent. There were 18,139 hits on LoboMail knowledge articles. In the first four weeks, the service desk received 1,135 requests for LoboMail support, resolved 92 percent at the service desk, and saw 34,222 hits on LoboMail knowledge articles.
More importantly, we delivered real value to both our end users and the technical team. Our end users experienced faster and more accurate resolutions, increased support availability (with knowledge articles available 24×7), and new features and functionality that were fully and consistently supported by the service desk. The technical teams benefitted from having to dedicate fewer technical resources to support activities (especially repetitive questions or issues), being interrupted less frequently, and being able to identify trends and issues earlier. As just one example, the service desk was able to provide feedback and metrics that justified an emergency change to the login process, which the technical team was able to execute because they weren’t being pulled away by end-user support requests.
Lessons Learned
Our implementation was a great success, and we learned some valuable lessons for future implementations:
- A true pilot includes knowledge and support.
- Define and communicate service and end-user requirements first. These requirements will inform your support boundaries and the associated knowledge.
- Define support levels and map service functionality, support boundaries, and end-user requirements to support levels.
- Make sure you have technical resources (SMEs) available for knowledge review, feedback, and creation.
- Get the desktop support team involved before go-live and after, as a tier 3 support provider.
- Get the service desk involved early, before other test groups.
* * * * *
There was no “silver bullet” that made our Office 365 migration a success. It was just good old-fashioned support processes and tools that have been around for a long time. This project gave us the opportunity to take those tools down off the shelf, polish them up, and sharpen them for a modern-day support model.
Tammy Jo (TJ) Martinez is currently the director of customer support at the University of New Mexico, where she’s committed to showing the value of the service desk as the face of IT. TJ serves as the executive sponsor of the UNM IT Agreements Committee and has led the group to creating several campus-wide service level agreements. TJ also directs the Workstation Management team at UNM IT and has successfully stood up a Managed Workstation fee for service.
Andrea Rodgers is the service desk and incident manager for the University of New Mexico. She has more than nine years of practical experience in service desk management, knowledge management, leadership, customer service, and ITIL. Andrea has been an HDI member since 2005, and her passion for continuous self-improvement has led her to earn an MBA and several ITIL Intermediate certifications.