Spectrum Health is a not-for-profit health system based in West Michigan, offering a full continuum of care through the Spectrum Health Hospital Group, the Spectrum Health Medical Group, and Priority Health, a health plan provider. The system is comprised of twelve hospitals, 180 ambulatory and service sites, 1,300 physicians and advanced practice providers, and more than 600,000 health plan members. Spectrum Health serves the health of our community with 23,000 employees. In support of a large user base that provides direct patient care, the twenty-seven members of the IS Help Desk team processed 149,756 calls, 35,517 emails, and 17,916 self-service tickets in 2015.

What was the situation before the launch of the knowledge management initiative?

As part of our continuous improvement initiative, we took a long, hard look at our help desk. Our help desk team was known for making a lot of mistakes, and the help desk’s leadership team was struggling to understand why the team’s error rate was so high. In observing the help desk team in action, we found that, in many cases, the errors could be traced to out-of-date, difficult to parse knowledge documentation. It was clear that our approach to knowledge management wasn’t working.

  • Our knowledge documents (known as triage documents) were incredibly long—some up to twenty pages long! This meant that our team had to not only search for the document but also scan that (potentially long) document quickly it to find an answer. Because the triage documents were hard to use and unreliable, staff would rely on their memories instead.
  • The teams that owned documents were ignoring update reminders, which resulted in out-of-date documentation. When we did receive updates, it would take days, sometimes weeks to make adjustments.
  • Our second-level help desk team was being used incorrectly—it had become a dumping ground for tickets from the help desk and third-level technical teams.
  • We had a self-service portal, but no one used it because it was too difficult to navigate. Also, it offered little in the way of customer-facing documentation (just eight customer-facing triage documents against 640 internal triage documents)

During the discovery process, it became clear that creating an environment that was rich in knowledge documentation was the key. We wanted to not only increase the number of issues that could be resolved by the help desk but also increase the number of issues our customers could resolve themselves.

What was the knowledge management strategy?

Around the same time as our early investigations, our help desk manager was introduced to Knowledge-Centered Support (KCS). After some consideration, we decided to implement KCS as our knowledge management methodology. Per KCS, the most effective way to go about implementing it is to start with a small group; we decided to start with the help desk and then, once the processes and tools were well established, roll it out to other teams. Our strategy had six key steps:

  1. Start with the basics: First, certify the Knowledge Management and Quality Assurance team (formerly the second-level help desk) in KCS, and then draft processes and procedures that align with KCS.
  2. Find a tool that supports the process: Search for a KCS-certified knowledge tool that will enable us to stick as close to the KCS methodology as possible.
  3. Implement KCS and the new tool within the help desk: Start small, with the help desk, and work out all the kinks; then bring other teams into the fold.
  4. Audit and validate existing documentation as part of the migration: If we simply moved the documentation without reviewing it, all we’d have had was bad documentation in a better tool.
  5. Introduce the IS department to the new knowledge base and KCS
  6. Introduce our customers to our knowledge base and self-service

Which processes and tools had to be implemented, modified, or leveraged to support the knowledge management strategy?


Our knowledge management process had to be completely overhauled. Before implementing KCS, only a select few on the help desk had the power to upload, edit, or retire triage documents, and we relied on other teams to submit updated documentation in response to automated prompts (generated every six to twelve months). However, no one was accountable for making sure the documentation was actually updated. When we implemented KCS, we started by defining the new documentation templates and introducing the concept of multiple roles in knowledge management. We also updated our onboarding and training process to include knowledge management, and built out a governance process through which the Knowledge Management and Quality Assurance team monitors the effectiveness of the training program and the quality of the documentation. This team also sits on the knowledge council, which meets quarterly.


  • CA Service Desk and RightAnswers: Our original knowledge base was contained within our CA Service Desk tool. We had to remove the documents from that system and create a single document that pointed anyone looking there to the new knowledge base. We redesigned the self-service portal of our ticketing system, changing the way we routed tickets and embedding our new knowledge base, RightAnswers, to improve the self-service offering.
  • Lectora: Lectora is the learning management system we use to create the training modules in our electronic training portal, SHLI.
  • Spectrum Health Learning Institute (SHLI): Prior to this project, in-house help desk training was exclusively instructor-led. As part of the larger KCS implementation, we created a self-paced online training program that could be delivered and tracked in our training portal.
  • Intranet: We leveraged our intranet to answer questions and post information related to the new knowledge management processes.

What organizational changes (cultural, structural, or political) had to be implemented or modified to support the knowledge management strategy?

The biggest organizational change we made was evolving the second-level help desk team into the Knowledge Management and Quality Assurance team. They went from owning no processes or tools to owning the entire knowledge management process and knowledge base. Every team member is now responsible for UFFA, where previously they weren’t even able to contribute to the knowledge base directly. Another shift came when we asked each IS team to volunteer a team member to be their team’s knowledge management point person, tasked with creating knowledge and moving through the KCS Competency model.

Knowledge is now viewed as a necessary resource instead of an afterthought. Everyone owns the knowledge, and if they have an issue with a triage document, it is up to them to fix it.

How did your organization define success for this initiative?

  • Helping our customers help themselves: In healthcare, every moment matters. Our strongest driver for delivering KCS to our organization was to make information easy to find and digest. We wanted our customers to be able to help themselves, and we wanted to make it simple, ensuring they weren’t wasting time on hold or searching endlessly for a solution they’d never find.
  • Presenting our help desk as a provider of valued information: Help desks are often seen as a necessary evil. Our help desk wanted to give the organization more: they wanted to add value to the organization beyond just answering calls; they wanted to be the one-stop-shop where all issues could be resolved and all questions answered. This was critical to the morale and engagement of our team members.
  • Reducing tickets for our third-level teams: Healthcare moves fast, and we have to be able to keep up with the demands of a rapidly changing industry. It was quite hard to do that when our engineers and high-value talent were spending their time resolving incident tickets. Ticket reduction was an important success factor: if our customers and the help desk could resolve more issues, the third-level teams could concentrate their efforts on improving the organization.
  • Positioning IS for success in other key initiatives: The implementation of KCS in our organization positions our department well for other key initiatives, such as centralized knowledge management and problem management. Our knowledge base is already being used as a communication tool, and we hope to use it for future project go-lives.
  • Foster a culture of knowledge sharing: Tribal knowledge benefits no one. Rather, it creates a single point of failure within an organization. By fostering a knowledge-sharing culture, we’ve dedicated our organization to getting the right answers to the right people when they need it, not a moment later.
  • Reducing frustration by having up-to-date information: An outdated knowledge base frustrates the help desk and customers alike. has outdated information it not only causes frustration for our Help Desk staff, but also for our customers. Delays in issue resolution are tied directly to inaccurate or missing information. Tickets would get punted from team to team until it landed with the correct individual for resolution. In many cases these issues are time sensitive, so it is unacceptable for us to rely on information that is incorrect.

What were some of the lessons learned?

We learned that when designing a new tool for your customers, you must involve your customers. When it came to creating our new self-service page, we went through many Gemba (that is, going to where the work is done) sessions where we presented multiple options and asked users try to navigate the page. Their feedback enabled us to create a page that we knew our customers would like.

We also learned about the value of word of mouth. Looking at other KCS implementations, we knew that users would reject a half-baked tool or process. We took the opposite approach and it worked wonderfully. By implementing KCS in the help desk first, we worked out all the bugs before rolling it out to the organization. Because we took this approach, we didn’t have to push KCS on the organization. Through word of mouth, they heard about the great things we were achieving with knowledge management and they wanted to get involved. These teams saw the value and were ultimately more committed and dedicated. Forcing a new initiative on people isn’t nearly as effective of engaging them in the rollout.

Finally, we learned the value of patience. We were very aggressive with our timelines initially, but this type of project takes time. We thought our KCS implementation would move much faster, but we missed every single one of our deadlines. When changing culture like this, you must give your organization enough time to change course.